Чому ШІ-система NDR пропускає атаки всередині периметра
Класична схема захисту будується навколо периметра: трафік на вході й виході розбирається повноцінно, а все, що відбувається між внутрішніми сегментами, залишається в тіні.
ШІ-система NDR, навчена переважно на таких даних, упевнено ловить зовнішні сканування й звернення до рідкісних адрес, але втрачає чутливість там, де починається справжня атака.
Головна сліпа зона мережі — східно-західні потоки: обмін між серверами, базами, робочими станціями та контейнерними середовищами.
Отримавши першу точку опори, зловмисник не йде назовні — він озирається й починає бічне переміщення, а кожен такий крок виглядає як штатний внутрішній запит.
Без розбору цього трафіку детекція мережевих загроз працює за залишковим принципом: сигнал формально є, але він не відрізняється від нормальної активності.
Друге джерело провалів — шифрування. Значна частина внутрішнього трафіку закрита, і модель, що спирається лише на вміст пакетів, втрачає контекст.
Виручають метадані: тривалість і обсяг сесій, ритм обміну, набори адрес, поведінка облікових записів — за ними аномалія читається й без розшифрування.
Третій шар — розрізнені логи. Міжмережеві екрани, служби каталогів, агенти на хостах пишуть кожен у своєму форматі та зі своїм часом.
Поки події не зведені в єдину шкалу, реакція вимірюється годинами: аналітик вручну зіставляє фрагменти, а атака за цей час проходить кілька етапів. Розбираємо, як це закривається.
Що дає NDR-контур: вимірювані ефекти впровадження
Галузеві дані про інциденти сходяться в одному: значна частка атак розкривається не своєю командою, а зовнішньою стороною — тобто коли збитки вже завдано (Verizon Data Breach Investigations Report).
NDR-контур зміщує саме цю точку: активність стає видною в момент, коли вона відбувається, а не в момент розбору наслідків.
Швидкість виявлення інцидентів
Система зіставляє метадані мережевих потоків, журнали мережевих пристроїв і звернення до зовнішніх вузлів між собою, тому аномалія в поведінці окремого вузла проявляється на етапі, коли вредитель ще озирається всередині периметра.
Швидкість виявлення інцидентів вимірюється десятками хвилин від першого підозрілого з’єднання замість діб і тижнів — а це вже принципово інший сценарій реагування.
Усунений клас відмов
Частина сценаріїв раніше не детектувалася в принципі: розтягнута на тижні взаємодія із зовнішнім вузлом через дозволені сервіси, тихе вивантаження легітимними каналами, аномальні обсяги вихідного трафіку в неробочі години.
Поведінкові правила й моделі закривають ці сценарії — клас відмов зникає, а не залишається в сірій зоні.
Чергова зміна аналітиків і розбір інцидентів
Пріоритизація за критичністю знімає рутину: чергова зміна аналітиків працює з десятками підтверджених подій замість сотень сирих спрацьовувань, а розбір інцидентів іде за готовим ланцюжком свідчень із хронологією. Частка підтверджених тривог зростає, а час на передачу інциденту в реакцію скорочується.
Режими роботи: спостереження, реагування чи повний цикл
Режим роботи визначає не функціональність системи, а глибину її втручання в мережу. Тому вибір починають із двох запитань: чи є право змінювати конфігурацію вузлів і наскільки зрілі правила детекції.
Поки правило не підтвердило себе на своїх даних, автоматичне реагування перетворюється на джерело аварій.
Тому контур збирають поетапно: спочатку пасивне спостереження, потім автоматичні дії за вузьким списком сценаріїв. Впровадження без зупинки сервісів можливе саме в такій послідовності — аналізатор підключається до дзеркала трафіку й нічого не змінює в поточній топології.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пасивне спостереження | Перший етап: інвентаризація трафіку, навчання правил на своїх даних | Лише сигнал, блокування немає; видно тільки те, що потрапляє в дзеркало |
| Детекція з ручним розбором | Є чергова зміна та готові регламенти ескалації | Швидкість реакції залежить від людей; нічні спрацьовування чекають ранку |
| Автоматичне реагування на межі | Правила відпрацювали, є тестовий контур для перевірки | Хибне спрацьовування рве легітимний сервіс; потрібні списки винятків і відкат |
| Повний цикл: детекція, реакція, перевірка | Свої сервіси, керовані вузли, розмежовані права | Потрібен доступ до керуючих інтерфейсів і узгоджена модель відповідальності |
Перемикання між режимами не потребує перезбирання контуру: змінюється лише набір дозволених дій, а правила й накопичена статистика залишаються. Це дозволяє починати зі спостереження й доходити до повного циклу в міру накопичення довіри до моделі.
Впровадження: від аудиту мережі до передачі в експлуатацію
Порядок робіт у проєкті ШІ-системи 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 — контур не розростається, при цьому покриття зростає, а не перезбирається заново.
Технічні сумніви: сенсори, навантаження та приватність
Технічні заперечення щодо ШІ-системи NDR зазвичай зводяться до трьох питань: чи не постраждає мережа, що саме зберігається з трафіку і хто до нього має доступ, наскільки шумно поводиться детекція. Нижче — короткі відповіді з тим, як це налаштовується на практиці.
Чи не просяде мережа від сенсорів і агентів?
Сенсор працює пасивно: трафік копіюється на аналізатор через зеркалювання на комутаторі або точку агрегації, транзитом через нього не йде. Там, де дзеркало недоступне, ставимо агент на хості й обмежуємо вибірку — пріоритет віддаємо заголовкам потоків, а не повному дампу. Затримку й утилізацію каналів заміряємо до ввімкнення, щоб вплив на продакшен був передбачуваним.
Що саме ви зберігаєте з трафіку і хто бачить дані?
За замовчуванням система працює на метаданих: адреси, порти, час, обсяг, ознаки сесій — цього достатньо для більшості сценаріїв. Вміст пакетів вмикається точково й на обмежений строк зберігання; доступ розмежовано за ролями, вивантаження фіксується в журналі. Підмережі з чутливими даними виключаються з аналізу й маскуються на етапі розгортання.
Наскільки шумною буде детекція?
Модель спирається на поведінкові ознаки, а не на списки сигнатур, тому хибні спрацьовування приходять переважно з легітимних аномалій — інвентаризації, нічного резервного копіювання, оновлень.
Пороги калібруємо на історичних даних замовника, а підтверджені розборами події повертаються в навчання. Орієнтир — черга, яку черговий розбирає за одну зміну, а не потік у тисячі рядків.
Обговоримо вашу задачу: з чого починаємо роботу
Щоб повернутися з планом впровадження й оцінкою строків, а не із загальними словами, нам потрібен мінімум ввідних.
Достатньо описати задачу у вільній формі: які сегменти мережі під контролем, який клас загроз турбує в першу чергу, що вже стоїть із засобів захисту й яка історія трафіку доступна.
Що потрібно від вас для старту:
- перелік сегментів і точок знімання трафіку — де спостерігаємо, а де можемо впливати на з’єднання;
- глибина зберігання історії: за який період є дані, щоб навчити модель на вашому трафіку, а не на синтетиці;
- поточні засоби захисту й журнали — щоб не дублювати те, що вже відпрацьовує;
- сценарії, які важливо закрити: зовнішні підключення, переміщення всередині мережі, звернення до рідкісних адрес;
- вимоги до реакції: лише оповіщення або автоматичне блокування на периметрі;
- відповідальний з вашого боку, хто підтверджує хибні спрацьовування й править правила детекції.
Що повернемо у відповідь:
- схему включення у вашу мережу з явною межею між спостереженням і активними діями;
- склад робіт за етапами: збір даних, налаштування правил, навчання на вашому трафіку, дослідна експлуатація;
- оцінку строків за кожним етапом і точки, де потрібні ваші погодження;
- набір метрик результату: частка покритих сценаріїв, кількість хибних спрацьовувань за зміну, час від події до оповіщення.
Обговоримо задачу — опишіть ввідні, і ми повернемося з планом, складом робіт і строками. Рішення щодо старту залишається за вами.
