Экономика уязвимостей и патч-менеджмент: кто быстрее

Понедельник, 9:15 утра. В SIEM прилетает серия алертов: массовое сканирование портов 443 и 8443 по всему внешнему диапазону. Паттерн совпадает с reconnaissance-активностью - Vulnerability Scanning (T1595.002, Reconnaissance) - под свежий CVE в веб-сервере, опубликованный в пятницу вечером. VM-сканер ещё не обновил сигнатуры. Патч скачан, но застрял на тестировании: dev-стенд занят другим релизом. К 11:00 WAF логирует первые попытки эксплуатации с трёх IP - payload совпадает с PoC, появившимся на GitHub в субботу.

Патч будет развёрнут на продакшн через 18 дней. Между публикацией уязвимости и первой попыткой эксплуатации прошло 48 часов. Между публикацией и установкой патча пройдёт более 430.

По данным IBM X-Force, среднее время между публикацией CVE и фактическим устранением в организации - 29 месяцев. Экономика уязвимостей и патч-менеджмент сегодня - арифметика, в которой защитник проигрывает по умолчанию. Если не перестраивает правила.

Time to exploit vs time to patch: скорость эксплуатации уязвимостей в цифрах​

Самые системные лонгитюдные данные по таймлайнам эксплуатации собирает Mandiant. Согласно исследованию Cloud Security Alliance «The Exploit-Before-Patch Gap», медианное время от раскрытия уязвимости до первой эксплуатации сократилось с 63 дней в 2018–2019 годах до примерно 5–7 дней к 2023 году. Значительная доля отслеживаемых N-day уязвимостей в 2021–2022 годах была эксплуатирована в течение двух недель после раскрытия.

Кривая соответствует экспоненциальному затуханию. Не постепенное сжатие цикла - обвал.

По другую сторону - remediation. Отраслевая медиана развёртывания патча - около 20 дней, хотя для конкретных организаций фактический MTTR бывает значительно выше (как в примере выше - 18 дней, и это ещё неплохо). Verizon DBIR фиксирует смену основного вектора начального доступа: эксплуатация уязвимостей в непатченных системах - 31% всех инцидентов, впервые обогнав кражу учётных данных.

Окно эксплуатации уязвимости - разрыв между time-to-exploit и time-to-patch - не сужается. Оно расширяется. Атакующий ускоряется быстрее, чем защитник. В терминах MITRE ATT&CK массовое сканирование интернета на уязвимые сервисы - Vulnerability Scanning (T1595.002, Reconnaissance) - и последующая эксплуатация - Exploit Public-Facing Application (T1190, Initial Access) - начинаются за часы после публикации advisory. На стороне защитника патч в это время нередко только проходит тестирование.

Автоматизированные эксплойты и AI-generated exploit: новая экономика атаки​

Раньше разработка эксплойта требовала глубокого понимания memory layout, механизмов митигации и внутренностей ОС. Конвертация раскрытой уязвимости в рабочий exploit занимала недели квалифицированной инженерной работы. Этот «налог на сложность» давал защитнику временной буфер - время на реакцию.

Согласно CSA, AI меняет ситуацию качественно: не инкрементальное сокращение времени разработки, а потенциальная автоматизация полного цикла - от анализа advisory до генерации функционального кода. LLM уже демонстрируют способность анализировать описания уязвимостей и генерировать exploit-код с минимальным участием человека.

Принцип, который Halvar Flake сформулировал ещё в 2004 году - «the patch is the advisory» - стал критически актуальным. Сравнение бинарного кода до и после патча (patch-diffing) позволяет восстановить суть уязвимости. Раньше это требовало недель ручного реверса. С AI-инструментами patch-diffing выполняется за минуты. Каждый выпущенный патч - стартовый пистолет для атакующих, которые его ещё не развернули у себя. По сути, защитник сам публикует рецепт эксплойта.

В категориях MITRE ATT&CK это ресурсная подготовка: техники Exploits (T1588.005, Resource Development) и Vulnerabilities (T1588.006, Resource Development) стали доступнее. Если раньше покупка или разработка zero-day эксплойта была прерогативой APT-группировок с государственным финансированием, то автоматизация кибератак снижает порог входа до коммерчески доступного уровня.

Объём усиливает проблему. По данным CSA, количество новых CVE достигает примерно 40 000 в год. При 29 месяцах среднего MTTR (IBM X-Force) и сотнях активных CVE в типовой инфраструктуре - пропускная способность патч-процесса становится структурным ограничением. Автоматизированные эксплойты масштабируются с каждым новым advisory. Пропускная способность команды патчинга - нет.

Экономика атаки сместилась необратимо: стоимость создания exploit снижается, стоимость remediation остаётся фиксированной или растёт. Это определяет всю дальнейшую стратегию vulnerability management - невозможно выиграть гонку скоростей, нужно менять дистанцию.

CISA KEV каталог и EPSS: приоритизация патчей вместо CVSS-лотереи​

Если патчить всё подряд физически невозможно - остаётся приоритизация. Вопрос - на основе чего.

CVSS - стандарт de facto для scoring уязвимостей, но слабый инструмент для оперативных решений. Он отражает теоретическую опасность, а не вероятность реальной эксплуатации. Уязвимость с CVSS 9.8 (AV:N/AC:L/PR:N/UI:N), но без публичного PoC и не входящая в KEV, может оказаться менее срочной, чем уязвимость с CVSS 7.5, которую уже массово сканируют ботнеты. Vulnerability scoring CVSS EPSS - два инструмента, которые закрывают этот разрыв, но используются принципиально по-разному.

CISA KEV (Known Exploited Vulnerabilities) - каталог уязвимостей с подтверждённой активной эксплуатацией. Попадание CVE в CISA KEV каталог - не теоретическая оценка, а факт: эту уязвимость эксплуатируют прямо сейчас. Для организаций, подпадающих под ФЗ-187 о безопасности КИИ, мониторинг KEV должен быть частью операционного процесса. ФСТЭК надзирает за выполнением требований по безопасности ЗОКИИ (Постановление Правительства №162), и непатченные KEV-уязвимости на объектах КИИ - прямой риск при плановой или внеплановой проверке.

EPSS (Exploit Prediction Scoring System) - вероятностная модель, оценивающая шанс эксплуатации CVE в течение ближайших 30 дней. EPSS учитывает наличие публичного PoC, упоминания в threat intelligence feeds и характеристики уязвимости. EPSS выше 0.7 при CVSS от 7.0 - сигнал к немедленному патчингу.

Операционная формула для риск-ориентированного патчинга:


Эта модель приоритизации патчей не устраняет 29-месячный хвост целиком, но концентрирует ресурсы на 5–10% уязвимостей, покрывающих более 90% реального риска. Риск-ориентированный патчинг - не «патчить меньше», а «патчить то, что убьёт первым».

Vulnerability management: detection в окне эксплуатации​

Между раскрытием уязвимости и установкой патча защитник не бессилен - если работает detection. Проблема в том, что многие VM-программы заканчиваются на этапе «создан тикет на патч» и не включают мониторинг попыток эксплуатации. А тикет - это не защита, тикет - это намерение.

Скомпрометированные хосты и lateral movement​

Непатченные сервисы внутри периметра - отдельная головная боль. Exploitation of Remote Services (T1210, Lateral Movement) эксплуатирует уязвимости во внутренних сервисах для горизонтального перемещения. WAF и внешний IPS тут не помогают: трафик внутренний. Скомпрометированный легитимный хост с непатченным SMB, RDP или базой данных - типовая точка pivot для атакующего, который закрепился через фишинг или другой initial access. Именно поэтому управление уязвимостями в компании не может ограничиваться только внешним периметром.

Detection-чеклист для окна между disclosure и patch​

Сетевой уровень:

• IDS/IPS-сигнатуры на известные PoC-паттерны обновляются быстрее, чем патчи на целевых системах - это первая линия
• Алертинг на аномальный доступ к портам уязвимых сервисов из нехарактерных подсетей
• Сегментация: если актив нельзя патчить немедленно - изоляция через VLAN/ACL до завершения remediation

Корреляционное правило в SIEM (логика Sigma-стиля):
Endpoint-уровень:

Организационный уровень:

• Автоматическое обогащение тикетов VM-системы данными CISA KEV и EPSS через API-интеграцию
• Ежедневная сверка непатченных активов со списком KEV
• Playbook при detection exploitation attempt: изоляция актива, форензика, патч, верификация, возврат в продакшн

Управление уязвимостями в компании: от MTTR к операционному циклу​

Ключевая метрика vulnerability management - MTTR (Mean Time to Remediate), но не усреднённый по всей базе CVE. Операционный смысл имеет только MTTR по категориям приоритизации из таблицы выше.

Если фактический MTTR для KEV-уязвимостей превышает 7 дней - VM-процесс формально существует, но фактически не защищает. При медиане time-to-exploit в 5–7 дней (данные Mandiant) семидневный MTTR означает, что атакующий систематически успевает первым.

Операционный цикл управления уязвимостями:

1. Discovery - сканирование (Tenable, Qualys, Rapid7 или аналоги) не реже раза в сутки для критичных сегментов. Активы в DMZ - приоритет
2. Enrichment - автоматическое обогащение: EPSS-score, KEV-статус, наличие PoC в ExploitDB/Metasploit
3. Triage - приоритизация по категориям (KEV → EPSS → exposure), а не только по CVSS
4. Remediation - патч или компенсирующая мера: WAF-правило, отключение уязвимой функции, сетевая изоляция
5. Verification - повторное сканирование для подтверждения закрытия уязвимости
6. Detection - параллельно всему циклу: SIEM-мониторинг попыток эксплуатации непатченных активов

Один из ключевых разрывов - между командой ИБ, которая обнаруживает уязвимость, и командой ИТ, которая ставит патч. Этот организационный gap вносит существенный вклад в 29-месячный MTTR наряду с отсутствием приоритизации по риску. Автоматизация передачи тикетов с SLA по категориям и эскалацией при просрочке - не опциональная оптимизация, а необходимое условие работоспособности VM-программы.

По данным IBM X-Force, 70% атак затрагивают критическую инфраструктуру. Для организаций, подпадающих под ФЗ-187, это двойной риск: технический - компрометация, и регуляторный - ФСТЭК проводит плановые и внеплановые проверки выполнения требований по безопасности ЗОКИИ. VM-программа, не обеспечивающая приоритизированное устранение уязвимостей, ставит организацию под удар одновременно со стороны атакующих и со стороны регулятора.

Три года я строю VM-процессы в инфраструктурах от 200 до 2000 хостов. Команды, которые выравнивают MTTR по всей базе CVE, стабильно проигрывают гонку скорости. Они патчат по принципу «что проще развернуть», а не «что эксплуатируют прямо сейчас». Переход на EPSS-based triage сокращает объём срочной работы в 5–8 раз при покрытии более 90% реального риска - эту пропорцию я наблюдаю стабильно на разных масштабах.

Неудобная правда: немало VM-программ в российских организациях до сих пор строятся вокруг CVSS-severity и квартальных отчётов. Это работало при time-to-exploit в месяцы. При текущей динамике - 5–7 дней до эксплуатации - квартальный цикл означает три месяца с открытым периметром. MTTR для KEV-уязвимостей должен стать таким же baseline для SOC, как время реакции на алерт P1.

Мой прогноз: в ближайшие два года VM-программы разделятся на два класса - интегрированные с detection и работающие в режиме реального времени, и те, что генерируют PDF-отчёты постфактум. Второй класс будет стабильно поставлять материал для постмортемов. На codeby.net ведётся тред с разбором операционных workflow VM-программ и практик EPSS-triage - полезно для тех, кто перестраивает приоритизацию под текущие реалии скорости эксплуатации.