NDR против EDR и SIEM: различия через риски и деньги

С чего начинается путаница: «нам нужен NDR»

Фраза «нам нужен NDR» обычно появляется не потому, что компания точно выбрала класс решения. Чаще где-то болит, а разговор сразу уходит в названия продуктов и модные аббревиатуры. В итоге спорят о том, чем NDR лучше EDR или SIEM, но не отвечают на главный вопрос: какой риск уменьшаем и сколько это стоит.

За таким запросом почти всегда стоят приземленные бизнес-страхи: простой ключевого сервиса, штрафы за инцидент, утечка данных клиентов или внутренней информации, срыв проектов из-за остановки инфраструктуры. Финансовый директор часто формулирует это так: «Сколько нам будет стоить один день простоя и как быстро мы это заметим?» Это уже разговор не про инструмент, а про риск и время.

Объяснять кибербезопасность в терминах риска значит привязать технические события к последствиям: вероятность инцидента, масштаб ущерба, время обнаружения, время восстановления, а также кто и как принимает решения в моменте. Когда это ясно, выбор между классами решений становится проще.

Полезно заранее зафиксировать, что именно вы хотите измерять и улучшить:

• время обнаружения подозрительной активности в сети и на узлах
• долю инцидентов, которые доходят до влияния на бизнес (простои, утечки)
• нагрузку на команду: сколько сигналов реально разбирают, а сколько игнорируют
• стоимость владения: лицензии, хранение данных, работа людей, услуги внедрения
• покрытие: какие сегменты сети и типы трафика вообще видны

Когда эти цели сформулированы, вы сможете требовать на пилоте конкретные метрики и заранее задать вопросы, чтобы пилот не превратился в историю «поставили датчик, получили шум, ничего не поняли».

Коротко и по делу: что делают EDR, SIEM и NDR

Если говорить простыми словами, это три разные «точки наблюдения» за одной и той же атакой. Они дополняют друг друга, но редко взаимозаменяемы.

Что именно делает каждый класс

EDR смотрит на конечные устройства: ноутбуки, серверы, виртуальные машины. Он видит процессы и файлы, попытки запуска вредоносного кода и умеет быстро реагировать на хосте.

SIEM собирает события из разных источников: AD, почта, VPN, межсетевые экраны, приложения, EDR. Дальше помогает связывать события между собой, вести расследования и готовить отчетность для контроля и аудита.

NDR наблюдает за сетью: кто с кем общается, какие протоколы и поведение появляются в трафике. Он полезен там, где «на хосте тихо», но в сети уже видно подозрительное движение.

Если нужна шпаргалка, то она такая:

• EDR - что происходит внутри устройства и быстрая реакция на нем
• SIEM - единая картина по логам, корреляция и расследования
• NDR - аномалии и поведение в сетевом трафике, особенно внутри периметра

Где границы и слепые зоны

EDR слабее там, где вы не можете поставить агент: часть IoT, принтеры, сетевое оборудование, некоторые медицинские устройства. SIEM зависит от качества логов: если источник не пишет нужные события или их «съедает» фильтрация, расследование упрется в пробелы. NDR, в свою очередь, хуже видит то, что полностью спрятано в шифровании без дополнительных методов, и не заменяет контроль того, что происходит внутри процесса на хосте.

Пример: злоумышленник получил доступ к одному серверу и начал тихо сканировать соседние подсети. EDR может не поднять тревогу, если на хосте нет явного вредоносного процесса. SIEM заметит это только при наличии нужных сетевых логов и настроенных правил. NDR чаще увидит нетипичный внутренний скан и странные подключения между сегментами, даже если сами устройства настроены по-разному.

Какие риски закрывает сеть, а какие - конечные точки и логи

Вместо спора о названиях полезнее разложить инструменты по рискам: что именно может остановить бизнес, привести к утечке или штрафу.

EDR сильнее всего там, где важны конкретные устройства: ноутбук бухгалтера, сервер 1С, рабочая станция инженера. Если шифровальщик попал на конечную точку, EDR может заметить подозрительные процессы, заблокировать запуск и изолировать хост. Это напрямую снижает риск простоя, когда из-за остановки сервисов теряются деньги каждый час.

NDR смотрит на сеть как на «дороги» между системами. Он особенно полезен, когда атака идет через боковое перемещение, удаленный доступ подрядчика, странные подключения к внутренним сервисам или тихую передачу данных наружу. Это снижает риск утечки (клиентские данные, коммерческая тайна) и риск цепочки поставок, когда проблема появляется не у вас, а у партнера.

