Разбор инцидента (post-mortem): как не наступить на те же грабли

Когда системы восстановлены, пользователи снова работают, а отчёты руководству отправлены, у команды почти всегда возникает соблазн просто выдохнуть и двигаться дальше. Это понятное, но опасное желание. Именно разбор инцидента — post-mortem — превращает пережитую атаку из травмирующего опыта в конкретные улучшения процессов, инфраструктуры и обучения команды. Без него компания рискует через год или два наступить на ровно те же грабли, потому что коренные причины так и остались неразобранными, а исправлены были только видимые симптомы.

Есть и более прозаичная причина проводить post-mortem обязательно, а не по желанию: инциденты с шифровальщиками почти никогда не бывают полностью случайными. Группировки, специализирующиеся на вымогательстве, часто действуют по шаблону, находят сеть через сканирование известных уязвимостей или скупают доступ у брокеров начального доступа, и если конкретная уязвимость или процессный пробел, через который произошло проникновение, не устранены, ничто не мешает той же или другой группировке вернуться через тот же путь спустя несколько месяцев — уже зная, что эта цель уязвима.

Мы разберём, как построить такой разбор на примере той же производственной компании из нашей серии статей: домен itpages.lab.local, сеть 192.168.10.0/24, серверы srv-dc01, srv-fs01, srv-backup01, виртуализация на esxi-host01. После реального инцидента там провели post-mortem по структуре, которую мы опишем ниже, и по его итогам внедрили именно те меры — изоляцию backup-инфраструктуры, отдельные учётные записи, регулярное тестирование восстановления, — которые мы разбирали в предыдущих материалах серии.

Главное правило: без поиска виноватых

Первое и самое важное условие продуктивного разбора инцидента — культура blameless post-mortem, разбора без поиска и наказания виноватых. Если цель встречи — выяснить, кто конкретно открыл фишинговое письмо или кто не настроил MFA вовремя, участники будут защищаться и скрывать детали, а не делиться честной информацией. Если цель — понять, какие условия в системе и процессах позволили инциденту произойти и как их изменить, люди говорят открыто, и разбор действительно приносит пользу.

Это не значит, что ответственность вообще не обсуждается — если сотрудник систематически нарушает политики безопасности, это отдельный управленческий разговор. Но сам post-mortem должен фокусироваться на системных причинах, а не на персональной вине.

Практический приём для поддержания такой атмосферы — формулировать вопросы не про людей, а про систему. Не «почему ты не заметил подозрительное письмо», а «что в системе фильтрации почты и в обучении сотрудников позволило этому письму дойти до адресата и не вызвать подозрений». Разница в формулировке кажется мелочью, но она напрямую влияет на то, насколько открыто участники будут делиться деталями произошедшего.

Структура разбора инцидента

Хорошо структурированный post-mortem обычно строится вокруг нескольких блоков вопросов, в строгой последовательности.

Блок 1. Восстановление хронологии

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

Пример временной шкалы:
T-14 дней: предполагаемый первичный доступ (фишинговое письмо, рабочая станция бухгалтерии)
T-9 дней:  боковое перемещение, компрометация учётной записи локального администратора
T-2 дня:   попытка отключения антивируса на нескольких хостах (не замечена)
T-0:       обнаружение шифрования файлов на srv-fs01
T+1 час:   изоляция заражённых хостов
T+6 часов: смена паролей привилегированных учёток
T+18 часов: подтверждена целостность резервных копий на srv-backup01
T+3 дня:   восстановлены все критичные системы
T+14 дней: снят режим усиленного мониторинга

Такая хронология наглядно показывает, сколько времени атакующий провёл в сети незамеченным (в этом примере — 14 дней) и сколько заняло каждое действие реагирования. Разрыв между T-14 и T-2 днями — это как раз то время, когда своевременное обнаружение могло бы предотвратить инцидент целиком или значительно снизить ущерб.

Блок 2. Анализ первопричины (root cause)

Здесь важно не останавливаться на первом очевидном ответе. Техника «пяти почему» хорошо подходит для того, чтобы докопаться до системной причины, а не до поверхностного симптома.

Пример цепочки "пять почему":
1. Почему данные оказались зашифрованы?
   -> Потому что шифровальщик получил доступ к srv-fs01 с правами администратора.
2. Почему у скомпрометированной учётки были такие права?
   -> Потому что учётка локального администратора рабочей станции совпадала с учёткой на файловом сервере.
3. Почему пароли локальных администраторов были одинаковыми на разных машинах?
   -> Потому что не было внедрено решение по управлению паролями локальных администраторов (LAPS).
4. Почему LAPS не был внедрён раньше?
   -> Потому что это не считалось приоритетной задачей до этого инцидента.
5. Почему приоритеты безопасности не пересматривались?
   -> Потому что не было регулярного процесса оценки рисков ИТ-инфраструктуры.

