Кіберінцидент рідко починається з повідомлення «вас зламали». Зазвичай першим сигналом стає підозрілий вхід у корпоративний обліковий запис, несподіване правило пересилання пошти, відключений EDR-агент, недоступний сервер або скарга співробітника на незвичайний запит багатофакторної автентифікації.

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

Часу для цих рішень стає дедалі менше. У найшвидших випадках, які розслідувала Unit 42, зловмисникам знадобилося 72 хвилини, щоб пройти шлях від початкового доступу до підтвердженого вивантаження даних. Це приблизно в чотири рази швидше, ніж роком раніше. Мова йде не про середній час для всіх атак, а про найшвидші випадки, але цей показник добре демонструє, наскільки сильно звузилися часові рамки для захисників. У наших же розслідуваннях нам доводилося бачити атаки на інфраструктуру AWS, що тривали менше ніж 10 хвилин. Зловмисник, отримавши ключ, одразу ж починав вивантаження даних. Йому знадобилося всього 6 хвилин, щоб розпочати вивантаження даних із бакета компанії.

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

Що змінилося до 2026 року

Атака більше не обмежується однією системою

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

Навіть після ізоляції зараженого ноутбука у нього можуть залишитися:

  • активна хмарна сесія;
  • refresh-токен;
  • OAuth-дозвіл;
  • ключ API;
  • скомпрометований службовий обліковий запис;
  • делегований адміністративний доступ;
  • резервний канал управління через легітимний хмарний сервіс.

За даними Unit 42, у 87% досліджених інцидентів для встановлення того, що сталося, потрібно було зіставити докази щонайменше з двох різних джерел, а в найскладніших випадках — з десяти. Це означає, що розслідування більше не можна обмежувати одним комп’ютером або одним журналом подій: необхідно одночасно аналізувати дані ідентифікації, кінцевих точок, мережі, хмари та SaaS. (Unit 42)

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

Ідентичності та вразливості однаково важливі

Сучасний інцидент не має єдиного універсального вектора проникнення.

За даними Unit 42, 65% первинних проникнень у її розслідуваннях були пов’язані з identity-based techniques: викраденими обліковими даними, маніпуляціями з MFA, викраденням сесій, видаванням себе за співробітника служби підтримки або зловживанням легітимним віддаленим доступом. (Unit 42)

Водночас Verizon DBIR 2026 називає експлуатацію програмних вразливостей провідним початковим вектором у своїй вибірці: вона фігурувала в 31% витоків і вперше випередила викрадені облікові дані.

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

Постачальники стали частиною поверхні атаки

За даними Verizon DBIR 2026, треті сторони брали участь у 48% витоків — на 60% частіше, ніж роком раніше. У ролі точки входу може виступити постачальник програмного забезпечення, MSP, інтегратор, хмарний сервіс або підрядник із легітимним доступом.

Організація повинна заздалегідь розуміти:

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

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

Вимагання більше не вимагає шифрування

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

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

ШІ прискорює обидві сторони

ШІ допомагає зловмисникам швидше аналізувати поверхню атаки, адаптувати соціальну інженерію, шукати вразливості та створювати шкідливий код. Verizon DBIR 2026 виділяє 15 технік атак, які вже посилюються за допомогою генеративного ШІ.

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

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

Нова парадигма: реагування починається ще до інциденту

У квітні 2025 року NIST випустив SP 800-61 Revision 3, який замінив посібник 2012 року.

Головна зміна полягає в тому, що реагування на інциденти більше не розглядається як окремий лінійний процес, який запускається після отримання сповіщення. Воно вбудовано в загальну модель управління кіберризиками NIST CSF 2.0 і пов’язане з усіма шістьма її функціями:

Govern, Identify, Protect, Detect, Respond та Recover.

Управління ролями, інвентаризація активів, сегментація, резервне копіювання, договори з постачальниками та ведення журналів є не допоміжними заходами, а частиною готовності до інциденту. (NIST Computer Security Resource Center)

11 червня 2026 року NIST також опублікував IR 8374 Revision 1 — оновлений профіль управління ризиками ransomware на базі CSF 2.0. Документ об’єднує підготовку, захист, реагування та відновлення в єдиний цикл управління ризиками. (NIST Computer Security Resource Center)

Головний висновок простий:

Правильне реагування починається задовго до першого сповіщення.

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

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

Перші 60 хвилин: не лікувати систему наосліп

На початку інциденту команда майже завжди має неповну інформацію.

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

1. Призначте керівника інциденту

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

Необхідний єдиний response bridge та призначений керівник інциденту — Incident Commander.

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

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

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

2. Перейдіть на надійний канал зв’язку

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

Використовуйте заздалегідь підготовлений позасмуговий канал. Через потенційно скомпрометовані системи не слід передавати:

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

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

3. Підтвердьте інцидент і визначте його початковий масштаб

Не потрібно чекати на повну картину, щоб почати реагувати.