SIEM больше про доказательства и управляемость: он собирает логи, помогает разбирать инциденты, показывать аудитору, что контроль есть, и быстрее закрывать требования регуляторов. Но SIEM упирается в качество источников: если нужного события нет, его не «додумаешь».

На практике по слоям риска это обычно выглядит так:

• простой - EDR плюс базовые сетевые меры, а NDR помогает поймать распространение по сети
• утечка - NDR плюс SIEM (корреляция), EDR ловит часть действий на хосте
• санкции и аудит - SIEM как центр отчетности, плюс подтверждение действий EDR/NDR
• цепочка поставок - NDR для контроля удаленных сессий и необычных сетевых маршрутов

Пример: подрядчик подключился по удаленному доступу, его учетку украли. EDR может ничего не увидеть, если злоумышленник работает «тихо» легитимными инструментами. SIEM увидит вход, если лог дошел и правило настроено. NDR покажет, что после входа начались нетипичные запросы к файловым шарам и передача данных на внешний адрес, и даст повод реагировать до утечки.

Как перевести разницу в деньги: из чего складывается бюджет

Спорят обычно про функции, а в бюджете важнее другое: за что вы платите один раз, а за что будете платить каждый месяц, и сколько людей нужно, чтобы система приносила пользу.

Разделите затраты на CapEx и OpEx. CapEx появляется, если нужны сенсоры, отдельные серверы под анализ трафика или дополнительное хранилище. OpEx чаще включает лицензии (по объему трафика, числу узлов или событий), поддержку и подписки на обновления.

Обычно бюджет состоит из пяти понятных частей: лицензии и поддержка; инфраструктура (сенсоры/зеркалирование, вычисления, хранение); внедрение (проектирование, настройка, интеграции, тестирование); эксплуатация (обновления, контроль качества детектов, обучение); и время аналитиков на первичную проверку и расследования.

Самая недооцененная часть - стоимость владения через рабочее время. Если NDR добавляет 30 алертов в день, а на первичную проверку уходит 10 минут, это 5 часов в день только на первичный разбор. При стоимости часа аналитика, например, 12 000 KZT, это около 60 000 KZT в день и примерно 1,2 млн KZT в месяц (20 рабочих дней). Поэтому при сравнении решений важно спрашивать не только про «точность», но и про то, как быстро сигнал превращается в понятное действие.

Отдельно посчитайте цену ложных срабатываний. Каждый лишний алерт - это не только время SOC, но и отвлеченные админы сети, простои согласований и задержки проектов. Нормальный финансовый вопрос перед покупкой: сколько ложных тревог вы готовы оплачивать ежедневно и кто будет владельцем этого времени.

Если пилот идет в большой сети, инфраструктурные затраты тоже могут быть заметными. При размещении вычислений и хранения on-prem важно заранее понять, есть ли свободные ресурсы, или их придется закупать и обслуживать. В Казахстане это часто связано с требованиями к локальному размещению и поддержке - такие детали лучше фиксировать в смете до пилота, а не после первых недель работы.

Где NDR обычно сильнее: сценарии, которые «прячутся» от EDR и SIEM

NDR видит сеть как «дорогу», по которой ездят все устройства и сервисы. Поэтому он чаще выигрывает там, где атака живет в трафике, а не на одном конкретном ноутбуке или в аккуратно собранных логах.

Самая частая зона силы NDR - east-west трафик внутри периметра. Когда злоумышленник уже попал внутрь, он начинает искать доступы, ходить между сегментами и пробовать разные учетные данные. EDR может не стоять на сервере, а SIEM может не получать нужные события вовремя, но сеть все равно «помнит», кто с кем общался.

Типовые сценарии, где NDR дает более ранний и понятный сигнал:

• боковое перемещение: необычные подключения между подсетями, всплески SMB, попытки доступа к шарам и админским ресурсам
• слепые зоны EDR: неуправляемые устройства, IoT, принтеры, медоборудование, терминалы в филиалах
• слепые зоны SIEM: неполные логи, задержки доставки, «утопленные» в шуме события
• ранние сетевые аномалии: странные DNS-запросы, обращения к редким доменам, новые внешние связи у сервера, который обычно никуда не ходит
• нарушения сегментации: сервис вдруг начинает общаться с сегментом, с которым по правилам не должен

Простой пример: в больнице заражение начинается с рабочей станции, дальше идет поиск слабых устройств в сети. EDR поймает часть активности на ПК, SIEM увидит отдельные события, но NDR первым покажет цепочку: кто инициировал сканирование, какие узлы стали целями, где начались SMB-попытки и какие DNS-имена использовались. Для бизнеса это напрямую переводится в деньги: меньше времени на расследование и меньше шанс, что инцидент успеет разрастись.

Пошагово: как подготовиться к пилоту NDR в корпоративной сети

Пилот NDR чаще проваливается не из-за технологии, а из-за расплывчатой цели. Сформулируйте 3-5 сценариев, которые вы хотите увидеть в сети: внутреннее перемещение между серверами, неожиданные соединения к внешним адресам, сканирование портов, попытки выгрузки данных, подозрительные DNS-запросы.

Дальше выберите, где именно смотреть. Один хороший сегмент лучше пяти случайных. Обычно берут ЦОД (там критичные сервисы), один офисный участок (пользовательский трафик) и при необходимости один филиал, если там слабее контроль и больше «серых» каналов.

Заранее договоритесь, какие данные вы дадите на вход и какие ограничения считаются нормой. Иначе сравнение окажется нечестным: у одного решения есть нужный поток, у другого его нет.

Минимальный план подготовки

• Зафиксируйте цель пилота и критерии успеха: какие алерты считаем полезными и за какое время они должны превращаться в действие.
• Определите сегменты и точки подключения: что важнее для вашего случая - север-юг (интернет) или восток-запад (между серверами).
• Выберите источники: SPAN/TAP или зеркалирование, NetFlow/sFlow, журналы DNS/Proxy при наличии.
• Решите, как учитываете шифрованный трафик: без расшифровки будет видна метаинформация, но не содержимое.
• Назначьте владельцев задач: ИБ, сетевые инженеры, SOC, владельцы систем и тот, кто принимает итоговое решение.

Практическая проверка проста: если цель - поймать «тихую» утечку с бухгалтерского сервера, пилот должен включать трафик этой подсети и выход в интернет. Иначе вы проверяете не NDR, а удачу.

Если вы привлекаете интегратора, заранее уточните, кто обеспечивает доступ к SPAN/TAP, кто меняет конфигурации на коммутаторах и кто будет разбирать срабатывания вместе с вашей командой. В GSE.kz, как у системного интегратора, такие роли обычно фиксируют в плане пилота до установки, чтобы не потерять первую неделю на согласования.

Вопросы перед пилотом: охват, данные и ограничения

Пилот часто «проваливается» не потому, что продукт слабый, а потому что вы смотрите не туда или не видите нужный трафик. Если говорить языком рисков и денег, задача простая: понять, какие сегменты дадут максимальный ущерб при инциденте, и какие данные реально можно собрать без поломок и конфликтов с приватностью.

Начните с охвата: какие активы должны быть видны именно на пилоте. Если подключить только офисный VLAN, а критичные серверы оставить в тени, вы получите красивые графики и слабую пользу.

Минимальный набор вопросов по охвату

Сформулируйте их так, чтобы на выходе получилась карта «что видим/чего не видим» и почему:

• Какие сегменты обязательны: дата-центр, серверы приложений, рабочие места, Wi-Fi, удаленные пользователи, подрядчики, OT/IoT (если есть)?
• Какие зоны и потоки критичны: AD, DNS, почта, VPN, RDP/SSH администрирование, резервное копирование, обмен с внешними API?
• Где узкие места видимости: NAT, межсетевые экраны, прокси, SD-WAN, SPAN/TAP, облачные выходы?
• Какой ожидаемый объем трафика и пики, чтобы пилот не уперся в производительность?
• Какая «единица охвата» считается успехом: процент подсетей, число ключевых серверов, доля критичных потоков?

Данные, шифрование и ограничения

Шифрование почти всегда главный ограничитель. Уточните, что вы рассчитываете получить: расшифровку (TLS-инспекция) или метаданные (SNI, сертификаты, направления, частоты). Иногда метаданных достаточно, чтобы поймать командование и управление или боковое перемещение, но не всегда.

Отдельно зафиксируйте требования к хранению и приватности: какие поля считаются персональными, кто имеет доступ к сырым данным и отчетам, сколько дней хранить и кто оплачивает хранение. В сети клиники или банка доступ к сетевым данным может быть ограничен - это нормально, но тогда критерии пилота нужно корректировать заранее.

Итог этих вопросов простой: вы заранее понимаете, где NDR даст быстрый эффект, а где ожидания завышены из-за шифрования, отсутствия зеркалирования или правил доступа.

Вопросы перед пилотом: процессы, интеграция и ответственность

