Оценка уязвимостей только по CVSS не показывает, насколько опасна конкретная брешь для бизнеса. Разбираемся, как объединить данные VM, SIEM и CMDB, учесть EPSS и CISA KEV, настроить расчёт риска и расставить приоритеты устранения.
- 1. Введение
- 2. Почему одного CVSS недостаточно
- 3. Как рассчитать совокупный риск
- 4. Как работают вместе VM, SIEM и CMDB
- 5. Как выявлять слепые зоны
- 6. Как работать с критичностью инцидента
- 7. Как внедрить RBVM на практике
- 8. Выводы
Введение
Системы управления уязвимостями ежедневно формируют большие массивы данных. Если обрабатывать находки только по базовому баллу CVSS, первыми в очереди на устранение окажутся технически опасные уязвимости, которые могут находиться на некритичных или изолированных узлах. В то же время уязвимость со средним баллом на доступном из интернета бизнес-сервисе рискует остаться без внимания.
Поэтому процесс управления уязвимостями (Vulnerability Management, VM) полезно связывать с системой управления информацией и событиями безопасности (Security Information and Event Management, SIEM) и базой данных управления конфигурациями (Configuration Management Database, CMDB). VM показывает, какие уязвимости присутствуют на активах, CMDB добавляет бизнес-контекст, а SIEM сопоставляет эти сведения с текущей активностью в инфраструктуре.
Такая архитектура помогает перейти от очереди на установку обновлений к управлению рисками эксплуатации уязвимостей (Risk-Based Vulnerability Management, RBVM). Результатом становится не математически точный прогноз атаки, а прозрачная и воспроизводимая оценка, по которой ИБ- и ИТ-команды могут согласовать очерёдность действий.
Почему одного CVSS недостаточно
Приоритизация начинается с технической оценки уязвимости, но не должна ею заканчиваться. Для расчёта полезно объединить четыре группы данных: техническую опасность, вероятность эксплуатации, подтверждённые атаки и контекст конкретной инфраструктуры.
CVSS: техническая опасность
Common Vulnerability Scoring System (CVSS) описывает характеристики и серьёзность уязвимости по шкале от 0 до 10. В CVSS 4.0 предусмотрены базовые метрики, метрики угроз, метрики среды и дополнительные метрики. Базовый балл отражает свойства уязвимости, но сам по себе не учитывает все особенности конкретного внедрения.
При расчётах важно фиксировать версию CVSS и вектор оценки. Баллы CVSS 3.1 и CVSS 4.0 нельзя без пояснения смешивать в одной выборке: одинаковое число может быть получено по разным наборам метрик.
EPSS: вероятность эксплуатации
Exploit Prediction Scoring System (EPSS) — модель организации FIRST, которая оценивает вероятность эксплуатации опубликованной уязвимости с идентификатором CVE в реальных атаках в следующие 30 дней. Показатель EPSS находится в диапазоне от 0 до 1 и обновляется ежедневно. Например, значение 0,05 соответствует вероятности пяти процентов для совокупности уязвимостей с таким баллом, но не гарантирует и не исключает эксплуатацию конкретной CVE.
Порог EPSS нельзя выбирать один раз для всех организаций. Его следует калибровать с учётом допустимого риска, доступных ресурсов и статистики собственных инцидентов.
CISA KEV: подтверждённая эксплуатация
Каталог известных эксплуатируемых уязвимостей (Known Exploited Vulnerabilities, KEV) Агентства по кибербезопасности и защите инфраструктуры США (CISA) содержит уязвимости, для которых есть подтверждение эксплуатации и понятные рекомендации по устранению или снижению риска. Наличие CVE в CISA KEV можно использовать как бинарный признак: да или нет.
Попадание в CISA KEV повышает приоритет, но не отменяет локальный контекст. Организации всё равно необходимо проверить, присутствует ли уязвимый продукт в инфраструктуре, достижим ли компонент для потенциального нарушителя и какие компенсирующие меры уже действуют.
Контекст инфраструктуры
Последний уровень оценки формируется внутри организации. В него входят доступность актива из внешней и внутренних сетей, значимость бизнес-сервиса, наличие межсетевого экрана веб-приложений (Web Application Firewall, WAF) или системы предотвращения вторжений (Intrusion Prevention System, IPS), сетевые ограничения, привилегии учётных записей и возможный радиус распространения атаки.
Иерархия не означает, что нижние уровни можно игнорировать. CVSS остаётся технической основой, EPSS показывает вероятностный сигнал, CISA KEV подтверждает эксплуатацию, а контекст инфраструктуры определяет последствия именно для этой организации.
Рисунок 1. Расчёт базовой оценки риска с учётом CVSS, EPSS и критичности актива
Как рассчитать совокупный риск
Ни FIRST, ни CISA не устанавливают универсальную формулу RBVM. Ниже приведена иллюстративная модель, которую можно использовать как отправную точку. Перед промышленным применением веса, коэффициенты и границы уровней необходимо проверить на исторических данных организации и закрепить во внутренней методике.
Базовая оценка
Чтобы складывать показатели, сначала нужно привести их к одной шкале. В примере CVSS и бизнес-критичность C измеряются от 0 до 10, а EPSS умножается на 10. Базовый риск рассчитывается так:
Rбаз = 0,3 × CVSS + 0,4 × (EPSS × 10) + 0,3 × C
Веса 0,3, 0,4 и 0,3 отражают выбранный приоритет технической опасности, вероятности эксплуатации и бизнес-критичности. Их сумма равна единице. Если организация считает влияние на бизнес более важным, веса можно изменить, сохранив общую логику нормализации.
Рисунок 2. Повышение оценки риска для уязвимостей из каталога CISA KEV
Повышающие коэффициенты
После расчёта базового риска применяются коэффициенты, отражающие подтверждённую эксплуатацию и особенности размещения актива. В иллюстративной модели используются три условия:
- CVE входит в CISA KEV — коэффициент 2,0;
- уязвимый сервис доступен из интернета — коэффициент 1,5;
- с актива достижимы не менее трёх смежных сегментов — коэффициент 1,2.
Если условие не выполняется, соответствующий коэффициент равен единице. Порог для радиуса потенциального ущерба и значения коэффициентов не являются отраслевым стандартом: их следует настроить под архитектуру организации.
Рисунок 3. Учёт наличия уязвимости в CISA KEV и доступности сервиса из интернета
Итоговая оценка
Итоговый риск получается после умножения базовой оценки на повышающие коэффициенты. Ограничение в 100 баллов упрощает представление результата, но не скрывает причины высокого приоритета. В карточке уязвимости необходимо показывать базовые показатели, сработавшие коэффициенты, дату актуальности данных и итоговую оценку.
Рисунок 4. Повышающие коэффициенты для расчёта итогового риска
Уровни риска и сроки реагирования
Результат можно связать с соглашением об уровне обслуживания (Service Level Agreement, SLA). В примере используются четыре уровня риска и соответствующие сроки устранения либо применения компенсирующих мер:
- 80–100 баллов — критический риск, реагирование в течение 24 часов;
- 60–79 баллов — высокий риск, реагирование в течение трёх суток;
- 30–59 баллов — средний риск, работа в ближайшее плановое окно обновлений;
- 0–29 баллов — низкий риск, постановка в очередь и наблюдение за изменением контекста.
Организация может задать другие границы и сроки. Главное, чтобы они соответствовали её ресурсам, критичности систем и нормативным требованиям, а исключения из SLA были формализованы.
Рисунок 5. Формула расчёта итогового показателя Risk Score
Пример расчёта
Сравнение нескольких сценариев показывает, почему базового CVSS недостаточно. Уязвимость с более низким CVSS может получить максимальный приоритет, если она подтверждённо эксплуатируется, доступна извне и находится на активе с широкими сетевыми связями.
В примере ниже все значения условны. Они демонстрируют механику формулы, а не рекомендуемые настройки для конкретной инфраструктуры.
Рисунок 6. Уровни риска и сроки устранения уязвимостей
Как работают вместе VM, SIEM и CMDB
Каждый источник отвечает на отдельную группу вопросов. Система VM хранит сведения об активах, установленном ПО, обнаруженных CVE, сетевых службах, CVSS и актуальности результатов сканирования. CMDB добавляет владельца актива, связанный бизнес-сервис, критичность, сетевую зону и допустимые зависимости. SIEM получает события от источников, выполняет корреляцию и показывает наблюдаемую активность.
В результате формируется единый профиль актива. Аналитик видит не только уязвимость, но и её расположение, важность узла, признаки эксплуатации, состояние защитных мер и связанные инциденты. Такой подход соответствует общей логике взаимодействия SIEM-систем с решениями других классов.
На практике состав полей и способ обмена зависят от версий продуктов и архитектуры внедрения. MaxPatrol VM поддерживает взаимодействие с MaxPatrol SIEM и PT NAD, а продукты на платформе MaxPatrol используют общую модель активов. Перед настройкой необходимо сверить документацию развёрнутых версий и определить допустимый срок актуальности каждого типа данных.
Рисунок 7. Примеры расчёта Risk Score
Контекстное обогащение не отменяет распределение ответственности между ИТ, ИБ и бизнесом. ИБ определяет модель риска и контролирует сроки, ИТ оценивает возможность установки обновлений, а владелец бизнес-сервиса согласует технологические окна и принимает остаточный риск.
Как выявлять слепые зоны
Связка VM и SIEM полезна не только для приоритизации CVE. Сопоставление инвентаризации и событий помогает находить активы, которые выпали из одного из контуров наблюдения.
Актив есть в событиях, но отсутствует в VM
Если узел проявляет активность в телеметрии NetFlow, сообщениях Syslog или журналах межсетевых экранов, но отсутствует в последней инвентаризации VM, SIEM может создать инцидент о неучтённом активе. Порог в один час подходит только как пример: в промышленной среде его нужно выбирать с учётом периодичности сканирования и нормального профиля трафика.
Актив есть в VM, но не передаёт события
Обратная ситуация возникает, когда VM видит узел, а SIEM не получает от него событий. Причиной могут быть остановка службы журналирования, изменение сетевых правил или ошибка конфигурации источника. Порог в 24 часа также следует соотнести с ожидаемой частотой событий конкретного актива.
Оба правила должны учитывать плановые простои, тестовые сегменты и исключения. Иначе система обнаружит не слепые зоны, а большое количество ожидаемых расхождений.
Рисунок 8. Формирование итогового Risk Score на основе данных VM, CMDB и SIEM
Как работать с критичностью инцидента
Данные VM не следует использовать для автоматического понижения уровня критичности (Severity), если неизвестна их актуальность. Между двумя сканированиями администратор может обновить ПО, установить уязвимую версию повторно или изменить конфигурацию сервиса.
В консервативной модели действует следующая логика:
- правило корреляции SIEM задаёт исходный уровень критичности;
- при отсутствии свежего контекста VM исходный уровень сохраняется, а инцидент получает метку NO_VM_CONTEXT и направляется на ручную проверку;
- свежие данные VM, наличие CVE в CISA KEV и внешняя доступность актива могут повысить критичность;
- автоматическое понижение допускается только по отдельно утверждённому правилу с проверкой актуальности данных.
Такая схема снижает вероятность пропустить атаку из-за устаревших результатов сканирования. Одновременно аналитик получает объяснение, какие признаки привели к повышению приоритета.
Рисунок 9. Сравнение подходов к оценке события SMB-сканирования
Например, SIEM обнаруживает аномальные обращения одного узла к службе SMB — сетевому протоколу общего доступа к файлам — на другом. Если сведения VM устарели, система сохраняет исходную критичность и запрашивает проверку. Если свежие данные подтверждают уязвимую службу, CVE входит в CISA KEV, а актив доступен из внешней сети, приоритет повышается до критического.
Как внедрить RBVM на практике
Интеграция MaxPatrol VM и MaxPatrol SIEM — часть более широкого процесса. Возможности продуктов и общая модель активов описаны в материале об экосистеме MaxPatrol, но результат зависит от качества инвентаризации и правил организации.
Внедрение можно разделить на пять последовательных этапов:
- Провести инвентаризацию и классификацию активов. Для каждого узла определить владельца, бизнес-функцию, критичность и сетевую зону.
- Зафиксировать источники и требования к актуальности данных. Необходимо определить периодичность сканирования, ожидаемую частоту событий и допустимое время отсутствия связи.
- Настроить обогащение сведений об уязвимостях. В профиль CVE следует добавить CVSS с версией и вектором, EPSS с датой обновления, признак CISA KEV и локальный контекст.
- Организовать обмен данными между VM, SIEM и CMDB. Поля нужно нормализовать, а активы — однозначно сопоставить по устойчивым идентификаторам.
- Настроить и откалибровать правила корреляции. Сначала правила запускают в режиме наблюдения, затем проверяют долю ложных срабатываний, полноту контекста и соответствие рассчитанного риска фактическим инцидентам.
После запуска модель необходимо регулярно пересматривать. Изменение инфраструктуры, профиля атак и качества данных способно сделать прежние коэффициенты и пороги неактуальными.
Выводы
Связка VM, SIEM и CMDB помогает оценивать уязвимости в контексте реальной инфраструктуры. Для работающей модели необходимо привести CVSS, EPSS и бизнес-критичность к сопоставимым шкалам, показывать не только итоговый балл, но и все данные и коэффициенты, из которых он получен, а также не понижать критичность по устаревшему контексту и регулярно калибровать правила.
RBVM не устраняет неопределённость и не заменяет экспертизу аналитика. Его задача — сделать приоритеты объяснимыми, связать их с бизнес-контекстом и направить ограниченные ресурсы на те уязвимости, которые создают наибольший риск здесь и сейчас.
