“Без осмысления, что такое CVE, CWE и CVSS, невозможно создать систему оценки угроз, которая говорит на одном языке с остальным миром ИБ. Это не просто аббревиатуры, а полноценные языки для описания проблем — от самой уязвимости до её сути и опасности.”
Что такое CVE: идентификатор уязвимости, а не её описание
Common Vulnerabilities and Exposures (CVE), это не база данных, а система каталогизации. Её основная задача — дать каждой публично раскрытой уязвимости в программном обеспечении уникальный и стабильный идентификатор. Формат идентификатора — CVE-ГГГГ-НОМЕР (например, CVE-2021-44228 для Log4Shell).
Ключевая особенность CVE — он ничего не говорит о серьёзности или природе проблемы. Это лишь метка, ссылка, по которой можно найти описание уязвимости в других источниках, таких как Национальная база данных уязвимостей (NVD). Без CVE обсуждение конкретной дыры превращается в хаос: «та уязвимость в библиотеке Apache», «проблема с парсингом логов» — CVE убирает эту неоднозначность.
Процесс присвоения CVE контролируется уполномоченными организациями (CNA). В России этой функцией обладает ФСТЭК России, что позволяет отечественным разработчикам и исследователям вносить уязвимости в международный реестр. Для специалиста по ИБ в России работа с CVE означает не только мониторинг глобальных угроз, но и понимание процедуры через национального CNA.
CWE: таксономия ошибок, а не конкретных инцидентов
Common Weakness Enumeration (CWE) отвечает на вопрос «что пошло не так?» на уровне архитектуры и кода. Это не список конкретных уязвимостей, а каталог типовых ошибок проектирования, реализации, защиты. Если CVE, это «что случилось», то CWE — «почему это произошло».
CWE представляет собой иерархическую таксономию. Например:
- CWE-79: Межсайтовый скриптинг (XSS) — класс уязвимостей.
- CWE-89: SQL-инъекция — другой класс.
Одна конкретная уязвимость CVE может быть отнесена к одному или нескольким CWE. Так, та же CVE-2021-44228 (Log4Shell) связана с CWE-77: Неправильная нейтрализация специальных элементов, используемых в команде (‘Command Injection’). Понимание CWE позволяет сместить фокус с тушения пожаров (реакция на CVE) на профилактику: если в продукте систематически встречаются уязвимости определённого класса CWE, значит, в процессах разработки или тестирования есть фундаментальный пробел.
CVSS: метрика тяжести, а не абсолютная истина
Common Vulnerability Scoring System (CVSS), это система оценки серьёзности уязвимости по балльной шкале от 0.0 до 10.0. CVSS не является частью CVE, но часто публикуется вместе с ним в базе NVD. это именно метрика, а не диагноз.
Оценка CVSS состоит из трёх групп метрик:
| Группа метрик | Что оценивает | Пример |
|---|---|---|
| Базовые | Вектор атаки, сложность эксплуатации, уровень привилегий, влияние на конфиденциальность, целостность, доступность | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — максимальный балл 10.0 |
| Временные | Актуальность эксплойта, уровень исправления, достоверность информации | Существует ли публичный эксплойт (Exploit Code Maturity) |
| Контекстуальные | Важность атакуемого актива для конкретной организации | Насколько критична система, где находится уязвимость, для бизнес-процессов |
Базовый балл, это объективная оценка технических характеристик уязвимости. Временной и контекстуальный баллы субъективны и должны пересчитываться внутри каждой организации с учётом её ландшафта угроз и инфраструктуры. Слепая вера в базовый CVSS из NVD — распространённая ошибка: уязвимость с баллом 9.8 на периферийном сервисе может представлять меньший реальный риск, чем уязвимость 6.5 на критичном домен-контроллере.
Как они работают вместе: практический пример
Рассмотрим гипотетическую, но реалистичную ситуацию. Исследователь обнаруживает, что веб-приложение некорректно обрабатывает параметры сессии, что позволяет аутентифицированному пользователю получить доступ к данным других пользователей.
- Присвоение CVE. Исследователь через CNA (например, ФСТЭК России или разработчика ПО) получает для уязвимости идентификатор CVE-2024-10001. Теперь о проблеме можно однозначно говорить.
- Классификация по CWE. Анализ показывает, что корень проблемы — в недостаточной проверке прав доступа при запросе данных. Это соответствует CWE-639: Непрямой доступ к объекту через нечувствительный к авторизации идентификатор. Эта классификация помогает другим разработчикам искать аналогичные ошибки в своём коде.
- Расчёт CVSS. Эксперты анализируют уязвимость:
- Базовые метрики: Для эксплуатации нужна аутентификация (PR:L), атака через сеть (AV:N), сложность низкая (AC:L), влияет на конфиденциальность (C:H). Базовый балл, допустим, 8.8 (Высокий).
- Временные метрики: Эксплойта в публичном доступе нет, но разработчик выпустил исправление. Временной балл может снизить общую оценку.
- Контекстуальные метрики: Для интернет-банка, где каждый аккаунт — финансовые данные, критичность максимальна. Для внутреннего сервиса с тестовыми данными — низкая.
в отчётах будет фигурировать: CVE-2024-10001 (CWE-639) с CVSS 8.8 (High). Это даёт полную картину: идентификатор, природу ошибки и её предполагаемую опасность.
Роль в российском регулировании и практике
В контексте 152-ФЗ и требований ФСТЭК эти системы играют ключевую, но не всегда прямую роль.
- Оценка защищённости. При проведении оценки защищённости (ОЗ) или анализа защищённости (АЗ) специалисты часто используют базы CVE для поиска известных уязвимостей в проверяемых системах. Классификация CWE помогает понять системные слабости в разработке или настройке.
- Управление инцидентами. При расследовании инцидентов ИБ идентификатор CVE позволяет быстро найти технические детали и способы устранения уязвимости, которая могла быть использована.
- Приказ ФСТЭК № 31. Требования по мониторингу актуальных угроз и устранению уязвимостей имплицитно предполагают работу с источниками, использующими CVE/CVSS для приоритизации. Без понимания CVSS невозможно грамотно расставить приоритеты для установки патчей.
При этом важно помнить, что слепое следование зарубежным рейтингам без учёта контекста российской ИТ-инфраструктуры (распространённость конкретного ПО, особенности его настройки) может привести к неэффективному распределению ресурсов ИБ.
Частые ошибки и заблуждения
Работа с CVE, CWE и CVSS сопряжена с типичными ошибками.
| Заблуждение | Реальность |
|---|---|
| «Высокий CVSS (9-10) = немедленная атака на нас» | Базовый CVSS отражает потенциал ущерба, но не вероятность атаки. Уязвимость должна быть в эксплуатируемом вами ПО, доступной из атакуемых сетей и представлять интерес для злоумышленника. |
| «CVE присваивается только критическим уязвимостям» | CVE присваивается любой публично раскрытой уязвимости, независимо от её серьёзности. Существует множество CVE с низким CVSS. |
| «Если в продукте нет CVE, он безопасен» | Отсутствие CVE может означать лишь то, что уязвимости не были найдены или не были раскрыты публично. Безопасность — процесс, а не статус. |
| «Достаточно смотреть только на базовый балл CVSS» | Без учёта временных и, главное, контекстуальных метрик оценка риска будет неполной и часто неверной. |
| «CWE нужны только разработчикам» | Специалистам по ИБ знание CWE помогает выстраивать более эффективную программу тестирования на проникновение и запрашивать у вендоров исправления не просто «багов», а целых классов уязвимостей. |
Итог: три разных инструмента для одной цели
CVE, CWE и CVSS — не взаимозаменяемые инструменты, а элементы одного «конструктора» для описания и оценки угроз.
- CVE даёт имя. Это точка входа для обсуждения, поиска информации и координации исправлений.
- CWE объясняет суть. Это язык для анализа коренных причин и улучшения процессов безопасности на стадии разработки и конфигурирования.
- CVSS оценивает опасность. Это методика для расстановки приоритетов в работе по устранению уязвимостей, основанная как на технических деталях, так и на контексте конкретной организации.
Грамотное использование всех трёх систем позволяет перейти от хаотической реакции на каждую новую «дыру» к системному управлению уязвимостями. В российских реалиях это также означает умение фильтровать глобальный шум угроз через призму локальной ИТ-инфраструктуры и регуляторных требований.