Управление инцидентами информационной безопасности: процесс, стандарты и практика

Управление инцидентами информационной безопасности — процесс, от зрелости которого зависит, обойдётся ли кибератака организации в часы простоя или в миллионы рублей ущерба. По данным Positive Technologies, в 2025 году среднее время обнаружения компрометации в российских компаниях составило 37 дней, а средний ущерб от одного критического инцидента достиг 27 млн рублей. При этом организации с выстроенным процессом управления инцидентами сокращали время обнаружения до 2–4 часов и ущерб — в 5–8 раз.

В этой статье разберём полный цикл управления инцидентами ИБ: от подготовки и обнаружения до расследования и извлечения уроков. Привяжем каждый этап к стандартам ISO 27035, NIST SP 800-61, требованиям ГосСОПКА и российской нормативной базе. Покажем, как автоматизировать процесс через SGRC.

Что такое инцидент информационной безопасности

Определение: событие vs инцидент

Стандарт ISO 27000 разделяет два понятия:

• Событие ИБ (security event) — любое наблюдаемое явление в информационной системе, которое может иметь отношение к безопасности. Пример: неудачная попытка входа в систему, срабатывание правила МЭ, подключение USB-носителя.
• Инцидент ИБ (security incident) — одно или несколько событий ИБ, которые с высокой вероятностью приведут к нарушению конфиденциальности, целостности или доступности информации и нанесут ущерб организации.

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

Типы инцидентов: классификация по вектору атаки

Статистика инцидентов ИБ в России

По данным НКЦКИ, в 2025 году зафиксировано более 200 000 компьютерных инцидентов на объектах КИИ. По данным Роскомнадзора, число утечек персональных данных превысило 700 случаев. Отраслевая структура инцидентов: госсектор (24%), финансы (18%), промышленность (15%), здравоохранение (12%), образование (9%), остальные (22%).

Ransomware остаётся главной угрозой. В 2025 году средний размер выкупа за расшифровку данных в России достиг 10 млн рублей, а время восстановления после атаки без резервных копий — от 14 до 30 дней.

Стандарты и фреймворки управления инцидентами

ISO/IEC 27035: международный стандарт

ISO 27035:2023 — основной международный стандарт управления инцидентами ИБ. Состоит из трёх частей:

• Часть 1: Принципы — терминология, общая модель, взаимосвязь с другими процессами СУИБ.
• Часть 2: Планирование и подготовка — политика управления инцидентами, создание команды реагирования, разработка процедур.
• Часть 3: Операции — обнаружение, оценка, реагирование, извлечение уроков.

ISO 27035 определяет пять фаз: планирование и подготовка, обнаружение и оповещение, оценка и принятие решения, реагирование, извлечение уроков.

NIST SP 800-61: фреймворк реагирования

NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide) — практическое руководство, широко используемое как в США, так и в международной практике. NIST определяет четыре фазы:

1. Preparation — подготовка: политика, команда, инструменты, обучение.
2. Detection & Analysis — обнаружение и анализ: источники данных, индикаторы, приоритизация.
3. Containment, Eradication & Recovery — сдерживание, устранение, восстановление.
4. Post-Incident Activity — деятельность после инцидента: lessons learned, метрики.

Требования ФСБ: ГосСОПКА и Приказ №367

Субъекты КИИ обязаны подключиться к ГосСОПКА (Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак) и информировать НКЦКИ о компьютерных инцидентах. Приказ ФСБ №367 определяет порядок информирования:

• Срок уведомления — не позднее 24 часов с момента обнаружения инцидента.
• Содержание уведомления: дата и время обнаружения, описание инцидента, затронутые объекты КИИ.
• Канал передачи: техническая инфраструктура НКЦКИ, а при её недоступности — альтернативные каналы.

Сравнительная таблица стандартов

Этап 1. Подготовка к управлению инцидентами

Создание команды реагирования (CSIRT)

CSIRT (Computer Security Incident Response Team) — команда, ответственная за координацию реагирования на инциденты. Состав зависит от размера организации:

Выделенная CSIRT (для крупных организаций, субъектов КИИ):

