Представьте ситуацию: директор спрашивает про состояние информационной безопасности, а вы отвечаете — «Мы закрыли 100 уязвимостей за квартал». Звучит солидно. Для бизнеса же это почти ничего не значит. Руководству важнее понимать, насколько снизился риск и работает ли вообще то, на что компания тратит деньги.

Поговорим о метриках технического долга в ИБ, которые помогают ответить на эти вопросы и перевести ценность безопасности на язык, понятный бизнесу.

Покрытие контролей

Первая метрика — coverage, уровень покрытия защитой. По сути, это доля инфраструктуры, которую реально контролируют средства безопасности. Если из 100 серверов сканируются на уязвимости только 80, оставшиеся 20 находятся в слепой зоне.

Там может происходить что угодно, и мы об этом даже не узнаем.

Coverage стоит измерять по категориям активов. Допустим, веб-приложения защищены на 90%, корпоративная сеть покрыта полностью, а старые legacy-сервисы — только на 30%. Цифры сразу указывают на болевую точку: там, где 30%, скорее всего скопилась куча невыявленных проблем. Бизнесу это понятно без лишних объяснений.

Высокое покрытие само по себе безопасность не гарантирует. Но без него остальные метрики превращаются в самообман. Если половина систем вообще не мониторится, красивые показатели по уязвимостям — просто картинка, не имеющая отношени�� к реальности. Поэтому логика такая: сначала расширяем покрытие, добиваемся видимости всей инфраструктуры, и только потом имеет смысл хвастаться другими достижениями.

На практике добиться стопроцентного покрытия сложно.

Скорость ремедиации

Второй ключевой показатель — время до исправления уязвимости, Mean Time to Remediate. Он отражает, сколько в среднем проходит от момента обнаружения проблемы до её полного устранения. Чем меньше MTTR — тем лучше, тут всё очевидно.

Обычно MTTR считают отдельно по уровням критичности. Например, критические уязвимости в среднем закрываются за 5 дней, высокие — за 10, средние — за 30. Если критические баги висят открытыми по 50 дней, это уже не просто плохо — это системная проблема, которую надо решать на уровне процессов.

Ещё важнее смотреть на динамику. Сокращение MTTR со временем говорит о том, что процессы реально улучшаются: автоматизировали накатку обновлений, ускорили тестирование, убрали лишние согласования. Рост MTTR, наоборот, сигнализирует о проблемах — возможно, людей не хватает, или деплой стал сложнее, или появились новые бюрократические барьеры.

Динамика MTTR — отличный материал для отчёта руководству. Фраза «Год назад на исправление критической уязвимости уходило 14 дней, сейчас справляемся за 5» показывает конкретный прогресс. Это не абстрактные цифры, а измеримое улучшение, которое можно связать с конкретными инициативами команды.

Отдельно стоит отслеживать MTTR по разным командам или системам. Иногда выясняется, что одна команда закрывает уязвимости за три дня, а другая за три недели. Это повод разобраться: может, у второй команды не хватает ресурсов, или процесс согласования изменений слишком тяжёлый, или просто нет понимания приоритетов.

Возраст долга

Третий ракурс — возраст уязвимостей. То есть насколько давно они обнаружены и всё ещё не устранены. Здесь мы смотрим, сколько уязвимостей протухает дольше определённых сроков — 30, 60, 90, 180 дней. Фактически это показатель того, копится ли просроченный долг.

Если критические уязвимости не закрыты больше 90 дней — это тревожный сигнал. Значит, либо приоритеты расставлены неверно, либо процесс где-то буксует. Для бизнеса картина понятная: компания месяцами живёт с известной дырой, и риск никуда не девается. Более того, информация о такой уязвимости может утечь или стать публичной, и тогда она превратится в мишень для атакующих.

Метрика возраста обычно представляется как количество или процент уязвимостей старше N дней с разбивкой по критичности. Идеальная цель — чтобы критических багов старше, скажем, 7 дней не было вовсе. Если они есть, надо разбираться в причинах. Может, ответственная команда перегружена. Может, исправление требует серьёзных архитектурных изменений. Может, просто никто не взял задачу в работу.

Многие компании вводят внутренние нормативы: «критические уязвимости должны быть исправлены в течение 14 дней», «высокие — в течение 30 дней» и так далее. Такие SLA дисциплинируют и дают чёткие ориентиры. Когда норматив нарушается, это автоматически становится поводом для эскалации и разбора.

KPI и KRI: в чём разница

Полезно различать KPI (Key Performance Indicators) и KRI (Key Risk Indicators). KPI показывают эффективность работы команды, KRI — уровень риска для компании. Это связанные, но разные вещи.

Пример KPI: «за месяц закрыто 100 уязвимостей». Пример KRI: «количество неисправленных критических уязвимостей на внешнем периметре — 0». Первый показатель говорит о проделанной работе, второй — о текущем состоянии риска.

Почему «закрыли N уязвимостей» — плохой показатель, если он единственный? Потому что можно закрыть сотню мелких багов, а одну критическую дыру оставить открытой. Формально работа кипит, а реальная опасность никуда не делась. Такой KPI может даже создавать неправильные стимулы: команда будет гоняться за количеством, выбирая простые задачи вместо важных.

Гораздо полезнее метрики, которые связывают усилия с результатом: процент критических уязвимостей, закрытых в пределах SLA; количество уязвимостей высокого риска, оставшихся открытыми; суммарный риск-показатель и его динамика во времени.

Руководителю не нужно знать каждую техническую деталь, но он хочет видеть, снижается ли рисковый профиль компании. Доклад в стиле «За квартал средний риск уязвимостей снизился на 30%, все критические проблемы закрыты, покрытие выросло с 80% до 95%» — это конкретика, которую можно обсуждать и сравнивать. Гораздо лучше, чем абстрактное «мы исправили 250 багов».

KPI тоже нужны — для мотивации команды, для отслеживания процессов внутри отдела. Но на уровне бизнеса упор должен быть на KRI. Правильно выбранные метрики направляют команду на то, что реально снижает риски, а не на погоню за формальными цифрами. В итоге и компания защищена лучше, и руководству понятно, что бюджет на безопасность тратится не впустую.

На курсе «CISO / Директор по ИБ» разбираем, как строить стратегию и контуры контролей, управлять рисками и требованиями, планировать ресурсы и лидировать команду. Для знакомства с форматом обучения и экспертами приходите на бесплатные демо-уроки:

  • 3 февраля в 20:00. «Soft Skills: умение договариваться для руководителя». Записаться

  • 19 февраля в 20:00. «DDoS-инцидент: как действует CISO». Записаться