«Все говорят о CVSS, но для реального приоритизации исправлений он почти бесполезен. CWSS уходит вглубь — от общей угрозы к конкретному бизнес-ущербу для вашего актива. Это не смена цифр, а смена парадигмы оценки.»
Приоритизация уязвимостей — ежедневная рутина для специалистов по безопасности. Чаще всего для этого используется Common Vulnerability Scoring System (CVSS). Он даёт удобную числовую оценку, но имеет фундаментальный недостаток: CVSS оценивает саму уязвимость в вакууме, не учитывая контекст её эксплуатации в конкретной инфраструктуре. Уязвимость с высоким CVSS может быть на изолированном тестовом сервере, а «средняя» — в сердце платежной системы. Первую все равно будут «горячо» исправлять, вторую — откладывать.
Common Weakness Scoring System (CWSS) предлагает иной подход. Он фокусируется не на уязвимости как таковой, а на слабости (weakness) и условиях, необходимых для её эксплуатации в вашем окружении. Метрика переводит разговор с технического уровня «насколько это опасно вообще» на бизнес-уровень «какой ущерб это может нанести нам здесь и сейчас».
От CVSS к CWSS: в чём принципиальная разница?
CVSS, это сканер, выстреливающий общую оценку. CWSS, это расследование, собирающее улики для конкретного дела. Разницу можно свести к нескольким ключевым аспектам.
- Объект оценки: CVSS оценивает конкретный экземпляр уязвимости (CVE). CWSS оценивает класс слабости (CWE) и то, как он проявляется в ваших активах. Это позволяет оценивать не только известные CVE, но и потенциальные уязвимости, возникающие из-за слабых архитектурных решений.
- Контекст: CVSS имеет только одну опциональную метрику «окружающая среда». В CWSS контекст — основа всей модели. Оценка напрямую зависит от защищённости атакуемого актива, его бизнес-ценности и технических особенностей развёртывания.
- Результат: CVSS даёт базовый, временный и окружной балл. CWSS выдаёт итоговый вес слабости (score), который уже является приоритетом для исправления в вашей системе.
Проще говоря, CVSS отвечает на вопрос «Насколько плоха эта дыра?». CWSS — «Насколько дорого нам обойдётся, если через эту дыру пробьются именно к нашему X?».
Структура CWSS: три основополагающих вектора
Оценка в CWSS формируется из трёх основных групп метрик, каждая из которых разбита на факторы. Вес слабости (score) вычисляется по формуле, объединяющей эти группы. Понимание их — ключ к эффективному использованию системы.
Базовые метрики (Base Finding)
Эта группа описывает саму слабость, её техническую суть и потенциальное влияние без привязки к окружению. Здесь оценивается, что делает эта слабость опасной в принципе.
- Технический удар (Technical Impact): Какие возможности получает злоумышленник? Получение привилегий, обход защиты, раскрытие информации, отказ в обслуживании. Например, SQL-инъекция сразу даёт высокий балл за потенциальное раскрытие и модификацию данных.
- Распространённость атаки (Attack Method): Насколько тривиально эксплуатировать слабость? Нужны ли специальные условия, редкие знания или доступность эксплойта публична? Уязвимость в популярном веб-фреймворке с публичным PoC получит максимальный балл.
- Внутренний ущерб (Internal Control Effectiveness): Насколько существующие внутренние контрмеры (логирование, мониторинг, сегментация) могут затруднить или обнаружить эксплуатацию? Если атака оставляет чистые логи, её вес снижается.
Метрики окружения (Attack Surface)
Здесь фокус смещается на атакуемый актив. Эти метрики делают оценку уникальной для вашего конкретного сервера, приложения или сети.
- Расположение (Required Privilege): Какие права нужны злоумышленнику для доступа к точке атаки? Анонимный доступ из интернета — максимальный риск. Требуется аутентифицированный доступ внутри сегмента сети — риск ниже.
- Сложность защиты (Required Privilege Scope): Насколько легко изолировать или защитить уязвимый компонент? Устаревшая библиотека в микросервисе, который легко вывести из эксплуатации, менее критична, чем та же библиотека в монолитном ядре ERP-системы.
- Время эксплуатации (Finding Confidence): Насколько надёжны данные о слабости? Это подтверждённый эксплойт, теоретическая возможность или результат статического анализа с ложными срабатываниями?
Метрики бизнес-влияния (Environmental)
Самая субъективная и важная группа. Она связывает техническую угрозу с бизнес-последствиями. Без неё приоритизация остаётся в руках технарей, не понимающих стоимости простоя.
- Ущерб для бизнеса (Business Impact): К каким потерям приведёт успешная атака? Финансовые потери, репутационный ущерб, нарушение compliance (например, 152-ФЗ о персональных данных). Утечка данных клиентов для интернет-магазина критичнее, чем для внутреннего портала.
- Приоритет актива (Asset Criticality): Насколько важен атакуемый актив для выполнения бизнес-функций? Критическая система (платежи, биллинг) получает высший балл, тестовая среда — минимальный.
- Масштаб воздействия (Collateral Damage Potential): Может ли инцидент вызвать цепную реакцию и повлиять на другие системы? Взлом сервера в демилитаризованной зоне (DMZ) может открыть путь во внутреннюю сеть.
Именно комбинация этих трёх векторов — технической угрозы, экспозиции в вашей сети и бизнес-стоимости актива — даёт итоговый приоритет. Слабость с высоким техническим ударом на маловажном активе может оказаться ниже в списке, чем умеренная угроза на критическом сервере.
Практическое применение CWSS в российском контексте регуляторики
В России, где требования регуляторов (ФСТЭК, 152-ФЗ) носят обязательный характер, CVSS часто приводит к неэффективному распределению ресурсов. Команды вынуждены в первую очередь латать «критические» уязвимости по CVSS, даже если они не попадают под действие регуляторных норм для их конкретного актива.
CWSS позволяет строить приоритизацию, напрямую учитывающую регуляторные риски. Например, требования 152-ФЗ жёстко регламентируют защиту персональных данных (ПДн). Рассмотрим две уязвимости:
- Уязвимость CVE с CVSS 9.0 в модуле обработки изображений на публичном сайте компании. Сайт не обрабатывает ПДн.
- Уязвимость CVE с CVSS 6.5 в СУБД, где хранятся базы ПДн клиентов. Доступ к СУБД возможен из сегмента прикладных серверов.
По CVSS первая уязвимость будет приоритетнее. По CWSS картина кардинально меняется. Для второй уязвимости в метриках бизнес-влияния выставляется максимальный балл за «Нарушение compliance (152-ФЗ)» и «Высокую критичность актива». В метриках окружения оценивается потенциальный доступ из смежной сети. В итоге её итоговый CWSS score может в разы превысить score первой уязвимости, корректно отразив реальный риск штрафов и репутационных потерь.
Этот подход согласуется с методологией ФСТЭК, которая предписывает оценивать защищённость информации с учётом её актуальности, важности и последствий нарушений. CWSS формализует эту оценку для конкретных технических слабостей.
Пошаговая методика: как внедрить CWSS в процесс
Внедрение CWSS требует смены подхода, а не просто установки нового инструмента. Вот последовательность шагов.
Шаг 1: Инвентаризация и классификация активов
Без понимания, что у вас есть и насколько это важно, метрики бизнес-влияния CWSS будут субъективной догадкой. Создайте реестр информационных активов (ИС, серверы, базы данных) и присвойте каждому атрибуты:
- Критичность для бизнеса (высокая, средняя, низкая).
- Обрабатываемые данные (ПДн, коммерческая тайна, открытые данные).
- Регуляторный статус (попадает под 152-ФЗ, требования ФСТЭК и т.д.).
- Сетевую сегментацию (публичный доступ, ДМЗ, внутренняя сеть).
Этот реестр станет источником данных для заполнения метрик CWSS.
Шаг 2: Интеграция с источниками данных об уязвимостях
CWSS не заменяет сканеры. Напротив, он потребляет их данные. Настройте передачу результатов сканирования (от инструментов вроде MaxPatrol, Qualys, Acunetix) в систему, где будет рассчитываться CWSS. К каждому найденному CVE должна быть привязана информация об атакуемом хосте или приложении из вашего реестра активов.
Шаг 3: Разработка и формализация политики оценки
Чтобы оценки были консистентными, создайте внутреннюю инструкцию по заполнению метрик CWSS. Определите, например:
- Все системы с ПДн автоматически получают максимальный балл по «Бизнес-влиянию» в части compliance.
- Уязвимости на активах с доступом из интернета получают максимум по «Расположению» в метриках окружения.
- Для CVE с публичным эксплойтом всегда выставляется определённый балл в «Распространённости атаки».
Это снимет основную субъективность и ускорит процесс.
Шаг 4: Расчет, приоритизация и выдача задач
На этом этапе для каждой найденной уязвимости на основе политики и данных из реестра рассчитывается итоговый CWSS score. Результаты ранжируются от высокого к низкому. Этот ранжированный список — и есть план исправлений. Его можно интегрировать с тикет-системой (Jira, Redmine) для автоматического создания задач командам разработки и администрирования.
Шаг 5: Мониторинг и переоценка
Контекст меняется. Вы вывели сервер из эксплуатации, изменили сетевые правила, система перестала быть критичной. Политика CWSS должна предусматривать периодическую или событийную переоценку. Падение уязвимости в списке приоритетов после миграции актива — признак того, что система работает корректно.
Ограничения и сложности CWSS
CWSS — мощный, но не серебряная пуля. Его внедрение сопряжено с вызовами.
- Трудоёмкость на старте: Создание и поддержка качественного реестра активов требует значительных усилий.
- Субъективность бизнес-метрик: Оценка ущерба для репутации или финансовых потерь всегда будет содержать долю экспертного суждения. Чёткая политика минимизирует, но не устраняет её.
- Отсутствие полной автоматизации: Многие метрики, особенно в группе окружения (сложность защиты, уверенность в находке), требуют ручного анализа специалистом. Полностью автоматизированный CWSS-пайплайн — миф.
- Меньшая распространённость: В отличие от CVSS, который поддерживается всеми сканерами и базами уязвимостей, CWSS редко реализован «из коробки». Чаще всего его внедрение, это кастомная разработка или настройка платформ класса VMDR (Vulnerability Management, Detection and Response).
Эти сложности означают, что CWSS в первую очередь подходит для зрелых команд безопасности, которые уже переросли примитивную «гонку за CVSS» и готовы вкладываться в качественную аналитику рисков.
Итог: когда переходить на CWSS?
CWSS, это следующий этап эволюции для управления уязвимостями. Он не отменяет CVSS как общий индикатор опасности, но переводит его в роль справочной информации. Ключевой сигнал к переходу — когда вы понимаете, что тратите ресурсы на исправление «громких» уязвимостей, не оказывающих реального влияния на ваш бизнес-риск, в ущерб более тихим, но опасным в вашем контексте проблемам.
Если ваша инфраструктура сложна, содержит активы под регуляторным давлением (152-ФЗ) и критичные для бизнеса системы, а команда безопасности готова к более глубокому анализу — начинайте с пилотного проекта. Возьмите один критичный актив, проассоциируйте с ним найденные уязвимости и оцените их по CWSS. Сравните полученный порядок исправлений с тем, что диктует CVSS. Разница, скорее всего, будет разительной и станет лучшим аргументом для полномасштабного внедрения.
В конечном счёте, CWSS, это инструмент для того, чтобы говорить с бизнесом и разработкой на одном языке: языке конкретных рисков и их стоимости, а не абстрактных оценок опасности.