На проверке Метрики эффективности киберучений: MTTD, MTTR и KPI для оценки готовности SOC

По данным Mandiant M-Trends 2025, медианное время нахождения злоумышленника в инфраструктуре до обнаружения - 11 дней. Исторический минимум. Звучит неплохо, пока не проводишь внутренние purple team-спринты и не видишь: SOC зафиксировал первый алерт через 34 часа, а red team к тому моменту уже сдампил учётные данные из LSASS Memory (T1003.001, Credential Access) и построил полный путь до контроллера домена. Между индустриальной статистикой и результатами учений - пропасть. Метрики эффективности киберучений эту пропасть измеряют. Дальше - формулы расчёта, бенчмарки по severity и конкретные KPI, которые покажут CISO реальную готовность SOC, а не отфильтрованную картинку.

Зачем измерять киберучения: бизнес-логика метрик​

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

1. Обнаруживаем ли мы атаки? - метрики обнаружения (MTTD, Detection Coverage).
2. Реагируем ли достаточно быстро? - метрики реагирования (MTTR, MTTC).
3. Улучшаемся ли между раундами? - трендовые KPI (динамика от учений к учениям).

По данным IBM X-Force Threat Intelligence Index 2025, рост атак с использованием действительных учётных данных (Valid Accounts, T1078, Initial Access) составил +71% год к году. Сигнатурные детекты на эту технику не срабатывают - и только учения с замером метрик покажут, видит ли SOC lateral movement через легитимные аккаунты или пропускает его.

В российской практике методология Результативной кибербезопасности (rezbez.ru) выделяет до 12 метрик для оценки киберучений, включая своевременность реагирования и полноту покрытия средствами мониторинга. MTTD, MTTR и Detection Coverage - количественные эквиваленты этих метрик. Числа вместо «хорошо/плохо».

NIST CSF v2.0 подкрепляет подход: субкатегория DE.AE-01 требует установления baseline сетевых операций и ожидаемых потоков данных, а RS.AN-01 - расследования каждого уведомления от систем детектирования. Без метрик доказать выполнение этих требований не получится - останется формальная галочка.

При этом метрика ради метрики - антипаттерн. Количество срабатываний IDS или процент заблокированного фишинга не отвечают ни на один из трёх вопросов выше. Это «токсичные метрики»: создают иллюзию контроля, но ничего не говорят о способности команды обнаруживать и сдерживать реальные угрозы.

MTTD и MTTR - ядро оценки готовности SOC​

MTTD - Mean Time to Detect: формула и бенчмарки​

MTTD (Mean Time to Detect) - среднее время от начала вредоносной активности до её обнаружения SOC-командой. На киберучениях это разница между таймстампом действия red team и моментом, когда аналитик зафиксировал инцидент в тикетной системе.

MTTD = Σ (Detection_Time[i] - Activity_Start_Time[i]) / N

Пример расчёта по результатам учений - red team выполнил три техники:

• Spearphishing Attachment (T1566.001, Initial Access) - обнаружена через 2 часа
• Scheduled Task (T1053.005, Persistence) - обнаружена через 8 часов
• PowerShell execution (T1059.001, Execution) - обнаружена через 4 часа

MTTD = (2 + 8 + 4) / 3 = 4.67 часа.

По данным Prophet Security, высокопроизводительные SOC показывают MTTD в диапазоне 30 минут - 4 часа. По данным nflo.tech со ссылкой на IBM Cost of Data Breach 2025, организации с MTTD ниже 200 дней экономят в среднем $1.1M на инцидент. Тут нужна оговорка: эта цифра про реальные breach-инциденты в масштабе организаций (шкала - дни и месяцы), а не про контролируемые учения, где MTTD измеряется в часах.

Для киберучений ориентиры жёстче - среда-то контролируемая:

Уровень зрелости SOC	Целевой MTTD на учениях	Что требуется
Начальный	менее 24 часов	Базовая настройка SIEM
Зрелый	менее 4 часов	SIEM с корреляцией, EDR на хостах
Продвинутый	менее 1 часа	Автоматизация, ML, проактивный threat hunting

