Чому правила не встигають за атаками: де ламається SIEM
Класична SIEM-система тримається на правилах кореляції: інженер описує умову — «N невдалих входів за вікно T з однієї адреси», — і правило спрацьовує при збігу. Модель прозора й передбачувана, поки інфраструктура стабільна, а потік подій однорідний. Проблема в тому, що обидві умови перестають виконуватися майже одразу після запуску.
Кількість правил зростає швидше, ніж команда встигає їх супроводжувати. Кожен новий сервіс, зміна схеми логування або переїзд вузла ламає частину умов — правило перестає знаходити атаку, але продовжує значитися робочим.
Так з'являються сліпі зони: ніхто не знає, що саме перестало детектуватися, поки інцидент не спливе постфактум.
Друга сторона — хибні спрацьовування. Чим ширше правило перекриває поведінку, тим більше легітимних дій воно зачіпає: планові сканування, міграції, роботу автоматизації.
Аналітик тоне в черзі однотипних алертів, звикає закривати їх не дивлячись — і справжнє спрацьовування губиться серед шуму. Формально детекція є, фактично її немає.
Саме тут потрібна AI SIEM розробка: модель навчається на нормальній поведінці конкретної інфраструктури й оцінює відхилення, а не збіг із шаблоном. Правила залишаються для відомих технік, але перестають бути єдиним шаром. Розбираємо, як це закривається.
Що дає AI-детекція: вимірюваний ефект для SOC
Хибні спрацювання падають у рази
Правила на сигнатурах ловлять усе, що «схоже» на атаку, тому черга алертів зростає швидше, ніж чергова зміна встигає її розібрати.
Поведінкова аналітика будує базовий профіль за кожним користувачем, хостом і сервісом — облікові записи, години активності, типові напрямки трафіку, набір звернень до каталогу, — і підвищує пріоритет лише за відхилення від цього профілю. На практиці частка хибних спрацювань падає в рази, а черга алертів стає оглядною за зміну.
Час реакції SOC скорочується
Коли потік шуму спадає, аналітик витрачає час на розбір, а не на закриття однотипних карток. Подія надходить уже з контекстом: хто, звідки, до чого звертався, що було до і після, чи пов'язано з іншими вузлами.
Завдяки цьому середній час від події до вердикту скорочується з годин до хвилин, а ескалація до другої лінії йде лише за підтвердженими інцидентами.
Виявлення аномалій замість відомих шаблонів
Сигнатурна детекція безсила проти нового інструмента або легітимної утиліти, використаної не за призначенням.
Модель аномалій дивиться на послідовність дій, а не на збіг із відомим зразком: нетиповий обсяг вивантаження, доступ до чутливих ресурсів поза звичайним маршрутом, ланцюжок команд, якого раніше не було. Це закриває клас атак, який проходить повз правила за визначенням.
Зникає клас відмов «пропустили, бо не налаштували правило»
Ручний супровід сотень правил означає, що будь-яка зміна інфраструктури залишає сліпі зони — новий сервіс, новий сегмент, новий обліковий запис. Профіль поведінки будується автоматично за фактичним трафіком, тому покриття не залежить від того, чи встиг інженер дописати правило. Сліпі зони перестають накопичуватися між релізами.
Розслідування спирається на дані, а не на пам'ять
Кожне спрацювання зберігає зріз поведінки навколо події: попередні дії, звернення до ресурсів, зв'язки між вузлами. Розбір інциденту йде за відновленою хронологією, а не за розрізненими вивантаженнями з різних систем.
Це скорочує час на підтвердження інциденту й робить висновки відтворюваними під час повторної перевірки.
Варіанти побудови: від власної розробки до гібрида
Вибір підходу визначається не бюджетом, а тим, що вже стоїть у SOC і наскільки чутливі дані.
Якщо логи вже збираються в готовий движок кореляції, а бракує лише поведінкової аналітики, повна власна розробка не окупиться: ви будете роками відтворювати нормалізацію джерел, парсери та правила кореляції, які у зрілому продукті вже відлагоджені на тисячах впроваджень.
Гібридна модель закриває це інакше: збір, нормалізація та зберігання залишаються на готовому движку, а шар AI-детекції — моделі поведінкової аналітики, скоринг аномалій, збагачення контекстом — будується нашим.
Такий варіант дає контроль над логікою виявлення без ризику переписати з нуля всю інфраструктуру SOC.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власна розробка | Суворі вимоги до зберігання даних усередині периметра, нестандартні джерела телеметрії, потрібна унікальна логіка детекції | Тривалий строк до першої працюючої детекції, потрібна власна команда супроводу моделей і правил |
| Гібридна модель | Є готовий движок збору та кореляції, бракує поведінкової аналітики та скорингу | Залежність від форматів і обмежень базового движка, частину телеметрії доведеться адаптувати |
| Готові движки з AI-модулями | Потрібен швидкий старт і типові сценарії: вхід, привілеї, мережа | Слабка адаптація під вашу специфіку, логіка детекції закрита, донавчання під свої дані обмежене |
На практиці частіше виграє гібрид: він дає працюючу детекцію на ранньому етапі й залишає простір для поглиблення під ваші сценарії. Розбираємо, як це влаштовано на рівні конфігурації та які обмеження знімаються на кожному кроці.
Етапи впровадження AI-детекції в контур моніторингу
Впровадження AI-детекції починається не з моделі, а з інвентаризації того, що вже є в контурі. На цьому етапі фіксуємо джерела подій, їхніх власників і повноту: які системи пишуть у журнали, що втрачається при розриві зв'язку, де події дублюються. Без цього модель навчається на неповній картині й видає хибні спрацювання на рівному місці.
Далі вибудовуємо схему потоків і лише потім підключаємо детекцію — так результат відтворюваний, а не випадковий.
- Аудит джерел. Збираємо перелік систем, форматів і частоти подій, відзначаємо прогалини в покритті та джерела, які пишуть нестабільно.
- Схема потоків. Проєктуємо маршрут подій від джерела до сховища: нормалізація, збагачення контекстом, буферизація при пікових навантаженнях і розривах.
- Налаштування моделей. Навчаємо детектори на історичних даних контуру, задаємо пороги чутливості під профіль інфраструктури, а не за усередненими шаблонами.
- Перевірка детекцій. Проганяємо моделі на розмічених інцидентах минулого: дивимося, скільки реальних атак спіймано і скільки хибних спрацювань припадає на зміну.
- Тюнінг правил. Знижуємо шум точково — уточнюємо умови, додаємо винятки для легітимних сценаріїв, щоб аналітик не тонув у черзі.
- Передача в експлуатацію. Оформлюємо регламенти реагування, навчаємо зміну, фіксуємо метрики якості детекції для подальшого контролю.
Порядок принциповий: пропущений аудит джерел або схема потоків обертаються тим, що модель працює на неповних даних, а команда втрачає довіру до системи після першої хвилі хибних тривог.
Перевірка на історичних даних — обов'язковий шлюз перед експлуатацією: вона показує реальний клас відмов і дозволяє відкалібрувати пороги до того, як система потрапить у бойову зміну.
Артефакти на виході: конфігурації, схеми, регламенти
Після здачі проєкту у вашої команди залишається працююча система та повний комплект артефактів, за якими її можна розвивати, передавати на супровід і проходити перевірки. Нижче — що саме фіксується в документації та конфігураціях.
- Конфігурації детекцій. Правила кореляції та моделі аномалій у вигляді версіонованих файлів: логіка спрацювання, пороги, вікна агрегації, прив'язка до джерел. Правило можна увімкнути, вимкнути або налаштувати під свій контур без правки коду.
- Схеми потоків даних. Карта джерел: які системи віддають події, через які збирачі вони йдуть, де нормалізуються та збагачуються, куди потрапляють. Схема показує, який детект на яких даних працює і що станеться при відмові джерела.
- Регламенти реагування. Покрокові сценарії для чергової зміни: як читати алерт, що перевіряти в першу чергу, коли ескалювати, які дії допустимі автоматично, а які — тільки вручну.
- Політики доступу. Ролі та права: хто бачить сирі події, хто змінює правила детекцій, хто закриває інциденти. Розподіл зроблено так, щоб аналітик не міг непомітно вимкнути правило, що спрацювало.
- Документація з експлуатації. Інструкції з розгортання, оновлення моделей, додавання нового джерела та перевірки здоров'я системи після змін.
- Інструкції для чергової зміни. Короткі пам'ятки на кожен тип алерту — що це означає, чим підтверджується, що робити далі. Новий співробітник виходить на зміну, не розбираючись в устрої системи з нуля.
- План розвитку та журнал рішень. Зафіксовані припущення, відомі обмеження та черга доопрацювань, щоб наступний етап починався не з повторного аналізу.
Комплект передається у вашому репозиторії та у вашій інфраструктурі — без прив'язки до нас. Опишіть задачу, і ми повернемося з оцінкою та планом: які джерела підключаємо першими та які детекції закривають ваші ключові сценарії.
Кейс: скорочення хибних спрацювань утричі за один цикл
Замовник — оператор корпоративної мережі з розподіленим периметром. До проєкту аналітики розбирали близько 400 попереджень на добу, з яких підтверджувалися одиниці: решта — легітимні адміністративні дії, сканери вразливостей за розкладом та оновлення внутрішніх сервісів.
Черга розбору не встигала за потоком, частину подій закривали «за терміном», а не за фактом перевірки.
Що змінили
Зібрали поведінкові профілі за кожним вузлом і обліковим записом: типові вікна активності, набори звернень до внутрішніх сервісів, обсяги вивантажень.
Модель оцінює відхилення від особистої норми, а не від загальної сигнатури, тому «незвичне для цього вузла» перестало губитися серед «звичайного для всіх».
Правила кореляції переписали так, щоб подія підтверджувалася зв'язкою ознак, а не одним збігом. Хибні спрацювання від планових сканерів і регламентних оновлень перейшли в білий список за розкладом, а не за адресою джерела.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Попереджень на добу | ~400 | ~130 |
| Частка підтверджених | низька | більша частина черги |
| Час виявлення реальної загрози | години | десятки хвилин |
| Навантаження на аналітика | постійний потік | розбір пріоритетного |
MITRE ATT&CK використовували як основу для розмітки технік — це дало спільну мову між моделлю, правилами кореляції та аналітиками під час розбору інциденту.
Окремо налаштували зворотний зв'язок: кожне закрите попередження повертається в розмітку, і модель донавчається на реальних рішеннях зміни. Через кілька циклів частка хибних спрацювань стабілізувалася на новому рівні, а не відкотилася назад.
Чим поведінкова аналітика відрізняється від кореляції правил
Кореляція правил — це детермінований шар: аналітик описує умову виду «подія A, потім B протягом N хвилин з одного вузла», і система шукає точний збіг.
Плюс — передбачуваність і пояснюваність: за кожним спрацюванням видно, яке правило і який ланцюжок подій його викликали, хибне спрацювання розбирається за хвилини.
Мінус — правило ловить лише те, що в нього заклали: будь-яке відхилення в порядку подій, таймінгу або джерелі логів обходить детект, а число правил зростає швидше, ніж покриття.
Поведінкова аналітика працює інакше: вона будує базову лінію для сутності — облікового запису, вузла, сервісного облікового запису — за історією її дій і сигналить про відхилення від цієї норми.
Правила не пишуться заздалегідь: модель сама виділяє аномалію в частоті звернень, обсязі вивантажуваних даних, нетиповому часі активності або новому поєднанні ресурсів.
Це ловить те, що не описано правилом, але ціна — інший клас помилок: аномалія не завжди загроза, і без контексту модель дає спрацювання на легітимні зміни на кшталт зміни регламенту або міграції сервісу.
Відмінності зводяться до трьох осей. Що шукаємо: точний збіг шаблону проти статистичного відхилення. Що потрібно для запуску: описане правило проти накопиченої історії за кожною сутністю. Чим платимо за помилку: пропуском при невідомій тактиці проти шуму при зміні нормальної поведінки.
Вибір методу — не «або-або». Кореляція правил дає точні, легко перевірювані спрацювання за відомими тактиками і слугує опорою для розбору. Поведінкова аналітика закриває сліпу зону — невідомі тактики і повільні відхилення, які за однією подією не видні.
На практиці їх комбінують: аномалія від моделі не йде напряму в чергу інцидентів, а піднімає пріоритет пов'язаних подій, які далі перевіряються правилами і збагачуються контекстом. Так знижується і шум, і число пропусків одночасно.
Звідси критерій: якщо у вас уже є зрілий набір правил і ви впираєтеся в пропуски за нетиповою поведінкою — додавайте поведінковий шар поверх, не замінюючи кореляцію.
Якщо правил майже немає, починати з моделі безглуздо: нема чому давати контекст, і потік спрацювань буде нічим розбирати.
Часті технічні сумніви перед стартом робіт
Сумніви інженерного рівня зазвичай зводяться до трьох речей: чи впишемося в поточний стек, чи вистачить накопичених логів для навчання моделей і чи не доведеться змінювати обладнання. Розберемо кожне предметно — так, як це виглядає на етапі проєктування, а не в презентації.
Чи сумісне рішення з нашим поточним стеком — колекторами, шиною, сховищем?
Так. Ми не замінюємо джерела телеметрії, а підключаємося до них: забираємо події з наявних колекторів і брокера, нормалізуємо в загальну схему та пишемо в те саме сховище, що вже використовується.
Якщо частина логів надходить в іншому форматі, додаємо парсери під конкретні джерела. Інтеграція з SIEM, тікетницею та системами оповіщення відбувається через штатні інтерфейси, тому звичні процеси реагування не ламаються.
У нас накопичено мало історичних даних — моделі взагалі навчаться?
Навчання будується у два шари. Базовий шар — правила та статистичні профілі поведінки, вони працюють на короткому вікні спостережень і дають ефект з перших тижнів.
Другий шар — моделі, які уточнюються в міру накопичення подій: чим більше проходить трафіку, тим точніше розділяються норма та аномалія. Якщо історії мало, стартуємо з базового шару й донавчаємо модель на живому потоці, не чекаючи «ідеального» датасету.
Чи доведеться закуповувати нове обладнання під навантаження?
Рахуємо обсяг подій на добу та пікову швидкість надходження — від цього залежить конфігурація. Часто достатньо наявних потужностей, якщо винести важкі обчислення на окремий вузол і налаштувати зберігання за рівнями: гарячі дані для детекції, архів для розслідувань. Вимоги до обладнання фіксуємо до старту, щоб не було сюрпризів під час введення в експлуатацію.
Якщо залишилися питання щодо вашого конкретного контуру — опишіть задачу, повернемося з оцінкою та планом.
Обговоримо ваше завдання і повернемося з планом
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібен мінімум вхідних даних від вас. Чим конкретніші ввідні, тим точніша оцінка термінів і складу робіт з AI SIEM розробки — без «уточнимо по ходу».
- Які джерела подій потрібно підключити: сервери, мережеві пристрої, хмари, застосунки, засоби захисту.
- Поточний ландшафт: чи вже є збір логів, де зберігаються, в якому обсязі та як довго.
- Які загрози та сценарії критичні саме для вас: атаки на периметр, аномалії в поведінці облікових записів, витоки, внутрішні порушення.
- Вимоги до реагування: хто і як отримує оповіщення, які дії автоматизуємо, що залишається за черговою зміною.
- Обмеження щодо інфраструктури: власний контур чи хмара, вимоги до ізоляції даних, регламенти щодо зберігання.
- Хто з боку замовника ухвалює рішення та узгоджує пріоритети.
У відповідь ми готуємо план робіт за етапами: збір і нормалізація подій, модель виявлення аномалій, правила кореляції, інтерфейс аналітика, інтеграції з оповіщеннями, тестування на реальному трафіку. До плану додаємо оцінку термінів, склад команди та схему розгортання. Опишіть завдання — повернемося з оцінкою та планом, за яким можна стартувати проєкт.