• Руководитель CSIRT — координация, принятие решений, эскалация.
• Аналитики ИБ — обнаружение, классификация, расследование.
• Инженеры ИБ — сдерживание, устранение, восстановление.
• Форензик-специалист — сбор и анализ цифровых доказательств.
• Юрист — правовые аспекты, взаимодействие с регуляторами.
• PR-специалист — коммуникации при публичных инцидентах.

Виртуальная CSIRT (для средних организаций): сотрудники разных подразделений, привлекаемые по заранее определённым ролям при возникновении инцидента.

Разработка политики управления инцидентами

Политика определяет:

• Что считается инцидентом в данной организации (критерии квалификации).
• Роли и ответственности участников процесса.
• Порядок эскалации по уровням критичности.
• Требования к документированию и хранению информации об инцидентах.
• Обязательства по уведомлению регуляторов (НКЦКИ, Роскомнадзор, ФинЦЕРТ).

Playbook: сценарии реагирования

Playbook — пошаговый сценарий реагирования на конкретный тип инцидента. Наличие playbook сокращает время реагирования в 3–5 раз, поскольку устраняет необходимость принимать решения в стрессовой ситуации.

Пример playbook: заражение ransomware

1. Сдерживание (немедленно): Изолировать заражённый хост от сети. НЕ выключать питание — это уничтожит ключи расшифровки в оперативной памяти.
2. Оповещение: Уведомить CSIRT, CISO. Для субъектов КИИ — запустить процедуру уведомления НКЦКИ.
3. Оценка масштаба: Определить количество заражённых хостов, тип шифровальщика, затронутые данные.
4. Сбор доказательств: Образ оперативной памяти (Volatility), логи EDR/SIEM, сетевые соединения.
5. Устранение: Идентифицировать и устранить вектор заражения (фишинг, уязвимость, RDP) до восстановления.
6. Восстановление: Восстановить данные из резервных копий, проверить целостность.
7. Post-Incident Review: Разбор, обновление мер защиты, дообучение персонала.

Инструменты обнаружения

Обнаружение инцидентов обеспечивается комплексом инструментов:

• SIEM — сбор, нормализация и корреляция событий из различных источников. Обнаружение аномалий по правилам корреляции.
• IDS/IPS — обнаружение и предотвращение вторжений на сетевом уровне.
• EDR/XDR — мониторинг конечных точек, обнаружение поведенческих аномалий, автоматическое реагирование.
• DLP — обнаружение попыток утечки данных через каналы коммуникации.
• Honeypots — ловушки для обнаружения несанкционированной активности.

Этап 2. Обнаружение и регистрация

Источники информации

Инциденты обнаруживаются через три канала:

Автоматическое обнаружение. SIEM-система генерирует алерт на основе правила корреляции: множественные неудачные попытки аутентификации с последующим успешным входом → возможный brute-force. EDR обнаруживает подозрительный процесс, запущенный из временной директории.

Обращения пользователей. Сотрудник сообщает о подозрительном письме, недоступности сервиса, странном поведении рабочей станции. Важно обеспечить простой канал для обращений (e-mail security@, горячая линия, чат-бот).

Внешние источники. Уведомление от НКЦКИ/CERT о компрометации, сообщение от партнёра об утечке данных, обнаружение данных организации на теневых форумах.

Регистрация инцидента

Каждый инцидент фиксируется в системе учёта с обязательными полями:

• Уникальный идентификатор инцидента.
• Дата и время обнаружения.
• Источник информации (кто/что обнаружил).
• Краткое описание инцидента.
• Затронутые активы и системы.
• Первичная оценка критичности.
• Назначенный ответственный.

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

Этап 3. Классификация и приоритизация

Уровни критичности: P1–P4

КиберОснова автоматически классифицирует инциденты по заданным критериям и запускает соответствующий playbook реагирования — подробнее на странице автоматизации ИБ.

Эскалация

Матрица эскалации определяет, кто уведомляется при каждом приоритете:

Этап 4. Реагирование и сдерживание

Сдерживание: краткосрочное и долгосрочное

Краткосрочное сдерживание — немедленные действия для предотвращения распространения инцидента:

• Изоляция заражённого хоста от сети (не выключение!).
• Блокировка скомпрометированной учётной записи.
• Блокировка IP-адреса атакующего на МЭ.
• Перенаправление DNS для фишингового домена.

Долгосрочное сдерживание — меры, позволяющие продолжить работу до полного устранения:

• Переключение на резервные системы.
• Усиление мониторинга затронутого сегмента сети.
• Временные правила WAF/IPS.
• Принудительная смена паролей для затронутых учётных записей.

Сбор и сохранение доказательств

При расследовании необходимо обеспечить юридическую значимость доказательств: образ оперативной памяти (Volatility, WinPmem), образ диска (dd, FTK Imager), сетевой трафик (pcap), логи SIEM/EDR, скриншоты. Каждое доказательство фиксируется в журнале с указанием: что, кто, когда, как собрал. Нарушение цепочки хранения (chain of custody) делает доказательства непригодными для правоохранительных органов.

Коммуникация во время инцидента

Коммуникация — часто недооценённый аспект реагирования:

• Внутренняя: Регулярные обновления статуса для руководства (каждые 2–4 часа для P1). Чёткий канал коммуникации (выделенный чат, конференц-линия).
• Регуляторы: НКЦКИ (24 часа для КИИ), Роскомнадзор (24+72 часа для утечек ПДн), ФинЦЕРТ (для финансовых организаций).
• Внешняя: Клиенты и партнёры (при утечке их данных), СМИ (при публичных инцидентах — только через пресс-службу).

Этап 5. Расследование и восстановление

Установление причин и масштаба

Расследование отвечает на четыре вопроса:

1. Что произошло? Хронология событий: первичный вектор атаки, последовательность действий злоумышленника, достигнутые цели.
2. Как произошло? Использованная уязвимость, метод проникновения, инструменты атакующего.
3. Каков масштаб? Затронутые системы, скомпрометированные данные, длительность компрометации.
4. Кто стоит за атакой? Внешний злоумышленник, инсайдер, APT-группа (атрибуция — если возможна).

Для расследования используются данные из БДУ ФСТЭК (идентификация эксплуатируемых уязвимостей), MITRE ATT&CK (классификация техник атакующего), Threat Intelligence (индикаторы компрометации).

Устранение вектора атаки

До восстановления необходимо устранить причину инцидента:

• Закрыть эксплуатируемую уязвимость (установить патч).
• Удалить вредоносное ПО и бэкдоры со всех затронутых хостов.
• Отозвать скомпрометированные сертификаты и ключи.
• Пересмотреть права доступа.
• Обновить правила МЭ/IPS.

Критическая ошибка: восстановление из резервной копии без устранения вектора. Если уязвимость не закрыта, а вектор не заблокирован — повторная компрометация произойдёт в течение часов.

Восстановление систем

Порядок восстановления зависит от характера инцидента:

1. Восстановление из чистой резервной копии — предпочтительный вариант для заражений ВПО и ransomware. Копия должна быть от даты до компрометации.
2. Переустановка системы — если нет уверенности в целостности резервной копии.
3. Очистка системы — допустима только для незначительных инцидентов, когда масштаб достоверно установлен.
4. Постепенный ввод в эксплуатацию — восстановленные системы вводятся поэтапно с усиленным мониторингом.

Этап 6. Извлечение уроков (Post-Incident Review)

Формат проведения PIR

Post-Incident Review (PIR) — самый недооценённый этап. Без него организация повторяет одни и те же ошибки. PIR проводится в течение 5–10 рабочих дней после закрытия инцидента.

Участники: все, кто участвовал в реагировании — CSIRT, ИТ, владельцы затронутых систем, руководство (для P1/P2).

Формат: структурированная встреча (60–120 минут) с фиксацией выводов. Атмосфера — «blameless»: фокус на процессах и системах, не на поиске виноватых.

Вопросы для обсуждения:

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

Отчёт об инциденте

Итоговый отчёт содержит:

• Краткое описание инцидента (executive summary).
• Хронология событий (timeline).
• Масштаб: затронутые системы, данные, пользователи.
• Причина (root cause).
• Предпринятые действия и их результат.
• Финансовый ущерб (если оценён).
• Корректирующие действия с ответственными и сроками.
• Рекомендации по предотвращению аналогичных инцидентов.

Метрики эффективности

Информирование регуляторов

ГосСОПКА / НКЦКИ: субъекты КИИ

Субъекты КИИ обязаны информировать НКЦКИ (Национальный координационный центр по компьютерным инцидентам, подразделение ФСБ) о компьютерных инцидентах на значимых объектах КИИ в течение 24 часов. Для незначимых объектов КИИ — рекомендуется, но не обязательно.