Если MTTD на учениях превышает 24 часа - дело не в скорости аналитика. Тут системные провалы: нет телеметрии с нужных хостов, правила корреляции кривые или gaps в покрытии MITRE ATT&CK.

MTTD напрямую зависит от полноты логирования. Red team выполнил технику на хосте без Sysmon, без сбора PowerShell ScriptBlock-логов или без EDR-агента - MTTD для этой техники равен бесконечности (техника не обнаружена). Это не баг метрики, а сигнал: мониторинг дырявый.

MTTR - Mean Time to Respond: формула и бенчмарки по severity​

MTTR (Mean Time to Respond) - среднее время от обнаружения инцидента до первого действия по сдерживанию: изоляция хоста, блокировка учётной записи, применение firewall-правила.

MTTR = Σ (Containment_Time[i] - Detection_Time[i]) / N

Буква «R» в MTTR - источник путаницы. Где-то это Respond (первое действие), где-то Resolve (полное восстановление), где-то Recover. На учениях я рекомендую фиксировать оба значения - MTTR (respond) и MTTResolve - и разделять их в отчёте. Два SOC с одинаковым «MTTR = 2 часа» могут показывать принципиально разную скорость: один считает до первой изоляции, другой - до закрытия тикета.

Бенчмарки по severity (по данным Prophet Security):

Severity	Целевой MTTR	Типичный сценарий на учениях
Critical	менее 1 часа	Ransomware (T1486, Impact), активный lateral movement
High	менее 2 часов	Компрометация учётных данных, C2-коммуникация
Medium	менее 4 часов	Подозрительная активность без подтверждённого импакта
Low	менее 8 часов	Информационные алерты, policy violations

Общий ориентир по всем severity в среднем: 2-4 часа.

Почему SOAR искажает MTTR и как это исправить​

SOAR-платформы дают ощутимое ускорение: по данным nflo.tech, организации с SOAR достигают MTTR на 60-90% ниже, чем без автоматизации. Автоматическая изоляция заражённого хоста, блокировка IP, сброс пароля - всё это сжимает MTTR до минут.

На учениях это создаёт ложное чувство безопасности. SOAR-плейбук, заточенный под конкретный алертный сценарий, даёт MTTR = 3 минуты. А red team, использующий технику за пределами плейбука - скажем, Clear Windows Event Logs (T1070.001, Defense Evasion / Stealth) - обходит автоматизацию, и ручной MTTR для этой техники растягивается на часы.

На учениях MTTR нужно считать раздельно:

• Автоматизированный MTTR - время срабатывания SOAR-плейбука. Показывает качество автоматизации.
• Ручной MTTR - время ответа аналитика на алерт без готового плейбука. Показывает квалификацию команды.
• Общий MTTR - взвешенное среднее по всем инцидентам.

Именно ручной MTTR - реальный индикатор зрелости SOC. Автоматизированный MTTR = 2 минуты, а ручной = 6 часов? Команда зависима от плейбуков и не справится с нестандартной атакой. Это нужно видеть в отчёте.

KPI для оценки SOC помимо MTTD и MTTR​

MTTD и MTTR - необходимый минимум, но не достаточный. Ниже - метрики, закрывающие слепые зоны.

Detection Coverage - покрытие MITRE ATT&CK​

Detection Coverage - процент техник MITRE ATT&CK, на которые у SOC есть рабочие, протестированные детекты.

По данным Prophet Security, в ATT&CK 194 техники, связанные с действиями до стадий Exfiltration и Impact. Формула:

Coverage = Detections_Mapped / Total_Techniques × 100%

Гнаться за 100% бессмысленно - это колоссальные ресурсы на поддержку правил. Prophet Security приводит расчёт: для приемлемого уровня обнаружения достаточно порядка 65% покрытия при условии качественной телеметрии.

