Что такое реагирование на инциденты?

Национальный институт стандартов и технологий (NIST) и Институт SANS разработали общепринятые модели, определяющие различные этапы реагирования на инциденты. Шесть этапов, предложенных Институтом SANS, подробно описаны ниже.

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

2. Выявление
Этот этап, также известный как обнаружение, включает использование технологий и методологий для определения самого факта инцидента, например произошедшей кибератаки. Существует множество решений по безопасности для мониторинга систем и данных в режиме реального времени, а также автоматизации оповещений и реагирования. Часто организации используют платформу управления информацией о безопасности и событиями безопасности (SIEM). Для выявления подозрительной активности используются данные из таких инструментов, как логи устройств, системы обнаружения вторжений или межсетевые экраны. Оповещения отправляются команде реагирования на инциденты, которая анализирует и сортирует их, выявляет индикаторы компрометации (IoC) и отбрасывает ложноположительные результаты. В случае инцидента безопасности вступает в силу план реагирования на инциденты, включающий уведомление соответствующего персонала и выполнение плана коммуникаций.

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

4. Устранение
На этом этапе угроза полностью устраняется, то есть злоумышленник или вредоносное ПО удаляются из систем и сетей. Важно убедиться, что следов атаки или утечки не осталось, чтобы данные или системы можно было полностью восстановить.

5. Восстановление

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

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

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