По данным IBM X-Force Threat Intelligence Index 2025, среднее время между публикацией CVE и её устранением в организациях - 29 месяцев. Не дней. Месяцев. А дашборд VM-программы в это время бодро показывал «80% критикалов закрыто» - потому что восемьдесят процентов считались по Low и Medium на рабочих станциях с автоматическим патчингом через WSUS. Сканер работает, команда работает, а проблема - в метриках, которые создают иллюзию контроля. Дальше - формулы, SQL-запросы и пороговые значения, которые можно забрать в свой дашборд прямо сейчас.
Операционные и бизнес-метрики VM: два языка для двух аудиторий
Прежде чем считать MTTP и coverage rate, определитесь - для кого эти цифры. Разрыв между тем, что хочет видеть борд, и тем, что считает VM-команда, колоссален.Борд и CISO хотят:
- Соответствие регуляторным требованиям (ФСТЭК в рамках ФЗ-187 проверяет выполнение требований по безопасности ЗОКИИ - наличие документированной VM-программы с метриками один из проверяемых артефактов)
- ROI на security-инструменты
- Снижение risk exposure в деньгах
- MTTD / MTTR / MTTP
- Scan coverage и частотой сканирования
- Remediation rate по severity
- Recurrence rate и backlog age
Обратная ситуация не лучше: «снижение risk exposure на 34%» без операционных данных под капотом - красивая цифра, которую невозможно проверить и невозможно воспроизвести.
Я пришёл к простому подходу: два набора метрик. Операционные - для ежедневного управления процессом. Бизнес-метрики - для ежеквартальных отчётов руководству. Дальше разберём каждую ключевую метрику управления уязвимостями с формулами и подводными камнями.
MTTP и MTTR: время устранения уязвимостей - ядро измерения эффективности VM
MTTP (Mean Time to Patch) и MTTR (Mean Time to Remediate) часто используют как синонимы, но разница существенна. В глоссариях Tenable, Qualys, SANS VMMM эти термины мешают в одну кучу. Здесь я их разделяю:MTTR (Mean Time to Remediate) - среднее время от обнаружения уязвимости до её устранения любым способом: патч, компенсирующая мера, WAF-правило, вывод актива из эксплуатации.
MTTP (Mean Time to Patch) - среднее время от обнаружения до установки конкретного патча вендора на все затронутые хосты.
MTTR может быть меньше MTTP: компенсирующая мера (сегментация, виртуальный патч на IPS) применяется до выхода патча. Для отчётности полезно считать оба.
Формула и SQL-запрос для расчёта
Формула MTTP: сумма дней от обнаружения до закрытия по каждой CVE, делённая на количество закрытых CVE. Считать нужно отдельно по severity - агрегированный MTTP по всем severity маскирует проблемы (об этом ниже).Если данные из сканера (Tenable.sc, Qualys, MaxPatrol VM) экспортированы в PostgreSQL или ClickHouse:
SQL:
SELECT
severity,
ROUND(AVG(EXTRACT(DAY FROM (date_patched - date_detected))), 1) AS mttp_days,
COUNT(*) AS total_patched
FROM vulnerabilities
WHERE status = 'patched'
AND date_patched >= NOW() - INTERVAL '90 days'
AND asset_status = 'active'
GROUP BY severity
ORDER BY
CASE severity
WHEN 'Critical' THEN 1 WHEN 'High' THEN 2
WHEN 'Medium' THEN 3 ELSE 4 END;asset_status = 'active' критически важен - без него «мёртвые» хосты, удалённые из инфраструктуры, раздувают статистику.Три фактора, искажающих MTTP
Массовый Patch Tuesday. Один цикл обновлений Windows закрывает десятки CVE разом. MTTP резко падает - иллюзия прогресса. А критикалы на периметральных сервисах могли лежать месяцами до этого момента.Задержка пересканирования. Патч установлен в понедельник, сканер прошёл в пятницу -
date_patched считается по дате rescan, MTTP раздулся на 4 дня. Решение: брать дату установки из WSUS/SCCM/MDM, а не из результатов сканирования.«Мёртвые» CVE без закрытия. Хост удалён, тикет в Jira не закрыт, уязвимость висит в статусе Open. Считаете MTTP только по closed-тикетам - цифра выглядит нормально. Смотрите на open backlog - картина меняется. Поэтому считайте и MTTP, и средний возраст открытого бэклога параллельно.
SLA по уязвимостям: пороги по severity для реальной инфраструктуры
Почему CVSS недостаточно: EPSS и CISA KEV как override
CVSS - статичная метрика. Она не учитывает наличие публичного эксплойта, активную эксплуатацию и критичность конкретного актива. Три дополнительных сигнала меняют приоритизацию уязвимостей по severity радикально:EPSS (Exploit Prediction Scoring System) - вероятность эксплуатации CVE в ближайшие 30 дней. Рассчитывается FIRST.org.
CISA KEV - каталог активно эксплуатируемых уязвимостей. Попадание CVE в KEV - подтверждённый факт эксплуатации in the wild. Эта CVE активно используется в ransomware-кампаниях.
CISA SSVC (Stakeholder-Specific Vulnerability Categorization) - решение по приоритету: Act (немедленно), Attend (плановый цикл), Track (мониторить). SSVC Decision - Attend, CVE в KEV с сентября 2024. По правилу override (CVE в KEV → 7 дней) такую уязвимость нужно закрывать за 7 дней. Даже без KEV-override SSVC Attend подразумевает плановый цикл (~30 дней), что агрессивнее CVSS-based 90 дней.
Правило override, которое стоит зафиксировать в политике:
- CVE в CISA KEV → SLA автоматически сокращается до 7 дней независимо от CVSS
- EPSS > 0.5 и CVSS >= 7.0 → SLA сокращается до 14 дней
- SSVC Decision = Act → SLA 7 дней
SLA Compliance Rate
Формула: количество уязвимостей, закрытых в срок SLA, делённое на общее количество уязвимостей с назначенным SLA, умноженное на 100%. Целевой порог - не ниже 85% для Critical и не ниже 90% для High. Падение ниже - сигнал о системных проблемах в remediation: нехватка ресурсов, конфликт приоритетов с IT, отсутствие эскалации.Coverage rate: самая обманчивая метрика VM-программы
Coverage rate отвечает на вопрос: «Какую долю инфраструктуры видит сканер?» Формула проста: количество просканированных активов делится на общее количество активов в CMDB и умножается на 100%.95% coverage на бумаге - отличный результат. На практике - это, пожалуй, самая обманчивая метрика управления уязвимостями.
Где coverage rate врёт
Облачные workloads без агента. Tenable.io или Qualys Cloud Agent покрывают EC2-инстансы с установленным агентом. А serverless-функции (Lambda, Cloud Functions), managed-сервисы (RDS, Cloud SQL), контейнеры в ECS/EKS - за пределами стандартного агентного сканирования. CMDB показывает 500 хостов, сканер видит 500 - coverage 100%. А 200 Lambda-функций и 50 managed-баз не числятся в CMDB и не попадают в знаменатель. Красота.Shadow IT. Разработчик поднял тестовый сервер на стороннем хостинге. CMDB о нём не знает, сканер его не видит - coverage rate не пострадал, дыра в периметре появилась. NIST CSF v2.0 (ID.AM-01) требует непрерывной инвентаризации hardware, но реальность отстаёт от требований.
OT/IoT-сегмент. Промышленные контроллеры, сетевое оборудование с закрытыми прошивками - агентное сканирование невозможно, сетевое ограничено. Эти активы часто живут в отдельном реестре, не интегрированном со сканером уязвимостей.
Как аудировать coverage
- Выгрузите полный список активов из CMDB / asset inventory
- Выгрузите список хостов, просканированных за последние 30 дней, из сканера
- LEFT JOIN по IP / hostname / agent ID - всё, что есть в CMDB, но отсутствует в scan results, это слепые зоны
- Отдельно проверьте облачные сервисы (через API облачного провайдера), контейнерные окружения (registry scan), OT-сегмент (через пассивный мониторинг трафика)
KPI программы управления уязвимостями второго эшелона
MTTP, SLA compliance и coverage rate - фундамент. Зрелая VM-программа (уровень 4 по SANS Vulnerability Management Maturity Model) считает дополнительные метрики.Remediation Rate
Доля критических и высоких уязвимостей, закрытых за отчётный период. Формула: количество закрытых Critical+High делится на общее количество обнаруженных Critical+High за тот же период, умноженное на 100%.Порог: не ниже 75% за квартал для Critical+High. Ниже - это уже не «сложные патчи», а ресурсная проблема или отсутствие приоритизации уязвимостей по severity.
Recurrence Rate (частота рецидивов)
Как часто ранее закрытая уязвимость возвращается - на том же хосте или в аналогичной конфигурации. Формула: количество повторно открытых уязвимостей делится на общее число закрытых за период, умноженное на 100%.Recurrence rate выше 10% - сигнал о системных проблемах: configuration drift, откат патчей при деплое, пересоздание виртуальных машин из непропатченного golden image, отсутствие hardening baseline. По данным Cymulate и LegitSecurity, рецидивы - один из самых недооценённых KPI: команды фокусируются на закрытии новых CVE и не проверяют, не вернулись ли старые. Я сам натыкался на ситуацию, когда DevOps при каждом деплое перезаливал VM из образа двухмесячной давности - recurrence rate зашкаливал, а MTTP при этом выглядел прилично.
Vulnerability Backlog Age
Средний возраст незакрытых уязвимостей: сумма дней от обнаружения до текущей даты для всех открытых CVE, делённая на их количество.Растущий backlog age при стабильном MTTP - типичная ловушка. Команда быстро закрывает свежие CVE (MTTP выглядит хорошо), но хвост из Medium-уязвимостей тянется месяцами и годами. Формально SLA по Medium (90 дней) не нарушен - потому что эти CVE «приняты как риск» или попали в исключения. А реальная поверхность атаки не уменьшается.
Scan Frequency по группам активов
| Группа активов | Минимальная частота | Обоснование |
|---|---|---|
| DMZ / публичные сервисы | Еженедельно | Первая точка атаки - Exploit Public-Facing Application (T1190, Initial Access) |
| Внутренние серверы | 2 раза в месяц | Lateral movement после компрометации |
| Рабочие станции | Ежемесячно | Патчи через WSUS/SCCM, сканирование подтверждает |
| Облачные workloads | Непрерывно (агент) | Эфемерные ресурсы живут часы |
Метрики patch management для слайдов vs метрики для безопасности
Несколько лет построения VM-дашбордов научили меня различать числа, которые хорошо смотрятся в презентации, и числа, которые отражают реальный риск.«Закрыто 2 000 уязвимостей за квартал.» Абсолютное число без контекста. 1 900 могли быть Low на рабочих станциях (автопатч WSUS), а 3 оставшихся Critical на продовом VPN-шлюзе - всё ещё открыты.
«Coverage rate 98%.» Без аудита знаменателя бессмысленно. Если CMDB не видит 30% облачной инфраструктуры - 98% от неполного списка это не реальное покрытие.
«MTTP 14 дней.» Среднее по всем severity. Critical закрывается за 45 дней, Low - за 3 (автопатч). Средневзвешенный MTTP выглядит прилично, Critical SLA нарушен.
«SLA Compliance 92%.» Отличная цифра - пока не посмотришь разбивку. 92% за счёт Low и Medium (их больше по объёму). Для Critical compliance может быть 60%.
Правило: каждую метрику считайте с разбивкой по severity и по типу актива (DMZ / internal / cloud / OT). Агрегированные цифры - для борда, детализированные - для принятия решений. Если CISO видит только агрегат, а VM-инженер - только детализацию, никто не видит полной картины.
Чеклист: дашборд метрик VM-программы за один спринт
Готовый план для security-инженера, который строит или переосмысляет отчётность по уязвимостям.- Определите источник данных. Tenable.sc / Qualys / MaxPatrol VM → экспорт в PostgreSQL или ClickHouse через API сканера. Встроенные дашборды ограничены - внешняя аналитика даёт гибкость.
- Свяжите данные сканера с CMDB. LEFT JOIN по IP / hostname / agent_id. Разница между множествами = слепые зоны coverage rate.
- Рассчитайте MTTP по severity. SQL-запрос из раздела выше - база. Добавьте группировку по
asset_criticality(business_critical / standard / test). - Зафиксируйте SLA в политике. Таблица порогов → утвердите с IT-директором и CISO. Без подписи SLA остаётся рекомендацией.
- Добавьте override по EPSS и CISA KEV. CVE в CISA KEV → SLA 7 дней. EPSS > 0.5 при CVSS >= 7.0 → SLA 14 дней. Автоматизируйте через обогащение тикетов данными из API FIRST.org и CISA KEV feed.
- Настройте трекинг в Jira / ServiceNow. Каждая уязвимость с SLA = тикет с дедлайном. Автоматическая эскалация при просрочке → уведомление менеджеру актива и CISO.
- Визуализация. Grafana или Power BI, четыре панели: MTTP trend по severity, SLA compliance rate по severity, coverage rate с результатами аудита, vulnerability backlog age trend.
- Ежемесячный review. 30 минут с командой: какие метрики выросли, где SLA нарушен и почему. Документируйте причины: «патч ломает SAP» - валидная причина, но она фиксируется как accepted risk с датой пересмотра.
Согласно Mandiant M-Trends 2025, медианное время нахождения атакующего в сети до обнаружения - 11 дней, исторический минимум. При этом эксплойты остаются наиболее распространённым вектором initial access (38% расследований). Если реальный MTTP для Critical на периметральных сервисах превышает 11 дней - атакующий потенциально быстрее вашей VM-команды. Это не метрика для слайдов, а метрика для выживания. Я убеждён: единственный способ увидеть её честно - считать MTTP не «в среднем по больнице», а для конкретных групп активов с конкретным severity. Формулы, SQL, пороги SLA и логика override - всё выше. Большинство VM-программ, которые я видел, застревают не на этапе «какие метрики считать», а на этапе «как заставить IT-команды закрывать тикеты в срок». Технические метрики без процесса эскалации и ответственности владельцев активов - просто цифры в Grafana. Если хочется сверить свои SLA-пороги и подход к расчёту MTTP с тем, как это устроено у других VM-команд - на codeby.net обсуждают практику построения VM-процессов и подводные камни интеграции сканеров с тикет-системами.
