Розробка AI-системи кібербезпеки під ключ

AI-кібербезпека: де рветься захист периметра

Периметр сьогодні тримається на правилах, які інженери пишуть вручну під уже відомі сценарії: сигнатури, пороги кореляції в SIEM, списки винятків.

Вони справно ловлять те, що траплялося раніше, і мовчать, коли тактика змінюється — повільний перебір облікових записів, активність під сервісним обліковим записом, вивантаження, розтягнуте на тижні.

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

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

Справжні аномалії в трафіку — сплеск вихідних з’єднань на нестандартний порт, нетиповий обсяг вивантаження, вхід у неробочі години — губляться в цьому шумі.

Ціна — затримка виявлення інциденту. За галузевими оцінками Verizon DBIR, помітна частина витоків розкривається не власною командою, а третіми сторонами, через тижні після проникнення.

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

Розбираємо, як ці точки відмови закриває модель, яка сама будує базову лінію поведінки та виносить черговому ранжований список замість потоку подій.

AI-кібербезпека: вимірюваний ефект для бізнесу

Ефект вимірюється не кількістю спрацьованих правил, а тим, скільки сигналів аналітик розбирає вручну і як швидко закривається реальна атака.

Контрольні точки, за якими ми звіряємо результат в AI-кібербезпеці: частка хибних спрацювань, час реакції на інцидент, обсяг ручного розбору та кількість привілейованих дій, що залишилися поза спостереженням.

Розбір інцидентів без ручного перебору

Подія оцінюється в контексті: хто звертався до ресурсу, з якого вузла, у який час, чи вписується це у звичайну активність співробітника. Тому однотипні легітимні операції перестають потрапляти до черги розбору — частка хибних спрацювань падає в рази, а не на відсотки. Усунений клас відмов — «атаку пропустили в шумі оповіщень».

Звільнений час іде на реальні загрози: пріоритет виставляється автоматично за сукупністю ознак, а не за одним правилом, і час реакції на інцидент скорочується з годин до хвилин.

Наскрізний контроль привілейованих дій

Кожна дія з підвищеними правами фіксується разом з обліковим записом, ініціатором і обґрунтуванням: розмежування привілеїв перестає бути набором статичних ролей і стає перевірюваним процесом.

Права видаються за запитом і на обмежений термін, а не «назавжди», — розширення доступу видно в журналі так само, як і його використання.

Контроль облікових записів закриває те, що зазвичай залишається поза полем зору: сервісні записи, доступи підрядників, права, забуті після переведення співробітника.

Якщо дія вибивається зі звичайного профілю, вона піднімається в розбір разом з повним контекстом — розслідування займає хвилини, а не дні звірки журналів.

Варіанти побудови захисту: власний контур, гібрид, сервіс

Схему захисту обирають не за гучністю назви, а за обсягом подій, швидкістю реакції та вимогами до зберігання даних. Нижче — три робочі шляхи й ті обмеження, з якими замовник живе після впровадження.

Коли достатньо вбудованих засобів

Вбудовані засоби захисту закривають типові загрози: підбір паролів, відомі сигнатури, різкі відхилення в правах доступу. Якщо контурів один-два і виділеного чергування немає, вони дають базовий рівень без окремого проєкту.

Обмеження в тому, що правила не налаштовуються під ваш трафік, тому зв’язок між подіями різних систем залишається невидимим.

Коли потрібен виділений контур

Виділений контур виправданий, коли інциденти надходять із багатьох джерел і їх потрібно зіставляти. Ми розкладаємо тактики й техніки за MITRE ATT&CK, щоб правила закривали кроки атакувальника, а не окремі спрацювання.

Гібрид беруть, коли телеметрія має залишитися всередині, а розбір у неробочі години віддають на сторону.

Етапи впровадження системи захисту з поведінковою аналітикою

Порядок етапів не довільний: кожне наступне рішення спирається на дані попереднього. Якщо почати з правил детектування, минаючи інвентаризацію джерел, система ловитиме шум в одному сегменті й мовчатиме в іншому. Нижче — послідовність, за якою йде проєкт.

Аудит і зняття поточної картини

