Інцидент-менеджмент для системи на UBD

Більшість організацій планує захист, але не планує інциденти. Це помилка: інциденти трапляються незалежно від якості захисту — питання не «якщо», а «коли». Підготовлена організація локалізує інцидент за години; непідготовлена — за тижні, з кратно більшими втратами і потенційними штрафами за порушення reporting-термінів.

Класифікація інцидентів

Стандартний підхід — 4 категорії за тяжкістю наслідків:

Playbook 1: компрометація облікового запису

Симптоми: входи з незвичних IP, дії за межами робочого часу, доступ до ресурсів, до яких користувач раніше не звертався.

Кроки:

1. Containment (5 хв): заблокувати обліковий запис, інвалідувати всі активні сесії, заблокувати IP-адреси активних сесій.
2. Сповіщення: SOC-співробітник, відповідальний за КСЗІ, користувач (по альтернативному каналу, не e-mail).
3. Investigation (1-4 год): переглянути WORM-журнал — що користувач робив за останні 24-72 години. Які записи переглядав, експортував, змінював.
4. Розголошення (за результатом): якщо доступ був до конфіденційних даних — оцінити обсяг, повідомити суб’єктів даних згідно з GDPR/Закон 2297-VI.
5. Eradication: зміна пароля, переоформлення токенів, перевірка наявності backdoor (новостворених облікових, доданих делегувань).
6. Recovery: відновлення доступу після перевірки.
7. Post-incident: аналіз причин (як скомпрометували?), оновлення політик.

Playbook 2: DoS-атака

Симптоми: різке збільшення RPS, p99 latency, відмови сервера, скарги користувачів на недоступність.

Кроки:

1. Containment: увімкнути rate-limiting на edge (CDN, WAF), блокування підозрілих IP за geo або pattern.
2. Аналіз: які запити аномальні (POST /api/auth/login з 1000 IP — credentials stuffing? GET /api/export — data exfiltration спроба?).
3. Mitigation: якщо це L7 attack — налаштування WAF правил. Якщо L3/L4 — звернення до upstream-провайдера або DDoS-захисту.
4. Сповіщення: для систем КІІ — повідомлення CSIRT-UA згідно з законодавством.
5. Recovery: поступове ослаблення rate-limit’ів, моніторинг рецидиву.

Playbook 3: Malware на адмін-станції

Симптоми: антивірус виявив підозрілий файл, нестандартні мережеві з’єднання з адмін-машини, рapidly increasing CPU/disk на станції.

Кроки:

1. Containment: ізолювати станцію від мережі (фізично або через NAC), не вимикати — потрібен memory forensics.
2. Перевірка blast radius: які системи доступні з цієї станції? UBD-адмін інтерфейс? — припустити, що адмін-облікові скомпрометовані.
3. Інвалідація: заблокувати адмін-облікові, що використовувалися зі скомпрометованої станції, зробити audit їх активності у UBD.
4. Forensics: створення копії диска і RAM для подальшого аналізу.
5. Eradication: повна переустановка ОС адмін-станції, відновлення з відомого чистого образу.

Playbook 4: Ransomware

Симптоми: зашифровані файли, ransom note, недоступність файлових серверів.

Кроки:

1. Immediate containment: ізоляція уражених сегментів, зупинка mass file operations, відключення share-доступу.
2. Не платити викуп. Не комунікувати з атакувальниками.
3. Аналіз обсягу: які файли зашифровані, чи зачеплено БД UBD, чи зачеплено бекапи.
4. Verify бекапів: чи бекапи доступні з не-уражених систем, чи самі не зашифровані.
5. Recovery: відновлення з останнього чистого бекапа. Можливо втрата кількох годин/днів даних.
6. Сповіщення: для КІІ — CSIRT-UA, для організацій під GDPR — DPA протягом 72 годин.
7. Post-mortem: як ransomware потрапив, які превентивні заходи треба запровадити.

Playbook 5: Internal abuse

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

Особливість: формально атаки немає — користувач має права. Складніший випадок.

Кроки:

1. Verify: чи дійсно це аномалія, чи це новий аспект його роботи. Розмова з керівником.
2. Сповіщення: служба безпеки, HR, юридичний відділ — координовано.
3. Preserve evidence: WORM-журнал містить повну історію — не модифікувати, бекапити.
4. Containment: обмеження доступу до критичних ресурсів до завершення розслідування.
5. Investigation: формальна процедура з юридичним супроводом — internal abuse часто переходить у судові справи.

Ролі і відповідальності

Ескалація та зовнішня координація

Для операторів КІІ — обов’язкові терміни сповіщень за NIS2 Article 23 (транспонована у національне законодавство):

• Early warning: 24 години після виявлення значного інциденту.
• Incident notification: 72 години з детальним описом.
• Final report: 1 місяць з аналізом причин і вжитими заходами.

Контакти CSIRT-UA, Адміністрації Держспецзв’язку, координаторів — частина пакету КСЗІ. Має оновлюватися щонайменше раз на рік.

Метрики SLA

• MTTD (Mean Time To Detect) — від факту інциденту до виявлення. Ціль: < 1 година для Cat 1.
• MTTC (Mean Time To Contain) — від виявлення до локалізації. Ціль: < 4 години для Cat 1.
• MTTR (Mean Time To Recover) — від виявлення до повного відновлення. Ціль: < 24 години для Cat 1.
• Cost per incident — для бюджетування і пріоритизації превентивних заходів.

Пост-аналіз

Кожен Cat 1/Cat 2 інцидент завершується формальним post-mortem. Шаблон:

• Timeline: коли що сталося, хто реагував.
• Root cause: технічна, процесна, людська.
• Що спрацювало добре.
• Що спрацювало погано.
• Конкретні action items з відповідальними і термінами.
• Blameless culture: фокус на процесах, не на покаранні людей.