Разбор инцидента и извлечённые уроки

Заключительный этап жизненного цикла реагирования на инциденты NIST — Post-Incident активность, в центре которого находится разбор извлечённых уроков. Организации, пропускающие этот этап, статистически чаще сталкиваются с инцидентом того же типа повторно. Процесс извлечения уроков сохраняет институциональные знания, выявляет системные недостатки, способствовавшие инциденту, и обеспечивает конкретные улучшения средств контроля, процессов и обучения. Без этого цикла обратной связи затраты на реагирование остаются высокими, а время присутствия злоумышленника — длительным.

Post-Incident разбор (PIR) — также называемый посмертным разбором или отчётом по итогам действий — представляет собой структурированную встречу и процесс документирования, проводимые после полного закрытия инцидента. PIR следует проводить в течение 1–2 недель, пока воспоминания ещё свежи. К основным исходным данным относятся: временная шкала инцидента, все собранные доказательства, предпринятые действия и их результаты, записи обмена информацией и первоначальный отчёт об инциденте. В PIR должны участвовать все заинтересованные стороны: аналитики безопасности, владельцы систем, руководство, юристы и команды по коммуникациям.

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

Анализ Root-причины (RCA) выявляет самую глубокую первопричину инцидента, а не только непосредственный технический триггер. Методика 5 Whys заключается в многократном вопросе «почему?», чтобы проследить инцидент до его системного источника. Пример: почему произошла утечка данных? Потому что выполнялось вредоносное ПО. Почему вредоносное ПО не обнаружили? Потому что сигнатуры AV не обновлялись. Почему их не обновляли? Потому что установка исправлений не была автоматизирована. Почему? Потому что в IT не обеспечивалось соблюдение политики установки исправлений. Первопричина: отсутствие политики управления исправлениями, а не просто «необновлённая система».

Разборы после инцидентов позволяют получить ключевые показатели безопасности. MTTD (среднее время обнаружения) измеряет среднее время между началом инцидента и его обнаружением командой безопасности. Меньшее MTTD означает более быстрое обнаружение и меньше времени для причинения ущерба злоумышленником. MTTR (среднее время реагирования и восстановления) измеряет время от обнаружения до полного восстановления. Отслеживание этих показателей в разных инцидентах показывает, повышают ли инвестиции в безопасность скорость обнаружения и реагирования со временем.

PIR приводит к созданию отчёта по итогам действий (AAR) — официального документа, содержащего описание инцидента, выводы и рекомендации по улучшению. Он включает следующие разделы: резюме для руководства (нетехническое), временная шкала инцидента, анализ Root-причины, оценка воздействия (системы, данные, финансы, репутация), что сработало хорошо, области для улучшения и приоритетный список задач с ответственными и сроками выполнения. Во многих юрисдикциях AAR является конфиденциальным документом, защищённым юридической тайной между адвокатом и клиентом.

Выводы PIR должны превращаться в конкретные улучшения. Если инцидент показал, что в сценарии реагирования на программы-вымогатели отсутствовали шаги проверки облачных резервных копий, этот шаг необходимо добавить до следующего использования сценария. Если пробел в политике сделал атаку возможной (например, отсутствие требования MFA), политику необходимо обновить и проверить соблюдение обновлённых требований. Обновлённые сценарии и политики следует хранить под управлением версий, распространить среди всех участников CSIRT и включить в обучение и практические учения, чтобы улучшение действительно вошло в рабочую практику.

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

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

Действия после инцидента включают проверку того, что уведомления регулирующих органов были правильно направлены в установленные сроки. Некоторые нормативные требования предусматривают отправку регулирующим органам отчёта об оценке последствий утечки данных. Судебные предписания о сохранении материалов могут требовать длительного хранения доказательств инцидента. Если инцидент связан с судебным разбирательством, на AAR может распространяться процедура раскрытия доказательств — перед распространением документ должен проверить юрисконсульт. Некоторые организации проводят PIR в рамках адвокатской тайны, чтобы защитить результаты от раскрытия.

Задачи PIR необходимо отслеживать до фактического завершения, а не просто назначать. Для каждой задачи необходимы: конкретный ответственный (а не «команда безопасности»), измеримый критерий успеха, крайний срок и механизм отслеживания (система управления заявками или инструмент управления проектами). Назначенные, но не отслеживаемые задачи приводят к тому, что одни и те же уязвимости сохраняются после нескольких инцидентов. В ежемесячных совещаниях по работе службы безопасности следует постоянно включать в повестку статус задач PIR, пока все задачи не будут закрыты.

Проверьте своё понимание концепций CompTIA Security+ (SY0-701), рассмотренных в этом уроке.

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