Incident Response для українського бізнесу: план який працює коли атака реальна

З 2022 року Україна — найбільш атакована кіберпростором країна у світі. DDoS на банківський сектор, ransomware проти держпідприємств, supply chain атаки через постачальників ПЗ, злам облікових записів AD/LDAP держустанов. CERT-UA щомісяця фіксує сотні підтверджених інцидентів — і це лише ті, про які повідомляють.

Для більшості компаній питання не в тому, чи буде атака. Питання в тому, що відбудеться в перші 30 хвилин після того, як вона почнеться.

Більшість організацій не знають відповіді на це питання заздалегідь. Технічна команда реагує на те що бачить. Керівництво дізнається пізніше. Юридичний відділ підключається ще пізніше. НБУ або Держспецзвʼязку не повідомляють взагалі — або повідомляють через тижень. Клієнти дізнаються з новин.

Така ситуація — це не відсутність компетентних людей. Це відсутність структури. Incident Response plan (IR plan) — саме ця структура.

Реальність 2022–2026: атаки як норма, а не виняток

Кілька типів атак, які актуальні для українського бізнесу прямо зараз:

DDoS — масові атаки на банківський сектор, телеком, держпортали. Мета: недоступність сервісів у критичний момент. Банки з хорошим IR plan перемикаються на резервні канали за 15-20 хвилин. Без плану — збій на годинник і вище.

Ransomware — шифрування даних і інфраструктури з вимогою викупу. Особливість UA-контексту: частина атак не монетизаційна, а деструктивна (wiper). Відновлення без підготовленого плану займає тижні.

Supply chain attacks — компрометація через постачальника ПЗ або IT-аутсорс. Ви не є першочерговою ціллю, але стаєте жертвою через довірений сторонній доступ.

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

Credential harvesting + AD compromise — поступовий злам через фішинг, закріплення в мережі, латеральний рух. Виявляється пізно, наслідки — широкі.

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

Чому IT-команда не дорівнює Incident Response

У більшості організацій є IT-команда. Сповіщення налаштовані, тікети створюються, збої усуваються. Це IT-операції — необхідна основа, але не IR.

Відмінності суттєві і виявляються тільки під час реального інциденту:

Класифікація. IT-команда вміє визначати, що щось зламалось. IR-команда вміє визначати, чи є це інцидентом для регулятора, що вимагає сповіщення, і в які строки. Ці рішення приймаються з частковою інформацією, під тиском, у перші 30-60 хвилин. Команда, яка не відпрацьовувала цей процес заздалегідь, буде його дебатувати замість виконувати.

Збереження доказів. IT-операції прагнуть прибрати проблему — перезавантажити сервер, відновити з бекапу, перевстановити систему. IR-процес вимагає спочатку зафіксувати: зняти образ системи, зберегти логи, зафіксувати мережеві зʼєднання. Якщо прибрати проблему до того, як зафіксувати докази — регуляторне розслідування і судове провадження втрачають матеріал.

Регуляторне повідомлення. Повідомити НБУ або CERT-UA — не те саме, що написати тікет у систему. Є форма, є строки, є вимоги до змісту. Хтось конкретний повинен знати, як це робити, і мати повноваження.

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

Що вимагає українське законодавство

НБУ Постанова №143 — для фінансового сектору

Постанова НБУ №143 (та суміжні нормативні акти щодо кібербезпеки банків) встановлює вимоги до банків і небанківських фінансових установ щодо управління операційними ризиками та кіберінцидентами. Ключові вимоги:

• Наявність задокументованого плану реагування на інциденти

• Внутрішні процедури класифікації та ескалації

• Повідомлення НБУ про суттєві операційні інциденти у встановлені строки

• Ведення реєстру інцидентів і звітність

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

Закон "Про основні засади забезпечення кібербезпеки України"

Закон визначає об'єкти критичної інфраструктури (ОКІ) і встановлює для них вимоги щодо:

• Побудови системи управління інформаційною безпекою

• Взаємодії з CERT-UA в разі інцидентів

• Повідомлення про кіберінциденти відповідно до вимог Держспецзвʼязку

Для операторів критичної інфраструктури — енергетика, телеком, водопостачання, транспорт, держустанови — вимоги щодо IR є обовʼязковими, а не рекомендаційними.

Повідомлення CERT-UA та Держспецзвʼязку

CERT-UA — Урядова команда реагування на компʼютерні надзвичайні події — є основним національним CERT. Для суб'єктів із переліку ОКІ повідомлення CERT-UA про підтверджений інцидент є обов'язковим.

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

