При оценке угроз с помощью системы CVSS у многих возникает иллюзия простой приоритизации: чем выше балл, тем важнее устранить проблему. Однако в реальности такой подход оказывается нерабочим. Ежегодно количество опасных дефектов растет, команды кибербезопасности не успевают их обрабатывать, при этом большинство из них никогда не используются злоумышленниками. Между тем, атакующие активно применяют менее заметные уязвимости со средними оценками. Существуют и другие сложности — от технических нестыковок (противоречивые оценки) до методологических ограничений (игнорирование бизнес-аспектов).
Эти сложности не являются недостатками самого стандарта, они лишь подчеркивают необходимость грамотного применения CVSS в рамках комплексной стратегии управления угрозами.
Расхождения в оценках CVSS
Один и тот же дефект часто получает разные баллы критичности от различных источников: независимых исследователей, разработчиков ПО или государственных реестров. Помимо человеческих ошибок, причина кроется в различной интерпретации условий эксплуатации: уровня доступа к приложению, сетевой доступности и других факторов. Производитель может исходить из идеальных условий эксплуатации, тогда как специалист по безопасности — из реальных рабочих конфигураций. Различия в оценках сложности эксплуатации — обычная ситуация. Согласно исследованию VulnCheck (2023), 20% уязвимостей в NVD имеют несколько оценок CVSS3, и 56% таких оценок противоречат друг другу.
Распространенные ошибки при работе с CVSS
Несмотря на многолетние рекомендации организации FIRST, компании продолжают допускать типичные просчеты:
- Использование базового балла CVSS в качестве главного показателя риска. Этот стандарт оценивает техническую опасность, но не учитывает вероятность эксплуатации или бизнес-последствия для конкретной компании. Например, критическая уязвимость может быть безвредной в изолированной системе, тогда как утечка данных с оценкой 6 способна вызвать масштабную ransomware-атаку.
- Пренебрежение корректировками threat/temporal и environmental. Доступность исправлений, наличие эксплойтов и защитных мер напрямую влияет на срочность устранения проблемы.
- Фокусировка исключительно на дефектах с высокими рейтингами. Часто такой подход диктуется регуляторными требованиями, что приводит к бесконечному увеличению рабочей нагрузки без реального повышения защищенности. Число таких уязвимостей стабильно растет последние 10 лет.
- Попытки прогнозировать вероятность атак через CVSS. Эти показатели слабо коррелируют: только 17% критических уязвимостей используются злоумышленниками.
- Работа только с числовым рейтингом. Векторная строка в CVSS создана именно для анализа деталей угрозы, а версия 4.0 специально улучшена для учета бизнес-контекста. Любая стратегия устранения дефектов, основанная лишь на цифрах, будет неэффективной.
- Ограничение единственной базой данных. Без информации о патчах, эксплойтах и случаях реальной эксплуатации невозможно принимать обоснованные решения.
Что не учитывает CVSS
Система стандартизирует описание технических параметров угрозы, но за ее пределами остаются важные аспекты:
- Кто обнаружил уязвимость — производитель, этичный хакер или злоумышленники?
- Существуют ли публичные эксплойты?
- Какова практическая сложность эксплуатации?
- Доступны ли исправления? Насколько безопасно их внедрение?
- Требуется ли исправление на стороне организации или это задача облачного провайдера?
- Были ли зафиксированы реальные атаки с использованием дефекта?
- Оценивались ли перспективы будущей эксплуатации?
- Какие именно системы затронуты в конкретной компании?
- Физическая и логическая доступность уязвимых компонентов (например, изолированный принтер vs интернет-сервер).
- Последствия компрометации для бизнеса и связанные финансовые потери.
Эти факторы напрямую влияют на решение о срочности и способе устранения уязвимости.
RBVM: практическое решение для коррекции CVSS
Все перечисленные аспекты учитываются в Risk-Based Vulnerability Management — методике, основанной на оценке рисков.
RBVM представляет собой циклический процесс:
- Инвентаризация IT-инфраструктуры (оборудование, ПО, облачные сервисы, IoT-устройства);
- Выявление ключевых активов (crown jewels);
- Поиск известных уязвимостей;
- Обогащение данных: уточнение CVSS-оценок, анализ киберразведки, использование EPSS (вероятность эксплуатации от FIRST) и реестров вроде CISA KEV;
- Учет бизнес-контекста: возможное влияние на конкретные системы с учетом их настроек;
- Поиск доступных исправлений или альтернативных мер защиты;
- Оценка бизнес-рисков и приоритизация задач. Сначала устраняют угрозы с высокой вероятностью эксплуатации и значительным влиянием на важные активы;
- Установка реалистичных сроков устранения. При невозможности исправления — внедрение компенсирующих мер или осознанное принятие рисков.
Дополнительно проводится анализ инфраструктуры для внедрения превентивных мер: микросегментации сети, ограничения привилегий и усиления контроля доступа.
Правильная реализация RBVM снижает нагрузку на IT-команды, направляя усилия на действительно опасные дефекты. Исследование FIRST показывает: использование EPSS позволяет сосредоточиться на 3% уязвимостей с 65% эффективностью, тогда как фокус на CVSS-B требует обработки 57% дефектов при эффективности всего 4% (под эффективностью подразумевается устранение реально эксплуатируемых уязвимостей).