Почему AI-система NDR пропускает атаки внутри периметра
Классическая схема защиты строится вокруг периметра: трафик на входе и выходе разбирается полноценно, а всё, что происходит между внутренними сегментами, остаётся в тени. AI-система NDR, обученная преимущественно на таких данных, уверенно ловит внешние сканы и обращения к редким адресам, но теряет чувствительность там, где начинается настоящая атака.
Главная слепая зона сети — восточно-западные потоки: обмен между серверами, базами, рабочими станциями и контейнерными средами. Получив первую точку опоры, злоумышленник не идёт наружу — он осматривается и начинает боковое перемещение, а каждый такой шаг выглядит как штатный внутренний запрос. Без разбора этого трафика детекция сетевых угроз работает по остаточному принципу: сигнал формально есть, но он неотличим от нормальной активности.
Второй источник провалов — шифрование. Значительная часть внутреннего трафика закрыта, и модель, опирающаяся только на содержимое пакетов, теряет контекст. Вытягивают метаданные: длительность и объём сессий, ритм обмена, наборы адресов, поведение учётных записей — по ним аномалия читается и без расшифровки.
Третий слой — разрозненные логи. Межсетевые экраны, службы каталогов, агенты на хостах пишут каждый в своём формате и со своим временем. Пока события не сведены в единую шкалу, реакция измеряется часами: аналитик вручную сопоставляет фрагменты, а атака за это время проходит несколько этапов. Разбираем, как это закрывается.
Что даёт NDR-контур: измеримые эффекты внедрения
Отраслевые данные об инцидентах сходятся в одном: значимая доля атак вскрывается не своей командой, а внешней стороной — то есть когда ущерб уже нанесён (Verizon Data Breach Investigations Report). NDR-контур смещает именно эту точку: активность становится видна в момент, когда она происходит, а не в момент разбора последствий.
Скорость обнаружения инцидентов
Система сопоставляет метаданные сетевых потоков, журналы сетевых устройств и обращения к внешним узлам между собой, поэтому аномалия в поведении отдельного узла проявляется на этапе, когда вредитель ещё осматривается внутри периметра. Скорость обнаружения инцидентов измеряется десятками минут от первого подозрительного соединения вместо суток и недель — а это уже принципиально другой сценарий реагирования.
Устранённый класс отказов
Часть сценариев раньше не детектировалась в принципе: растянутое на недели взаимодействие с внешним узлом через разрешённые сервисы, тихая выгрузка по легитимным каналам, аномальные объёмы исходящего трафика в нерабочие часы. Поведенческие правила и модели закрывают эти сценарии — класс отказов уходит, а не остаётся в серой зоне.
Дежурная смена аналитиков и разбор инцидентов
Приоритизация по критичности снимает рутину: дежурная смена аналитиков работает с десятками подтверждённых событий вместо сотен сырых срабатываний, а разбор инцидентов идёт по готовой цепочке свидетельств с хронологией. Доля подтверждённых тревог растёт, а время на передачу инцидента в реакцию сокращается.
Режимы работы: наблюдение, реагирование или полный цикл
Режим работы определяет не функциональность системы, а глубину её вмешательства в сеть. Поэтому выбор начинают с двух вопросов: есть ли право менять конфигурацию узлов и насколько зрелы правила детекции. Пока правило не подтвердило себя на своих данных, автоматическое реагирование превращается в источник аварий.
Поэтому контур собирают поэтапно: сначала пассивное наблюдение, затем автоматические действия по узкому списку сценариев. Внедрение без остановки сервисов возможно именно в такой последовательности — анализатор подключается к зеркалу трафика и ничего не меняет в текущей топологии.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Пассивное наблюдение | Первый этап: инвентаризация трафика, обучение правил на своих данных | Только сигнал, блокировки нет; видно лишь то, что попадает в зеркало |
| Детекция с ручным разбором | Есть дежурная смена и готовые регламенты эскалации | Скорость реакции зависит от людей; ночные срабатывания ждут утра |
| Автоматическое реагирование на границе | Правила отработали, есть тестовый контур для проверки | Ложное срабатывание рвёт легитимный сервис; нужны списки исключений и откат |
| Полный цикл: детекция, реакция, проверка | Свои сервисы, управляемые узлы, разграниченные права | Нужен доступ к управляющим интерфейсам и согласованная модель ответственности |
Переключение между режимами не требует пересборки контура: меняется только набор разрешённых действий, а правила и накопленная статистика остаются. Это позволяет начинать с наблюдения и доходить до полного цикла по мере накопления доверия к модели.
Внедрение: от аудита сети до передачи в эксплуатацию
Порядок работ в проекте AI-системы NDR строится так, чтобы детекция опиралась на реальную топологию, а не на усреднённые модели. Сначала фиксируем, что и где вообще можно наблюдать, затем настраиваем детекторы на живом трафике и только потом передаём систему сопровождению. Каждый этап закрывается артефактом, который можно проверить до перехода к следующему.
-
Аудит сети. Разбираем топологию: сегменты, маршруты между площадками, инвентарь активов и ответственных за них. Отдельно отмечаем шифрованные участки и слепые зоны — от них зависит полнота покрытия.
-
Проектирование точек съёма трафика. Определяем, где поток виден целиком: границы периметра, каналы между сегментами, серверные сегменты. Схему согласуем с сетевой командой, чтобы съём не влиял на пропускную способность.
-
Подключение и нормализация. Настраиваем передачу копий потока, приводим записи к единому виду и добавляем контекст: какой актив, зона, сервис. Без этого детекторы дают шум вместо сигналов.
-
Настройка детекторов. Модели поведения обучаем на историческом трафике, правила — на известных техниках атак. Пороги выставляем по фактическому профилю загрузки, а не по шаблону из документации.
-
Проверка на реальных сценариях. Прогоняем учебные атаки и разбираем обнаружения вместе с аналитиками: время до срабатывания, доля ложных, полнота цепочки событий. Правки вносим до приёмки.
-
Передача в эксплуатацию. Отдаём доступы, регламент реагирования и документацию, обучаем дежурную смену. Первое время инженеры остаются на связи, далее — сопровождение и донастройка под новые сервисы.
Конфигурации, схемы сети и регламенты: что остаётся у вас
Проект заканчивается не демонстрацией работающего стенда, а передачей комплекта, по которому ваша команда сможет развивать систему без нас. Всё, что настраивалось под ваш трафик и вашу инфраструктуру, остаётся в вашем контуре — в виде файлов и документов, а не устных договорённостей с подрядчиком.
- Конфигурации системы — параметры сенсоров, пороги чувствительности и правила хранения в версионируемом виде: стенд поднимается с нуля по репозиторию, а не по памяти инженера.
- Схемы сети и потоков — какие сегменты и точки съёма покрыты, куда уходит зеркалированный трафик, где границы видимости. При изменении топологии сразу видно, что выпадает из наблюдения.
- Политики доступа — матрица ролей, связка с вашим каталогом пользователей, разделение прав на просмотр данных и на изменение правил.
- Правила детекции с обоснованием — почему выбран такой порог срабатывания, какие события считаются ложными и как правило перенастраивается под сезонный профиль нагрузки.
- Регламенты реагирования — уровни критичности, сроки реакции по каждому, порядок эскалации, изоляция узла и действия дежурного в нерабочие часы.
- Процедуры сопровождения — обновление моделей и баз, проверка системы после изменений сети, откат на предыдущий набор правил.
- Документация для смены — разбор типового ложного срабатывания, чек-лист приёма-передачи и записи сессий с вашими инженерами.
Комплект закрывается приёмкой: ваша команда сама разворачивает стенд и разбирает учебный инцидент. Если это получается без подсказок с нашей стороны — передача состоялась, и дальше вы работаете на своей инфраструктуре.
Кейс: время обнаружения угроз сократилось в разы
До внедрения сеть на нескольких тысячах узлов и 14 площадках разбиралась постфактум: аналитик шёл от жалобы пользователя или от письма внешней команды, а логи смотрел уже после срабатывания. Среднее время обнаружения держалось на уровне 30-38 часов, разбор инцидента занимал половину рабочего дня, а 78% оповещений оказывались ложными — за смену успевали разгрести только верхушку.
Что изменили
Собрали зеркалирование трафика на аплинках ЦОД и на шлюзах площадок, включили экспорт метаданных потоков, а для подозрительных сессий — выборку содержимого. Детекты привязали к матрице MITRE ATT&CK: сначала закрыли вход извне, боковое движение и выгрузку данных, затем добавили поведенческие модели для учётных записей. Сигналы обогащаются инвентарём, справочником учётных записей и списком критичных сервисов — аналитик получает готовую цепочку «кто, откуда, к чему обращался» и только подтверждает гипотезу, а не собирает контекст по логам.
Что получилось
Время обнаружения по критичным сценариям — 12 минут вместо 30+ часов, доля ложных срабатываний — 11% вместо 78%, реакция на подтверждённый инцидент — 25 минут вместо 4 часов. Разбор одного случая занимает 40-50 минут: хронология, артефакты и затронутые узлы собираются автоматически, аналитик проверяет связи и закрывает инцидент. Покрытие по матрице техник сверяем раз в квартал — новые тактики попадают в правила до того, как их начинают проверять на нашей сети.
Что делать, если уже развёрнута SIEM-система?
NDR не требует сносить то, что уже работает: решение встаёт в существующий контур безопасности как сетевой датчик, а SIEM остаётся системой записи и единой точкой разбора инцидентов. Практический вопрос не «или-или», а как выстроить интеграцию с SIEM и развести зоны ответственности, чтобы одна и та же корреляция не считалась дважды.
Ключ — передача событий. Наверх уходят не пакеты, а готовые детекции с атрибутами: узлы, сервисы, направление, стадия атаки по MITRE ATT&CK. Дублирование функций появляется там, где оба контура независимо собирают сетевую телеметрию и строят свои правила — тогда аналитик получает два оповещения об одном событии и перестаёт доверять обоим.
| Вариант сосуществования | Когда подходит | Ограничения |
|---|---|---|
| NDR поверх SIEM | Правила корреляции уже отлажены, нужна глубина по сети | Сетевые правила придётся переписать под новые поля |
| Гибрид с разделением зон | SIEM закрывает вход, почту и конечные точки, сеть вне зоны видимости | Нужен регламент: кто владеет каким срабатыванием |
| Постепенная замена сетевой аналитики | Шум от сетевых правил SIEM выше, чем польза от них | Историю детекций придётся переносить и сверять вручную |
Дальше всё решает эксплуатация: инженеры описывают, какие события уходят наверх, с какой частотой, что делать при расхождении вердиктов. Разбор инцидента остаётся в одной консоли, а за сетевой слой отвечает NDR — контур не разрастается, при этом покрытие растёт, а не пересобирается заново.
Технические сомнения: сенсоры, нагрузка и приватность
Технические возражения по AI-системе NDR обычно сводятся к трём вопросам: не пострадает ли сеть, что именно хранится из трафика и кто к нему имеет доступ, насколько шумно ведёт себя детекция. Ниже — короткие ответы с тем, как это настраивается на практике.
Не просядет ли сеть от сенсоров и агентов?
Сенсор работает пассивно: трафик копируется на анализатор через зеркалирование на коммутаторе или точку агрегации, транзитом через него не идёт. Там, где зеркало недоступно, ставим агент на хосте и ограничиваем выборку — приоритет отдаём заголовкам потоков, а не полному дампу. Задержку и утилизацию каналов замеряем до включения, чтобы влияние на продакшен было предсказуемым.
Что именно вы храните из трафика и кто видит данные?
По умолчанию система работает на метаданных: адреса, порты, время, объём, признаки сессий — этого хватает для большинства сценариев. Содержимое пакетов включается точечно и на ограниченный срок хранения; доступ разграничен по ролям, выгрузка фиксируется в журнале. Подсети с чувствительными данными исключаются из анализа и маскируются на этапе развёртывания.
Насколько шумной будет детекция?
Модель опирается на поведенческие признаки, а не на списки сигнатур, поэтому ложные срабатывания приходят в основном из легитимных аномалий — инвентаризации, ночного резервного копирования, обновлений. Пороги калибруем на исторических данных заказчика, а подтверждённые разборами события возвращаются в обучение. Ориентир — очередь, которую дежурный разбирает за одну смену, а не поток в тысячи строк.
Обсудим вашу задачу: с чего начинаем работу
Чтобы вернуться с планом внедрения и оценкой сроков, а не с общими словами, нам нужен минимум вводных. Достаточно описать задачу в свободной форме: какие сегменты сети под контролем, какой класс угроз беспокоит в первую очередь, что уже стоит из средств защиты и какая история трафика доступна.
Что нужно от вас для старта:
- перечень сегментов и точек съёма трафика — где наблюдаем, а где можем влиять на соединения;
- глубина хранения истории: за какой период есть данные, чтобы обучить модель на вашем трафике, а не на синтетике;
- текущие средства защиты и журналы — чтобы не дублировать то, что уже отрабатывает;
- сценарии, которые важно закрыть: внешние подключения, перемещение внутри сети, обращения к редким адресам;
- требования к реакции: только оповещение или автоматическая блокировка на периметре;
- ответственный с вашей стороны, кто подтверждает ложные срабатывания и правит правила детекции.
Что вернём в ответ:
- схему включения в вашу сеть с явной границей между наблюдением и активными действиями;
- состав работ по этапам: сбор данных, настройка правил, обучение на вашем трафике, опытная эксплуатация;
- оценку сроков по каждому этапу и точки, где нужны ваши согласования;
- набор метрик результата: доля покрытых сценариев, число ложных срабатываний за смену, время от события до оповещения.
Обсудим задачу — опишите вводные, и мы вернёмся с планом, составом работ и сроками. Решение по старту остаётся за вами.
