Як побудувати план реагування на інциденти, який працює?

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

Почніть з фаз, а не з посібників

NIST SP 800-61 визначає чотири фази: підготовка, виявлення та аналіз, локалізація/знищення/відновлення та постінцидентна діяльність. Цей порядок важливий. Команди люблять одразу перескочити до локалізації, тому що це виглядає продуктивно, але якщо ви не провели підготовчі роботи, ви недостатньо добре знаєте свою мережу, щоб щось чисто локалізувати.

Підготовка означає реєстри активів, які насправді актуальні, а не електронну таблицю з 2022 року. Це означає знання вікна збереження логів (якщо це 7 днів, а зловмисник було 30 днів, ви вже втратили час). Це означає попередньо розгорнуті інструменти судової експертизи — Velociraptor, KAPE або навіть документовану процедуру tar/dd для образів диска — щоб ніхто не завантажував інструменти на скомпрометований хост під час активного інциденту.

Визначте рівні серйозності до того, як вони вам знадобляться

SEV1 (активна крадіжка даних, детонація вимагальницького ПО, компрометація облікового запису доменного адміністратора) потребує іншої відповіді, ніж SEV3 (ізольований шкідлив код на одній непривілейованій робочій станції). Напишіть це як матрицю: вплив проти масштабу проти впевненості. Присвойте кожному рівню серйозності необхідний час реакції та шлях есколації. Якщо командир інциденту для SEV1 — це та сама людина, яка повинна затвердити кожен розпорядження на суму $500, ви вбудували вузьке місце в своєму власному аварійному процесі.

Роль командира інциденту не є необов'язковою

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

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

Рішення про локалізацію, які насправді мають значення

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

Розумний компроміс: використовуйте сегментацію мережі та ізоляцію EDR (CrowdStrike, Defender для Endpoint, SentinelOne — усі підтримують це), щоб відрізати хост від бічного руху, одночасно тримаючи його увімкненим для захоплення пам'яті. Повне вимкнення має бути крайнім заходом — це знищує летучі докази та, у випадках з вимагальницьким ПО, може спровокувати поведінку анти-судової експертизи, вбудовану в деякі корисні навантаження.

Прогалини в логуванні, за які ви пожалкуєте під час, а не раніше

Налаштування Windows Event Log за умовчанням недостатньо. Якщо у вас не розгорнуто Sysmon з приємною конфігурацією (базові конфігурації SwiftOnSecurity або Olaf Hartong — добра стартова точка), ви реконструюватимете дерева процесів із фрагментів. На боці мережі логи NetFlow або Zeek мають більшого значення, ніж більшість організацій розуміють, поки вони не потребують відповіді