Главная / Словарь / Реагирование на инциденты
Словарь угроз · Процессы ИБ

Реагирование на инциденты: этапы и модели

Проверено экспертной редакцией SecRadar · по первоисточникам ФСТЭК / ФСБ / Банка России

Реагирование на инциденты (Incident Response, IR) — это процесс обнаружения, анализа, сдерживания и устранения инцидентов информационной безопасности с последующим разбором причин, который выполняют SOC и CSIRT/CERT по заранее согласованному регламенту. Материал разбирает этапы IR по двум признанным моделям — NIST SP 800-61 и SANS, — роли SOC и CSIRT в этом процессе, сроки информирования ГосСОПКА по приказу ФСБ №547 для субъектов КИИ и инструменты, которыми реагирование закрывают на практике: SIEM, SOAR и EDR.

Экспертная редакция SecRadar · как мы проверяем факты → Обновлено 14 июля 2026 · ~9 мин чтения общепринятые модели ИБ, без вендорной привязки

Кратко

Что это
Процесс обнаружения, анализа, сдерживания и устранения инцидентов ИБ с разбором причин после завершения.
Модель NIST
4 этапа по NIST SP 800-61 Rev. 2 (2012): подготовка → обнаружение и анализ → сдерживание, устранение и восстановление → разбор после инцидента. В апреле 2025 NIST заменил Rev. 2 на Rev. 3, встроив IR в 6 функций CSF 2.0.
Модель SANS
6 шагов: подготовка, идентификация, сдерживание, устранение, восстановление, извлечённые уроки — та же логика, но детальнее.
Кто реагирует
SOC обнаруживает инцидент в потоке событий, CSIRT/CERT расследует и координирует само реагирование.
Сроки ГосСОПКА
3 часа для значимых объектов КИИ / 24 часа для иных — приказ ФСБ №547 от 25.12.2025, действует с 30.01.2026.
Инструменты
SIEM детектирует, SOAR автоматизирует шаги по плейбукам, EDR реагирует на конечных точках.

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

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

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

Реагирование стоит отличать от смежных, но не тождественных практик. Threat Intelligence поставляет контекст об угрозах ещё до атаки. DFIR (Digital Forensics and Incident Response) — более широкая дисциплина, которая помимо реагирования включает цифровую криминалистику: сбор и анализ доказательств для установления полной картины атаки, в том числе для последующих юридических или регуляторных процедур. Реагирование — операционное ядро этой дисциплины: то, что происходит здесь и сейчас, пока инцидент активен.

оценка определение и разграничение с DFIR — редакционная систематизация распространённой практики SOC, синтез NIST SP 800-61 и общепринятой терминологии отрасли

Этапы реагирования на инциденты

Самая цитируемая модель этапов IR — четырёхфазный цикл из руководства NIST SP 800-61 Rev. 2 (2012): подготовка, обнаружение и анализ, сдерживание/устранение/восстановление, разбор после инцидента. Институт SANS использует более детализированную версию из шести шагов, где третья фаза NIST разбита на три отдельных этапа — по сути та же логика, изложенная подробнее для обучения и практики SOC.

↔ таблицу можно прокрутить вбок

NIST SP 800-61 Rev. 2 (2012)SANS (6 шагов)Что происходит на этапе
1. Preparation
Подготовка
1. Preparation
Подготовка
Команда выстраивает регламент, инструменты (SIEM, SOAR, EDR), контакты и роли до того, как случится инцидент — политики реагирования, плейбуки, обучение персонала.
2. Detection & Analysis
Обнаружение и анализ
2. Identification
Идентификация
Событие в потоке телеметрии классифицируется как инцидент, определяются масштаб, вектор и затронутые системы — обычно на этом этапе первым сигналит SOC.
3. Containment, Eradication & Recovery
Сдерживание, устранение, восстановление
3. Containment
Сдерживание
Инцидент локализуется, чтобы не распространялся дальше: изоляция хоста, блокировка учётной записи или сетевого сегмента.
4. Eradication
Устранение
Из инфраструктуры убирают первопричину — вредоносный код, бэкдор, скомпрометированную учётную запись — а не только видимые следствия инцидента.
5. Recovery
Восстановление
Затронутые системы возвращают в рабочее состояние и усиленно наблюдают за ними некоторое время, чтобы убедиться, что угроза не вернулась.
4. Post-Incident Activity
Разбор после инцидента
6. Lessons Learned
Извлечённые уроки
Команда разбирает хронологию инцидента, фиксирует, что сработало и что нет, и обновляет регламенты и защитные меры, чтобы закрыть использованный вектор атаки.
Оговорка про актуальность документа NIST. Четырёхфазная модель принадлежит NIST SP 800-61 Rev. 2 (2012, «Computer Security Incident Handling Guide»). В апреле 2025 года NIST официально отозвал Rev. 2 и заменил его на SP 800-61 Rev. 3 («Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile») — вместо единого линейного цикла реагирования Rev. 3 встраивает действия IR в шесть функций CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) и прямо указывает, что фиксировать конкретные шаги реагирования в одном статичном документе больше не имеет смысла. На практике классическая четырёхфазная модель Rev. 2 остаётся общепринятым рабочим языком SOC и вендоров по всему миру, включая российские команды, — и поэтому приведена в этом материале как основная модель для сравнения с SANS, — но формально это уже не текущая редакция NIST SP 800-61.