На киберучениях Detection Coverage проверяется напрямую: red team выполняет N техник, SOC фиксирует M. Coverage_effective = M / N × 100%. Эффективное покрытие (не теоретическое из ATT&CK Navigator, а реальное по итогам учений) - вот ключевая метрика зрелости SOC. Разница между теоретическим и эффективным покрытием бывает удручающей.

False Positive Rate и Alert Fatigue Index​

False Positive Rate (FPR) - доля ложных срабатываний:

FPR = False_Positives / Total_Alerts × 100%.

По данным nflo.tech, целевой FPR - 10-30%. Парадоксально, FPR около 0% - тоже тревожный знак: правила детекции слишком консервативны и пропускают реальные угрозы (высокий False Negative Rate). По данным Prophet Security, целевой False Negative Rate - не более 1%.

Alert Fatigue Index = Alert_Volume × FPR. Чем выше индекс, тем больше риск, что аналитик пропустит реальную атаку из-за информационного шума. На учениях этот индекс стоит фиксировать: если red team-активность генерирует поток ложных срабатываний параллельно с реальными алертами - вы проверяете устойчивость аналитиков к перегрузке. А она, как правило, ниже, чем хочется думать.

Dwell Time и MTTC - время нахождения в сети​

Dwell Time - время нахождения атакующего в инфраструктуре до обнаружения. По данным Mandiant M-Trends 2025, глобальная медиана - 11 дней. По данным nflo.tech, лучшие команды выходят на показатель менее 7 дней, а при ransomware dwell time часто менее 24 часов (атакующие торопятся).

MTTC (Mean Time to Contain) - время от обнаружения до изоляции угрозы и остановки распространения. Бенчмарк: менее 1 часа для критических инцидентов. По данным nflo.tech, ransomware может зашифровать всю сеть за 45 минут - каждая минута задержки containment увеличивает ущерб.

Сравнительная таблица метрик Red Team и Blue Team​

На киберучениях метрики нужны обеим сторонам. Таблица ниже - шаблон для отчёта, заполняемый после каждого раунда.

Метрика	Что измеряет	Кто отвечает	Хороший результат	Плохой результат	Ограничения
MTTD	Скорость обнаружения	Blue Team	менее 4 ч	более 24 ч	Бессмысленна без Detection Coverage
MTTR (respond)	Скорость первого ответа	Blue Team	менее 2 ч	более 8 ч	Искажается SOAR-автоматизацией
MTTR (resolve)	Время до полного закрытия	Blue Team	менее 24 ч	более 72 ч	Зависит от определения «закрыт»
MTTC	Скорость изоляции угрозы	Blue Team	менее 1 ч	более 4 ч	Применима только к containable-инцидентам
Detection Coverage	% покрытых техник ATT&CK	Blue Team	более 65%	менее 40%	Теоретическое покрытие ≠ эффективное
FPR	Доля ложных срабатываний	Blue Team	10-30%	более 50%	0% может скрывать False Negatives
False Negative Rate	Доля пропущенных атак	Blue Team	менее 1%	более 5%	Трудно измерить без red team-лога
Evasion Rate	% необнаруженных техник RT	Red Team	Для blue - менее 20%	Для blue - более 50%	Зависит от сложности техник RT
Alert-to-Incident Ratio	Доля алертов, ставших инцидентами	Оба	10-30%	менее 5% (шум)	Зависит от тюнинга правил

Эту таблицу заполняют после каждого раунда учений и показывают CISO с квартальной динамикой. Тренд важнее абсолютного значения: MTTD = 6 часов, снизившийся с 18 часов за два квартала, - сильнее, чем стабильные 4 часа без динамики.

Как собирать метрики на киберучениях: пошаговый процесс​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Шаг 2. Синхронизация времени. Убедитесь, что NTP синхронизирован на всех компонентах: SIEM, тикетная система, хосты red team. Расхождение в 5 минут искажает MTTD для быстрых техник. (Казалось бы, мелочь - но на практике именно рассинхрон NTP портит половину замеров.)

