Приоритизация уязвимостей: от asset discovery до тикета

На аудите инфраструктуры финтех-клиента мы нашли 14 хостов, которых не было ни в CMDB, ни в scope Tenable. Три из них крутили устаревший Apache Struts с CVE, по которым давно опубликованы эксплойты и которые входят в каталог CISA KEV. Сканер отрабатывал каждую неделю, сканировал на совесть - но сканировал только то, что знал. Хосты вне инвентаря оставались невидимыми. Если asset discovery инфраструктуры не связан с vulnerability management в единый пайплайн, приоритизация уязвимостей работает вхолостую - вы ранжируете 80% поверхности атаки и считаете, что покрыли всё.

Слепые зоны инвентаря: где ломается vulnerability management процесс​

Vulnerability management процесс обычно начинается с запуска сканера по заранее сформированному списку хостов. Список берётся из CMDB, которая в большинстве организаций отстаёт от реальности на недели или месяцы. DevOps подняла тестовый кластер в AWS - он не попал в CMDB. Подрядчик подключил VPN-шлюз - его тоже нет. Старый сервер отдела аналитики, который "временно" развернули три года назад, - забыли, но он торчит наружу. Подробнее - в нашем руководстве по asset management пентест.

Атакующие действуют ровно наоборот. Фаза reconnaissance по MITRE ATT&CK - Active Scanning (T1595), Scanning IP Blocks (T1595.001) - первое, что делает нарушитель: полный скан диапазонов, fingerprinting сервисов через Gather Victim Host Information / Software (T1592.002), построение карты топологии через Network Topology (T1590.004). Атакующий не ограничивается инвентарём, который кто-то когда-то занёс в ServiceNow. Он сканирует всё. И находит ровно те хосты, которые VM-команда пропустила.

По данным FIRST.org, организации способны устранять от 5 до 20% уязвимостей в месяц. Если при этом 10-15% ИТ-активов вообще не попадают в scope сканирования - арифметика работает против защитников. Критические уязвимости на невидимых хостах живут месяцами, и никакой CVSS скоринг этого не покажет, потому что скоринговать нечего - сканер не видит хост.

Бизнес-логика атаки проста: атакующему выгоднее эксплуатировать уязвимость на хосте, о котором никто не знает, чем бороться с EDR и SIEM на хостах из инвентаря. Shadow IT - не абстракция из презентаций. Это конкретный вектор initial access, через который проходят реальные инциденты.

NIST CSF v2.0 фиксирует это в ID.AM-01: инвентаризация аппаратных активов должна поддерживаться в актуальном состоянии. На практике «актуальное» означает непрерывную сверку, а не ежеквартальный экспорт из CMDB.

Asset discovery инфраструктуры: практический пайплайн​

Задача asset discovery - найти всё, что есть в инфраструктуре, до того как это найдёт атакующий. Не сканирование уязвимостей инфраструктуры - а именно discovery, отдельный этап, который кормит данными весь vulnerability management процесс.

Сетевое сканирование и облачные API​

Первый уровень - сетевое обнаружение. Masscan для быстрого SYN-скана крупных диапазонов, Nmap для точечного fingerprinting найденных хостов.
Masscan прожёвывает диапазон /8 за минуты, но выдаёт только открытые порты. Nmap добавляет версии сервисов и ОС - без этого сопоставление с базами CVE не работает. Выход в XML парсится и загружается в Tenable или Qualys через API. Можно использовать nmap2csv или написать свой парсер - формат стабилен.

Второй уровень - облачные API. Если часть инфраструктуры живёт в AWS или Azure, сетевой скан из on-prem не покроет все ресурсы. Нативные API дают полный список: aws configservice list-discovered-resources для AWS Config, az graph query -q "Resources" для Azure Resource Graph. Lambda-функции, S3-бакеты, управляемые базы - у них нет классического IP, Nmap их не увидит, но уязвимости в их конфигурациях есть.

Третий уровень - пассивное обнаружение через сетевой трафик. Решения вроде Tenable.ot или пассивных сенсоров на SPAN-порту видят устройства, которые активным сканированием трогать нельзя: OT-сегмент, медоборудование, legacy без поддержки. Для организаций с OT-инфраструктурой это не опциональный слой, а обязательный.

CMDB и управление активами: как найти shadow IT​

Когда данные из сетевого скана и облачных API собраны, нужно сравнить их с тем, что числится в CMDB. Расхождения и есть слепые зоны. Я использую Python-скрипт, который делает три вещи: парсит вывод Masscan/Nmap, забирает список активов из CMDB через REST API и выполняет diff.
Каждый хост из shadow_assets - потенциальная точка входа, которую vulnerability management процесс не покрывает. Дальше каждому shadow-хосту нужно присвоить владельца, уровень критичности и включить в scope сканера.

Частота сверки зависит от динамики инфраструктуры. Статичный дата-центр на 200 серверов - раз в неделю хватит за глаза. Kubernetes с auto-scaling groups - ежедневно. Облачные среды с Terraform-пайплайнами - при каждом деплое через CI/CD-хук.

Risk-based vulnerability management: за пределами CVSS​