1. Аудит поточного захисту. Збираємо перелік джерел подій, дивимося, що вже потрапляє до журналів, де сліпі зони і хто розбирає оповіщення. На виході — карта покриття за сегментами.

2. Схема потоків подій. Описуємо маршрут від джерела до сховища: точки збору, нормалізація форматів, терміни зберігання, поведінка при недоступності вузла. Схема одразу показує, де події губляться.

3. Налаштування правил і моделей. Будуємо базові лінії поведінки для сервісів та облікових записів, поверх — детектори відхилень і кореляція між сегментами. Пороги підбираємо так, щоб потік оповіщень залишався розбираним для чергової зміни.

4. Перевірка на реальних подіях. Моделі працюють у режимі спостереження, без блокувань, зокрема за історичними журналами за минулі періоди. Рахуємо частку хибних спрацювань і підтверджених знахідок, правимо правила — і лише потім вмикаємо автоматичні реакції.

Передача та навчання команди

• Передача документації. Схема потоків, опис правил, регламенти реагування та порядок відкату — щоб систему можна було розвивати без нас.

• Навчання команди. Розбираємо з черговими інженерами типові сценарії: як читати оповіщення, що перевіряти першим, коли ескалювати. Проганяємо навчальний інцидент повністю.

• Супровід після запуску. Перші тижні стежимо за реальним навантаженням, доналаштовуємо пороги та доповнюємо регламенти за фактичними знахідками.

Комплект на виході: схеми, правила доступу, регламенти

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

Документи пишуться не «для звіту», а під конкретну зміну й процедуру — для кожного зазначено, хто власник і що робити при відхиленні.

Правила доступу та ролі

Матриця ролей і привілеїв описує, хто і до яких вузлів, даних та функцій керування має доступ і за яким принципом видається підвищення прав. Поруч — схема потоків подій: від джерела до місця, де ухвалюється рішення.

• матриця ролей і привілеїв з власниками по кожному контуру;
• схема потоків подій від джерел до аналітики та зберігання;
• правила доступу до чутливих даних і журналів, порядок видачі та відкликання прав;
• опис сервісних облікових записів і дій при їх компрометації.

Регламенти реагування

Регламент реагування задає рівні інцидентів, межі автоматичних дій і точку, де обов’язкова людина. Окремий документ — інструкції для чергової зміни: порядок кроків, критерії ескалації, форма фіксації.

• регламент реагування з рівнями інцидентів і термінами реакції;
• інструкції для чергової зміни за типовими сценаріями;
• порядок ізоляції вузла, відкату змін і повернення в роботу;
• план розвитку: що розширюємо на наступному етапі та за якими ознаками.

Кожен документ перевіряється на навчаннях: проганяємо сценарій по кроках і правимо те, що на практиці не спрацювало. Комплект версіонується разом із системою — зміна конфігурації без оновлення регламенту вважається незавершеною.

Кейс: до і після впровадження поведінкової аналітики

Цей кейс впровадження — про організацію з розподіленою інфраструктурою та кількома тисячами облікових записів.

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

Почали з розмітки накопиченої статистики за тактиками MITRE ATT&CK та оцінки того, які сигнали справді доходили до розслідування.

Що було до

Чергова зміна аналітиків розбирала близько трьох тисяч сигналів на тиждень, і понад дев’ять із десяти виявлялися хибними. На первинний розбір інциденту йшло від сорока хвилин, пріоритет виставлявся вручну й залежав від завантаження зміни.

Час від події до блокування облікового запису вимірювався добами: поки сигнал доходив до чергового й підтверджувався, підозріла активність продовжувалася.

Що стало після

Поведінкова модель побудувала профіль для кожного облікового запису: типові години активності, набір сервісів і пристроїв, географія входів, обсяг даних, що вивантажуються.

Сигнал тепер формується за відхиленням від особистого профілю, а не за абсолютним порогом, тому зміна графіка або нова робоча станція більше не виглядають як атака.

Потік сигналів скоротився приблизно до двохсот на тиждень, частка хибних спрацювань — до однієї десятої. Середній розбір займає близько восьми хвилин, а підозріла сесія блокується автоматично в межах хвилини.