Если пилот устроен как «поставили датчик и ждем магии», он почти всегда разочарует. Польза появляется, когда заранее понятно, куда идут сигналы, кто принимает решения и что команда делает в первые 15-60 минут.

Начните с интеграций. Это не история про «что лучше», а про то, как NDR, EDR и SIEM дополняют друг друга в одном процессе. Уточните, будет ли NDR отправлять алерты в ваш SIEM, в систему тикетов и в рабочие каналы дежурной смены, и в каком виде: сырые события или уже обогащенные инциденты.

Дальше - ответственность. Кто делает настройку детектов, исключения и разбор ложных срабатываний: вендор, интегратор или ваша SOC-команда? И что делаете при расхождениях, когда EDR молчит, а NDR видит подозрительный трафик.

Чтобы пилот проверял управляемость, подготовьте минимальный набор действий по реагированию:

• кто может изолировать хост в EDR и за сколько минут это реально делается
• кто и где блокирует на периметре (FW, прокси, NAC) по данным из NDR
• как запускается форензика: какие артефакты собираем и кто их хранит
• как оформляется тикет и кто подтверждает закрытие инцидента

Заранее договоритесь, как измерите пользу. Зафиксируйте «до» (среднее время обнаружения, доля инцидентов без владельца, количество ручных проверок) и «после» (на сколько сократилось время, сколько инцидентов дошло до подтверждения). В конце пилота нужен короткий отчет для руководства: 3-5 находок, влияние на риски и что потребуется для промышленного режима (люди, интеграции, правила реагирования).

Если вы привлекаете внешнюю команду, сразу пропишите границы: кто отвечает за настройку интеграций, кто за сопровождение после пилота и какой уровень поддержки доступен в нерабочее время.

Частые ошибки и ловушки на пилоте NDR

Главная ловушка - поставить NDR «вслепую». Если цель звучит как «посмотрим, что найдется», вы почти гарантированно получите спор о ценности: много сигналов, мало понятного эффекта. Рабочая цель может быть простой: обнаружить боковое перемещение в офисной сети, контролировать исходящий трафик из критичных подсетей или найти неучтенные сервисы.

Вторая ошибка - подключить сразу все сегменты. Пилот превращается в шум: десятки тысяч событий, а команда не успевает разобрать даже верхушку. Лучше начать с 1-2 зон, где ущерб максимальный: серверный сегмент с учетными системами и один пользовательский VLAN, где чаще всего начинается заражение.

Третья ловушка - качество данных. При плохом зеркалировании (SPAN/TAP) или неправильно настроенном NetFlow/IPFIX NDR видит обрывки сессий, путает роли клиентов и серверов, пропускает DNS или TLS-рукопожатия. Итог - ложные выводы вроде «подозрительный объем» или «неизвестный протокол», хотя на деле просто не полностью собран трафик.

Четвертая - не договориться о реакции. Если сигналы приходят, но непонятно, кто проверяет, кто закрывает и за какое время, пилот не докажет пользу.

Перед стартом полезно зафиксировать на одной странице:

• 2-3 измеримых критерия успеха (например, найти X неуправляемых хостов или сократить время первичной проверки до Y минут)
• список сегментов пилота и что в них критично
• требования к источникам трафика и проверку полноты
• RACI: кто делает первичный разбор, кто расследует, кто блокирует
• окно работ и правила эскалации, чтобы не остановить бизнес

Пример из практики: NDR сообщает о подозрительных соединениях между двумя внутренними подсетями ночью. Если заранее нет владельца реагирования, сигнал «доживет» до утра, а реальная проблема успеет разойтись дальше по сети.

Быстрый чеклист: что проверить за 1-2 недели

Цель пилота не в том, чтобы «победить все атаки». Она проще: понять, даст ли NDR видимость там, где EDR и SIEM обычно молчат, и сколько это будет стоить в работе людей.

На коротком промежутке полезно прогнать несколько сценариев (лучше в тестовом сегменте или в согласованном окне):

• боковое перемещение: SMB/RDP/WinRM, нетипичные связи «кто с кем»
• C2 (command and control): регулярные обращения к внешним адресам с одинаковым интервалом, новые домены, странные SNI/JA3
• подозрительный DNS: всплески NXDOMAIN, запросы к DGA-похожим доменам, резкие изменения у одного хоста
• эксфильтрация: длительные исходящие сессии, нетипичные объемы, передачи в нерабочее время
• сканирование: много коротких соединений по портам, перебор подсетей, рост отказов

Чтобы пилот не превратился в спор «нравится/не нравится», зафиксируйте три метрики:

• время обнаружения: от события до алерта и до реакции
• доля полезных сигналов: сколько алертов реально ведут к проверке и находкам
• покрытие активов: какую часть сегментов и критичных систем вы действительно видите

Параллельно проверьте качество данных. Если есть потери пакетов, перегруз SPAN/TAP, расходится время на сенсоре и в логах, а NAT скрывает источники, вы получите либо шум, либо слепые зоны.

И еще один быстрый тест - операционка: кому приходит алерт (SOC, ИБ, дежурный админ), как он эскалируется, сколько времени есть на первичную проверку, и что фиксируется как результат (тикет, отметка «ложное/подтверждено», какие артефакты сохраняем). Без этого даже хороший NDR будет выглядеть «слишком шумным».

Реалистичный сценарий: один инцидент глазами NDR, EDR и SIEM

Офис, обычный рабочий день. Сотрудник открывает вложение, и через пару минут в сети появляется шифровальщик. На большинстве компьютеров стоит EDR, но один старый ПК в бухгалтерии временно заменили, и агент на него не поставили. Именно с него и началась атака.

EDR срабатывает на тех машинах, где агент есть: замечает подозрительный процесс и попытку запуска из папки пользователя. Но на «немом» ПК EDR ничего не видит - ему нечего собирать.

NDR смотрит на сеть и замечает то, что видно даже без агента. Почти сразу появляется аномальная активность по SMB: один хост начинает массово открывать файлы на файловом сервере, быстро перебирает каталоги и делает много однотипных операций. Для бизнеса это выглядит просто: «сервер с документами начал тормозить, люди не могут работать».

SIEM здесь работает как связующее звено. По логам видно, что:

• была нетипичная авторизация под учеткой сотрудника
• за короткое время изменились права на несколько папок
• пошли ошибки доступа и всплеск событий на файловом сервере
• по времени это совпало с сетевыми аномалиями, которые поднял NDR

В итоге расследование собирается быстрее: NDR показывает, где началось и куда пошло по сети, EDR дает детали по зараженным конечным точкам, SIEM подтверждает цепочку по учеткам и изменениям.

Деньги считаются просто. Если из-за шифрования файлов простой отдела длится 4-8 часов, а в это время стоят продажи, закупки или платежи, потери часто выше стоимости пилота в разы. Пилот окупается уже тем, что вы раньше увидели массовое шифрование на сервере и успели отключить зараженный хост и учетку, пока не пострадала вся сеть.

Следующие шаги после пилота: решение и план внедрения

После пилота важно быстро превратить «много алертов и впечатлений» в понятное решение. Выигрывает тот вариант, который снижает конкретные риски за понятные деньги, а не тот, где «больше функций».

Соберите одностраничное резюме для ИБ и бизнеса. На нем должны быть: 2-3 ключевых риска, которые пилот реально нашел или подтвердил; оценка ущерба, если это случится; стоимость внедрения; метрики качества (количество выявленных инцидентов, уровень ложных срабатываний, среднее время до обнаружения, реальное покрытие сегментов и хостов, что удалось передать в SIEM и встроить в реагирование).

Дальше зафиксируйте целевую архитектуру. Обычно NDR делают обязательным там, где критичны боковые перемещения и внутренний трафик: дата-центр, сегменты с серверами, финансовые системы, медицина, АСУ и другие зоны, где сбой дорогой. А там, где главное - контроль рабочих мест и расследование на хосте, часто достаточно EDR плюс дисциплина логирования в SIEM.

План внедрения без растягивания на год

• 0-30 дней: подтвердить точки установки сенсоров, доступы, источники трафика, правила хранения и роли.
• 30-60 дней: включить интеграции (SIEM, EDR, инвентарь активов), настроить базовые сценарии и пороги.
• 60-90 дней: отработать 3-5 плейбуков реагирования, измерить нагрузку на SOC, закрепить KPI.
• Далее: расширять охват по сегментам, добавлять сценарии под ваши типовые угрозы.

Параллельно посчитайте полную стоимость владения: лицензии, сенсоры и зеркалирование, хранение данных, время аналитиков, обучение, поддержка 24/7 (если требуется).

Если пилот показал ценность, но вы уперлись в сеть или ресурсы команды, имеет смысл обсудить поставку инфраструктуры и интеграцию на месте. Например, GSE.kz (gse.kz) как технологический производитель и системный интегратор в Казахстане может помочь собрать и поддерживать базовую инфраструктуру под ИБ и ЦОД, а также выстроить интеграции в вашей архитектуре, не замыкаясь на одном вендоре.