Попередня оцінка має дати відповідь щонайменше на п’ять питань:

  1. Що саме було виявлено?
  2. Які користувачі, пристрої та сервіси можуть бути зачеплені?
  3. Чи триває активність зловмисника?
  4. Чи існує ризик зупинки критичного процесу?
  5. Чи є ознаки викрадення даних, знищення резервних копій або компрометації привілейованого доступу?

Класифікація може змінюватися в міру розслідування. Головне — якомога раніше сформувати робочу гіпотезу та визначити пріоритети.

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

4. Ізолюйте, але не знищуйте докази

Ізоляція та відключення — це не одне й те саме.

Уражений хост зазвичай слід відключити від мережі за допомогою EDR, NAC, VLAN, комутатора або хмарної політики. Але без необхідності не варто негайно:

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

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

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

5. Створіть єдину часову шкалу

Записуйте кожну значущу подію:

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

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

Без часової шкали розслідування швидко перетворюється на набір суперечливих спогадів.

6. Захистіть резервні копії

Під час інциденту з ransomware системи резервного копіювання часто стають однією з перших цілей зловмисника.

Не починайте масове відновлення, доки не з’ясуєте:

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

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

Під час активного інциденту команда DFIR PWN-ALL може взяти на себе технічну координацію: первинне стримування, збереження доказів, визначення масштабу компрометації та підготовку безпечного плану відновлення. Практика компанії охоплює роботу з ransomware, крадіжкою даних, BEC, захопленням облікових записів та компрометацією хмарних середовищ.

Реагування має відбуватися за паралельними напрямками

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

У реальному інциденті ці напрямки повинні розвиватися одночасно.

Технічний напрямок

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

Управлінський потік

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

Юридичний та комунікаційний потік

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

Конкретні вимоги різняться залежно від галузі, договорів та юрисдикцій. Тому правова оцінка не повинна чекати на остаточний forensic report.

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

Identity takeback: повернути контроль над ідентичностями

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

Перевірці підлягають:

  • привілейовані та аварійні облікові записи;
  • активні сесії та токени оновлення;
  • нові або змінені методи MFA;
  • OAuth-додатки та надані дозволи;
  • суб’єкти послуг та ідентифікатори робочих навантажень;
  • правила федерації;
  • політики умовного доступу;
  • делегований адміністративний доступ;
  • ключі API, сертифікати та секрети CI/CD;
  • правила пересилання пошти;
  • зареєстровані пристрої;
  • доступ підрядників.

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

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

Спочатку створюється чиста робоча зона з перевіреними пристроями, окремим каналом зв’язку, контрольованими обліковими записами та автономним журналюванням. Лише після цього розпочинається coordinated identity takeback.

Хмара та SaaS вимагають окремого посібника

Хмарний інцидент не можна розслідувати як звичайне зараження робочої станції.

Частина доказів існує лише в журналах провайдера і може зберігатися обмежений час. У перші години слід зберегти:

  • журнали входу та аудиту;
  • історію змін IAM;
  • журнали control plane;
  • події пошти та спільної роботи;
  • зміни політик та мережевих правил;
  • відомості про створення ключів і токенів;
  • знімки дисків та конфігурацій;
  • дані SaaS-додатків, пов’язаних через SSO або OAuth.

Окремо необхідно перевірити створення нових адміністраторів, зміну федерації, видачу довготривалих токенів, OAuth consent grants, відключення захисних політик, запуск нових хмарних ресурсів та експорт даних.

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

PWN-ALL використовує окремі процеси для розслідування компрометації Microsoft 365, Google Workspace, хмарної інфраструктури та корпоративних облікових записів. Це дозволяє аналізувати дії, які могли не залишити слідів на традиційних кінцевих точках.

Як використовувати ШІ під час розслідування

ШІ може прискорити:

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

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

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

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

ШІ може запропонувати напрямок розслідування. Відповідальність за висновок залишається за людиною.

Відновлення — це не повернення до попереднього стану

Найнебезпечніша фраза під час інциденту:

«Просто відновимо все з резервної копії».

Якщо відновити колишню архітектуру разом із колишніми вразливостями, скомпрометованими секретами та помилками конфігурації, зловмисник може повернутися.

Безпечне відновлення виконується поетапно:

  1. Створюється чисте адміністративне середовище.
  2. Відновлюється контроль над ідентичностями.
  3. Закривається початковий вектор проникнення.
  4. Видаляються механізми закріплення.
  5. Здійснюється ротація секретів, ключів, токенів та сертифікатів.
  6. Перевіряються резервні копії.
  7. Відновлюються критичні залежності.
  8. Системи підключаються контрольованими групами.
  9. На кожному етапі перевіряються безпека та працездатність.
  10. Після запуску триває посилений моніторинг.

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

Доступність системи ще не означає завершення інциденту.