Аналітики переключилися з рутинної фільтрації на реальні розслідування — саме це, а не сама цифра, визначає стійкість захисту.

Чим поведінкова аналітика відрізняється від правил кореляції?

Правила кореляції — детерміновані умови: набір подій, поріг і часове вікно. Вони передбачувані, прості в підтримці та дають однозначний розбір — видно, яка умова спрацювала.

Але поріг задає людина: новий сегмент мережі або зміна регламенту ламає сценарій, і його переписують вручну.

Поведінкова аналітика будує профіль норми для облікового запису, сервісу або пристрою: типові джерела входу, обсяги вивантажень, час активності.

Відхилення рахується за сукупністю ознак, тому розтягнута в часі атака — поступовий збір даних під легітимним обліковим записом — видна там, де одинична подія не перевищує поріг.

На практиці підходи поєднують: правила тримають те, що не повинно залежати від статистики — доступ до критичних систем, масове видалення, звернення до сховища секретів поза регламентом. Модель закриває решту й підказує, які пороги в сценаріях підняти або опустити.

Гібрид знижує кількість хибних спрацювань за того самого покриття: аномалія приходить не «голою», а з контекстом спрацьованих правил. Що віддавати правилам, а що моделі, вирішуємо після розбору вашої інфраструктури та типових маршрутів доступу.

Технічні питання перед стартом проєкту

Інженерні сумніви перед стартом зазвичай стосуються не самої моделі, а того, як вона вбудовується в наявний контур захисту. Нижче — питання, які найчастіше піднімає служба безпеки, і короткі відповіді на кожне.

Розмітка подій неповна — модель буде помилятися?

Оцінюємо частку розмічених випадків на історичній вибірці та дорозмічуємо проблемні класи: атака, норма, хибне спрацювання. Поки узгоджений рівень не досягнуто, у роботу йдуть правила кореляції, а не статистика.

Що буде при втраті зовнішніх каналів?

Виявлення відбувається в закритому контурі: модель, правила й довідники лежать усередині. При обриві каналу оновлень система продовжує працювати на поточній версії, а події накопичуються локально.

Як часто перенавчати модель?

За розкладом і за тригером — коли якість на контрольній вибірці падає нижче узгодженого порогу. Навчання відбувається офлайн, версія фіксується, відкат на попередню займає хвилини.

Який доступ потрібен усередині самої системи захисту?

Лише читання журналів і подій, окремий сервісний обліковий запис без права змінювати політики. Усі дії потрапляють в аудит, розширення прав узгоджується заздалегідь.

Обговоримо задачу та повернемося з оцінкою і планом

Щоб оцінка була предметною, а не середньою по галузі, на старті достатньо кількох вступних даних — готувати технічне завдання заздалегідь не потрібно. Опишіть контур своїми словами, решту уточнимо в розмові.

Що потрібно від вас для старту:

• Перелік систем і джерел подій: поштовий шлюз, SIEM, EDR, журнали хмари та мережевого периметра. Чим повніший список, тим точніша схема збору даних.
• Де зараз біль: частка хибних спрацювань, середній час реакції на інцидент, скільки розборів робиться вручну.
• Обмеження контуру: закритий периметр без виходу назовні, вимоги до термінів зберігання подій, регламенти щодо персональних даних.
• Зони відповідальності: хто погоджує доступи, хто приймає результат, хто чергує на дослідній експлуатації.
• Стенд для перевірки: тестовий сегмент зі знеособленими подіями або спостереження за одним вузлом без втручання в роботу захисних засобів.
• Орієнтир за навантаженням: скільки подій на добу надходить і яке зростання очікується при підключенні нових джерел.

У відповідь повертаємо схему етапів впровадження з точками контролю, склад робіт за кожним етапом та оцінку термінів з урахуванням обсягу подій і узгоджених зон відповідальності.

Окремо фіксуємо критерії приймання — за якими метриками ви перевірите, що AI-система кібербезпеки справді знижує шум і прискорює реакцію, а не просто додає ще одну панель моніторингу.

Опишіть задачу у вільній формі — повернемося з оцінкою і планом.