SIEM і SOC у зв'язці: як події стають керованими інцидентами

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

Подія, сигнал тривоги, інцидент: три різні речі

Ці три слова плутають найчастіше, хоча між ними — принципова різниця:

• Подія (event) — будь-який зафіксований факт: вхід, з'єднання, зміна файлу, спрацювання правила. Переважна більшість подій цілком нормальні.
• Сигнал тривоги (alert) — ланцюжок подій, який збігся з правилом і потребує перевірки. Частина таких сигналів виявиться хибною.
• Інцидент (incident) — підтверджений випадок, який реально загрожує активам і вимагає дій.

Головне тут ось що: перехід між рівнями — не автоматика, а рішення людини. Машина може підняти тривогу, але оголосити інцидент і запустити реагування має той, хто відповідає за наслідки. Не випадково ISO/IEC 27035 виділяє «оцінювання й рішення» в окрему фазу процесу — між виявленням і реагуванням.

Як називають цей процес

У технічних завданнях і каталогах те саме звучить по-різному:

• управління подіями та інформацією безпеки;
• система управління інформацією про події безпеки;
• управління інцидентами та подіями безпеки.

Це варіанти перекладу однієї англійської назви — Security Information and Event Management. Ідеться про технічну частину зв'язки, платформу кореляції; детальніше — у матеріалі SIEM: що це.

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

Шлях від сигналу до керованого інциденту

1. Виявлення. Платформа зіставляє журнали різних джерел і піднімає тривогу за правилом.
2. Тріаж. Черговий аналітик розбирає потік: справжнє чи хибне.
3. Класифікація й пріоритет. Підтвердженому випадку призначають тип і терміновість.
4. Ескалація. Складне або серйозне передають вище — за визначеними критеріями.
5. Передача на реагування. Разом із випадком передають контекст, а не сам рядок тривоги.
6. Закриття й висновки. Розбір: чому спрацювало, чому мовчало раніше, які правила змінити.

Кроки 2–5 — саме те, що лишається за людиною. Далі розберемо кожен окремо.

Тріаж: три питання за п'ять хвилин

Тріаж — фільтр, який визначає ефективність усього подальшого. Аналітик відповідає на три питання:

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

Четверте питання економить найбільше часу: чи таке вже було? Якщо той самий сигнал уже розбирали вчора й закрили як хибний, повторний розбір — марна витрата години. Тому дедуплікація й пошук по історії належать до обов'язкових інструментів чергового.

Як це виглядає вночі

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

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

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

Сценарій опрацювання: чергового не можна лишати з чистим аркушем

Кожен тип тривоги має власний записаний сценарій опрацювання — короткий, на одну сторінку:

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

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

Правило без сценарію — кандидат на видалення. Якщо ніхто не знає, як діяти за тривогою, вона лише додає шуму.

Пріоритет визначає актив, а не тривога

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

Робоча схема — матриця «вплив × терміновість»:

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

Ескалація: за критеріями, а не за відчуттям

«Складний випадок» — не критерій. Критерії мають бути записані заздалегідь:

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

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

Передача на реагування: віддають контекст, а не рядок

Найчастіша поломка процесу — на стику. Команда реагування отримує «тривогу №4718» і починає розслідування з нуля, дублюючи роботу. Разом із випадком мають передати:

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

Останній рядок рятує розслідування частіше, ніж усі попередні. Як далі працює команда — у матеріалі як влаштований CSIRT.

SOC: IT-безпека в режимі 24/7

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

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

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

Хибні спрацювання й пропуски: небезпечні обидва

• Хибне спрацювання (false positive) — тривога без загрози. Головна шкода не в марній годині, а у втраті довіри: коли з десяти сигналів дев'ять порожні, десятий читають неуважно.
• Пропуск (false negative) — загроза без тривоги. Виявляється зазвичай найгіршим способом: із дзвінка клієнта або з публікації даних.

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

Саме цей зворотний контур перетворює гасіння пожеж на керований процес: висновок після випадку → зміна правила → менше шуму → більше уваги справжньому.

Типові поломки процесу

• Тривога без власника. Сигнал бачать усі, відповідає ніхто — черга росте до першого випадкового погляду.
• Черга без стелі. Коли ліміту немає, вона набухає до безкінечності, а найстаріші сигнали помирають нерозібраними.
• «Розберемося в понеділок». Проміжок від п'ятничного вечора до ранку понеділка — улюблений час зловмисника саме з цієї причини.
• Аналітик і адміністратор — одна людина. Той, хто адмініструє сервер, — сумнівний кандидат оцінювати тривогу з цього ж сервера: конфлікт інтересів очевидний.
• Розбір без наслідків. Висновок, який не змінив жодного правила, жодного доступу й жодної інструкції, — то радше протокол.

Метрики: як побачити, чи процес живий

• Час до виявлення (MTTD) — від першої дії зловмисника до тривоги.
• Час до реагування (MTTR) — від тривоги до локалізації.
• Час тріажу — скільки сигнал чекає на першу оцінку.
• Частка хибних — здоров'я правил.
• Покриття джерел — скільки критичних систем справді надсилає журнали.

Одне застереження. Гнатися лише за MTTR небезпечно: найшвидший спосіб «покращити» показник — закривати випадки поспіхом. Метрики читають парами: швидко й правильно.

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

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

SOC: інформаційна безпека як безперервний цикл

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

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