Идея статьи
Любая уязвимость в системе, это проблема, но не любая проблема требует завтрашнего патча. CVE-записей тысячи, ресурсов — ограниченное количество. CWSS, это попытка формализовать экспертный опыт анализа уязвимости и перевести его в цифру, которую можно сравнить с другой цифрой. Но эта система не для того, чтобы дать один единственный верный ответ, а для того, чтобы задать правильные вопросы об угрозе, атаке и бизнес-последствиях. Многие думают, что это просто очередной CVSS, но это ошибка. CWSS показывает не дыру, а путь, который ведёт от уязвимости к реальному инциденту.
Отличие CWSS от привычных метрик: это не «насколько дыра», а «насколько опасен путь»
Большинство специалистов по ИБ знакомы с Common Vulnerability Scoring System (CVSS). Эта система оценивает технические характеристики уязвимости: сложность эксплуатации, уровень привилегий, необходимых атакующему, влияние на конфиденциальность, целостность и доступность. CVSS отвечает на вопрос: «Насколько серьёзна сама уязвимость?»
Common Weakness Scoring System (CWSS) задаётся другим вопросом: «Насколько опасна цепочка событий, которую эта уязвимость позволяет создать в конкретном контексте?» Вместо оценки единичного бага CWSS анализирует слабость (weakness) — более широкую ошибку в дизайне, архитектуре или коде, которая может порождать множество конкретных уязвимостей. Система была создана сообществом MITRE как часть проекта Common Weakness Enumeration (CWE) и призвана помочь расставить приоритеты при устранении причин, а не симптомов.
Главное концептуальное различие: CVSS смотрит на уязвимость изолированно, а CWSS — на её место в атаке. Уязвимость типа SQL-инъекции может получить высокий балл CVSS, но если она находится в административном интерфейсе, доступном только из внутренней сети за двухфакторной аутентификацией, её реальная опасность ниже. CWSS позволяет учесть эти контекстные факторы.
Структура оценки: три группы факторов
Оценка по CWSS разбита на три логические группы, каждая из которых вносит свой вклад в итоговый балл от 0 до 100.
Базовые факторы (Base Finding)
Эта группа ближе всего к CVSS и описывает техническую суть слабости. Она отвечает за «потенциальную» опасность.
- Техническое влияние (Technical Impact): Что атакующий может сделать, успешно использовав слабость? Варианты варьируются от чтения данных до полного захвата контроля над системой.
- Распространённость приобретённых навыков (Acquired Skill): Насколько распространены знания, необходимые для эксплуатации. Эксплуатация утечки памяти в ядре требует иных навыков, чем простая подстановка в SQL-запрос.
- Вектор атаки (Attack Vector): Откуда может быть инициирова4на атака: локально, из смежной сети или через интернет.
- Сложность эксплуатации (Attack Complexity): Наличие дополнительных условий для успешной атаки, помимо знания самой уязвимости (например, необходимость угадать конкретный идентификатор сессии).
Эти факторы формируют так называемый «базовый балл» (Base Score), который затем модифицируется следующими группами.
Факторы среды атаки (Attack Surface)
Здесь оценивается, насколько защищён или открыт компонент, содержащий слабость. Это переход от теории к практике.
- Необходимый уровень авторизации (Required Privilege): Нужны ли атакующему учётные данные для доступа к функционалу, где есть слабость?
- Взаимодействие с пользователем (User Interaction): Требуется ли действие от легитимного пользователя (например, переход по ссылке) для успешной атаки?
- Уровень защищённости среды (Environment Hardening): Насколько система, в которой работает уязвимый компонент, укреплена стандартными средствами (ASLR, DEP, SELinux/AppArmor).
- Распространённость среды (Prevalence of the Environment): Насколько распространена уязвимая платформа или библиотека в исследуемой экосистеме.
Факторы воздействия на бизнес (Environmental)
Самая субъективная и контекстно-зависимая группа. Она привязывает техническую оценку к конкретной организации.
- Бизнес-последствия (Business Impact): К каким потерям приведёт успешная эксплуатация: финансовым, репутационным, операционным или юридическим? Утечка данных тестового стенда и боевой базы клиентов имеет разный вес.
- Лёгкость обнаружения (Likelihood of Discovery): Насколько просто найти эту слабость? Можно ли её обнаружить автоматизированными сканерами или требуется глубокий ручной аудит?
- Лёгкость эксплуатации (Likelihood of Exploit): Насколько вероятно, что найденная слабость будет реально использована? Существуют ли публичные эксплойты (PoC) в открытом доступе?
- Внешние контрмеры (External Control Effectiveness): Учитывает эффективность периметровых средств защиты (WAF, IPS, NGFW), которые могут блокировать попытки эксплуатации, даже если сама уязвимость не устранена.
Практическое применение: от теории к российским реалиям
Формальная модель хороша, но её ценность определяется применением. Рассмотрим, как CWSS вписывается в процессы, регламентированные 152-ФЗ и требованиями ФСТЭК.
Приоритизация при исправлении уязвимостей
Согласно требованиям регуляторов, организация должна иметь процесс управления уязвимостями. Часто этот процесс сводится к патчингу всего подряд по мере выхода обновлений, что создаёт операционную нагрузку и риск сбоев. CWSS даёт методику для обоснованного выбора.
Пример: в результате сканирования выявлены две уязвимости на веб-сервере.
- Уязвимость A (CVE-XXXX-XXXX): Высокий балл CVSS (8.5), позволяет выполнить удалённый код. По CWSS: находится в модуле, отключённом по умолчанию; доступ к серверу возможен только через VPN для сотрудников; WAF настроен на сигнатуры данной атаки. Итоговый балл CWSS — 45.
- Уязвимость B (CVE-YYYY-YYYY): Средний балл CVSS (6.2), позволяет провести SQL-инъекцию. По CWSS: находится в публичном API, используемом мобильным приложением; данные — персональные данные клиентов (ПДн); публичный эксплойт есть в сети; WAF не детектирует эту конкретную инъекцию. Итоговый балл CWSS — 78.
Несмотря на более низкий CVSS, уязвимость B представляет большую реальную опасность для организации и требует первоочередного внимания. Такой подход прямо соответствует принципу оценки рисков, заложенному в 152-ФЗ.
Интеграция в цикл разработки и аттестацию
ФСТЭК предъявляет требования к безопасности разработки и аттестации сложных информационных систем. CWSS можно использовать не только для эксплуатационных систем, но и на этапе проектирования и тестирования.
- Статический и динамический анализ (SAST/DAST): Вместо простого списка найденных проблем инструменты, поддерживающие CWE/CWSS, могут выдавать ранжированный отчёт. Уязвимости, ведущие к нарушению конфиденциальности ПДн (высокий балл в группе Business Impact), автоматически поднимаются наверх.
- Аттестация по требованиям: При составлении модели угроз и оценки рисков в рамках аттестационных мероприятий CWSS предоставляет структурированную методику для квалификации выявленных недостатков защиты. Это превращает экспертные суждения в документированные и воспроизводимые оценки.
Ограничения и подводные камни
CWSS — мощный инструмент, но не панацея. Его эффективность напрямую зависит от качества входных данных.
- Субъективность бизнес-факторов: Оценка бизнес-последствий (Business Impact) всегда будет субъективной. Что важнее для компании — час простоя торговой платформы или утечка внутренних переписок? Эти веса должны быть определены и согласованы внутри организации заранее, иначе оценки разных аналитиков будут несопоставимы.
- Требует глубокого контекста: Для точной оценки по CWSS необходимо хорошо знать архитектуру системы, сетевую топологию, настройки средств защиты. Автоматические сканеры таким контекстом не обладают, поэтому расчёт CWSS часто остаётся задачей для специалиста по анализу уязвимостей или SOC-аналитика.
- Вычислительная сложность: Ручной расчёт баллов для сотен уязвимостей непрактичен. Необходима интеграция с системами управления уязвимостями (VM) или SIEM, где контекстная информация (например, о расположении актива и его критичности) уже присутствует.
Первый шаг к внедрению
Внедрение CWSS не должно быть одномоментной революцией. Практичнее начать с пилотного проекта.
- Определите критические активы: Выделите 5-10 самых важных систем (например, хранилище ПДн, биллинг, шлюз электронного документооборота).
- Зафиксируйте веса для бизнес-факторов: Проведите внутреннюю сессию с владельцами бизнес-процессов и ИБ, чтобы определить, какие последствия (финансовые, репутационные, регуляторные) считаются для организации критическими, высокими, средними и низкими.
- Оцените вручную несколько уязвимостей: Возьмите последний отчёт сканера по критическому активу. Выберите 3-5 уязвимостей с высоким CVSS и 3-5 — со средним. Проведите для них оценку по CWSS, собрав контекст (доступность из сети, наличие WAF, критичность данных). Сравните итоговый порядок приоритетов с тем, который диктует CVSS.
- Автоматизируйте на уровне процессов: На основе успеха пилота сформулируйте требования к своим инструментам (VM-системе, баг-трекеру) — возможность добавлять поля для контекстных факторов и рассчитывать CWSS на их основе.
Такой подход позволяет сместить фокус с бесконечной «охоты за патчами» на управление рисками, основанное на данных. В конечном счёте, CWSS, это не замена экспертизе, а её структурированное продолжение, которое помогает принимать обоснованные решения в условиях нехватки времени и ресурсов. В российском regulatory-контексте, где отчётность и обоснованность принимаемых мер имеют первостепенное значение, такой структурированный подход оказывается не просто полезным, а необходимым.