Ограничения подхода, основанного исключительно на CVSS
Традиционная модель управления уязвимостями, опирающаяся преимущественно на базовую оценку CVSS, в масштабах современной инфраструктуры демонстрирует ряд системных ограничений. Формирование очереди на устранение на основании только технического балла без учёта бизнес контекста актива приводит к следующим последствиям:
Диспропорция в распределении ресурсов. Значительная доля усилий ИБ и ИТ подразделений направляется на устранение уязвимостей с высоким CVSS на активах, не участвующих в критичных бизнес-процессах (например, в изолированных тестовых средах). В то же время уязвимости со средним или даже низким баллом, но расположенные на внешнем периметре критичных систем и имеющие признаки активной эксплуатации, могут оставаться без внимания.
Разрыв между активностью и результатом. Метрики «количество закрытых уязвимостей» или «количество установленных патчей» характеризуют объём выполненных работ, но не свидетельствуют о снижении фактического риска для организации. Это затрудняет коммуникацию с руководством и бизнес подразделениями, которые ожидают от функции ИБ управления рисками, а не отчётности о её внутренней активности.
Потеря управляемости. При отсутствии формализованных правил приоритизации, учитывающих бизнес критичность, решение о том, «что чинить в первую очередь», фактически делегируется команде эксплуатации или принимается ситуативно, что не обеспечивает предсказуемого уровня защищённости.
Переход к риск ориентированному управлению уязвимостями (RBVM) позволяет преодолеть эти ограничения за счёт включения в модель принятия решений контекстных факторов, характеризующих как сам актив, так и актуальный ландшафт угроз.
Risk-Based Vulnerability Management (RBVM) — это подход к управлению уязвимостями, при котором очередь на исправление формируется по риску для конкретной организации. Он не отменяет сканирование и CVSS, а добавляет к ним контекст: данные об активе и владельце, бизнес-критичность, сетевую экспозицию, сведения об угрозах, наличие исправления и компенсирующих мер. В результате команда получает не перечень «критичных CVE», а управляемый список действий с понятным обоснованием приоритета.
-
Поток находок. Отчёты сканеров, результаты SCA, облачные активы и контейнеры могут формировать тысячи записей. Без правил нормализации, дедупликации и назначения владельца действительно важные находки теряются среди шума.
-
Недостаток контекста. Базовый CVSS описывает технические свойства уязвимости, но не бизнес‑значимость конкретного актива. Уязвимость со средним баллом на внешнем сервисе, связанном с критическим процессом, может требовать более срочных действий, чем более высокий балл на изолированной тестовой системе.
-
Динамика угроз. Приоритет меняется по мере появления публичного эксплойта, сведений о подтверждённой эксплуатации, новых путей доступа или изменений в архитектуре. Модель должна регулярно пересчитывать риск, а не опираться на оценку из отчёта, полученного несколько месяцев назад.
-
CVSS не равен вероятности атаки. Высокий CVSS сам по себе не доказывает, что уязвимость будет использована в конкретной среде, а «средняя» уязвимость может оказаться актуальной при наличии подтверждённой эксплуатации, внешней доступности и отсутствии защитных мер.
Финансовый сектор
Для организаций финансового рынка RBVM может быть практическим способом связать анализ уязвимостей с управлением рисками информационной безопасности, операционной надёжностью и приоритетами бизнеса. При этом RBVM не является самостоятельной обязательной моделью, установленной Банком России: применимость конкретных документов зависит от статуса организации, вида деятельности и состава её информационной инфраструктуры.
Среди релевантных документов:
-
Положение Банка России от 8 апреля 2020 года № 716‑П. Устанавливает требования к системе управления операционным риском в кредитной организации и банковской группе; в том числе содержит положения, связанные с рисками информационной безопасности и информационных систем. Документ задаёт контекст управления рисками, но не предписывает конкретный продукт или единую схему RBVM.
-
Методические рекомендации Банка России от 22 января 2025 года № 2‑МР. Описывают рекомендуемые подходы к тестированию на проникновение и анализу уязвимостей информационной безопасности объектов информационной инфраструктуры организаций финансового рынка. Это методические рекомендации, а не самостоятельное предписание внедрить RBVM.
-
ГОСТ Р 57580.3‑2022. Содержит общие положения по управлению риском реализации информационных угроз и обеспечению операционной надёжности. Его использование необходимо соотносить с применимыми нормативными актами, договорными обязательствами и внутренними документами организации.
Категорирование объектов критической информационной инфраструктуры (КИИ) и RBVM — связанные, но не тождественные процессы. Категорирование устанавливает, соответствует ли объект критериям значимости, и при необходимости определяет его категорию значимости. Эти сведения могут стать важным фактором бизнес-критичности актива в модели RBVM, однако сами по себе не заменяют оценку уязвимости, её экспозиции и вероятности эксплуатации. Процедура категорирования регулируется Федеральным законом от 26.07.2017 № 187-ФЗ, Правилами категорирования, утверждёнными постановлением Правительства РФ от 08.02.2018 № 127, а также отраслевыми особенностями и иными применимыми документами.
Статья 7 187-ФЗ связывает категорирование с оценкой последствий нарушения функционирования объекта КИИ и присвоением одной из категорий значимости. Для значимых объектов КИИ действуют специальные требования к безопасности. Однако категория значимости не задаёт автоматически порядок устранения конкретных уязвимостей, не устанавливает универсальный SLA на патчинг и не предписывает использование определённого VM-решения или поведенческого анализа. Эти решения принимаются в рамках применимых требований и внутреннего управления рисками.
Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств, утверждённая ФСТЭК России 30 июня 2025 года, задаёт подход к оценке критичности уязвимостей. На практике для приоритизации её результаты целесообразно дополнять сведениями о категории и назначении актива, сетевой доступности, наличии компенсирующих мер, статусе исправления и актуальных угрозах. RBVM может поддерживать выполнение требований по мониторингу и управлению уязвимостями, но не подменяет обязанности субъекта КИИ, установленные законодательством.
Практический цикл RBVM
RBVM начинается не со сканера, а с понимания того, какие активы и сервисы существуют, кому они принадлежат и какое значение имеют для бизнеса. Практический цикл включает следующие этапы:
1. Инвентаризация и назначение владельцев. Для каждого актива нужны устойчивый идентификатор, владелец, роль, бизнес-критичность, окружение и сетевые связи. IP-адреса и разовые выгрузки сканера недостаточны: они быстро устаревают и плохо работают в динамической инфраструктуре.
2. Выявление и нормализация уязвимостей. Регулярное сканирование, контроль конфигураций, учёт облачных ресурсов, контейнеров и компонентов ПО должны давать данные, связанные с конкретным активом и его владельцем. На этом этапе устраняют дубликаты и фиксируют дату актуальности результата.
3. Анализ риска. Для каждой находки оцениваются технические, угрозовые и бизнес-факторы:
-
Сигналы угроз: подтверждённая эксплуатация, сведения threat intelligence, наличие публичного эксплойта, релевантные прогнозные оценки — при этом публичный PoC не равен факту эксплуатации.
-
Контекст актива: роль в бизнес‑процессе, обрабатываемые данные, внешняя и внутренняя сетевые экспозиции, возможный радиус поражения.
-
Реализуемость устранения и защитные факторы: наличие патча, компенсирующие меры, сегментация, покрытие средствами защиты, SLA и согласованные исключения.
5. Обработка риска. Меры могут включать установку обновления, изменение конфигурации, сегментацию, отключение уязвимой функции, усиление мониторинга или формальное принятие риска. Для исключений необходимы владелец, срок действия и условия повторного пересмотра.
6. Проверка, отчётность и пересмотр. После изменения нужно подтвердить результат повторным сканированием или иной технической проверкой. Модель риска пересматривается при появлении новых угроз, изменении архитектуры, истечении исключения или смене критичности сервиса.
Что измерять, чтобы RBVM не остался формальностью
Полезнее измерять не общее число закрытых CVE, а управляемость риска: долю активов с назначенным владельцем и критичностью, время устранения приоритетных уязвимостей, долю известных эксплуатируемых уязвимостей, закрытых в пределах SLA, возраст исключений и количество критичных активов без актуальных данных сканирования. Такие показатели помогают руководителям видеть не активность команды, а снижение наиболее значимых рисков.
RBVM — это не отдельный класс продукта и не способ «отменить» CVSS. Это управленческий процесс, который связывает уязвимость, угрозу, актив, бизнес-процесс и ответственного за решение. В зрелой модели в нём участвуют ИБ, ИТ, владельцы систем, риск-менеджмент и бизнес. Итогом становится не бесконечная очередь из отчётов сканера, а понятный и проверяемый план снижения риска.
Нормативные и методические источники
-
Положение Банка России № 716‑П от 08.04.2020.
-
Методические рекомендации Банка России № 2‑МР от 22.01.2025.
-
Методика оценки уровня критичности уязвимостей, утверждённая ФСТЭК России 30.06.2025.
-
Федеральный закон от 26.07.2017 № 187‑ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации».
-
Постановление Правительства РФ от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации».
-
Распоряжение Правительства РФ от 26.02.2026 № 360‑р «Об утверждении перечня типовых отраслевых объектов критической информационной инфраструктуры Российской Федерации».
Алексей Варлаханов, руководитель отдела прикладных систем Angara Security
15.07.2026