Когда инвентарь полный и все активы попадают в scope сканера, возникает следующая проблема: на 5 000 хостов сканер выдаёт 40 000 CVE. Сортировка по CVSS сверху вниз - самый распространённый подход и самый бестолковый.

CVSS описывает уязвимость в вакууме. Балл 9.8 на CVE в RDP ничего не значит, если RDP закрыт на периметре и доступен только через VPN с MFA. А CVE с баллом 6.5 на публичном веб-сервере, которую прямо сейчас эксплуатируют ransomware-группировки, - это P1, который нельзя откладывать. По данным опроса Positive Technologies, всего 52% респондентов при приоритизации используют CVSS - остальные учитывают дополнительные факторы: влияние на бизнес-процессы, наличие публичных эксплойтов, метрики вендоров.

EPSS и CISA KEV в приоритизации патчей​

EPSS (Exploit Prediction Scoring System) от FIRST.org даёт вероятностную оценку от 0 до 1: какова вероятность эксплуатации CVE в ближайшие 30 дней. Модель обновляется ежедневно на основе данных об активных атаках, публикациях эксплойтов и активности в даркнете. По данным FIRST.org, лишь около 5% всех CVE имеют EPSS выше 0.1 - подавляющее большинство уязвимостей с высоким CVSS никогда не будут эксплуатироваться в реальных атаках. Вдумайтесь: 95% того, что сканер помечает красным, никто не будет ломать.

CISA KEV (Known Exploited Vulnerabilities) - каталог CVE с подтверждённой эксплуатацией в дикой природе. Если CVE есть в KEV - она идёт в топ очереди на ремедиацию независимо от CVSS-балла. Без вариантов.

На практике: после каждого цикла сканирования пропускаю результаты через фильтр EPSS + KEV. Это делается через API FIRST.org (api.first.org/data/v1/epss?cve=CVE-XXXX-YYYY) и публичный JSON-фид CISA. CVE с EPSS > 0.1 или присутствием в CISA KEV автоматически получают повышенный приоритет.

Критичность активов и бизнес-контекст​

Третий слой - контекст актива. Одна и та же CVE на dev-сервере в изолированном VLAN и на прод-сервере с платёжными данными - разные риски при одинаковом CVSS. Управление уязвимостями на основе рисков требует, чтобы каждому активу был присвоен уровень критичности.

Я использую четырёхуровневую классификацию:


Критичность определяется не ИБ-командой в одиночку. Бизнес-владельцы участвуют в классификации - они знают, какие системы генерируют выручку, хранят клиентские данные, обеспечивают производство. Без бизнес-контекста risk-based vulnerability management превращается в очередную CVSS-сортировку с косметическими надстройками. Я такое видел не раз: красивые дашборды, а под ними - та же голая девятка сверху вниз.

Сквозной пайплайн: гибридный скоринг и SLA​

Compensating controls (правило WAF, IP-ограничение, сегментация, отключение уязвимого сервиса) - временная мера, не закрытие тикета. Для каждого компенсирующего контроля фиксируется срок действия и триггер для повторного review.

Верификация и метрики​

Слово "исправлено" в тикете не закрывает уязвимость. Закрывает - повторный скан, подтвердивший устранение. Без верификации патч объявлен применённым, но конфигурация откатилась, пакет не обновился, зависимость осталась старой. Видел кейс, где apt upgrade прошёл, а сервис продолжал работать со старой библиотекой из /opt - потому что его собирали руками.

Ключевые метрики vulnerability management процесса:

• MTTR (Mean Time to Remediate) по классам P1/P2/P3 - от обнаружения до подтверждённого устранения
• Coverage - процент активов, покрытых сканированием, от общего числа в инвентаре
• SLA compliance - доля уязвимостей, закрытых в установленные сроки
• Shadow asset rate - процент хостов, обнаруженных при сверке, отсутствовавших в CMDB

Эти метрики - язык общения с CISO. Не "мы закрыли 500 CVE", а «MTTR для P1 снизился с 14 до 3 дней, coverage выросла с 78% до 96%».

Последние два года я строю подобные пайплайны в организациях разного масштаба - от 200 хостов до 15 000. Закономерность одна: большинство VM-программ ломается не на сканировании и не на приоритизации, а на стыке asset discovery и vulnerability management. Инвентарь неполный - сканер видит не всё - приоритизация работает на неполных данных - критические хосты остаются без патчей. CVSS, EPSS, CISA KEV, гибридные формулы - всё полезно, но всё бессмысленно, если 10% активов не попали в scope. Когда я защищал SLA по патчингу перед CISO одного клиента, ключевым аргументом стал не CVSS-рейтинг, а факт: на трёх непроинвентаризированных хостах жили CVE из CISA KEV с EPSS выше 0.9 - и жили там больше полугода. После этого бюджет на asset discovery перестали считать опциональной статьёй. Управление поверхностью атаки - не про алгоритмы скоринга. Это про полноту данных, на которых эти алгоритмы работают. Если attack surface management не начинается с актуального инвентаря - всё остальное просто красивые дашборды. Если хочешь повторить шаги - от сетевого recon до полного покрытия scope - на HackerLab (ХакерЛаб) есть лаба, где пайплайн нужно собрать самому.