«Безотносительный CVSS-балл, это математическая абстракция. Настоящий риск начинается там, где уязвимость пересекается с ценностью актива и требованиями регулятора. CWSS предлагает формализовать это пересечение, переводя разговор с инженеров на язык бизнес-рисков, понятный руководству и проверяющим.»
Почему CVSS недостаточно для приоритизации в российском контексте
Common Vulnerability Scoring System (CVSS) стала де-факто стандартом для оценки технической тяжести уязвимости. Её балл от 0.0 до 10.0 объективен и воспроизводим, но это же её главный недостаток: он не знает вашего бизнеса. Одна и та же CVE с рейтингом 7.5 (High) в публичном информационном сайте и в ядре биллинговой системы, обрабатывающей персональные данные по 152-ФЗ, представляет радикально разные риски.
Автоматическое сканирование генерирует сотни и тысячи таких «объективных» оценок. Следование им вслепую ведёт к парадоксальной ситуации: команда тратит ресурсы на устранение высокоуровневой уязвимости в незначительном активе, в то время как средняя по CVSS дыра в критичном сегменте продолжает жить. Для регуляторных проверок, особенно по требованиям ФСТЭК, такое положение недопустимо — требуется обоснованная модель управления рисками, а не реакция на сканер.
Что такое CWSS и как она устроена
Common Weakness Scoring System (CWSS), это методология, разработанная сообществом MITRE. Её цель — оценить не уязвимость саму по себе, а риск от эксплуатации конкретной слабости (weakness) в конкретном окружении. Если CVSS отвечает на вопрос «Насколько опасна эта дыра?», то CWSS — «Насколько опасна эта дыра для моего бизнеса, и что мне с этим делать?».
Оценка строится на трёх взаимосвязанных группах факторов. Их совокупный вес и определяет итоговый балл риска от 0 до 100.
Фактор 1: Базовая характеристика уязвимости (Base Finding)
Это техническое ядро оценки, наиболее близкое к CVSS. Оценивается, насколько легко использовать слабость. Параметры включают необходимый уровень доступа (локальный, смежная сеть, удалённый), требуемые привилегии (гость, пользователь, администратор) и сложность эксплуатации (низкая, средняя, высокая). Например, Remote Code Execution с низкой сложностью на граничном веб-сервере получит здесь максимальные оценки.
Фактор 2: Воздействие (Impact)
Здесь оценивается ущерб от успешной атаки через классическую триаду CIA:
- Конфиденциальность: К каким данным приведёт доступ? К публичным логам или к записям, составляющим коммерческую тайну или персональные данные?
- Целостность: Можно ли изменить данные? Приведёт ли это к финансовым потерям или нарушению процессов?
- Доступность: Будет ли сервис или данные полностью или частично недоступны? Каковы последствия простоя?
Воздействие оценивается не абстрактно, а с точки зрения масштаба (частичное, значительное, полное).
Фактор 3: Окружение (Environment) — ключевое отличие
Этот блок превращает техническую оценку в оценку бизнес-риска. Он учитывает контекст, в котором существует актив:
- Критичность бизнес-актива: Насколько важен сервис для выполнения миссии организации? Это тестовый стенд или платёжный шлюз?
- Распространённость слабости: Находится ли уязвимость в кастомной разработке или в широко используемой библиотеке, что увеличивает вероятность целенаправленного поиска.
- Требования регуляторов: Обрабатывает ли система персональные данные (152-ФЗ), гостайну, является ли критической информационной инфраструктурой (КИИ)? Наличие регуляторных требований резко повышает вес фактора окружения.
- Компенсирующие контроли: Применены ли меры защиты (WAF, сегментация, IPS), которые усложняют или делают невозможной эксплуатацию уязвимости в данном окружении.
Как считать CWSS: от формулы к практике
Финальная формула CWSS выглядит комплексно: CWSS Score = (BaseFinding * Impact * Environment) / 25, где каждый компонент, это взвешенная сумма своих метрик. Ручной расчёт громоздок, но на практике используют:
- Онлайн-калькуляторы и инструменты MITRE. Позволяют последовательно выбрать значения для всех метрик и автоматически получить итог.
- Интеграции в платформы управления уязвимостями (VM). Некоторые VM-системы позволяют импортировать данные об активах и автоматически рассчитывать CWSS на основе предзаданных профилей критичности.
- Упрощённые табличные модели внутри компании. Можно создать Excel-таблицу с ключевыми для организации факторами (например: актив = КИИ? да/нет; данные = ПДн? да/нет) и на её основе корректировать приоритеты, полученные от сканеров.
Важно понимать: итоговый балл, это не догма, а инструмент для сравнения и принятия решений. Разрыв между 85 и 30 баллами значителен и явно указывает, на что обратить внимание в первую очередь.
Применение CWSS для выполнения требований ФСТЭК и 152-ФЗ
Методология CWSS напрямую ложится на требования российских регуляторов к управлению уязвимостями.
- Для 152-ФЗ: Оператор ПДн обязан принимать меры, соответствующие актуальным угрозам. CWSS позволяет формально обосновать, почему угроза от конкретной уязвимости в системе, обрабатывающей ПДн, оценена как высокая (например, из-за сочетания технической возможности утечки и высокой критичности данных), и почему именно эта мера (срочный патч) была выбрана и применена в первую очередь.
- Для аттестации по требованиям ФСТЭК: Проверяющие смотрят на системность подхода. Наличие документально зафиксированной процедуры оценки рисков на основе CWSS, привязанной к реестру информационных активов,, это весомый аргумент в пользу зрелости процесса управления информационной безопасностью. Это доказывает, что исправления выполняются не хаотично, а на основе оценки реального ущерба.
- Для КИИ: Требования включают мониторинг и устранение уязвимостей с учётом критичности объектов. CWSS с её фактором «окружение» идеально подходит для ранжирования уязвимостей внутри сегментов КИИ.
Интеграция CWSS в рабочий процесс ИБ-специалиста
Внедрение CWSS не означает отказ от CVSS. Эффективная стратегия выглядит как двухэтапный воронка:
- Первичная фильтрация (CVSS). Автоматизированные сканеры и SIEM используют CVSS для первоначального отсева шума и выделения уязвимостей с высоким и критическим базовым рейтингом.
- Контекстуальная оценка (CWSS). Для сокращённого списка потенциально опасных уязвимостей ИБ-аналитик вручную или с помощью инструментов проводит оценку CWSS. Ключевой вклад вносят данные из CMDB (базы управления конфигурациями) о критичности актива и из нормативных документов о регуляторном статусе.
Результат CWSS-оценки, это готовое обоснование для:
- Задачи на исправление с ясным приоритетом (P0, P1, P2) для службы разработки или администрирования.
- Отчёта руководству о топ-рисках на языке бизнес-последствий («уязвимость в платёжном модуле грозит финансовыми потерями и штрафами от ЦБ»).
- Плана корректирующих мер для проверяющих органов.
Ограничения и подводные камни
CWSS — мощный инструмент, но не панацея. Его эффективность упирается в качество входных данных.
- Требует глубокого знания инфраструктуры. Без актуального реестра активов с оценкой их критичности фактор «Окружение» превращается в гадание.
- Не заменяет экспертизу для нулевых дней (0-day). Для неизвестных уязвимостей, где полное воздействие неясно, оценка будет неточной. CWSS лучше работает с известными, классифицированными слабостями (CWE).
- Риск субъективности. Оценка факторов окружения, особенно «критичности бизнес-актива», может разниться между подразделениями. Необходима внутренняя политика с чёткими критериями.
- Сложность полной автоматизации. Полноценный расчёт CWSS часто требует ручного вмешательства аналитика для учёта всех нюансов бизнес-контекста.
С чего начать внедрение
Полноценная интеграция CWSS — эволюционный процесс. Первые шаги могут быть такими:
- Определите 5-10 самых критичных информационных систем с точки зрения бизнеса и регуляторов.
- Для следующего отчёта сканера выберите все уязвимости (CVSS 5.0 и выше), затрагивающие эти системы.
- Проведите для них упрощённую CWSS-оценку вручную, сфокусировавшись на двух вопросах: «Каков потенциальный ущерб (Impact)?» и «Насколько это важно для компании (Environment)?». Используйте простую шкалу: Высокий/Средний/Низкий.
- Сравните полученный приоритет с приоритетом, который предложил сканер на основе CVSS. Различия станут наглядной иллюстрацией ценности контекстуального подхода.
- На основе этого опыта разработайте и задокументируйте внутреннюю процедуру оценки, закрепив её в политике управления уязвимостями.
CWSS формализует то, что опытные специалисты делают интуитивно: смотрят на уязвимость через призму ценности того, что она может сломать. В условиях ограниченных ресурсов и растущего регуляторного давления такой подход превращает техническую задачу патчинга в управленческое решение по снижению бизнес-рисков. Это не просто ещё одна метрика, а язык, на котором безопасность может говорить с бизнесом и с проверяющими.