Що робити в перші 24 години після інциденту кібербезпеки в компанії?

У першу добу після кіберінциденту важливо зробити дві речі: 1) зупинити розвиток інциденту, 2) зберегти дані та докази так, щоб потім можна було точно відновити картину подій. Нижче — порядок дій у випадку настання кіберінциденту.

0–60 хвилин: стабілізація та контроль ситуації
1) Зафіксуйте факт інциденту
Хто і як виявив проблему (лист, алерт, скарга користувача, збій сервісу).
Час, перші симптоми, які системи/акаунти під підозрою.
Зробіть короткий запис в одному місці (інцидент-нотатка): дата/час, факти, що вже зроблено.
2) Призначте відповідального та канал комунікації
Одна людина ухвалює оперативні рішення (Incident Lead).
Створіть окремий чат/дзвінок для команди реагування.
Не використовуйте скомпрометовану корпоративну пошту, якщо є підозра на злом пошти.
3) Зупиніть поширення, але не знищуйте сліди
Ізолюйте підозрілі пристрої від мережі (через EDR/мережеву сегментацію/відключення порту).
Уникайте миттєвого повного відключення всіх систем, якщо немає прямої необхідності: вимкнення може знищити важливі дані в оперативній пам’яті та ускладнити розслідування.
Якщо триває активне шифрування або масова компрометація — пріоритетом є зупинка поширення атаки та локалізація інциденту, навіть якщо частина доказів втратиться.
1–4 години: первинна оцінка масштабу (тріаж) та захист доступів
4) Оцініть, що саме відбуваєтьсяСпробуйте відповісти на три питання:
Що атакують? (пошта, домен, сервери, кінцеві пристрої, хмара, сайт)
Наскільки масштабно? (один користувач/відділ/вся мережа)
Чи триває атака зараз? (підозрілі входи, нові правила пошти, нові адміни, активні процеси)
5) Захистіть найважливіші облікові записиЦе критично майже в кожному інциденті.
Перевірте та за потреби змініть паролі/ключі для: адмін-акаунтів, VPN, Microsoft 365/Google Workspace, ключових сервісних акаунтів.
Перевірте MFA: чи не додано нові методи, чи не вимкнено політики.
Перевірте, чи не з’явилися нові адміністратори або нетипові зміни ролей.
За наявності ознак компрометації — тимчасово обмежте доступи (наприклад, за країнами/умовами входу) і підніміть рівень контролю.
6) Сформуйте список “критичних активів” і не робіть ризикових дій без плану
Визначте системи, зупинка яких спричинить найбільші втрати (платежі, логістика, виробництво, підтримка).
Узгодьте з бізнесом, що можна тимчасово обмежити/зупинити, а що — ні.
4–12 годин: збір доказів і перевірка версій
7) Зберіть базові докази (мінімальний набір)
Логи входів і подій безпеки з хмари (M365/Azure AD/Entra, Google Workspace) — підозрілі входи, зміни ролей, правила пошти.
Події з EDR/антивіруса (що детектилось, на яких хостах, які процеси).
Логи VPN, firewall, proxy/DNS (за наявності).
Список уражених/підозрілих хостів і користувачів.
8) Зафіксуйте “хто/коли/що збирав”Це потрібно, щоб матеріалам можна було довіряти:
де зберігаються файли/логи,
хто отримав доступ,
час збору,
що саме зібрано.
9) Паралельно перевіряйте найбільш типові сценаріїЗалежно від симптомів:
Пошта/хмара: правила пересилання, делегування, підозрілі OAuth-додатки, масові завантаження.
AD/Windows: підозрілі дії адміністратора, нові акаунти, зміни GPO, спроби доступу до контролерів домену.
Ransomware: масштаб шифрування, доступ до бекапів, підозрілі інструменти віддаленого доступу.
12–24 години: план відновлення, комунікації та рішення по ризиках
10) Підготуйте короткий статус для керівництва1 сторінка або 5–7 пунктів:
що відомо з фактами,
що під підозрою,
що вже зробили,
які ризики (простій, витік даних),
що робимо в наступні 24–48 годин,
що потрібно від бізнесу (рішення/доступи/комунікація).
11) Почніть планувати відновлення, але тільки після того, як ви зупинили атаку і переконалися, що вона більше не поширюється
Перевірте резервні копії: чи вони доступні, чи не пошкоджені, і з якої дати/часу можна відновлюватися без ризику повернути заражені або змінені дані.
Якщо є підозра на ransomware — відокремте сховища резервних копій від мережі і перевірте, чи зловмисники не отримали до них доступ і не зіпсували їх.
Не відновлюйте сервіси, поки не закрили причину інциденту. Інакше система запуститься, і атака може повторитися тим самим шляхом (наприклад через той самий зламаний акаунт, відкритий доступ або шкідливе правило).
12) Комунікації: внутрішні та зовнішні
Внутрішня: коротка інструкція співробітникам (не відкривати підозрілі листи, не встановлювати ПЗ, повідомляти про симптоми).
Зовнішня (клієнти/партнери/регулятор): готується лише на підтверджених фактах і за необхідності — із юридичним супроводом (перевірити терміни та вимоги договорів/законодавства).
13) Прийміть рішення про залучення зовнішньої допомогиПідключення DFIR/IR команди бажане, якщо:
є ознаки витоку або компрометації пошти/адмін-акаунтів,
ransomware зачіпає кілька систем,
немає достатніх логів та експертизи всередині,
інцидент може мати юридичні/фінансові наслідки.