Видно, что поверхностная причина («шифровальщик получил админский доступ») и системная причина («отсутствие процесса регулярной оценки рисков») — это два совершенно разных уровня, и исправление только первого симптома (сброс одного пароля) не защитит от повторения инцидента.

Блок 3. Что сработало, а что нет

Важно фиксировать не только провалы, но и то, что сработало хорошо — это тоже ценная информация, которая показывает, какие вложения в защиту и подготовку команды окупились.

• Что позволило обнаружить инцидент относительно быстро (или, наоборот, что задержало обнаружение)?
• Какие меры защиты сработали и ограничили масштаб поражения (например, изолированный backup-сервер, который атакующий не смог зашифровать)?
• Какие этапы плана реагирования выполнялись гладко, а какие вызвали затруднения или заняли больше времени, чем ожидалось?
• Насколько актуальной и точной оказалась документация (инструкции по восстановлению, контактные данные, схемы сети)?

Блок 4. План действий с ответственными и сроками

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

Пример плана действий по итогам post-mortem:
- Внедрить LAPS для управления паролями локальных администраторов
  Ответственный: инженер инфраструктуры, срок: 3 недели
- Изолировать srv-backup01 в отдельный домен без доверительных отношений
  Ответственный: администратор backup-инфраструктуры, срок: 2 недели
- Внедрить регулярное тестирование восстановления по расписанию
  Ответственный: руководитель ИТ, срок: 1 месяц на запуск процесса
- Ввести обязательный MFA для всех учётных записей с удалённым доступом
  Ответственный: администратор безопасности, срок: 1 неделя
- Запустить ежеквартальный процесс оценки рисков ИТ-инфраструктуры
  Ответственный: руководитель ИТ, срок: старт со следующего квартала

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

Блок 5. Проверка эффективности изменений

Post-mortem не заканчивается написанием плана действий. Через оговорённый срок (обычно 1-3 месяца) стоит вернуться к списку и проверить, что изменения не только внедрены формально, но и реально работают. Именно для этого и нужно регулярное тестирование восстановления и периодические учения — они дают возможность проверить, что уроки предыдущего инцидента действительно усвоены, а не просто записаны в отчёт, который никто больше не открывал.

Документирование для будущих инцидентов

Отдельная ценность post-mortem — это материал, который он оставляет после себя. Хронология, цепочка первопричин и план действий должны храниться не в личных заметках участников встречи, а в общей базе знаний компании, доступной будущим сотрудникам ИТ-отдела, даже если текущая команда полностью сменится через несколько лет. При этом саму базу знаний с разборами инцидентов стоит хранить так, чтобы она была доступна и в случае, если файловый сервер снова окажется недоступен — например, дублировать критичные документы вне основной инфраструктуры компании.

Хорошая практика — вести реестр всех инцидентов и близких к инцидентам событий (near-miss), даже тех, что не переросли в полноценную атаку. Если фишинговое письмо было вовремя замечено и не привело к заражению, это тоже стоит зафиксировать и разобрать: такие случаи показывают, где защита сработала на грани, и часто содержат те же уроки, что и полноценный инцидент, но достаются компании значительно дешевле.

Кого приглашать на разбор

Полноценный post-mortem крупного инцидента редко бывает чисто технической встречей. Стоит приглашать не только ИТ-специалистов, непосредственно занимавшихся реагированием, но и представителей бизнес-подразделений, пострадавших от простоя, руководство, при необходимости — юриста и представителя внешнего подрядчика по реагированию на инциденты, если он привлекался. Разные точки зрения помогают увидеть проблему шире: ИТ-специалист может не знать, что простой файлового сервера на день сорвал критичную поставку клиенту, а бизнес не знает, почему техническое восстановление контроллера домена вообще является предварительным условием для доступа к файлам.

Оптимальная продолжительность такой встречи — полтора-два часа, с заранее разосланной повесткой и, желательно, с уже собранной хронологией событий, а не с попыткой восстанавливать её прямо на встрече по памяти участников. Если инцидент был крупным, имеет смысл провести две отдельные сессии: техническую, с подробным разбором первопричин для инженерной команды, и управленческую, с фокусом на бизнес-последствия и план действий для руководства.

Частые ошибки и как их избежать

• Поиск виноватого вместо системной причины. Обвинительная атмосфера заставляет участников скрывать детали и мешает докопаться до реальной первопричины инцидента.
• План действий без сроков и ответственных. Список благих намерений без конкретных дедлайнов и исполнителей почти никогда не реализуется полностью, особенно когда острота момента проходит.
• Разбор сразу после инцидента, пока эмоции ещё высоки, без последующей проверки. Первая встреча важна, но без контрольной точки через несколько месяцев легко обнаружить, что часть договорённостей так и осталась на бумаге.
• Разбор только технической стороны инцидента. Если на встречу не приглашены представители пострадавших бизнес-подразделений, план действий рискует упустить реальные приоритеты компании и сосредоточиться только на том, что интересно ИТ-отделу.

Автор — Команда IT-Pages