Управление инцидентами не должно строиться на ощущениях («кажется, это опасно»). Оно должно строиться на математике. Ниже приведена модель расчета приоритетов и конкретные значения (Thresholds) для метрик эффективности, к которым должен стремиться современный SOC.

1. Расчет критичности (Severity Scoring)

Мы используем формулу, где максимальный балл – 12, а минимальный – 0.

Severity = (Бизнес-влияние + Влияние на данные) + Сложность восстановления

Компоненты формулы:

Бизнес-влияние (0–5):

  • 0: Нет влияния.
  • 1: Деградация некритичных сервисов (тормозит Wi-Fi в гостевой сети).
  • 3: Частичный отказ (не работает CRM у отдела продаж).
  • 5: Полный отказ (Downtime). Остановка платежей/конвейера.

Влияние на данные (0–5):

  • 0: Данные не затронуты.
  • 3: Утечка персональных данных (ПДн) или внутренней кухни.
  • 5: Потеря целостности (Integrity Loss). Данные подменены/зашифрованы.

Восстановление (0–2):

  • 0: Стандартный плейбук (изолировать хост, сменить пароль).
  • 2: Требуется Disaster Recovery (разворачивание из бэкапов, Forensic-расследование).

2. Матрица реагирования (SLA)

Исходя из полученного балла (0–12), инцидент попадает в одну из четырех категорий.

Пример с «фишингом и шифрованием» (Бизнес: 5 + Данные: 5 + Восстановление: 2 = 12) – это потолок шкалы, катастрофа.

Градация инцидентов:

  • 10-12 баллов (P1 - Critical) - Время реакции 15 минут **Кризис. **Требует немедленного сбора Crisis Team 24/7.

Примеры: Успешная атака Ransomware, компрометация контроллера домена, утечка клиентской БД, обнаружение активного C2 канала на серверах процессинга.

  • **7-9 баллов ** (P2 - High) - Время реакции 1 час Угроза бизнесу. Требует немедленной работы L2/L3 аналитиков.

Примеры: Mimikatz на рабочей станции админа, массовый фишинг с успешными вводами паролей, обнаружение веб-шелла на внешнем периметре.

  • **4-6 баллов ** (P3 - Medium) - Время реакции 4 часа Штатный инцидент. Обрабатывается в порядке очереди.

Примеры: Единичное заражение malware на изолированном хосте, подозрительная активность VPN из необычной гео-зоны (без подтверждения взлома).

  • **0-3 балла ** (P4 - Low) - Время реакции 24 часа Информационный / Тюнинг. Обрабатывается в порядке очереди.

Примеры: Сканирование портов (отбитое WAF), нарушение политик (использование Tor), установка нежелательного ПО (Adware).

3. Метрики эффективности (KPI)

Отказываясь от «средней температуры по больнице» (MTTR), мы внедряем показатели качества обнаружения и сдерживания.

1. False Positive Rate (FPR) – Уровень ложных срабатываний

Метрика показывает «зашумленность» вашего SOC.

  • Проблема: Если из 100 алертов 90 оказываются пустышками, аналитики перестают реагировать (Alert Fatigue).

Целевой показатель:

  • Для автоматических блокировок: < 0.1% (ошибка здесь недопустима, иначе остановим бизнес).
  • Для алертов аналитику (L1): < 10-15%.

Как читать: Если FPR выше 20% (каждый пятый алерт – ложный), нужно не нанимать людей, а отключать правила корреляции и переписывать их.

2. Breakout Time (вместо абстрактного Dwell Time)

«Время присутствия хакера» часто меряют месяцами. Это пост-фактум метрика. Для оперативной работы используйте Breakout Time – время, за которое хакер успевает уйти с первого зараженного хоста дальше по сети (Lateral Movement).

  • Статистика: Среднее время «прорыва» у продвинутых групп — 1 час 30 минут.

Целевой KPI (Правило 1-10-60):

  • 1 минута на обнаружение (автоматика).
  • 10 минут на анализ и верификацию.
  • 60 минут на изоляцию хоста.

Итог: Вы должны быть быстрее, чем 90 минут. Если вы реагируете дольше 2 часов, злоумышленник уже контролирует не один ноутбук, а всю подсеть.

3. ARR (Autonomous Resolution Rate)

Показатель зрелости автоматизации (SOAR).

  • Что считаем: Процент тикетов категории P3/P4 (типовые вирусы, сканирования), которые были закрыты скриптами без участия человека.
  • Целевой показатель: > 80% для рутинных инцидентов.

Смысл: Люди должны заниматься только P1 и P2. Если L3-аналитик вручную сбрасывает пароли пользователям – это провал экономики SOC.

4. Signal-to-Noise Ratio (SNR)

Отношение полезных, обогащенных кейсов к сырому потоку событий.

Хороший SOC не гордится тем, что обработал «миллиард логов». Он гордится тем, что из миллиарда логов сгенерировал 10 высокоточных инцидентов и предотвратил ущерб.