
Что такое трендовые уязвимости
В управлении уязвимостями под трендовыми уязвимостями чаще всего понимают не уязвимости с высоким CVSS, а сигнал о том, что уязвимость активно эксплуатируется в реальных атаках. При этом не важно когда уязвимость была опубликована, важна активность.
Трендовые уязвимости желательно учитывать ежедневно, так как в инфраструктуре почти всегда есть технический долг: пока устраняются уязвимости с CVSS High, реальная атака приходит через активно эксплуатируемую Medium. Именно поэтому трендовые уязвимости должны попадать в приоритизацию отдельно, а не конкурировать в общей очереди по риску CVSS.
В статье я опишу, как я обогатил и интегрировал каталог уязвимостей CISA KEV в свою VM платформу, а так же приведу результаты исследования — сравнения трендовых уязвимостей CISA с одним из самых известных вендоров VM платформ.
Что такое CISA KEV
CISA KEV (US Cybersecurity and Infrastructure Security Agency Known Exploited Vulnerabilities Catalog) — это каталог уязвимостей, по которым есть подтвержденная активность эксплуатации. Для аналитиков такая уязвимость это авторитетный сигнал эксплуатации, основанный на поведении злоумышленников.
В каталоге KEV для каждой записи есть:
CVE ID
дата добавления в каталог (когда сигнал стал актуальным)
описание и рекомендации по устранению
дедлайн (due date) для федеральных агентств США (полезный ориентир срочности)
дополнительные заметки (в т.ч. про кампании)
Информация об активно эксплуатируемых уязвимостях очень полезна для SOC, так как предоставляет следующие возможности:
threat hunting - где искать компрометацию и какие сценарии проверять;
понимания какие активы сейчас под риском;
более целенаправленная приоритизация по факту;
оптимизация мониторинга - целенаправленное усиление детекта и логирования на уязвимых активах.
Про мультивендорность и когда экспертизы одного вендора может быть недостаточно
Большинство современных VM-платформ и сканеров могут иметь собственные данные о трендовых уязвимостях. У вендора так же бывает своя внутренняя аналитика(threat & vulnerability intelligence). И это действительно полезно, но на практике сигналы вендора и CISA KEV не обязательно совпадают.
В США многие вендоры VM решений активно обогащают свои платформы данными из CISA KEV, по здравому смыслу и требованиям регуляторов и публично заявляют об этом. Я думаю это так же является и конкурентным преимуществом для их платформ.
В СНГ и ряде других стран это не так и далеко не все вендоры активно заявляют, что включено и откуда поступают трендовые уязвимости.
Несмотря на то что тренд эксплуатации уязвимостей может теоретически о��личаться по странам, я считаю, что так или иначе фаза активной эксплуатации может мигрировать из региона в регион, с течением времени. При этом пик инцидентов успешной эксплуатации придется скорее на те регионы, где атаки проводились в первую очередь.
Если брать страны, где по определенным причинам(финансы и политика) отсутствует возможность своевременного патчинга, то там этот временной лаг не сыграет большой роли, так как даже при выходе патча от вендора уязвимого продукта, обновление может быть затруднено и пик "true positive" инцидентов с эксплуатацией может сравняться.
Поэтому рациональная стратегия для любого SOC это дополнять сигналы VM-платформы независимыми авторитетными источниками эксплуатации по максимому.
Далее в статье я сознательно рассматриваю VM-платформу как Vendor VM и не ставлю задачу оценивать качество коммерческих VM-платформ, а сравниваю покрытие сигналов активно эксплуатируемых уязвимостей.
Варианты интеграции CISA KEV и обогащение данными VM
Варианты интеграции у каждого могут быть свои. Я решил нарисовать простую схему.

В моем подходе я использую вариант справа. В качестве источников я беру выгрузку файла CISA KEV и выгрузку уязвимостей с пометкой как трендовые из VM-платформы.
Моя интеграция в общих чертах выглядит следующим образом:
Скрипт скачивает по API перечень уязвимостей из VM платформы.
Скрипт скачивает KEV файл с официального ресурса CISA.
Проводится нормализация, парсинг и объединение данных с условием по идентификатору CVE.
Проставляется приоритет к каждой уязвимости по условию: если уязвимость трендовая по данным вендора и/или CISA, то приоритет ставится повышенный.
Тут стоит отметить на третьем этапе следует учесть идентификатор еще и BDU так как бывают уязвимости с отсутствующим CVE. Аналогично не все CVE имеют BDU.
Исследование эффективности и результаты интеграции
Исследование и проверка эффективности это пожалуй была самая интересная для меня часть. Цель была проверить, что даст интеграция CISA KEV в моем случае. В целом те же показатели будут верны и для многих других, кто полагается только на тренды от вендора.
Я выделил ряд показателей и рассчитал статистику в JupyterLab на python и pandas, и отобразил результаты в виде графиков с помощью библиотеки matplotlib. В качестве данных я использовал, выгруженный CISA KEV в csv формате и выгруженный перечень трендовых уязвимостей из коммерческого VM решения.
Более подробно исследование можно посмотреть по ссылке на Jupyter Notebook в GitHub.
Хочу сразу отметить, что графики строились по тем данным, которые были в каталогах и у меня в итоге были сомнения, что даты классификации уязвимости в тренд, являются действительными, тем не менее объективно по количеству можно делать выводы.
Охват трендовых уязвимостей(Trending Vulnerability Awareness Coverage) - показатель, который отражает, сколько трендовых уязвимостей видит каждый источник по месяцам:

Интерпретация результатов:
Синие сегменты (KEV-added) стабильно превышают красные (Vendor VM) на протяжении большинства месяцев. Это указывает на то, что значительная часть реально эксплуатируемых уязвимостей выявляется через CISA KEV, но не попадает в трендовые сигналы VM-платформы.
После пикового периода вклад KEV сохраняется на стабильном уровне и не исчезает со временем.
Даже в те месяцы, когда Vendor VM фиксирует трендовые уязвимости, CISA KEV продолжает добавлять значимое количество реально эксплуатируемых CVE. Это подтверждает, что KEV не д��блирует сигналы вендора, а выступает независимым и авторитетным источником информации об эксплуатации.
Накопительный охват трендовых уязвимостей(Cumulative Trending Vulnerability Awareness Coverage) - показатель, который отражает, сколько трендовых уязвимостей накапливает каждый источник во времени:

Тут Custom Priotitization учитывает пересечения одинаковых CVE между CISA KEV и вендором, и отражает обогащение уникальными CVE от CISA KEV(+1282 уязвимости).
Интерпретация результатов:
CISA KEV стабильно выявляет больше трендовых уязвимостей, чем VM-платформа вендора. Синие сегменты (Total CISA KEV) превышают красные (Total Vendor VM) на протяжении большинства месяцев, что указывает на то, что значительная часть реально эксплуатируемых уязвимостей обнаруживается через CISA KEV, но не отражается в трендовых сигналах VM-платформы.
Добавленная ценность KEV сохраняется во времени, а не ограничивается пиковыми периодами. После начального всплеска вклад KEV остается стабильным, подтверждая, что его значимость носит устойчивый, а не разовый характер.
KEV предоставляет независимую информацию об эксплуатации, а не дублирует сигналы вендора. Даже в те месяцы, когда VM-платформа фиксирует трендовые уязвимости, CISA KEV продолжает добавлять дополнительные реально эксплуатируемые CVE. Это подтверждает, что KEV выступает авторитетным и независимым источником сигналов об эксплуатации.
Скорость классификации трендовых уязвимостей(Trending Vulnerability Classification Speed) - показывает как быстро разные источники классифицируют уязвимость как трендовую. Это обобщенная метрика, но по ней можно предположить какой источник классифицирует уязвимость в тренд раньше.
Входе сравнения анализировались только те уязвимости, которые присутствуют в обоих источниках. На момент сравнения их было 204.
Лимит лага(задержки) установлен в +-180 дней.
Сравнивалась не абсолютная скорость реакции, а относительная CISA KEV | Vendor VM, то есть кто раньше классифицировал одну и ту же CVE как трендовую.


Лаг дней = Дата классификации в тренд Vendor VM - Дата классификации в тренд CISA KEV
Как трактовать точку на ECDF графике:
Если при x=10 график показывает y=0.7, это значит: 70% наблюдений ≤ 10.
Y = 0.6 - 60% уязвимостей имеют lag ≤ X, Y = 1.0 - 100% уязвимостей имеют lag ≤ X
Чем больше X (правее) - тем раньше KEV
Чем меньше X (левее) - тем раньше Vendor
X = 0 - одновременно
Распределение лага показывает, что CISA KEV в большинстве случаев выявляет трендовые уязвимости не позже, а зачастую раньше VM-платформы. ECDF подтверждает, что преимущество CISA KEV носит системный характер и проявляется на уровне частоты случаев, а не только отдельных выбросов. Мои сомнения в точности временных меток VM-платформы не позволяют корректно интерпретировать абсолютные значения лага.
Среднее время классификации трендовых уязвимостей(Mean Time to Trending Classification (MTTC)) - среднее время от публикации CVE до момента, когда она становится трендовой в источнике.
Входе сравнения анализировались только те уязвимости, которые присутствуют в обоих источниках и с датой огласки в выгрузке из cve.org. На момент сравнения их было 171.
Стоит отметить, что часть уязвимостей публиковались от 2017 года — до того как стали формироваться каталоги трендовых уязвимостей. Поэтому цифры тут скорее субъективны.

MTCC = (Дата классификации в тренд - Дата огласки уязвимости CVE disclosure).mean()
Это более понятная метрика, тут чем меньше MTTC тем быстрее источник помечает ее как активно эксплуатируемую.
Меньше времени на классификацию дает оперативность в реагировании на угрозы.
По суммарным результатам в днях виден заметный эффект от такой интеграции - 69 дней против 95 от вендора и против 169 от CISA KEV. Обогатив экспертизу от двух источников получаем выше оперативность и как итог более эффективную возможность для реагирования на угрозы.
Итоговый результат
Интеграция CISA KEV дала примерно 4.1x (>400%) увеличение “осведомленности” относительно vendor-only решения.
Такая интеграция обеспечивает наименьшее среднее время классификации уязвимостей как трендовые в своей инфраструктуре за счет использования самого раннего, доступного сигнала.
Построив новую веб-панель и обогатив экспертизу появилась возможность замечать и отслеживать значимые уязвимости и пересматривать их политику. Например, среди трендовых уязвимостей могут попадаться и те, что были исключены из процесса на устранение и этот сигнал можно использовать для пересмотра статуса.

Интеграция CISA KEV в систему управления уязвимостями это практичный способ добавить в приоритизацию авторитетный сигнал реальной активной эксплуатации, который полезен не только для VM-отчетности, но и для SOC-процессов: от hunting до оперативного контроля экспозиции.
Даже если вендор коммерческой VM платформы предоставляет собственные индикаторы тренда и threat intel, каталог CISA KEV способен выступать дополнительным и независимым источником, который повышает покры��ие эксплуатируемых угроз и делает процесс приоритизации надежнее.
В конце хочется отметить, что требования и методические документы в РФ, как правило, не описывают стандартизированный механизм приоритизации на основе информации об активно эксплуатируемых уязвимостей. Было бы неплохо, если бы ФСТЭК помечала у себя в BDU отдельным списком или атрибутом признак того, что уязвимость активно эксплуатируется в Интернет, а так же учли это в рекомендациях по приоритизации как это делает CISA. Так же было бы здорово иметь возможность скачивать перечни угроз в форматах json и csv.
