Управление инцидентами — почему это не про тикеты, а про выживание

В одном из прошлых постов я высказал мысль, что без процессов SOC — это просто дорогой телевизор, который показывает шум. Сегодня начинаем глубокое погружение. И первый на очереди — Процесс управления инцидентами (Incident Management).

Казалось бы, что тут обсуждать? У всех есть тикет-система, все умеют нажимать кнопку «Create Incident». Но вот парадокс: у 80% команд, которые я видел, «управление инцидентами» заканчивается там, где начинается реальная работа. Они управляют тикетами, но не инцидентами.

В чем разница?
Управление тикетами — это про заполнение полей, соблюдение SLA на «первый ответ» и красивую статистику для руководства. Это бюрократия в чистом виде.
Управление инцидентами — это про то, как ваша система безопасности реагирует на угрозу, локализует её и извлекает уроки. Это кровеносная система SOC. Если она забита тромбами из ненужных согласований или, наоборот, дырявая как решето — ваш SOC умрет при первой же серьезной атаке.

Анатомия провального процесса:
1. «Инцидент ради инцидента». Аналитик создает тикет на каждый чих SIEM, потому что «так положено». В итоге в системе 500 открытых инцидентов, из которых 499 — ложноположительные сработки (False Positive). Реальная атака просто тонет в этом мусоре.
2. Отсутствие жизненного цикла. Инцидент создается, а дальше... тишина. Никто не знает, в каком он статусе, кто над ним работает и что было сделано. Это не процесс, это черная дыра.
3. Формализм вместо контекста. Тикет содержит заголовок «Suspicious Activity» и ссылку на лог. Всё. Аналитик следующей смены тратит час, чтобы просто понять, о чем вообще шла речь.

Как выглядит здоровый Incident Management в 2026 году?

Процесс должен отвечать на три главных вопроса: Что происходит? Что мы с этим делаем прямо сейчас? И как сделать так, чтобы это не повторилось завтра?

Классификация и Приоритизация (Triage)

Ваш процесс должен четко определять: что мы считаем инцидентом, а что — событием ИБ. Не каждый алерт — инцидент. Инцидент — это когда подтверждено нарушение политики или есть реальная угроза.

Практический совет: Внедрите «Матрицу критичности». Приоритизация должна опираться на два фактора: Критичность актива (Asset Criticality) и Уровень угрозы (Severity). Взлом ноутбука курьера (Low Asset) и взлом сервера БД (High Asset) — это разные инциденты по приоритету, даже если техника атаки (например, Mimikatz) одна и та же.

Четкие фазы жизненного цикла (NIST/SANS style)
• Detection & Analysis: подтверждаем, что это не фантомные боли SIEM. Здесь аналитик должен собрать «доказательную базу»: хэши, IP, логи процессов.
• Containment (Локализация): Это самая важная фаза. Ваша цель — остановить «кровотечение».
◦ Совет: Имейте заранее согласованные «аварийные кнопки». Например: «SOC имеет право блокировать учетную запись без согласования, если подтвержден Brute Force». Если аналитик должен ждать три часа одобрения от начальника ИТ, чтобы изолировать зараженный хост — у вас нет процесса реагирования.
• Eradication & Recovery: вычищаем следы и возвращаем бизнес в строй. Здесь мы удаляем веб-шеллы, меняем пароли, восстанавливаем данные из бэкапов.
• Post-Incident Activity: закрываем тикет только после того, как проведен разбор полетов.

«Золотой стандарт» карточки инцидента

Чтобы ваш процесс не превратился в свалку, каждый инцидент должен содержать:
• Executive Summary: кратко для людей (что случилось и каков риск).
• Timeline: хронология событий (когда началось, когда обнаружили, когда локализовали).
• Evidence: ссылки на конкретные события в SIEM/EDR.
• Actions Taken: что именно сделал аналитик. «Посмотрел логи» — это не действие. «Заблокировал IP на FW, изолировал хост через EDR» — это действие.

Практический чек-лист: Здоров ли ваш процесс?
Попробуйте честно ответить на эти вопросы:
1. Знает ли аналитик L1, что ему делать, если он увидел шифровальщик в 3 часа ночи в субботу? (Без звонка начальнику).
2. Можете ли вы за 1 минуту выгрузить список всех инцидентов, связанных с конкретным пользователем за последний месяц?
3. Есть ли у вас статус «Resolved», который отличается от «Closed»? (Разница в том, что угроза устранена, но разбор еще не закончен).
4. Связаны ли ваши инциденты с техниками MITRE ATT&CK?

Главный совет: Начните не с покупки дорогой IRP/SOAR системы, а с рисования схемы на доске. Если вы не можете объяснить процесс управления инцидентом новому аналитику за 10 минут без использования названий кнопок в софте — у вас нет процесса.

Управление инцидентами — это дисциплина. Это умение всей команды действовать как единый механизм в условиях стресса. Если ваш процесс — это просто «создать тикет в Jira», то вы не SOC, вы — секретарь хакера, который старательно записывает его успехи.


НеДобрый SOC
Когда заканчиваются красивые отчеты — начинается настоящая работа.