Типові помилки в першу добу після інциденту і як їх уникнути

1) «Видалимо вірус і все» — без збереження логів і фіксації дійКоли систему намагаються “швидко почистити” під час інциденту (видаляють підозрілі файли, запускають «лікування», перевстановлюють програми або навіть перевстановлюють ОС), дуже часто разом із цим знищуються ключові сліди атаки. У результаті команда втрачає можливість точно встановити, яким шляхом зловмисник отримав доступ, скільки систем або облікових записів було зачеплено, чи були ознаки витоку даних і чи залишився механізм, який дозволяє зловмиснику повернутися. Без цих даних розслідування перетворюється на припущення, а рекомендації стають загальними й не гарантують, що інцидент не повториться тим самим способом. Саме тому перед будь-яким “очищенням” потрібно спочатку ізолювати уражені системи та зібрати базові логи й артефакти, а вже потім переходити до відновлення.

Чим це загрожує:
Інцидент повторюється через той самий “вхід” (наприклад, зламаний акаунт, небезпечне правило пошти, вразливий сервіс).
Ви не можете обґрунтувати клієнтам/керівництву “що сталося” і “що зроблено”.
Якщо є страхова/аудит/регулятор — може не вистачити доказів і документації.

Як варто зробити:Спочатку потрібно відокремити підозрілі комп’ютери або сервери від мережі, щоб атака не поширювалася далі, і зберегти мінімальний набір інформації, який допоможе зрозуміти, що саме сталося. Це означає: зафіксувати події входів у облікові записи, зібрати записи з антивіруса/EDR про підозрілі дії, переглянути журнали пошти або хмарних сервісів на предмет незвичних правил чи доступів, а також записати, які зміни були зроблені в системах і ким. Лише після цього варто переходити до “прибирання” та відновлення — тобто видаляти шкідливі компоненти, закривати вразливості, відновлювати дані з резервних копій і повертати сервіси в роботу за узгодженим планом. Паралельно важливо вести коротку фіксацію дій у простому форматі: що саме зробили, хто це зробив, коли і з якою метою — це зменшує хаос і дозволяє потім точно відтворити картину інциденту.

2) Повне відключенняМиттєве повне відключення всіх комп’ютерів і серверів “про всяк випадок” часто створює більше проблем, ніж вирішує. Таке рішення може зупинити критичні процеси бізнесу — платежі, логістику, підтримку клієнтів або виробництво — і втрати від простою інколи перевищують прямі збитки від інциденту. Крім цього, різке вимкнення систем може ускладнити розслідування: частина журналів подій не встигне записатися, обірвуться активні сесії, зникнуть дані, які допомагають встановити шлях проникнення та дії зловмисника. Без координації такі відключення швидко перетворюються на хаотичні дії, коли різні люди зупиняють різні системи, а команда втрачає розуміння, що саме вже вимкнено, що ще працює і які наслідки це має.
Як варто зробити:Більш правильно швидко визначити підозрілі або уражені системи та ізолювати саме їх (від’єднати від мережі або перевести в карантин через EDR), за потреби тимчасово обмежити зв’язок між сегментами, а критично важливі сервіси чіпати лише за узгодженим планом. Повністю вимикати все середовище варто лише тоді, коли атака масово поширюється і її інакше не зупинити.

3) Масові зміни налаштувань без журналу дійВ першу добу часто починають поспіхом змінювати налаштування в різних системах:● змінюють політики доступу;● вимикають/вмикають сервіси;● чистять правила пошти;● змінюють конфіги firewall;● масово змінюють паролі.

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

Як варто зробити:Вести простий “журнал реагування” (можна в документі/таблиці) з 5 полями: час, дія, хто зробив, де саме (система/акаунт/сервіс), причина/очікуваний ефект. Під час інциденту важливо, щоб усі критичні зміни узгоджувалися через одного відповідального, який координує дії команди. Це допомагає уникнути ситуацій, коли різні люди одночасно вносять несумісні правки, випадково скасовують роботу одне одного або створюють додаткові збої.

4) Поспішна комунікація з клієнтами без перевірених фактівКоли компанія швидко повідомляє клієнтів про інцидент, не маючи підтверджених фактів, з’являється ризик сказати зайве, а потім вимушено змінювати позицію. Це підриває довіру, створює репутаційні та юридичні ризики і може спровокувати неправильні дії з боку клієнтів. Правильніше спочатку зібрати мінімум перевіреної інформації, а в комунікації триматися фактів: що виявлено інцидент, які первинні заходи вже виконані, що триває перевірка, коли буде наступне оновлення та надати контакти в разі виникнення запитань.

← Назад