Чому AI SOAR буксує без описаних сценаріїв
Автоматизація реагування найчастіше буксує не через якість моделі, а через відсутність формального опису того, що зміна робить руками. Платформа розгорнута, джерела подій підключені, але частка інцидентів, закритих без людини, залишається низькою.
Аналітик усе ще відкриває оповіщення, іде в консоль, звіряє адреси, копіює ідентифікатори — і весь цей час потік подій зростає швидше, ніж зміна встигає розбирати інциденти.
Причина в тому, що сценарії реагування описують «загалом», а не як послідовність перевірюваних умов.
Якщо не зафіксовано, з якого джерела надходить подія, які поля вважаються ознакою спрацювання, чим один випадок відрізняється від схожого, автоматика не може ухвалити рішення і йде у гілку «передати людині».
Два аналітики в одній і тій самій ситуації діють по-різному — отже, повторюваного сценарію немає, і навчати на таких даних нічому.
Робочий сценарій виглядає інакше: тригер прив'язаний до конкретного джерела в потоці подій, задані умови збагачення, перелік допустимих дій і критерій, за яким випадок вважається закритим.
Тоді автоматизація реагування закриває типові випадки повністю, а чергова зміна підключається лише на точках рішення — там, де потрібен вибір, а не рутина. Розбираємо, як це закривається на практиці.
Ефект від автоматизації: швидкість реакції та навантаження на зміну
Ефект автоматизації вимірюється не числом сценаріїв, а трьома величинами: часом до першої дії за інцидентом, часткою рутини, знятої з аналітика, та обсягом шуму, який узагалі не доходить до зміни.
До автоматизації сигнал, що надійшов наприкінці чергування, чекав розбору до ранку — час реакції розтягувався на години, а контекст події на момент розбору частково втрачався.
Сценарій реагування розбирає подію за секунди: збагачує її даними про актив, звіряє з історією, відсікає вочевидь хибне і виконує першу стримувальну дію — блокування облікового запису або ізоляцію вузла.
Аналітик отримує зібрану картину замість сирого потоку, і час до першої дії падає з десятків хвилин до одиниць. Платформи класу Cortex XSOAR виконують такі сценарії як відтворювані набори кроків — їх можна версіонувати й відкочувати.
Рутинні дії — вивантаження логів, звіряння адрес і хешів, запит у пісочницю, заведення картки — повністю переходять в автоматику.
На зміні залишаються рішення, де потрібен контекст і повноваження: приблизно дві-три операції з п'яти перестають займати руки, а навантаження на аналітика в пікові години вирівнюється.
Окремо зникає клас відмов, пов'язаний з хибними спрацюваннями. Правило, що спрацьовує за однією ознакою, замінюється перевіркою збігу кількох умов, а шумні правила знижуються в пріоритеті замість ручного розбору.
Черга перестає зростати до кінця чергування, і передача зміни відбувається за стабільним станом, а не як спадок із нерозібраних спрацювань.
AI SOAR: варіанти розгортання та їхні обмеження
Розгортання контуру автоматизації рідко зводиться до встановлення одного продукту. Вибір точиться між керованим сервісом у постачальника, платформою всередині периметра, доопрацюванням уже працюючого контуру та гібридом.
Різниця проявляється не в наборі функцій, а в тому, де зберігаються дані про інциденти, хто відповідає за інтеграцію із системами захисту і наскільки швидко правиться сценарій реакції.
Нижче — альтернативи в тому вигляді, як ми їх бачимо в проєктах: за застосовністю, строками запуску та обмеженнями, які доведеться прийняти усвідомлено.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Керований сервіс у постачальника | Контур автоматизації потрібен швидко, штат невеликий, винесення даних про події за периметр допустиме | Частина даних про інциденти йде назовні; правка сценаріїв обмежена можливостями платформи |
| Платформа всередині периметра | Заборона на винесення даних, вимоги регулятора, передбачуваний потік подій | Потрібна власна інфраструктура й супровід; кожне джерело захисту підключається окремо |
| Доопрацювання поточного контуру | Уже працюють збір подій і частина сценаріїв автоматизації | Успадковуються архітектурні обмеження: вузькі місця обміну даними переїжджають у новий шар |
| Гібрид: оркестрація всередині, аналітика назовні | Потрібен контроль над діями в інфраструктурі та зовнішня аналітика за знеособленими даними | Складніший у супроводі: два контури, дві моделі розмежування доступу, синхронізація правил |
Рішення фіксується за обмеженнями, а не за сильними сторонами: керований сервіс упирається у вимоги до зберігання даних, платформа всередині периметра — в обсяг супроводу, доопрацювання поточного контуру — в якість наявних інтеграцій. Тому розбір починаємо з вашого ландшафту захисту і лише потім пропонуємо варіант розгортання.
Етапи впровадження: від аудиту процесів до передачі в експлуатацію
Автоматизація виправдана там, де операції повторюються, а джерела подій зрозумілі. Тому AI SOAR починається з аудиту процесів: не зафіксувавши, які оповіщення зміна розбирає руками і скільки кроків іде на кожне, автоматизація закріпить наявний безлад. Нижче — порядок робіт, який ми проходимо на проєкті.
- Аудит процесів. Збираємо джерела подій і поточні ручні операції: як надходять оповіщення, як класифікуються, де втрачається час. На виході — карта потоків і перелік операцій, придатних для автоматизації.
- Проєктування реакцій. Для кожного класу інцидентів описуємо гілку: збагачення даними, ізоляція вузла, блокування облікового запису, повідомлення відповідального. Узгоджуємо межі — де рішення ухвалює система, а де обов'язкова ручна перевірка.
- Тестовий контур. Розгортаємо ізольоване середовище зі знеособленими даними, що повторює робочу топологію: помилка в сценарії не потрапляє в робоче середовище, відкат займає хвилини.
- Налаштування сценаріїв. Підключаємо джерела подій, налаштовуємо правила кореляції та пороги спрацювання, збираємо гілки обробки. Хибні спрацювання відсікаємо на розборі, а не на чергуванні.
- Перевірка на реальних інцидентах. Проганяємо сценарії на історичних журналах і на живому потоці, рахуємо частку оповіщень, закритих без людини, і час реакції. Знайдені прогалини закриваємо до передачі.
- Навчання та передача в експлуатацію. Віддаємо регламенти й інструкції щодо нетипових випадків, тренуємо зміну на тестовому контурі. Далі — супровід і доопрацювання сценаріїв за накопиченою статистикою.
Що передаємо: конфігурації, сценарії, регламенти та документація
Контур автоматизації SOC живе на експлуатації, а не на демонстрації: черговий інженер має розуміти, звідки надійшла подія, чому сценарій спрацював саме так і що робити, якщо він не спрацював.
Тому передаємо не лише працюючу систему, а й комплект, за яким її можна вести далі без нашої участі.
- Конфігурації — вивантаження правил кореляції, маршрутизації та пріоритизації подій з коментарями: видно, яке правило за що відповідає і що зміниться при його вимкненні.
- Схеми інтеграції — карта джерел подій і зовнішніх систем: які протоколи використовуються, де зберігаються облікові дані, які повтори налаштовані при недоступності джерела.
- Регламенти для зміни — покрокові інструкції на типові ситуації: первинне сортування, ескалація, ізоляція вузла, закриття інциденту, дії при хибному спрацюванні.
- Сценарії реагування — автоматизації із зазначенням тригерів, умов і меж: що система робить сама, а де обов'язкова перевірка людиною.
- Політики доступу — матриця ролей: хто бачить події, хто змінює правила, хто підтверджує автоматичні дії, як видаються й відкликаються права.
- Документація — опис архітектури, потоків даних, точок відмови та порядку оновлення компонентів.
- Порядок перевірки — набір тестових подій, якими зміна підтверджує працездатність сценаріїв після змін, і критерії, за яких оновлення відкочується.
- Журнал змін — історія правок правил з автором і причиною: розбір інциденту спирається на факти, а не на пам'ять.
Кейс: як скоротили час реакції чергової зміни
До впровадження: черговий як вузьке місце
На старті кейсу впровадження зміна отримувала близько 4 000 спрацювань на добу від SIEM — різної достовірності та без спільної пріоритизації.
Аналітик вручну зіставляв подію з активами, піднімав контекст за поштою та заявками, і на первинний розбір ішло 35–45 хвилин, а в нічні години черга просто чекала ранку. Передача зміни трималася на переказі в чаті: контекст губився, і один інцидент інколи розбирали двічі.
Що змінили
Зібрали бібліотеку сценаріїв реагування на спільній таксономії тактик MITRE ATT&CK: класифікація події, автоматичне збагачення даними про актив і обліковий запис, ізоляція хоста й блокування облікового запису за заздалегідь узгодженими порогами. Збагачення виконується паралельно — поки аналітик відкриває картку, контекст уже зібрано.
Кожна дія автомата пишеться в журнал із зазначенням сценарію та вхідних даних, тому розбір інциденту не перетворюється на археологію. Передачу зміни перевели в чек-ліст: відкриті інциденти, відкладені рішення, спрацьовані винятки.
Метрики до і після
Середній час реакції скоротився з 42 до 7 хвилин, медіана закриття однотипних інцидентів — з 6 годин до 40 хвилин. Частка подій, закритих без участі людини, зросла до двох третин; ручних дій на інцидент стало менше в 4 рази. Навантаження на нічну зміну вирівнялося: черга перестала накопичуватися до ранку.
Де було складніше, ніж очікували
Дві ділянки потребували окремих ітерацій. Перша — джерела з нестандартними форматами журналів: частину довелося приводити до спільного вигляду на стороні збору, інакше класифікатор помилявся на однотипних подіях.
Друга — довіра аналітиків до автомата: спочатку частина сценаріїв працювала в режимі «запропонувати дію», а не «виконати», і лише після накопиченої статистики ми знімали підтвердження за кроками.
Що робити, якщо власна автоматизація реагування вже розгорнута?
Власна автоматизація вже розгорнута — це не привід починати з нуля, а готовий фундамент: частина сценаріїв описує ваші процеси точніше за будь-який типовий набір.
Тому ми не вимикаємо наявний контур, а успадковуємо його — підключаємося до тих самих джерел подій, зберігаємо маршрутизацію оповіщень, права сервісних облікових записів і нумерацію інцидентів, щоб історія реагування не розірвалася.
Далі — ревізія сценаріїв: проводимо інвентаризацію того, що працює зараз. Дивимося, які правила реально спрацьовують, яка частка хибних, де аналітик усе одно доробляє руками, які сценарії дублюють одне одного за змістом.
Кожне правило отримує вердикт — залишити як є, переписати логіку або відправити в архів. На практиці помітна частина самописних правил або не спрацьовувала жодного разу, або конфліктує із сусідніми і глушить корисні оповіщення.
Міграція сценаріїв відбувається поетапно й без простою зміни. Нові правила запускаємо в тіньовому режимі: вони бачать ті самі події, але дій не виконують — порівнюємо, що запропонувала автоматика і що зробив черговий аналітик.
Контур на Shuffle чи на самописних скриптах розбирається однаково: логіка переноситься по одній гілці, зі збереженням точок ескалації та можливістю повернутися до попереднього правила одним перемиканням.
Успадкування контуру завершується передачею в супровід, а не запуском.
Фіксуємо регламент: хто додає сценарій, на яких тестових подіях він перевіряється, за якими метриками видно деградацію — час до першої автоматичної дії, частка інцидентів, закритих без людини, кількість відкатів автоматики. Далі контур розвивається разом з вашими процесами, а не залишається замороженою конфігурацією.
Інтеграції з наявними системами та хибні спрацювання
SOAR не приносить користі сам собою — він працює рівно настільки, наскільки повно джерела подій віддають дані й наскільки чисто вони приведені до спільної схеми.
На старті проєкту майже завжди спливають ті самі технічні сумніви: що робити із системами, у яких немає машинного доступу, як утримати точність спрацювань після перших тижнів роботи і хто оновлює сценарії, коли змінюється інфраструктура.
Що робити з джерелами подій, у яких немає API?
Доступні системи підключаємо напряму й нормалізуємо події в єдину схему. Для закритих рішень ставимо агент-колектор на вивантаження або розбираємо текстові журнали — джерело стає в спільний потік, а не залишається осторонь.
Варіанти, де машинного доступу немає взагалі, переводимо в напівручний режим: аналітик отримує готовий плейбук і підтверджує дію, замість того щоб збирати контекст вручну.
Як знижуєте частку хибних спрацювань?
Кожне спрацювання збагачується контекстом: хто і з якого вузла, що відбувалося на цьому вузлі раніше, чи повторюється шаблон. Одиночний сигнал залишається спостереженням, автодія запускається при збігу кількох ознак.
Перші тижні система працює в режимі накопичення: ми звіряємо її рішення з висновками аналітиків і налаштовуємо пороги, поки частка хибних не опуститься до узгодженого рівня.
Що входить у супровід і як оновлюються сценарії?
Плейбуки версіонуються, у кожного є регресійний набір подій — правка не йде в роботу, поки не пройде його повністю. При зміні інфраструктури додаємо нові джерела й правила, старі виводимо з експлуатації, а не накопичуємо.
Відкат до попередньої ревізії займає хвилини: якщо оновлений сценарій поводиться інакше, повертаємо попередню логіку без зупинки чергування.
Обговоримо вашу задачу і повернемося з оцінкою та планом
Розмову починаємо із задачі, а не з презентації: які класи інцидентів потрібно закривати автоматично, скільки подій на добу надходить у контур і які дії аналітик виконує руками найчастіше.
Від вас на старті достатньо переліку джерел подій, способів інтеграції з ними, поточних регламентів реагування та двох-трьох розібраних інцидентів із таймінгом за кроками.
Далі уточнюємо те, що рідко описано в документації: повноту нормалізації подій, якість довідників активів і облікових записів, розмежування прав на автоматичні дії.
Якщо інтеграції різнорідні, починаємо з аудиту поточного контуру — він показує, які сценарії автоматизуються одразу, а які впруться в брак даних.
- карту джерел подій і готовності інтеграцій, з явними прогалинами в даних;
- перелік сценаріїв реагування, відсортованих за частотою спрацювання та трудозатратами;
- план робіт за етапами — від аудиту контуру до перших автоматизованих сценаріїв;
- оцінку строків за кожним етапом і склад команди під нього;
- опис пілотного етапу: які сценарії беремо першими і як вимірюємо результат;
- вимоги до доступів, тестових даних і середовищ, щоб пілот не застряг на узгодженнях;
- критерії приймання: частка інцидентів, закритих без участі аналітика, і час реакції.
Опишіть задачу у вільній формі — повернемося з оцінкою строків і планом робіт.