У рамках відновлення PWN-ALL оцінює чисті резервні копії, можливість перебудови систем, доступні варіанти розшифрування та відновлення ключів, а потім формує пріоритети повернення інфраструктури в експлуатацію. Результат залежить від сімейства ransomware, стану систем, збережених доказів та якості резервних копій, тому повне розшифрування або повернення всіх даних не можуть бути гарантовані.

Якщо організація розглядає можливість виплати викупу

Професійний підхід до ransomware не повинен ґрунтуватися на тому, що виплата виключена за будь-яких обставин.

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

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

При цьому виплата — це не технічна дія, а виняткове управлінське рішення в умовах кризи.

Спочатку необхідно перевірити альтернативи

Перед ухваленням рішення слід оцінити:

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

Твердження зловмисника про те, що виплата є єдиним виходом, не можна приймати без незалежної технічної перевірки.

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

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

Порівнювати лише розмір викупу та вартість відновлення недостатньо.

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

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

Правові та санкційні обмеження оцінюються окремо

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

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

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

Комунікація зі зловмисником має бути контрольованою

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

За відповідної домовленості PWN-ALL може супроводжувати контрольовану комунікацію, допомагаючи:

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

Такий супровід не замінює юридичну перевірку, не означає рекомендації платити та не надає команді DFIR права приймати рішення від імені замовника.

Заяви зловмисника необхідно перевіряти

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

Але навіть успішна перевірка не гарантує повноцінного відновлення.

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

Отримані інструменти слід аналізувати та тестувати в ізольованому середовищі.

Переговори не зупиняють розслідування

Комунікація зі зловмисником не замінює реагування.

Паралельно необхідно продовжувати:

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

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

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

Чого не можна робити під час активного інциденту

Вимкнути всю інфраструктуру без плану

Це може знищити «volatile evidence», ускладнити аналіз та зупинити процеси, що не зазнали впливу. Ізоляція має бути точковою або сегментною та ґрунтуватися на оцінці ризику.

Перевстановлювати системи до збору даних

Швидке форматування видаляє сліди початкового доступу, закріплення та переміщення зловмисника.

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

Шкідливий файл може бути лише одним із інструментів. Необхідно перевірити ідентичності, хмарні сесії, токени, віддалений доступ, поштові правила, SaaS-додатки та інфраструктуру управління.

Вважати зміну пароля повним стримуванням

У зловмисника можуть залишитися активні сесії, токени оновлення, дозволи OAuth або альтернативні методи MFA.

Використовувати скомпрометовані канали зв'язку

Зловмисник може читати повідомлення команди, адаптувати тактику та знищувати сліди.

Самостійно зв’язуватися з вимагачем

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

Відновлювати системи до закриття точки входу

В іншому разі відновлення перетворюється на повторний інцидент.

Вважати відсутність шифрування відсутністю витоку

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

Довіряти резервній копії без перевірки

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

Публікувати непідтверджені висновки

Не можна обіцяти відсутність витоку, доки це не підтверджено розслідуванням.

Оголошувати середовище чистим через відсутність нових сповіщень

Відсутність подій може означати не відсутність зловмисника, а недостатню видимість.

Як вимірювати готовність

Кількість закритих сповіщень майже нічого не говорить про здатність організації витримати серйозну атаку.

Більш корисні показники:

  • час до підтвердження інциденту;
  • час до призначення Incident Commander;
  • час до першої ізоляції;
  • час до відкликання скомпрометованих сесій;
  • час отримання хмарних журналів;
  • час перевірки чистої резервної копії;
  • частка критичних систем із достатньою телеметрією;
  • повнота часової шкали;
  • час усунення початкового вектора;
  • частка вжитих заходів після post-incident review.

Важливо вимірювати не тільки швидкість, але й якість рішень:

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

Після інциденту потрібен не формальний документ «проведено бесіду», а конкретний план змін із зазначенням відповідальних осіб, термінів та критеріїв перевірки.

Мінімальна готовність організації у 2026 році

До інциденту компанія повинна мати:

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

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

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

Реагування — це управління невизначеністю

Під час атаки рідко вдається одразу отримати всі відповіді.

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

Інцидент неможливо зробити повністю передбачуваним.

Але можна зробити передбачуваною роботу команди.

Коли потрібна зовнішня команда реагування

PWN-ALL долучається до інцидентів, у яких важливі швидкість, збереження доказів та контрольоване відновлення:

  • ransomware та вимагання без шифрування;
  • крадіжка та оприлюднення даних;
  • BEC та компрометація корпоративної пошти;
  • захоплення облікових записів;
  • компрометація Microsoft 365 та Google Workspace;
  • атаки на хмарну інфраструктуру;
  • злом веб-додатків та серверів;
  • інциденти через постачальників та підрядників.

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

У разі активного інциденту:

Не вимикайте уражені системи, не видаляйте артефакти, не відповідайте зловмиснику самостійно та не розпочинайте масове відновлення до проведення первинної оцінки.

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