Держспецзвʼязку (Державна служба спеціального зв'язку та захисту інформації) — регулятор у сфері технічного захисту інформації. Вимоги до звітності перед Держспецзвʼязку залежать від класу інформаційної системи і наявності держтаємниці.

GDPR Article 33-34 — для тих, хто обробляє дані EU-резидентів

Якщо ваша організація обробляє персональні дані громадян ЄС — клієнтів, партнерів, співробітників — застосовується GDPR навіть без ліцензії ЄС. У разі витоку або компрометації персональних даних:

• Article 33: повідомлення наглядового органу (у вашій юрисдикції або юрисдикції ЄС) протягом 72 годин з моменту виявлення

• Article 34: повідомлення постраждалих осіб без невиправданої затримки, якщо інцидент несе високий ризик для їх прав

Ці зобов'язання паралельні, а не послідовні. IR-план повинен враховувати їх одночасно з внутрішньою технічною відповіддю.

SANS PICERL / NIST SP 800-61 — практичний фреймворк

SANS PICERL — Preparation (Підготовка), Identification (Ідентифікація), Containment (Локалізація), Eradication (Викорінення), Recovery (Відновлення), Lessons Learned (Уроки) — шестифазна модель, що є основою більшості IR-планів. Вона узгоджена з NIST SP 800-61 Rev 2, який об'єднує три середні фази в один блок. Для аудиторів НБУ і перевірок на відповідність вимогам кібербезпеки обидва фреймворки є визнаними точками відліку.

Phase 1: Preparation / Підготовка

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

• Визначення IR-команди і ролей (хто є Incident Commander, хто Technical Lead, хто відповідає за регуляторну комунікацію)

• Документування критеріїв класифікації інцидентів відповідно до вимог НБУ/Держспецзвʼязку

• Встановлення каналів звʼязку — захищений месенджер, резервна пошта, контакти CERT-UA

• Підготовка шаблонів повідомлень для НБУ, CERT-UA, клієнтів

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

• Проведення tabletop-навчань мінімум раз на рік

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

Phase 2: Identification / Ідентифікація

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

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

IR-план повинен містити задокументовані критерії класифікації — зокрема порогові значення з НБУ Постанови №143 і визначення ОКІ-інциденту для Держспецзвʼязку. Ці критерії повинні бути в плані, а не в голові окремого фахівця.

Phase 3: Containment / Локалізація

Локалізація обмежує поширення і вплив. Дві окремі дії:

Короткострокова локалізація: ізоляція скомпрометованого сегменту мережі, відключення уражених хостів від AD/LDAP, блокування підозрілих облікових записів. Мета — зупинити поширення.

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

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

Phase 4: Eradication / Викорінення

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

Найпоширеніша помилка: перехід до Recovery до завершення Eradication. Результат — повторна компрометація через тиждень. Для ransomware це означає повторне шифрування вже відновлених систем.

Phase 5: Recovery / Відновлення

Відновлення повертає системи в робочий стан і підтверджує стабільність. RTO (Recovery Time Objective) — цільовий показник часу відновлення — повинен бути визначений заздалегідь у плані безперервності бізнесу і підтверджений на практиці.

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

Phase 6: Lessons Learned / Уроки

Аналіз після інциденту — обовʼязкова фаза, а не опціональна. Він повинен відповісти на питання: що сталося, яка хронологія, де були прогалини у виявленні, локалізації, комунікації. Конкретні зміни до IR-плану або технічних засобів захисту — мають бути задокументовані з відповідальними і строками.

Це ж документ стає основою для підсумкового звіту перед регулятором, якщо інцидент підпав під обовʼязкове повідомлення.

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

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

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

Комунікація під час інциденту: регулятор, клієнти, публіка

Три паралельні треки, а не послідовні кроки.

НБУ / CERT-UA / Держспецзвʼязку. Використовуйте встановлену форму і процес. Будьте точними щодо часу виявлення, характеру інциденту, уражених систем, вжитих заходів. Не спекулюйте про причини, які ще не встановлені — використовуйте "розслідується". Не применшуйте масштаб: регулятор реагує жорсткіше на те, що початковий звіт суттєво занижував наслідки, ніж на початковий звіт зі словами "оцінюємо".

Для CERT-UA є практика оперативного обміну індикаторами компрометації (IoC) — якщо атака має ознаки стейт-актора або ширшої кампанії, CERT-UA зацікавлений у взаємодії і може надати додаткові дані.

Клієнти. Зобов'язання повідомити клієнтів залежить від характеру інциденту і того, чи були задіяні їх дані. Якщо є підстави вважати, що персональні дані клієнтів скомпрометовані — оцінка повинна відбутися в перші години. Для організацій з EU-клієнтами або EU-даними паралельно застосовуються GDPR Article 33-34. Ці зобов'язання керуються одночасно, а не після завершення технічної відповіді.

Публіка і ЗМІ. Не кожен інцидент потребує публічної комунікації. Але де потрібна — банківський DDoS із відомим збоєм, витік клієнтських даних — відповідальна за комунікацію особа повинна мати підготовлені заздалегідь holding statements і чіткий процес узгодження. Імпровізовані заяви під час кризи — це окремий ризик для репутації поверх самого інциденту.

Tabletop exercises: як проводити в Україні

Tabletop exercise — структоване навчання, де команда проходить через симуляцію інциденту і відпрацьовує рішення без реального ризику. Регуляторна обізнаність недостатня: команда повинна вміти виконати класифікацію і повідомлення під тиском часу, а не просто знати, що таке CERT-UA.

Ефективне tabletop для UA-контексту:

• Сценарій відповідає реальному профілю ризику — ransomware в банку, DDoS на критичну систему, компрометація постачальника ПЗ

• Проводиться в реальному часі з тиском — не академічна дискусія у зручному темпі

• Учасники приймають рішення про класифікацію з частковою інформацією (як у реальному інциденті) і застосовують критерії з IR-плану

• Включає крок складання повідомлення CERT-UA або НБУ за шаблоном

• Фіксує прогалини і конкретні дії для усунення — з відповідальними і строками

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

Документація: що зберігати і скільки

IR-план вимагає не лише виконання — вимагає фіксації.

Мінімальний перелік документів по інциденту:

• Журнал інциденту: хронологія подій, рішення, відповідальні

• Збережені логи і криміналістичні образи (до, під час, після)

• Всі повідомлення регуляторам: CERT-UA, НБУ, Держспецзвʼязку — з позначками часу

• Внутрішні комунікації (листи, повідомлення в захищеному каналі) за весь час інциденту

• Документація вжитих заходів: локалізація, викорінення, відновлення

• Звіт після інциденту (Lessons Learned)

Щодо строків зберігання: для банків під регуляторними вимогами НБУ — мінімум 3 роки. Для систем ОКІ — відповідно до вимог Держспецзвʼязку і профілю інформаційної системи. Для інцидентів із GDPR-складовою — відповідно до вимог наглядового органу, мінімум 3 роки.

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

Кейс з практики

Середній за розміром банк, 2023. Початок атаки — DDoS проти систем онлайн-банкінгу у пʼятницю вдень. Перший симптом — сповіщення від клієнтів через колл-центр, не від SIEM.

Без IR-плану: технічна команда починає аналізувати, зʼясовують масштаб — 40 хвилин. Починають фільтрувати трафік — ще 30 хвилин. Пишуть керівництву — через годину. НБУ — наступного дня.

З IR-планом: виявлення через SIEM за 8 хвилин. Incident Commander активований по протоколу. Класифікація за критеріями НБУ — 15 хвилин. Резервний канал обслуговування клієнтів увімкнений. Повідомлення НБУ — у встановлені строки. Загальна тривалість впливу на клієнтів — менше 45 хвилин проти кількох годин у порівнянному випадку без плану.

Банк залишився анонімним відповідно до NDA. Цифри — з реального постмортему, який вони нам надали після проекту.

Якщо у вас є EU-ліцензія: DORA Article 19

Для фінансових установ з ліцензією або операційною присутністю в ЄС застосовується DORA. Article 19 встановлює трьохетапну структуру звітування:

• Початкове повідомлення — протягом 4 годин з моменту класифікації як major ICT incident, максимум 24 години з моменту виявлення

• Проміжний звіт — за запитом компетентного органу або через 72 години після початкового повідомлення

• Підсумковий звіт — протягом одного місяця після проміжного

4-годинний відлік з моменту класифікації — жорстке обмеження. Якщо класифікація відбулась о 09:00, початкове повідомлення повинно надійти до регулятора до 13:00. Більшість організацій не структурували IR-процес так, щоб виконати це в реальному інциденті без підготовки.

Якщо ви обробляєте дані EU-клієнтів: NIS 2 Article 23 + GDPR

Навіть без EU-ліцензії — якщо ваша організація обробляє персональні дані резидентів ЄС або є частиною ланцюжка постачання EU-regulated entity — можуть застосовуватись NIS 2 і GDPR.

NIS 2 Article 23 вимагає:

• Раннє попередження протягом 24 годин з моменту усвідомлення значного інциденту

• Повне повідомлення протягом 72 годин з моменту усвідомлення

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

Якщо ваша організація будує або переглядає IR plan — для виконання вимог НБУ, підготовки до DORA, або просто тому що хоче знати, що відбудеться в перші 30 хвилин реального інциденту — ми працюємо з банками, фінтех-компаніями і операторами критичної інфраструктури. Звертайтесь для консультації.