Прочитал статью Игоря Панарина, руководителя направления анализа защищенности инфраструктуры ДИБ РАНХиГС, "Темные паттерны в управлении уязвимостями: как метрики ломают безопасность". Весьма полезная статья о том, как выбор простых, но неоптимальных метрик для VM приводит к выхолащиванию всего процесса. ИБ-команда начинает оптимизировать показатели, а не снижать реальный риск для критичных систем организации. По мнению автора, зрелость VM-процесса заключается в способности отличать формальное улучшение показателей от реального снижения риска.

В статье приводятся пять примеров тщеславных метрик-ловушек:

1️⃣ Если сделать снижение общего количества уязвимостей (с разбивкой на высокий, средний и низкий уровень критичности) главной целью, команда начинает закрывать простые и дешёвые в устранении уязвимости (например, в тестовом контуре) ради красивой динамики, обходя уязвимости, которые устранять неудобно (например, уязвимость среднего уровня на периметре или в проде). В итоге остаются опасные пути атаки до критичных систем.

2️⃣ Фиксированные SLA на устранение уязвимостей по уровню CVSS создают дисциплину и понятные правила, но не учитывают контекст уязвимости в конкретной инфраструктуре (доступность сервиса из Интернет, связь актива с ключевым бизнес-процессом, существование компенсирующих мер, факты эксплуатации уязвимости в реальных атаках, достижимость из других сегментов, цену компрометации и т.д.). В результате команда спорит по поводу CVSS-скоров, переводит уязвимости в исключения, внедряет самые быстрые исправления (а не правильные и надёжные). Формально регламент может соблюдаться, но это не означает, что реальный риск снижается.

3️⃣ Когда целью становится, например, устранение 95% найденных уязвимостей, уязвимости превращаются в объекты статистического учёта. Команда начинает устранять их формально, маскировать временными мерами или переводить в исключения, чтобы улучшить показатель. Если команда расширяет покрытие, находит новые активы и ранее неучтённые уязвимости, доля устранённых уязвимостей снижается. Если гонится за формальным устранением - показатель улучшается. В итоге честная работа выглядит хуже удобной.

4️⃣ Статичный дашборд без временной динамики показывает только текущее состояние и не отражает, как долго существует уязвимость. Если проблема месяцами не решается, это чаще говорит о системном сбое процесса: размытой зоне ответственности, отсутствии владельца актива, непонимании бизнесом цены откладывания или постоянном обходе командой сложных задач. Без учёта времени такие проблемы остаются незаметными. Необходимо учитывать срок жизни проблемы, скорость реакции, повторное появление, разницу между временной мерой и корневым исправлением.

5️⃣ Отсутствие находок может означать не отсутствие проблем, а наличие слепых зон ("забытый поддомен, старый тестовый контур, неполный учёт облачных ресурсов, исключение из лицензии на сканирование, подрядчик со своей частью инфраструктуры, сервис, который никто уже не считает важным, но который всё ещё доступен извне"). Важно измерять не только найденные уязвимости, но и полноту покрытия.

Настоящие риск-метрики требуют контекста - ценности и доступности актива, наличия эксплойтов (и оценки их работоспособности), признаков атак (и оценки их достоверности), связей в инфраструктуре.

Автор считает более полезным смотреть на:

🔹 долю действительно опасных уязвимостей на внешнем периметре;
🔹 среднее время до устранения проблем на бизнес-критичных активах;
🔹 долю активов без сканирования;
🔹 число повторно возникающих дефектов;
🔹 количество случаев, где команда устраняет первопричину, а не просто закрывает отдельную уязвимость.

В конце статьи также рассматриваются CTEM-подход, attack path-метрики и их реализация в MaxPatrol Carbon.