Шаг 3. Red team ведёт лог. Каждая техника фиксируется с таймстампом начала, T-кодом и целевым хостом. Пример строки: 2025-03-15 14:23 UTC | T1053.005 | DC01.corp.local | Scheduled Task created for persistence.

Шаг 4. Blue team работает в штатном режиме. Никаких подсказок о применяемых техниках. Аналитики работают по стандартным плейбукам. Каждый алерт фиксируется в тикете.

Шаг 5. Сведение результатов. После окончания red team передаёт лог, blue team - журнал тикетов. Для каждой техники считается: обнаружена или нет (Detection Coverage), время обнаружения (MTTD), время сдерживания (MTTR). Необнаруженные техники - красные ячейки в ATT&CK Navigator.

Шаг 6. Визуализация и отчёт. ATT&CK Navigator раскрашивается: зелёным - обнаруженные техники, красным - пропущенные. Заполняется сводная таблица метрик. Добавляется сравнение с предыдущим раундом.

Типичные ошибки при измерении эффективности киберучений​

Ошибка 1. Считать MTTD только по обнаруженным инцидентам. Red team выполнил 20 техник, SOC обнаружил 8. MTTD считается по 8, остальные 12 - MTTD = бесконечность. Среднее по обнаруженным выглядит красиво - допустим, 2 часа - но 60% атак пропущены. Всегда показывайте Detection Coverage рядом с MTTD. Одно без другого - самообман.

Ошибка 2. Смешивать автоматизированный и ручной MTTR. SOAR-плейбук закрыл алерт за 90 секунд, аналитик потратил 6 часов на расследование без плейбука. Средний MTTR = 3 часа. Число не говорит ни о качестве автоматизации, ни о квалификации аналитика - оно бесполезно.

Ошибка 3. Не фиксировать Evasion Rate red team. Если red team «поддаётся» - использует заведомо громкие техники, чтобы blue team показал результат - метрики учений обесцениваются. Evasion Rate = пропущенные техники / все техники × 100%. Этот показатель должен быть честным, иначе зачем вообще всё затевать.

Ошибка 4. Отсутствие baseline. Первые учения без предшествующих данных дают абсолютные числа, которые не с чем сравнивать. Начинайте с baseline: FPR за последние 90 дней, Detection Coverage из Navigator, медианный MTTR из тикетной системы.

Ошибка 5. Использовать mean вместо median. По замечанию Prophet Security, медиана (Median Time to Respond) устойчивее к выбросам. Один инцидент с MTTR = 48 часов (аналитик в отпуске, тикет завис) искажает среднее для всей команды. Для CISO-отчёта показывайте медиану и среднее - но решения принимайте по медиане.

Метрики эффективности киберучений - не dashboard, который настроил и забыл. За последние пару лет через мои руки прошли десятки отчётов по учениям, где MTTD и MTTR выглядят на уровне лучших бенчмарков - пока не начинаешь копать. Какой процент техник red team вообще был обнаружен? Сколько «быстрых ответов» - заслуга SOAR-плейбука, а не аналитика? Был ли хоть один тикет, где человек обнаружил атаку без алерта, по аномалии?

Неудобная правда: MTTD = 2 часа при Detection Coverage = 30% - плохой результат, замаскированный под хороший. SOC быстро реагирует на то, что видит, но не видит основную часть kill chain. Пока в отчёте рядом не стоят Coverage, Evasion Rate и раздельный MTTR - CISO получает фильтрованную картину.

Большинство организаций начинают с MTTD и MTTR и на этом останавливаются. Те, кто добавляет эффективный Detection Coverage по ATT&CK и раздельный MTTR (автоматизированный/ручной), за два-три квартала выходят на другой уровень зрелости - не потому что инструменты стали лучше, а потому что увидели свои реальные провалы. На форуме Codeby есть тред, где разбираем подобные кейсы по метрикам SOC и результатам учений - стоит заглянуть, если у вас другой стек или другие пороговые значения.