Уведомление передаётся через техническую инфраструктуру ГосСОПКА. При её недоступности — по электронной почте, телефону или через личный кабинет на сайте НКЦКИ.

Роскомнадзор: утечки ПДн

С 2023 года (изменения в 152-ФЗ, ст. 21.1) операторы персональных данных обязаны:

• В течение 24 часов — уведомить Роскомнадзор об утечке ПДн (факт, предварительный объём, предпринятые меры).
• В течение 72 часов — представить результаты внутреннего расследования (причины, масштаб, принятые меры, ответственные).

Уведомление подаётся через портал Роскомнадзора. Штрафы за непредставление уведомления или нарушение сроков — от 100 000 до 300 000 рублей, с 2025 года — оборотные штрафы за повторные утечки.

ФинЦЕРТ: финансовые организации

Финансовые организации уведомляют ФинЦЕРТ (подразделение Банка России) об инцидентах ИБ в соответствии с Положением ЦБ. Формат и сроки уведомления определяются нормативными актами ЦБ для конкретной категории организации.

Система автоматически формирует уведомления для НКЦКИ и Роскомнадзора в установленные сроки — модуль соответствия требованиям КиберОснова контролирует регуляторные обязательства.

Автоматизация управления инцидентами

Скорость реагирования как KPI

В управлении инцидентами время — критический ресурс. Каждый час задержки в обнаружении и сдерживании увеличивает ущерб. Автоматизация сокращает:

• MTTD — автоматическая корреляция событий вместо ручного анализа.
• MTTR — автоматический запуск playbook по типу инцидента.
• Время эскалации — автоматическое уведомление по матрице эскалации.
• Время формирования отчётов — шаблоны для регуляторов заполняются автоматически.

КиберОснова: от обнаружения до отчёта

SGRC-система автоматизирует ключевые аспекты управления инцидентами. Платформа КиберОснова реализует полный цикл:

• Регистрация инцидентов с привязкой к активам и владельцам — единая точка входа из SIEM, обращений, внешних уведомлений.
• Автоматическая классификация, приоритизация, запуск playbook.
• Workflow реагирования: назначение ответственных, контроль сроков, эскалация.
• Формирование отчётов и контроль уведомления регуляторов (НКЦКИ, РКН) в установленные сроки.
• Журнал действий для Post-Incident Review и аудита ИБ.
• Связь инцидентов с управлением рисками — пересмотр рисков по результатам инцидентов.
• Дашборды с метриками MTTD, MTTR, тренды по типам инцидентов.

Типичные ошибки управления инцидентами

1. Отсутствие подготовки

Организация не имеет политики управления инцидентами, playbook и CSIRT. При возникновении инцидента — хаотичные действия, потеря времени на выяснение «кто что делает», уничтожение доказательств. Подготовка — этап, который окупается при первом серьёзном инциденте.

2. Отключение питания заражённого хоста

Рефлекторная реакция — выключить компьютер. Результат: потеря оперативной памяти (ключи шифрования, сетевые соединения, вредоносные процессы). Правильно: изолировать от сети, но не выключать.

3. Игнорирование PIR и отрыв от рисков

Без Post-Incident Review те же ошибки повторяются. А если управление инцидентами существует отдельно от управления рисками, уроки не транслируются в меры защиты и цикл PDCA остаётся разорванным.

Заключение

Управление инцидентами ИБ — процесс, от которого зависит устойчивость организации к кибератакам. Шесть этапов — подготовка, обнаружение, классификация, реагирование, расследование, извлечение уроков — формируют замкнутый цикл, соответствующий требованиям ISO 27035, NIST SP 800-61, ГосСОПКА и российской нормативной базы.

Ключевые факторы успеха: подготовленная CSIRT, playbook для типовых инцидентов, автоматизация обнаружения и реагирования, соблюдение сроков уведомления регуляторов и — самое важное — систематическое извлечение уроков. Без Post-Incident Review процесс остаётся реактивным.

КиберОснова автоматизирует полный цикл управления инцидентами: от регистрации и классификации до формирования отчётов и уведомления регуляторов. Запросите демо и посмотрите, как SGRC-платформа закрывает процесс управления инцидентами от обнаружения до извлечения уроков.