Два года назад я собрал в Splunk дашборд для квартального отчёта перед советом директоров. Центральная метрика - "1 247 832 заблокированных атаки за квартал". Зелёные индикаторы, растущий тренд, красота. CFO посмотрел и спросил: "Если в следующем квартале заблокируем 800 тысяч - мы стали хуже защищены?". Я завис. Цифра не говорила ничего ни о рисках, ни о реальном уровне защиты. По данным PwC (цитата через UpGuard), только 22% CEO уверены, что получают достаточно полные данные о рисках для принятия решений. EY даёт ещё жёстче: 15% организаций считают свою ИБ-отчётность соответствующей ожиданиям. Проблема не в отсутствии измерений - security-команды измеряют не то.
KPI для ИБ-команды: какие метрики создают иллюзию защищённости
Есть категория показателей, которые выглядят убедительно на слайде, но не помогают ни принять решение, ни оценить реальный уровень защиты. Три главных "пустышки":"Количество заблокированных атак". Та самая цифра в миллионах. Растёт, когда ботнеты сканируют периметр, падает в праздники. Корреляция с защищённостью - нулевая. Вы не можете повлиять на количество входящих сканов, а значит метрика не actionable. Красивый фантик, внутри - пусто.
"Количество инцидентов за период". Снижение может означать улучшение защиты. А может - деградацию мониторинга. Как справедливо подметили на CISOClub, команда SOC способна занижать классификацию событий, чтобы "улучшить" статистику. Или наоборот: рост инцидентов показывает, что аналитики стали внимательнее, а не то, что атак стало больше. Метрика, где улучшение и деградация выглядят одинаково - бесполезна.
"Процент закрытых уязвимостей" без привязки к severity и SLA. 95% - звучит отлично, пока не выясняется, что оставшиеся 5% - critical на публичных сервисах, которые висят открытыми третий месяц.
Почему атакующий обесценивает ваши метрики
Опасность "пустышек" не только в ложном чувстве контроля. Атакующий, применяющий Disable or Modify Tools (T1562.001, Defense Evasion), отключает EDR-агент на хосте - а ваша метрика "покрытие EDR: 100%" остаётся зелёной. Spoof Security Alerting (T1685.003) позволяет подменить алерты - дашборды показывают штатную работу, а в сети идёт lateral movement. Clear Windows Event Logs (T1685.005) обнуляет MTTD для конкретного хоста: нельзя детектировать то, чего нет в логах.Через Security Software Discovery (T1518.001) атакующий первым делом определяет, какие инструменты вы используете и что мониторите. Он буквально знает, какие метрики вы собираете, и строит операцию так, чтобы не попасть ни в одну из них. Метрика, которую можно обмануть без ведома SOC - это не метрика, а декорация.
Как измерить эффективность ИБ: MTTD, MTTR и метрики SOC
Три операционные метрики - MTTD, MTTR и MTTC - считают почти все, но часто неправильно.
MTTD - Mean Time to Detect
Среднее время от момента, когда атакующий получает initial access, до фиксации подозрительной активности SOC. Формула:MTTD = Сумма (времядетекта − времякомпрометации) / количество_инцидентов
Типичная ошибка: за "время компрометации" берут момент первого алерта SIEM, а не реальный initial access. При расследовании инцидента момент проникновения восстанавливается ретроспективно - по логам аутентификации, сетевым записям, артефактам. Разрыв между "первый алерт" и "реальный initial access" может составлять дни. Если считать MTTD от алерта - получается время реакции на шум, а не время обнаружения атаки.
Пример: извлечение MTTD из Splunk, где
incident_timeline - lookup-таблица, заполняемая при расследовании с реальной датой компрометации:
Код:
index=notable status=closed
| eval detect_ts=_time
| lookup incident_timeline incident_id OUTPUT first_compromise_ts
| eval mttd_hrs=round((detect_ts - first_compromise_ts)/3600, 1)
| stats avg(mttd_hrs) as avg_mttd median(mttd_hrs) as p50_mttd by urgencyMTTR - Mean Time to Resolve
Общее время устранения инцидента. Единая цифра MTTR бесполезна - разумнее разбить на фазы и искать bottleneck:| Фаза | Что измеряет | Ориентир для зрелого SOC |
|---|---|---|
| Detection -> Triage | От алерта до начала разбора | 15-30 минут |
| Triage -> Containment | От начала разбора до изоляции | 1-4 часа |
| Containment -> Eradication | Полное удаление присутствия атакующего | 24-72 часа |
| Eradication -> Recovery | Восстановление сервисов | 4-48 часов |
Часто bottleneck - не в детекте, а в эскалации: аналитик L1 видит алерт, но не уверен в критичности и ждёт подтверждения от L2. Если ваш MTTR = 48 часов и 36 из них уходят на эскалацию - проблема в процессе, не в технологиях. Покупка нового SOAR тут не поможет.
MTTC - Mean Time to Contain
Время от обнаружения до изоляции угрозы - самая критичная метрика с точки зрения ущерба. Именно containment останавливает lateral movement. Если MTTC = 6 часов, атакующий успевает закрепиться на нескольких хостах и, вполне возможно, добраться до domain admin через privilege escalation. Шесть часов - это целая вечность для red team.Red team как проверка реальности
Заявленный MTTD из дашборда и фактический MTTD при настоящей атаке - часто два разных числа. На одном из tabletop exercises после red team-операции дашборд показывал MTTD = 4 часа. Красная команда просидела в сети 11 дней без единого алерта - использовала legitimate credentials и избегала шумных TTPs. Метрика была посчитана корректно, но базировалась только на инцидентах, которые SOC уже видел. Слепые зоны в расчёт не входили.Рекомендация: проводите red team-операции не реже раза в полугодие и сравнивайте фактический MTTD красной команды с отчётным. Расхождение больше чем в 2 раза - ваши метрики SOC описывают идеализированную картину, а не реальность.
Показатели эффективности vulnerability management: от сканера до SLA
Управление уязвимостями - область, где метрики информационной безопасности врут чаще всего. "10 000 уязвимостей найдено" - и что дальше? Без severity-приоритизации и контекста эксплуатируемости сырые цифры бесполезны.Покрытие: ширина и глубина
По модели ToucanToco для CISO-дашбордов, покрытие имеет два измерения.Ширина (breadth): процент активов, охваченных программой vulnerability management. Например, 70% серверов дата-центра и облачных активов покрыты сканированием через Tenable.io или Qualys. Цель - 100% к концу года. Но 100% покрытия сетевым сканером не означает 100% видимости: API-сервисы, контейнеры, serverless-функции часто выпадают из стандартного сканирования. Сканер их просто не видит.
Глубина (depth): какие слои стека проверяются. Если сканируете только ОС и не трогаете зависимости приложений, middleware, конфигурации - ваш "100% coverage" реально покрывает 30–40% атакуемой поверхности. Пентестер это заметит первым - обычно через уязвимую библиотеку в npm или pip.
Remediation backlog efficiency
Формула, показывающая, справляется ли команда с потоком уязвимостей или тонет:
Код:
Backlog Efficiency = Closed_This_Month / (Open_Backlog + New_This_Month) * 100Risk Exposure Rate
Процент уязвимостей, которые "утекли" в продакшн, несмотря на все проверки:Risk Exposure Rate = Vulns_In_Prod / (Vulns_Fixed_PreProd + Vulns_In_Prod) * 100
Один из сценариев ToucanToco: 30 уязвимостей найдено в продакшне при 250 исправленных на этапе подготовки - risk exposure rate = 11%. Цель - снижать этот процент от квартала к кварталу. Если RER растёт - ваш pipeline безопасности пропускает дефекты, и надо разбираться где именно дырка.
SLA по устранению: привязка к severity
Метрика «среднее время устранения уязвимости» бессмысленна без разбивки по критичности:| Severity | SLA (дни) | Что отслеживаем |
|---|---|---|
| Critical (CVSS 9.0+) | 7 | % закрытых в срок |
| High (CVSS 7.0-8.9) | 30 | % закрытых в срок |
| Medium (CVSS 4.0-6.9) | 90 | % закрытых в срок |
| Low (CVSS 0.1-3.9) | 180 | % закрытых в срок |
Показатель "% критических уязвимостей, закрытых в рамках SLA" - одна из немногих метрик vulnerability management, которая реально связана с бизнес-риском. 60% critical закрывается вовремя? Значит пентестер имеет 40%-ное окно для initial access через известные эксплойты. Это не абстрактный риск - это конкретное окно, через которое заходят.
Пентест vs сканер: разница в данных
Сканер находит CVE по версиям. Пентестер находит цепочки: слабый пароль -> lateral movement -> privilege escalation -> domain admin. Метрики, построенные только на данных сканера, не отражают реальную эксплуатируемость. Включайте результаты пентестов и red team-операций в расчёт: из 200 "high" по CVSS уязвимостей пентестер реально проэксплуатировал 12 - ваш процесс приоритизации нуждается в пересмотре. CVSS без контекста эксплуатируемости - это как диагноз по учебнику без осмотра пациента.Метрики зрелости ИБ-программы: CIS Controls и NIST CSF как система координат
Зрелость ИБ-программы - не бинарное "есть/нет", а спектр. Два фреймворка дают практическую шкалу для измерения защищённости организации.
CIS Controls v8: Implementation Groups как шкала
CIS Controls разделены на Implementation Groups (IG1 -> IG2 -> IG3), где IG1 - базовая кибергигиена, IG3 - продвинутая защита. Метрика зрелости: процент safeguards каждой IG, реально внедрённых и подтверждённых проверкой.Пример по CIS-1 (Inventory and Control of Enterprise Assets): safeguard 1.1 требует поддерживать актуальную инвентаризацию. Метрика: % активов в сети, зарегистрированных в CMDB с точностью до 24 часов. На 500 активов 120 "неопознанных устройств" - покрытие CIS-1.1 = 76%. Конкретная цифра, которую можно улучшать, и которая напрямую связана с безопасностью: неопознанные устройства - потенциальные точки входа без EDR и без патчей. Каждое такое устройство - подарок для атакующего.
По CIS-5 (Account Management): safeguard 5.3 требует отключения неактивных учёток. Метрика: % аккаунтов, не входивших в систему > 90 дней и всё ещё активных. Каждая такая учётная запись - вектор для атакующего, который через Password Policy Discovery (T1201) определяет требования к паролям и брутфорсит заброшенные аккаунты. Забытая учётка сервисного аккаунта с паролем
Company2019! - классика, которую я встречал не раз.NIST CSF v2.0: покрытие функций
NIST CSF v2.0 организует безопасность по шести функциям: Govern (GV), Identify (ID), Protect (PR), Detect (DE), Respond (RS), Recover (RC). Метрика зрелости - оценка реализации каждой функции по шкале от Partial до Adaptive.Типичная картина в средней организации: Protect = 3 (Repeatable), Detect = 2 (Risk-Informed), Respond = 1 (Partial). Деньги вложены в файрволы и антивирусы, мониторинг настроен на базовом уровне, плана реагирования либо нет, либо он не тестировался с прошлого года. Radar-диаграмма этих оценок - мощный визуальный инструмент для совета директоров: перекос виден мгновенно и не требует технического контекста. Директор видит "Respond = 1" и задаёт правильный вопрос.
Security metrics для CISO: дашборд отчётности по информационной безопасности
Большинство программ KPI кибербезопасности, которые я видел за время работы, проваливаются не из-за плохой математики. Формулы MTTD и MTTR все знают. Проблема глубже: команды измеряют то, что легко считается, а не то, что показывает реальную устойчивость к атаке. Процент патченных серверов легко вытащить из Tenable. А ответ на вопрос "сможет ли атакующий получить domain admin за 48 часов" - ни на одном дашборде не появляется, потому что для этого нужно регулярно проводить red team-операции и честно учитывать результаты.
Неудобная правда: большинство дашбордов существуют, чтобы CISO мог отчитаться перед советом директоров, а не чтобы улучшить защиту. Если vulnerability SLA показывает 95% compliance, а пентестер за два дня добирается до контроллера домена через цепочку, которую сканер не видит - эти 95% ничего не стоят.
Метрика должна болеть. Если показатель всегда зелёный - он бесполезен. Хороший KPI - тот, который периодически уходит в красную зону и заставляет пересматривать приоритеты. Если вы ни разу не нарушили SLA по устранению критических уязвимостей - либо SLA слишком мягкий, либо severity классифицируется неверно. Единственный способ проверить - столкнуть ваши метрики с реальной атакой. Запустите red team, сравните дашборд с результатами и посмотрите, сколько зелёных индикаторов переживут столкновение с действительностью.
Последнее редактирование модератором:
