«Мы вложили в безопасность серьёзные деньги. Стало лучше?» — вопрос, который рано или поздно задаёт любой руководитель, и на который команда vulnerability management (VM) часто отвечает словами вместо цифр. Проблема не в том, что работа не ведётся. Проблема в том, что она не переведена на язык, понятный бизнесу: сроки, риски, динамика. Ниже — практический разбор того, как построить защиту результатов VM перед руководством: от базовой метрики до проверки, которую сложно накрутить.

Почему «мы закрыли 500 уязвимостей» — плохой аргумент

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

Поэтому отчётность стоит строить вокруг времени и риска, а не вокруг объёма. Объём показывает активность команды, время и риск — эффект для бизнеса. Первое интересно внутри команды, второе — на уровне бюджета и приоритетов.

MTTR: главная метрика, которую нужно научиться считать честно

MTTR (mean time to remediate) — среднее время от обнаружения уязвимости до её устранения. Метрика хороша тем, что понятна без перевода: «критичные уязвимости живут в среднем N дней». Но у неё есть ловушки, из-за которых цифра легко превращается в самообман.

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

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

Лестница зрелости: где вы находитесь и что делать дальше

Метрики без процесса не растут. Полезно честно определить текущий уровень зрелости VM — не для красивой презентации, а чтобы понять следующий шаг. Условная лестница выглядит так:

  • Хаос. Сканеры есть, но результаты разрознены, приоритизация ручная, сроки не заданы. Метрики считать не на чем.
  • Учёт. Есть инвентаризация активов, единый список находок, назначены ответственные. Появляется возможность считать MTTR.
  • Приоритизация по риску. Уязвимости ранжируются с учётом эксплуатируемости и критичности активов, а не только по CVSS. Сроки устранения привязаны к уровню риска.
  • Управление по метрикам. Целевые сроки, регулярная отчётность, разбор просрочек, обратная связь владельцам систем.
  • Непрерывный цикл (CTEM-подход). Обнаружение, приоритизация, проверка и устранение идут постоянным циклом, а не квартальными кампаниями.

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

Проверка боем: метрика, которую невозможно накрутить

Любую отчётную цифру можно улучшить на бумаге: переклассифицировать находки, сдвинуть даты, закрыть тикет без реального исправления. Поэтому в отчётность стоит добавить проверку, которая показывает, работает ли процесс на практике. Варианты:

  • Выборочная верификация закрытий. Регулярно перепроверяйте часть «устранённых» уязвимостей повторным сканированием или ручной проверкой. Доля подтверждённых закрытий — честный индикатор качества процесса.
  • Контрольные находки. Договоритесь с командой, что часть тестовых уязвимостей вносится намеренно, и смотрите, за какое время процесс их поймает и закроет.
  • Учения по сценарию. Возьмите реальную критичную уязвимость и пройдите путь от обнаружения до устранения, замеряя время на каждом этапе. Это вскрывает узкие места лучше любого дашборда.

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

Как собрать это в разговор с руководством

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

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