Обе модели описывают один и тот же цикл, а не конкурируют друг с другом: четырёхфазную модель NIST SP 800-61 Rev. 2 чаще цитируют как отраслевой стандарт де-факто, а шестишаговую версию SANS используют в обучении и сертификации специалистов реагирования (в том числе в курсе GCIH). На практике команды SOC редко придерживаются названий буквально — важнее сама последовательность: сначала подготовиться, затем обнаружить и локализовать, затем устранить причину и восстановиться, и в конце разобрать инцидент, чтобы он не повторился.

факт 4 этапа — NIST SP 800-61 Rev. 2, «Computer Security Incident Handling Guide», 2012 — nvlpubs.nist.gov факт 6 шагов модели SANS (PICERL) — sans.org (курс и материалы SANS Institute по incident handling) факт в апреле 2025 NIST отозвал Rev. 2 и заменил его на SP 800-61 Rev. 3, реструктурированный под функции CSF 2.0 — csrc.nist.gov

Кто реагирует: SOC и CSIRT

SOC (Security Operations Center) круглосуточно мониторит инфраструктуру и первым обнаруживает подозрительную активность, а CSIRT/CERT (Computer Security Incident Response Team) непосредственно расследует инцидент и координирует само реагирование. В крупной организации это, как правило, две разные структуры с разными задачами; в компании поменьше одна и та же команда SOC берёт на себя обе роли — сначала обнаруживает, затем сама же реагирует.

SOC обнаружение

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

CSIRT / CERT расследование и координация

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

Термины CSIRT и CERT на практике используют как синонимы: CERT (Computer Emergency Response Team) — более раннее и более закреплённое название (в том числе в маркировках вроде национального CERT), CSIRT — более нейтральный термин, который позже стали предпочитать многие организации и вендоры. Отдельно от внутренних команд организаций в России действует государственная структура реагирования на инциденты на объектах критической информационной инфраструктуры — ГосСОПКА, которую координирует НКЦКИ при ФСБ России.

оценка разграничение ролей SOC и CSIRT/CERT — редакционная систематизация распространённой отраслевой практики, не дословная цитата одного стандарта

Сроки и требования РФ: ГосСОПКА

Для субъектов критической информационной инфраструктуры (КИИ) сроки информирования ФСБ России об инцидентах закреплены приказом ФСБ №547 от 25.12.2025, который действует с 30 января 2026 года: 3 часа с момента обнаружения инцидента — для значимого объекта КИИ, 24 часа — для иных объектов КИИ. Приказ №547 сменил ранее действовавший приказ ФСБ №282 от 19.06.2019 и сохранил ту же логику сроков;

сведения о самой компьютерной атаке (в отличие от инцидента) во всех случаях направляются не позднее 24 часов.

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

Порядок подключения к ГосСОПКА, обязанности субъекта КИИ и разбор всех связанных приказов ФСБ — в отдельном материале о ГосСОПКА и НКЦКИ.

Срок ГосСОПКА не равен сроку полного закрытия инцидента. 3 часа и 24 часа — это окно для сообщения регулятору о факте инцидента, а не дедлайн на устранение причины и восстановление систем — эти шаги по объективным причинам занимают дольше и продолжаются уже после того, как ФСБ России уведомлена.
реестр сроки 3 часа / 24 часа — п. 3 Порядка, утв. приказом ФСБ России №547 от 25.12.2025 (действует с 30.01.2026), сверено на pravo.gov.ru — см. полный разбор на странице /komplaens/kii/gossopka/

Инструменты: SIEM, SOAR, EDR

Три класса СЗИ покрывают разные шаги реагирования: SIEM обнаруживает инцидент через корреляцию событий, SOAR автоматизирует и оркестрирует само реагирование по плейбукам, EDR выполняет действия реагирования непосредственно на конечных точках. Ни один из трёх классов не закрывает весь цикл IR в одиночку — на практике их используют вместе, как звенья одной цепочки от обнаружения до устранения.

  • SIEM — обнаружение. Собирает события со всей инфраструктуры и коррелирует их между источниками, чтобы отличить реальный инцидент от разрозненного шума. Обычно именно алерт SIEM запускает этап Detection & Analysis по модели NIST.
  • SOAR — автоматизация реагирования. Берёт подтверждённый инцидент и выполняет заранее описанный плейбук: обогащает контекстом из Threat Intelligence, блокирует индикатор на межсетевом экране, изолирует хост через EDR, заводит тикет и уведомляет дежурного аналитика — без постоянного ручного вмешательства на каждом шаге.
  • EDR — реагирование на хостах. Выполняет непосредственные действия на конечной точке: изолирует заражённое устройство от сети, останавливает вредоносный процесс, откатывает изменения файловой системы — обычно по команде SOAR или вручную по решению аналитика CSIRT.

Чем крупнее SOC и разнообразнее источники алертов, тем заметнее становится разрыв между обнаружением (SIEM) и фактическим действием (EDR) без прослойки автоматизации — именно этот разрыв и закрывает SOAR, сокращая время между алертом и сдерживанием инцидента.

оценка распределение классов СЗИ по этапам IR — редакционная систематизация распространённой практики построения SOC, не цитата конкретного стандарта

Частые вопросы

Что такое реагирование на инциденты простыми словами?
Это последовательность действий, которую команда ИБ выполняет с момента обнаружения подозрительной активности до полного восстановления систем и разбора причин произошедшего. Задача не только остановить конкретную атаку, но и закрыть путь, которым злоумышленник воспользовался, чтобы инцидент не повторился. Метка: оценка — раздел «Что такое реагирование на инциденты» выше.
Какие этапы реагирования на инциденты по NIST?
Четыре: подготовка (Preparation), обнаружение и анализ (Detection & Analysis), сдерживание, устранение и восстановление (Containment, Eradication & Recovery) и разбор после инцидента (Post-Incident Activity). Модель описана в руководстве NIST SP 800-61 Rev. 2 (2012) и остаётся самой цитируемой в мировой практике IR, включая российские SOC, хотя формально в апреле 2025 года NIST отозвал Rev. 2 и заменил его на SP 800-61 Rev. 3 — документ, встраивающий реагирование в шесть функций CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) вместо линейного четырёхфазного цикла. Метка: факт — раздел «Этапы реагирования на инциденты» выше.
Чем отличается модель SANS от модели NIST?
SANS Institute использует более детализированную модель из шести шагов: подготовка, идентификация, сдерживание, устранение, восстановление, извлечённые уроки. По сути это та же логика, что и в NIST SP 800-61, но третий этап NIST (сдерживание, устранение, восстановление) в модели SANS раскрыт на три отдельных шага, а не объединён в один. Метка: факт — раздел «Этапы реагирования на инциденты» выше.
Кто отвечает за реагирование на инциденты — SOC или CSIRT?
SOC (Security Operations Center) — постоянно действующее подразделение или сервис, которое круглосуточно мониторит инфраструктуру и первым обнаруживает инцидент. CSIRT/CERT (Computer Security Incident Response Team) — команда, которая непосредственно расследует инцидент и координирует реагирование; в крупной организации это отдельная выделенная группа, в небольшой — та же команда SOC берёт на себя обе роли. Метка: оценка — раздел «Кто реагирует: SOC и CSIRT» выше.
В какой срок нужно сообщать об инциденте в ГосСОПКА?
Для субъектов КИИ, обязанных взаимодействовать с ГосСОПКА, порядок и сроки установлены приказом ФСБ России №547 от 25.12.2025, который действует с 30 января 2026 года: 3 часа с момента обнаружения инцидента — для значимого объекта КИИ, 24 часа — для иных объектов КИИ. Это требование к информированию регулятора, а не ко всему циклу реагирования, который может занимать намного дольше. Метка: реестр — раздел «Сроки и требования РФ: ГосСОПКА» выше.
Какие инструменты используют для реагирования на инциденты?
SIEM собирает и коррелирует события со всей инфраструктуры и первым сигнализирует об инциденте. SOAR автоматизирует типовые шаги реагирования по заранее описанным плейбукам — обогащение контекстом, блокировку, изоляцию — и берёт на себя оркестрацию между разными СЗИ. EDR отвечает за реагирование непосредственно на конечных точках: изоляцию хоста, остановку процесса, откат изменений. Метка: оценка — раздел «Инструменты: SIEM, SOAR, EDR» выше.

Словарь угроз на SecRadar

Разбор терминов и процессов ИБ без вендорной привязки — что стоит за понятием, как оно связано со смежными практиками и какие классы СЗИ закрывают конкретный этап процесса.

Открыть словарь угроз
Telegram-канал SecRadar
Сводка рынка ИБ России — каждую неделю

Новые продукты и сертификаты ФСТЭК, ходы вендоров, дедлайны регуляторов — коротко и со ссылками на первоисточники.

Подписаться →