«Измерение безопасности, это не про сбор цифр, а про управление рисками. Большинство метрик, это просто шум, который создаёт иллюзию контроля. Настоящая задача — найти те несколько показателей, которые действительно покажут, куда движется система, и заставят команду действовать, а не отчитываться.»
Почему большинство метрик безопасности, это мусор
Отдел информационной безопасности начинает собирать метрики. Количество сработавших сигналов SIEM, процент закрытых уязвимостей, число пройденных сотрудниками тестов на фишинг. Цифры красиво ложатся в дашборды и квартальные отчёты. Но проходит время, и становится ясно: эти цифры ничего не говорят о реальной безопасности. Количество инцидентов не снижается, а уязвимости находят уже после того, как их эксплуатируют. Метрики есть, а понимания — нет.
Проблема в том, что легко измерить то, что просто подсчитать. Сложно измерить то, что действительно важно. Классические метрики активности (activity metrics) часто путают с метриками результата (outcome metrics). Первые показывают, что вы что-то делаете: провели 100 сканирований. Вторые — к чему это привело: снизился ли уровень риска? Если метрика не связана напрямую с бизнес-риском, её ценность близка к нулю. Она создаёт бюрократическую нагрузку, но не влияет на решения.
От целей к показателям: как не сбиться с пути
Разработка валидных метрик начинается не с выбора инструмента сбора данных, а с чёткого ответа на вопрос: «Что мы хотим защитить и от чего?» Для этого нужно определить критические активы и наиболее вероятные угрозы для них в контексте конкретного бизнеса. Цель метрики — показать, насколько эффективно мы управляем рисками для этих активов.
Популярная методология — Goal-Question-Metric (GQM). Она помогает выстроить логическую цепочку:
- Цель (Goal): Снизить риск компрометации внешнего периметра компании.
- Вопрос (Question): Насколько эффективно мы обнаруживаем и устраняем уязвимости на внешних веб-сервисах до их эксплуатации?
- Метрика (Metric): Время между обнаружением критической уязвимости на внешнем ресурсе и её устранением (Mean Time to Remediate, MTTR).
Такая метрика уже имеет контекст. Она измеряет не просто «количество уязвимостей», а скорость реакции на конкретную угрозу для конкретной цели. Если MTTR растёт, это сигнал о проблемах в процессах. Если снижается — процесс улучшается.
Что измерять: от количества к качеству и скорости
Сосредоточьтесь на трёх ключевых типах показателей, которые имеют практическую ценность.
Метрики состояния защищённости
Это снимок системы в определённый момент. Но важно измерять не статичные параметры, а их динамику. Вместо «95% серверов имеют установленный EDR-агент» лучше смотреть «Процент охвата EDR по критическим серверам еженедельно». Падение этого процента — немедленный сигнал к действию. Сюда же относятся показатели конфигурационной жёсткости, полученные от сканеров, но с привязкой к критичности asset-ов.
Метрики эффективности процессов
Безопасность, это процессы. Их эффективность определяет итоговый уровень риска. Ключевые метрики здесь связаны со временем.
- Mean Time to Detect (MTTD): Сколько времени проходит от начала атаки до её обнаружения. Снижение этого показателя — прямая цель SOC.
- Mean Time to Respond (MTTR): Время от обнаружения до полного устранения последствий инцидента. Показывает слаженность работы IR-команды.
- Mean Time to Remediate (для уязвимостей): Как быстро патч или фикс доходит до production-среды. Этот показатель часто упирается в процессы разработки и тестирования, выявляя межотдельские проблемы.
Измерение этих метрик требует чёткого фиксирования временных меток в системах (тикетинг, SIEM, сканеры).
Метрики воздействия и риска
Самые сложные, но самые ценные метрики. Они отвечают на вопрос «Во что нам это обошлось?». Это не только прямые финансовые потери от простоя, но и репутационный ущерб, стоимость восстановления данных, штрафы регуляторов. Часто они выражаются в денежном эквиваленте или в баллах риска. Например, агрегированный показатель «Среднегодовые ожидаемые потери от инцидентов ИБ» на основе исторических данных и моделирования угроз. Такие метрики говорят на языке бизнеса и помогают обосновать бюджет на безопасность.
Ловушки и антипаттерны при разработке метрик
Даже с правильным подходом легко попасть в ловушку, которая обесценит все усилия.
- Измерять то, что легко, а не то, что нужно. Процент выполнения обязательного обучения ИБ — простая метрика. Но она не говорит ни о чём, кроме факта прохождения теста. Качественной метрикой могло бы быть «Количество успешных фишинговых атак на сотрудников, прошедших обучение, vs. на непрошедших».
- Стимулировать неправильное поведение. Если KPI отдела ИБ — «нулевое количество инцидентов», это приведёт к сокрытию мелких инцидентов и замалчиванию проблем. Правильнее измерять «скорость обнаружения и прозрачность расследования».
- Игнорировать контекст. Метрика «100 критических уязвимостей» ничего не значит. 100 уязвимостей в тестовой среде, это одно. 100 уязвимостей на внешнем портале для клиентов, это чрезвычайная ситуация. Всегда добавляйте контекст: критичность системы, exposure, сложность эксплуатации.
- Слепая агрегация. Усреднение данных по всей компании скрывает проблемные зоны. Падение одного критического сервера в среднем по больнице с тысячей машин будет выглядеть как незначительное событие. Смотрите на метрики по сегментам: периметр, критичные активы, платёжные системы.
Практика: от дашборда к действию
Собранные метрики должны не просто лежать в отчёте, а влиять на решения. Для этого дашборды должны быть интерактивными и привязанными к процессам.
- Определите владельцев. У каждой ключевой метрики должен быть ответственный — тот, кто может повлиять на её значение. MTTR для уязвимостей веб-приложений — владелец команда разработки и ИБ.
- Установите целевые значения и пороги. Не просто «снижать MTTD», а «достичь MTTD менее 2 часов для инцидентов на критичных активах к концу года». При выходе за порог (например, MTTR > 7 дней) должна автоматически создаваться задача или инцидент.
- Интегрируйте в регулярные процессы. Обсуждайте ключевые метрики на оперативных совещаниях с разработкой и эксплуатацией. Включите их в отчёты руководству не как набор цифр, а как историю с выводами и планами действий.
Эффективный дашборд, это не мозаика из 50 графиков. Это 5-7 ключевых показателей, которые сразу отвечают на вопрос: «Всё ли в порядке с нашей безопасностью? Где горит?»
Валидация и адаптация: метрики должны меняться
Мир угроз и бизнес-процессы не стоят на месте. Метрики, актуальные год назад, сегодня могут потерять смысл. Регулярно, хотя бы раз в квартал, задавайте себе вопросы:
- Продолжает ли эта метрика отражать актуальные риски?
- Приводят ли данные по этой метрике к полезным действиям?
- Не стимулирует ли она негативное поведение?
- Можно ли собрать эти данные точнее или с меньшими затратами?
Если на большинство вопросов ответ «нет» — метрику пора пересматривать или удалять. Измерение безопасности, это не создание вечного отчёта. Это живой инструмент управления, который должен эволюционировать вместе с организацией и её угрозами.