Сергей Попов
Администратор
- 30.12.2015
- 6 308
- 7 005
- Специализация
- OSINT
- Веб-безопасность
- Статус верификации
- ✓ Verified
Последний квартальный скан Tenable по продуктивному контуру выдал 47 тысяч findings, из которых 312 - Critical по CVSS. Команда из трёх VM-инженеров физически способна закрыть 10-15% бэклога за месяц. Вопрос: какие 15%?
Среди этих 312 Critical есть CVE с публичным эксплойтом на GitHub, которую прямо сейчас раскатывают через ботнет. И есть CVE с таким же скором 9.8, но требующая локального доступа к dev-стенду, который смотрит в /dev/null. CVSS не различает эти случаи. А разница между ними - между инцидентом с ransomware и тикетом, который можно безопасно отложить на квартал.
Почему CVSS перестал работать как единственный фильтр приоритизации
CVSS оценивает теоретическую критичность: worst-case сценарий в вакууме. Оценка 9.8 означает удалённую эксплуатацию без аутентификации с полным компромиссом конфиденциальности, целостности и доступности. В спецификации CVSS v4.0 FIRST - разработчик и мейнтейнер стандарта - прямо пишет: базовый скор отражает intrinsic severity и предполагает reasonable worst-case impact. Полезный baseline, но не финальный ответ на вопрос "что патчить первым".Масштаб проблемы в цифрах
По данным Picus Security (Blue Report, 2025), ежедневно публикуется около 135 новых CVE - рост на 40% год к году. За 2025-й опубликовано более 48 000 CVE. Среднее время устранения (MTTR), по оценкам того же отчёта, - от 55 до 72 дней. За этот период в очередь добавляются тысячи новых записей. Средняя enterprise-организация устраняет 10-15% бэклога в месяц. Бэклог не сокращается - он растёт.При этом, по данным того же исследования (со ссылкой на результаты FIRST), из всех CVE с оценкой CVSS 7+ лишь единицы процентов фиксируются в реальных попытках эксплуатации за месяц. Одновременно 28% уязвимостей, которые атакующие действительно используют, имеют лишь средний уровень CVSS.
Команда, которая сортирует бэклог строго по CVSS, систематически откладывает четверть реально эксплуатируемых уязвимостей, одновременно тратя ресурсы на теоретические риски. Это не гипотеза - это арифметика.
Два примера, чтобы стало конкретнее:
Ложная тревога. CVE с CVSS 7.0 (HIGH), вектор CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H - локальная эксплуатация, высокая сложность, нужны привилегии. По CVSS это HIGH, попадает в SLA-очередь. Но реальная вероятность эксплуатации по EPSS - 0,31%, перцентиль 0,24: ниже 76% всех CVE в базе. CISA SSVC decision: Track (мониторить), exploitation: none, automatable: no. Этот тикет можно безопасно сдвинуть на плановый цикл.
Ложное спокойствие. Уязвимость со средним CVSS на публичном VPN-концентраторе с прямым доступом к сегменту PII - по CVSS-подходу она уходит вниз очереди. Если EPSS показывает высокую вероятность и есть публичный эксплойт - это не тикет, а инцидент в ожидании.
EPSS score - что это и как использовать для управления уязвимостями по рискам
EPSS (Exploit Prediction Scoring System) - модель машинного обучения от FIRST.org. Она оценивает вероятность того, что конкретная CVE будет эксплуатироваться in the wild в течение следующих 30 дней. CVSS измеряет, насколько плохо может быть. EPSS измеряет, насколько вероятно это произойдёт. Разница принципиальная.
Score и percentile - два значения, которые нужно понимать
EPSS выдаёт две метрики:- Score - вероятность эксплуатации от 0 до 1.0. Score 0,85 = 85% вероятности эксплуатации в ближайшие 30 дней.
- Percentile - позиция относительно всех CVE в базе. Перцентиль 0,95 означает: эта CVE вероятнее будет эксплуатироваться, чем 95% всех остальных зарегистрированных уязвимостей.
Ограничения EPSS
EPSS - глобальный прогноз, не локальная оценка. Модель показывает, что эксплуатируется в интернете в целом, но не знает вашей инфраструктуры:- Доступен ли уязвимый актив из внешней сети
- Есть ли компенсирующие контроли (WAF, EDR, сетевая сегментация)
- Какова бизнес-ценность конкретного актива
- Работает ли CVE только на специфических конфигурациях
CVSS против EPSS: три CVE, три решения
Лучший способ понять разницу - приложить оба метода к конкретным уязвимостям. Три CVE ниже - три типичных сценария из жизни VM-инженера.
| Параметр | CVE-2024-0646 | CVE-2024-4577 | CVE-2024-1709 |
|---|---|---|---|
| Продукт | Linux kernel (TLS splice) | PHP-CGI на Windows | ConnectWise ScreenConnect 23.9.7 и ниже |
| CWE | CWE-787 (Out-of-bounds Write) | CWE-78 (OS Command Injection) | CWE-288 (Auth Bypass via Alternate Path) |
| CVSS | 7.0 (HIGH) | 9.8 (CRITICAL) | 10.0 (CRITICAL) |
| Вектор CVSS | AV:L/AC:H/PR:L/UI:N | AV:N/AC:L/PR:N/UI:N | AV:N/AC:L/PR:N/UI:N/S:C |
| EPSS score | 0,0031 (0,31%) | 0,9999 (99,99%) | 0,9996 (99,96%) |
| EPSS percentile | 0,24 (нижняя четверть) | 0,9998 (top 0,02%) | 0,9998 (top 0,02%) |
| CISA KEV | Нет | Да (добавлена 2024-06-12) | Да (добавлена 2024-02-22) |
| CISA SSVC | Track (мониторить) | Act (патчить немедленно) | Act (патчить немедленно) |
| Автоматизируема | Нет | Да | Да |
| Связь с ransomware | Нет | Да | Да |
CVE-2024-0646 - на бумаге HIGH (7.0), что у большинства организаций попадает в SLA-очередь. Вектор AV:L/AC:H/PR:L: нужен локальный доступ, высокая сложность, привилегии пользователя. EPSS 0,31% при перцентиле 0,24 - ниже трёх четвертей всех CVE. CISA оценивает: exploitation none, automatable no, technical impact total. Рациональное решение: мониторинг, патч в плановом цикле. Можно выдохнуть.
CVE-2024-4577 - совсем другая история. CVSS 9.8 (AV:N/AC:L/PR:N/UI:N) - удалённая эксплуатация без аутентификации. EPSS 99,99% - top 0,02% по вероятности. CISA KEV с пометкой ransomware. Публичные PoC: репозиторий watchtowrlabs/CVE-2024-4577 на GitHub (319 звёзд), Exploit-DB EDB-52331. Это не теоретический риск - это активная массовая эксплуатация. Если у вас PHP-CGI на Windows торчит наружу - бросайте читать и идите патчить.
CVE-2024-1709 - ConnectWise ScreenConnect Authentication Bypass. CVSS 10.0, максимальный скор. EPSS 99,96%. CISA KEV добавлена 2024-02-22 с дедлайном 2024-02-29 - семь дней на устранение, ускоренный цикл. Атакующий с сетевым доступом к management interface создаёт администраторский аккаунт без каких-либо условий. Просто заходит и создаёт.
Сортировка по CVSS ставит CVE-2024-1709 (10.0) выше CVE-2024-4577 (9.8). По EPSS обе - в top 0,02%, обе требуют немедленного действия. При этом CVE-2024-0646 с CVSS 7.0 на dev-стенде, по данным EPSS и CISA, не представляет операционного риска. Один тикет из очереди HIGH можно безопасно перенести - и освободить руки для того, что реально эксплуатируется прямо сейчас.
Контекстные факторы риска: что не видят ни CVSS, ни EPSS
EPSS закрывает главный gap CVSS - вероятность эксплуатации. Но оба метода слепы к вашей конкретной инфраструктуре. Для полной приоритизации уязвимостей на основе рисков нужны дополнительные сигналы.
Бизнес-критичность актива. Одна CVE на изолированном dev-стенде и на production-системе платёжного шлюза - разный риск. Классификация по tier-уровням (1/2/3) - обязательное условие. Если CMDB нет или она не актуальна (а она обычно не актуальна), начните с трёх вопросов: стоимость простоя за час, обработка PII/финансовых данных/PHI, участие в цепочке аутентификации (IdP, AD, PKI).
Сетевая экспозиция и атакующие пути. Актив с прямым доступом из интернета vs актив за тремя слоями сегментации - фундаментально разный risk profile. Wiz описывает концепцию toxic combinations: medium-severity CVE на контейнере, который internet-facing, работает с IAM-ролью с admin-level access к базе с PII, и уязвимый пакет загружен в runtime. Каждый finding по отдельности - не критичен. Вместе - fix now. В терминах MITRE ATT&CK это Exploit Public-Facing Application (T1190, Initial Access) с последующим Exploitation of Remote Services (T1210, Lateral Movement) для продвижения к целевым данным.
Компенсирующие контроли. WAF с актуальной сигнатурой, IPS, EDR с поведенческим детектом - всё это влияет на реальную exploitability. Но вот неприятная цифра: по данным Picus Security (Blue Report), только 14% логируемой adversarial activity генерирует алерт. Четырнадцать процентов. Компенсирующий контроль - фактор снижения urgency, но не замена патчу. Надеяться на WAF, который пропускает 86% - так себе стратегия.
CISA KEV и Threat Intelligence. CISA Known Exploited Vulnerabilities Catalog - каталог CVE с подтверждённой активной эксплуатацией. Если CVE в KEV - это не прогноз, а факт. Дополнительные источники: GreyNoise (массовое сканирование), VulnCheck (обогащённые KEV-данные), вендорские бюллетени. Атакующие целенаправленно собирают эксплойты (T1588.005, Resource Development) и данные об уязвимостях (T1588.006) для подготовки к атаке - наличие CVE в CISA KEV сигнализирует, что этап resource development уже пройден. Дальше - дело техники.
Формула Hybrid Score и пороги для приоритизации патчей
Задача - свести CVSS, EPSS, контекст актива и threat intelligence в единый числовой скор, пригодный для Jira-тикета и отчёта CISO. Без магии, на арифметике.Hybrid Risk Score = (CVSS_Base * Asset_Weight) + Exploit_Modifier + KEV_Modifier
Где:
- CVSS_Base - базовый скор (0-10)
- Asset_Weight - множитель бизнес-критичности: 1.5 (tier-1: revenue, auth, PII), 1.0 (tier-2: internal production), 0.5 (tier-3: dev/test/isolated)
- Exploit_Modifier - на основе EPSS: EPSS >= 70% = +5; EPSS 30-70% = +3; EPSS < 30% = 0
- KEV_Modifier - CVE в CISA KEV = +5; нет = 0
Расчёт на трёх CVE
CVE-2024-4577 (PHP RCE, production web-сервер, tier-1):(9.8 * 1.5) + 5 + 5 = 14.7 + 10 = 24.7
CVE-2024-1709 (ScreenConnect, внутренний IT-инструмент, tier-2):
(10.0 * 1.0) + 5 + 5 = 10.0 + 10 = 20.0
CVE-2024-0646 (Linux kernel, dev-стенд, tier-3):
(7.0 * 0.5) + 0 + 0 = 3.5
CVSS ставит CVE-2024-1709 (10.0) выше CVE-2024-4577 (9.8). Hybrid Score учитывает, что PHP-сервер - tier-1 актив с прямым выходом в интернет, и ставит его выше. CVE-2024-0646 уходит в конец очереди: CVSS 7.0 на dev-стенде без эксплуатации - минимальный приоритет. Разница между 24.7 и 3.5 - это разница между "бросай всё" и "запиши в бэклог".
Пороги принятия решений
| Hybrid Score | Действие | SLA |
|---|---|---|
| 20+ | Немедленный патч, эскалация CISO | 24-48 часов |
| 12-19 | Приоритетный патч | 7 дней |
| 6-11 | Плановый патч | 30 дней |
| 0-5 | Мониторинг, отложенный патч | 90 дней / accept risk |
Веса и пороги - стартовая точка, не догма. Калибруйте под свою инфраструктуру: если 80% активов - tier-1, пороги нужно сдвигать. Если не калибровать - через месяц всё снова будет Critical.
Понедельник утром: 200 непропатченных хостов за 4 часа
Шаг 5. Создание тикетов с обоснованием. В каждый тикет включите: CVSS, EPSS, наличие в KEV, tier актива, итоговый Hybrid Score. Когда в Jira стоит не просто "CVSS 10.0, Critical", а "Hybrid Score 20.0 (tier-2, EPSS 99,96%, KEV, automatable)" - это данные, а не мнение аналитика. Вопрос "почему мы отложили CVE с CVSS 7.0?" закрывается одной строкой в тикете.
Парадокс MTTR: самые опасные CVE закрываются медленнее
Неочевидный момент из исследования Picus Security: уязвимости с высоким EPSS (>0.7) имеют значительно более длительное среднее время устранения, чем уязвимости с низким EPSS.Причина прозаичная: high-EPSS уязвимости чаще затрагивают critical production-системы, где patching window ограничен, change management длительнее, а цена отката выше. Для VM-инженера это означает: если EPSS > 0.7 и нет патча от вендора - компенсирующие меры (WAF rule, сетевая изоляция, усиленный мониторинг IoC эксплуатации) должны быть в тикете наравне с задачей на патч, а не вместо неё. "Ждём окно на патч" - не стратегия, а приглашение для атакующего.
Результат внедрения: 60-70% бэклога уходит в категорию "мониторинг" или "плановый патч". Не потому что проблемы нет, а потому что данные подтверждают: эксплуатация маловероятна, актив изолирован, контроли на месте. Оставшиеся 30-40% тикетов - реально опасные, и к ним команда подходит сфокусированной, а не измотанной бесконечным потоком Critical, которые никогда не будут эксплуатироваться.
Главная трудность тут не техническая, а организационная. DevOps и бизнес-владельцы привыкли к CVSS как к абсолюту, и фраза "мы отложили Critical" вызывает предсказуемую реакцию. Но когда в тикете стоит "Hybrid Score 3.5 - dev-стенд, EPSS 0,31%, вне KEV, automatable: no" - диалог переходит из эмоциональной плоскости в рациональную. Числа не спорят с должностями.
Через год-два организации, которые не внедрят EPSS и KEV как обязательные компоненты triage, будут выглядеть как те, кто в 2018-м сортировал уязвимости по дате публикации. Всё для перехода уже есть: API FIRST.org бесплатный, CISA KEV обновляется ежедневно, формула скоринга помещается в один абзац. Не хватает только решимости перестать патчить "по номерам" и начать патчить по данным.
Последнее редактирование модератором:
