По наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от Nucleus. Товарищи взяли CISA KEV и добавили туда данные EPSS (Score и Percentile), CVSS из NVD, а также Treat Intelligence фид от GreyNoise. Вроде ничего хитрого, но получилось занимательно.

1. Самое очевидное это то, что можно дополнительно приоритизировать уязвимости из CISA KEV для исправления.
2. С другой стороны здесь наглядно видны проблемы источников.
2.1. Если уязвимость эксплуатируется вживую, то почему эту эксплуатацию GreyNoise не видит? С одной стороны это может быть связано с ограничением фида GreyNoise - не по всем уязвимостям могут эксплуатацию отслеживать. С другой стороны это может быть связано с тем, что CISA берет признак эксплуатации от вендора, по факту это может быть "вероятная эксплутация в единичной таргетированной атаке в полнолуние и пятницу 13-е", а подробностей нет и не будет.
2.2. Вот Exploit Prediction Scoring System (EPSS) показывает "probability [0-1] of exploitation in the wild in the next 30 days (following score publication)". Весьма весело взять уязвимости "CVE-2022" с детектами от GreyNoise и увидеть, что EPSS для них вероятность появления эксплоита оценивала довольно низко. Выделил на скриншоте < 20%. Иногда оценка даже в 1-2%, как например в случае с одной из уязвимостей Exchange ProxyNotShell. В общем, EPSS это далеко не серебряная пуля.
2.3. Также интересно посортировать по CVSS. Сразу вылезают проблемы с уязвимостями, которых нет в NVD. Проблемы сортировки в таблице (но это ладно). А самое интересное уязвимости с CVSS < 7, т.е. меньше High. В данном случае укладываются в Medium. То есть горячий привет тем, кто жестко фильтрует по CVSS от High и выше.

@avleonovrus #CISA #CISAKEV #EPSS #GreyNoise #ProxyNotShell #Exchange #NVD #Nucleus

Вышла третья итерация Exploit Prediction Scoring System (EPSS). Пишут, что стала на 82% круче. Есть довольно прикольная и подробная статья про изменения. Например, EPSS-ники начали анализировать не 16 свойств уязвимостей, а аж 1164. Есть подозрение, что большая часть этих свойств это лейблы вендоров, как в таблице. Но выяснять как оно конкретно работает дело всё равно малоперспективное, потому что "а внутри у ней нейронка" (c). В целом, по запутанности уже похоже на Tenable VPR. Но бесплатность всё искупает. 😇 Кстати, в статье упоминают Tenable VPR и прочие коммерческие скоры и критикуют их за проприетарность, публичную недоступность и то, что они частично базируются на экспертном мнении, а не только на данных.

Поглядел выгрузку EPSS на примерах.
1. Для RCE уязвимости Word-а (CVE-2023-21716) с недавним PoC-ом EPSS очень высокий (0.16846,0.95168).
2. Для SPNEGO (CVE-2022-37958), для которого эксплоит ожидается в Q2, EPSS тоже высокий (0.07896,0.93195).
3. Для рандомной уязвимости MS Edge (CVE-2023-0696) из февральского MS Patch Tuesday (их десятки каждый месяц), EPSS низкий (0.00062,0.24659)
4. Взял наоборот уязвимость с высоким EPSS из выгрузки - CVE-2023-0297 (0.04128,0.90834). Тоже понятно почему, там ссылка на эксплоит прямо в NVD.

На первый взгляд всё вполне адекватно. 👍

То есть делать приоритизацию исключительно на основе EPSS я бы не советовал, но использовать как дополнительный фактор с весом как у CVSS Base Score (а возможно и повыше) выглядит вполне оправданным. Совсем без причины эта цифирь вверх вряд ли поползет, если она идёт к 0.9 и выше имеет смысл поглядеть на уязвимость повнимательнее. Подумываю начать учитывать EPSS в Vulristics. 😉

@avleonovrus #EPSS #TenableVPR #Tenable #Vulristics

Добавил учёт EPSS в Vulristics. EPSS стал ещё одним источником данных, т.е. команда для анализа набора CVE будет выглядеть так:

$ python3 vulristics.py --report-type "cve_list" --cve-project-name "New Project" --cve-list-path "analyze_cve_list.txt" --cve-comments-path "analyze_cve_comments.txt" --cve-data-sources "ms,nvd,epss,vulners,attackerkb" --rewrite-flag "True"

Добавление нового источника задача несложная. Сделал по аналогии с NVD. Однако возник вопрос: какое именно значение EPSS использовать. Было 2 варианта:

1. Probability - вероятность наблюдения эксплуатации уязвимости в течение следующих 30 дней ("probability of observing exploitation activity in the next 30 days").

2. Percentile - значение показывающее насколько вероятность наблюдения эксплуатации данной CVE уязвимости больше чем для всех других CVE уязвимостей. Например, вероятность EPSS, равная всего 0,10 (10%), находится примерно на уровне 88-го процентиля, что означает, что 88% всех CVE имеют более низкую оценку ("For example, an EPSS probability of just 0.10 (10%) rests at about the 88th percentile — meaning that 88% of all CVEs are scored lower").

В итоге опытным путем пришел к тому, что Probability слишком малы, а также мало различаются, поэтому лучше использовать Percentile.

Я перегенерил отчет для апрельского MS Patch Tuesday.

1. Старый отчет без EPSS
2. Новый отчет с EPSS

Выглядит довольно неплохо, но со странностями. Так наиболее критичная Elevation of Privilege - Windows Common Log File System Driver (CVE-2023-28252), которая присутствует в CISA KEV почему-то имеет очень низкий EPSS. 🤷‍♂️ Поэтому результат нейронки это, конечно, хорошо, но здравый смысл терять не нужно. 😉

@avleonovrus #EPSS #Vulristics #PatchTuesday #Microsoft #CLFS

Выпустил блогопост и видяшку по последним новостям Vulristics для англоязычного канала и блога.

00:00 EPSS v3
02:54 Поддержка EPSS v3 в Vulristics
05:12 Интеграция Vulristics в Cloud Advisor

Video: https://youtu.be/kWX_64wNxbg
Video2 (for Russia): https://vk.com/video-149273431_456239122
Blogpost: https://avleonov.com/2023/04/24/vulristics-news-epss-v3-support-integration-into-cloud-advisor/

@avleonovrus #Vulristics #EPSS #CLFS #CloudAdvisor #CSPM #Microsoft #PatchTuesday #Tenable #TenableVPR

Ещё раз про EPSS Probability и EPSS Percentile. В одной соцсеточке для профессионального общения от компании Microsoft меня увещевают отказаться от ереси и все-таки использовать EPSS Probability в Vulristics вместо EPSS Percentile. 🙂 Кажется имеет смысл продолжить тему.

1. Про разницу между Probability и Percentile, как их понимать и интерпретировать, есть подробная статья на официальном сайте. Вопрос: можно ли как-то получить из EPSS уровни критичности а-ля CVSS Base Score. Ответ: нет, нельзя. "По этим причинам EPSS в настоящее время не группирует результаты EPSS с использованием ярлыков" ("For these reasons, EPSS does not currently bin EPSS scores using labels"). В своём праве.

2. То, что они генерят в виде EPSS Probability, "вероятности эксплуатации", это просто очень маленькие цифири из нейронки, которые непонятно как сравнивать адекватно. Они даже в тех примерах, которые я рассматривал, маленькие. EPSS-ники сами об этом пишут в статье "Например, как пользователи должны интерпретировать общую важность (overall importance) уязвимости с вероятностью 0,212? Или, по-другому, как мы должны думать о сравнении относительной разницы в угрозе между вероятностью 0,115 и 0,087? Да, одна больше другой, но насколько больше? Насколько велика разница в угрозе первой уязвимости по сравнению со второй?" Для прошлого Patch Tuesday EPSS Probability для всех уязвимостей, была между 0 и 0.2 (0-20%). Даже для уязвимостей с отмеченной эксплуатацией в CISA KEV! Это с каким же весом мне надо брать эти значения, чтобы они хоть как-то влияли на итоговый скор? 🙂

3. Ну да, EPSS Percentile это результат ранжирования уязвимостей по EPSS Probability, величина искусственная и зависит от общего числа CVE. И она меняется со временем, так же как и EPSS Probability. Ну так и в чем проблема? EPSS Percentile это тоже какая-то искусственная величина из нейронки полученная. По EPSS Percentile хотя бы видно как эта нейронка оценивает конкретную уязвимость относительно всех остальных. То, что нам собственно и надо. 😉 И тут более-менее понятно, есть 0.8-1, то критично, а если 0-0.2 это фигня какая-то. Ну, в идеале. Потому что на практике, как я уже подсвечивал, бывают странности.

@avleonovrus #EPSS #EPSSProbability #EPSSPercentile

Про CVE_Prioritizer и Vulristics. Несколько раз за последние месяцы натыкался на посты про CVE_Prioritizer. Но сегодня появился повод прокомментировать.

"CVE_Prioritizer is a powerful tool that helps you prioritize vulnerability patching by combining CVSS, EPSS, and CISA's Known Exploited Vulnerabilities. It provides valuable insights into the likelihood of exploitation and the potential impact of vulnerabilities on your information system."

Прикольная утилита, но, имхо, мой Vulristics приоритизирует покруче. 🙂 Он учитывает не только CVSS, EPSS и CISA KEV, но и тип уязвимости, распространенность софта, информацию об эксплоитах (из многих паков на Vulners) и атаках из AttackersKB.

И CVE_Prioritizer, и Vulristics для каждой уязвимости в динамике выполняют запросы к внешним источникам. Только у CVE_Prioritizer таких источников только 2 и поэтому он отрабатывает быстрее. Кроме того, Vulristics каждый раз в динамике определяет наименование софта и тип уязвимости по описанию. Это медленная операция. А в случае использования Vulners в качестве источника, всё это ещё и стоит денег 💸 (хотя лично мне не стоит, т.к. у меня ресерчерская лицензия - спасибо ребятам из Vulners!❤️). Так что с помощью Vulristics достаточно удобно оценивать 100-200 уязвимостей за раз (как в MS Patch Tuesday), а оценивать больше не особо рационально. 🙁

Что с этим можно сделать? Если заранее формировать полный (и желательно бесплатный/общедоступный 😉) фид по всем уязвимостям, чтобы Vulristics строил отчёт по готовым данным, это было бы гораздо быстрее и эффективнее. В этом случае можно было бы приоритизировать уязвимости хоть для всей инфраструктуры разом. У меня есть в некоторых долгосрочных планах этим заняться. Кто хочет поучаствовать - всегда welcome! 🙂

@avleonovrus #CVEPrioritizer #Vulristics #Vulners #CVSS #EPSS #CISAKEV

По итогам выступления на Positive Customer Day. Всё прошло вполне удачно. Спасибо большое коллегам из Positive Technologies за приглашение! Кажется это был мой первый доклад на "бумажную" тему. Хоть я, в основном, делал акценты на технические сложности при реализации методик, но всё равно. Оказалось, что у "бумажных" докладов своя специфика. Были вопросы в духе: почему регулятор написал документ так, а не иначе? Почему он что-то учёл, а что-то решил не учитывать? Зачем регулятор вообще выпустил тот или иной документ? Раньше я с таким не сталкивался и даже впал в лёгкий ступор. Можно, конечно, что-то фантазировать на эту тему, но такие вопросы явно не по адресу. 😅

В целом же, по итогам Q&A для себя сформулировал следующее:

1. В методику оценки критичности уязвимостей неплохо было бы добавить учёт использования уязвимости в реальных атаках (аналог CISA KEV) и вероятности появления эксплоита для неё (аналог EPSS)
2. В руководство по построению процесса управления уязвимостями было бы неплохо добавить:
2.1. Требования к актуальности данных об обнаруженных уязвимостях, например максимально допустимую периодичность сканирования. Не должно быть возможности сканировать раз в квартал и делать какие-то выводы на основе этого.
2.2. Требования к полноте покрытия активов. Не должно быть активов (хостов, софтов, сетевых устройств и т.д.), которые не покрываются средствами детектирования уязвимостей. Должен быть какой-то процесс подтверждения, что VM-решение умеет детектировать уязвимости для всех активов в организации. Если есть какой-то актив, для которого автоматическое детектирование уязвимостей не производится, нужно с этим что-то делать. Как минимум подсветить.
2.3. Требования к оценке качества детектирования уязвимостей. Ситуация, когда несколько средств детектирования анализируют один и тот же актив и выдают совершенно разные наборы уязвимостей ненормальная. Если так происходит, значит в каких-то решениях реализована неправильная логика и такие решения нельзя использовать в процессе управления уязвимостями ("мусор на входе - мусор на выходе"). Следует ли из этого, что должен быть процесс сертификации средств детектирования уязвимостей, такой как для PCI ASV или SCAP сканеров? Возможно.

Ещё в выступлении я, среди прочего, позволил себе предположить, что подход Positive Technologies к VM-у (который я лично всячески поддерживаю), предполагающий процесс регулярного безусловного патчинга инфраструктуры не особенно сочетается с руководством ФСТЭК по построению процесса управления уязвимостями, т.к. это руководство требует тестирования обновлений для open-source и нероссийского софта по методике ФСТЭК перед установкой. Т.е. процесс регулярного безусловного патчинга может и быть, но кажется момент с тестированием обновлений должен быть определен: тестируем/не тестируем, если тестируем, то чьими силами и в каком объёме.

@avleonovrus #PositiveTechnologies #PCDay #FSTEC #ФСТЭК #CISA #CISAKEV #EPSS #SCAP #PCIASV

Американская микроблоггинговая площадка с птичкой перестаёт быть местом для сбора релевантной инфы по CVE-шкам.

1. В конце июня - начале июля количество сообщений с CVE сократилось с 1272 в рабочий день до 333 в рабочий день. А если не считать ботов, то, в среднем, с 500 в день до 66 в день. Видимо ИБ-шники куда-то мигрировали. Хотя возможно и просто сезонное.
2. Возможность бесплатного экспорта сообщений (в т.ч. с CVE-шками) убрали. 🤷‍♂️

Имхо, это очень даже позитивно. Нечего пользоваться замусоренными мейнстримными соцсеточками для обсуждения ИБ-вопросов, нужно формировать что-то специализированное, а-ля Peerlyst.

@avleonovrus #CVE #microblogging #Cyentia #EPSS #Peerlyst

Идея на миллион хамстер-коинов. 🐹😅 Делаем сайт/апп, на котором можно тапать CVE-шки. Но тапать будет иметь смысл не все CVE, а только те, у которых в течение следующей недели должен появиться подтверждённый эксплоит или признак эксплуатации вживую.

🪙 Когда такой признак или эксплоит действительно появляется, отсыпать коинов тем, кто за последнюю неделю тапал на эту уязвимость. Соразмерно количеству тапов, критичности уязвимости и т.п.

📈 А на основе анализа этих тапов делать прогнозы по эксплуатабельности уязвимостей. С помощью AI естественно.

Уверен, что работать такое будет всяко лучше EPSS и гадалкам по соцсетям. 😅

@avleonovrus #joke #fun #CVE #hype #prioritization #EPSS #hamster #crowdsourcing

У Tenable вышел пресс-релиз по поводу новой версии Nessus 10.8.0. Сама версия, правда, вышла 30 июля, PR-щики не особо спешили. 🙂 Самое заметное изменение - теперь для уязвимостей помимо CVSS и собственного скора Tenable VPR отображается ещё и скор EPSS (Exploit Prediction Scoring System).

Выглядит занимательно, но я как относился к EPSS со скепсисом, так и отношусь. Исследование от Cyentia (можете у Александра Редчица посмотреть), меня не убеждает. 🤷‍♂️ Хайпа много, а результаты как на иллюстрации: VPR высокий, а EPSS низкий. И тут либо фирменная проприетарная система приоритизации от Tenable косячит, либо EPSS. 😎

Ещё в Nessus добавили поддержку CVSS v4, добавили возможности по настройке агентов (в Nessus Manager), доработали offline режим (убрали трафик, генерируемый функциями, которые полагаются на активное подключение к Интернету). Востребованность оффлайн режима после 22-го значительно возросла (ЕВПОЧЯ 😉), можно только поприветствовать улучшения. 👍

@avleonovrus #Tenable #VPR #Nessus #EPSS #CVSSv4