Количество закрытых уязвимостей — одна из самых удобных метрик ИБ.

Она понятна, легко автоматизируется и хорошо выглядит в отчёте: обнаружили 20 тысяч; закрыли 14 тысяч; сократили backlog; улучшили SLA.

Но у этой метрики есть серьёзный недостаток: она показывает объём работы, а не величину сниженного риска.

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

CVSS не спасает от этой ошибки. Его базовая оценка описывает техническую тяжесть уязвимости, но не риск для конкретной организации. Для осмысленной приоритизации её необходимо дополнить данными об угрозе и собственной среде. (first.org)

На практике приоритет должен зависеть не только от severity, но и от контекста: - достижим ли уязвимый компонент; - наблюдается ли реальная эксплуатация; - какова ценность актива; - какие права получит злоумышленник; - куда он сможет двигаться дальше; - существуют ли компенсирующие меры; - участвует ли слабость в пути к критической системе.

И здесь vulnerability management неизбежно начинает сближаться с exposure management.

Отдельная CVE редко является полным сценарием атаки. Между точкой входа и бизнес-критичной системой обычно находятся учётные записи, сетевые связи, облачные роли, ошибочные конфигурации и избыточные привилегии.

Поэтому я считаю, что основной единицей приоритизации должен становиться не отдельный дефект, а attack path.

Если несколько путей проходят через один сервер, привилегированную учётную запись или административный интерфейс, устранение такого choke point может дать большее снижение риска, чем исправление сотен несвязанных CVE.

Концепция attack paths именно так и рассматривает сквозные маршруты от точки входа к критическому активу. (Microsoft Learn)

Это не призыв отказаться от патчей.

Базовая кибергигиена, обновления и технический долг никуда не исчезают. Но срочность должна определяться не цветом в сканере, а сочетанием пяти факторов:

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

И метрики руководству тоже нужны другие.

Помимо количества закрытых CVE, стоит показывать: - сколько путей ведёт к критическим системам; - сколько choke points устранено; - какие KEV доступны извне; - как изменился blast radius; - какой остаточный риск сохраняется; - подтверждено ли устранение повторной проверкой.

Моя позиция проста: закрытая уязвимость — это результат процесса. Разрушенный путь атаки — результат для бизнеса.

Как устроена приоритизация у вас: уязвимости ранжируются по CVSS или команда уже учитывает достижимость, identity-связи и пути к критическим активам?