Архив метки: CVSS

Первоначальные намётки по открытому фиду с уязвимостями - проект Vulrectory (пока пустой)

2 комментария

Первоначальные намётки по открытому фиду с уязвимостями - проект Vulrectory (пока пустой). По этому проекту хотелось бы в идеале получить обновляемый фид со всеми уязвимостями из NVD и БДУ, содержащий некоторые дополнительные поля, чтобы его можно было использовать как единственный источник данных в Vulristics. Сейчас если с помощью Vulristics приоритизировать, допустим, 100 CVE, то утилита будет делать запросы по каждой из этих CVE к различным источникам (как к бесплатным, так и к платному - Vulners), а затем комбинировать и анализировать данные. Таким образом, будут использоваться наиболее свежие данные, но генерация полного отчета займет довольно много времени. А за большое количество запросов бесплатные источники могут и побанить. Если же будет свой источник с уже подготовленными данными, который можно будет локально выкачать к себе, то можно будет запросто строить отчеты по десяткам тысяч уязвимостей без каких-либо внешних запросов. Сразу появится множество применений:

1. Оценка и приоритизация продетектированных уязвимостей (как для отдельных хостов, так и для инфраструктуры в целом!).
2. Оценка расхождений в результатах детектирования уязвимостей VM-продуктами и слепых пятен в базах знаний (детектов) VM-продуктов.
3. Vulnerability Intelligence - анализ всего входящего потока уязвимостей. Возможно с фокусом только на тех продуктах, которые используются в организации и без привязки к детектам в VM-решении.

В общем, как только можно будет работать с готовыми данными в оффлайне, всё сразу становится гораздо интереснее и удобнее. 😉

Какие дополнительные поля нужны Vulristics:

• Название уязвимого софта. Планирую переиспользовать детект продуктов по ключевым словам на основе описания CVE, который сейчас используется в Vulristics. Но лучше добавить ещё детект на основе CPE и парсинг генеренных описаний уязвимостей "имя софта> тип уязвимости>" (как у Microsoft). Также имя софта можно напрямую забирать из БДУ.
• Тип уязвимости. Планирую переиспользовать детект типа уязвимости по ключевым словам на основе описания CVE, который сейчас используется в Vulristics. Но лучше добавить ещё детектирование на основе CWE. Но это на крайний случай, т.к. к простановке CWE идентификаторов в NVD были вопросы.
• Наличие эксплоита. Если мы хотим, чтобы Vulrectory был бесплатным, то придется видимо ограничиться ссылками на эксплоиты из NVD и флажком "Наличие эксплойта" из БДУ. 🤷‍♂️ В Vulners их будет, конечно, гораздо больше (как вариант делать платную PRO версию?). Возможно есть какие-то открытые базы с признаками наличия эксплоитов на том же GitHub-е - нужно ресерчить.
• Признак эксплуатации вживую. Тут также видимо придется ограничиться бесплатным источником - CISA KEV и ресерчить наличие открытых источников по фактам эксплуатации.

В рамках этого же проекта можно для уязвимостей отображать не только CVSS, но и вектор/скор OSOKA (только Базовые и Эксплуатационные метрики, конечно). 🙂

В общем, пока какие-то такие мысли. Как вам?

VM-вендоры не умеют детектировать уязвимости, которые эксплуатируются шифровальщиками

1 комментарий

VM-вендоры не умеют детектировать уязвимости, которые эксплуатируются шифровальщиками

VM-вендоры не умеют детектировать уязвимости, которые эксплуатируются шифровальщиками. Прочитал отчёт "Index Update Q1 2023 RANSOMWARE Through the Lens of Threat and Vulnerability Management" по данным Securin и Ivanti. Товарищи анализируют информацию об уязвимостях, которые используются 356 шифровальщиками.

В отчёте утверждается, что есть 18 уязвимостей, эксплуатируемых шифровальщиками, которые не детектируются сканерами уязвимостей ТОПовых VM-вендоров (Tenable, Rapid7 и Qualys):

CVE-2010-1592
CVE-2012-3347
CVE-2013-0322
CVE-2013-2618
CVE-2013-3993
CVE-2015-2551
CVE-2015-7465
CVE-2017-15302
CVE-2017-18362
CVE-2017-3197
CVE-2017-3198
CVE-2017-6884
CVE-2019-16647
CVE-2019-16920
CVE-2019-5039
CVE-2019-9081
CVE-2020-36195
CVE-2021-33558

Эти уязвимости эксплуатируются 59 группировками шифровальщиков, среди которых Hive, Qlocker, QNAPCrypt и UEFI.

От меня: когда я призываю к открытости баз знаний VM-вендоров, я имею ввиду именно это. Любой VM-вендор умеет детектировать только часть из всех известных уязвимостей. Кто может сказать, что тех уязвимостей, которые он умеет детектировать, достаточно и в его слепой зоне точно нет ничего критичного? Вот имеем пример, когда исследователи, получив доступ к базам знаний (детектов) VM-вендоров, подтвердили проблему с полнотой. И это мы берём самый-самый топ критичных уязвимостей и самых крутых международных VM-вендоров.

Разумеется, сравнение по детектируемым CVE идентификаторам это далеко не идеальный способ обнаружить проблемы с полнотой, но это простой способ и какое-то представление он даёт. Поэтому, призываю всех пушить отечественных VM-вендоров, чтобы информация о детектируемых уязвимостях была публичной и общедоступной для стороннего анализа. Ну или хотя бы доступной регуляторам, чтобы регуляторы сами контролировали адекватность баз знаний (детектов) VM-вендоров.

В отчёте также есть критика CVSS, NVD и CISA KEV из-за некорректного учёта эксплуатируемых шифровальщиками CVE:

• 30% CVE не имеют CVSS v2 или v3 в NVD
• 2 CVE имеют severity Low, 57 Medium в NVD
• 2 CVE находятся в статусе Rejected в NVD (CVE-2015-2551 и CVE-2019-9081)
• только 68% CVE содержатся в CISA KEV, требуется добавить ещё 131

Первоначальные намётки по ОСОКА

5 комментариев

Первоначальные намётки по ОСОКА. 🙂 Думаю должно быть три группы метрик:

▪️Базовые
▪️Эксплуатационные
▪️Инфраструктурные

1. Базовые метрики будут ровно такие же как в CVSS v3.0/3.1. Почему? Это текущий стандарт, использующийся с 2015 года. Для большей части уязвимостей из NVD можно будет взять CVSS v3 Base вектор как он есть. Для уязвимостей, у которых доступен только CVSS v2 Base вектор есть более-менее рабочие способы конвертации в v3, которые можно будет взять за основу. Когда CVSS v4 появится в NVD, проблемы с конвертацией v4->v3 будут только из-за исключения метрики Scope, её придется как-то генерить, скорее всего из Impact Metrics для Subsequent Systems (но это неточно). Также для User Interaction будет 3 значения, а не два, но это тривиально схлопывается. В общем, оставаться на базовых метриках полностью повторяющих CVSS v3 нам должно быть достаточно комфортно.

2. Эксплуатационные предлагаю сделать такие:

Exploit Maturity: Not Defined (X), High (H), Functional (F), Proof-of-Concept ℗, Unreported (U) - эту штуку можно заполнять через анализ баз эксплоитов/малварей и получать из CVSS Temporal вектора некоторых вендоров (например Microsoft).

Exploitation Activities: Not Defined (X), Reported ®, Unreported (U) - это можно заполнять на основе баз отслеживающих эксплуатацию типа CISA KEV или AttackerKB. Фактов эксплуатации in the wild никогда не было в CVSS и не будет в 4.0 - преимущество ОСОКи. 😉

Exploitation Probability: Not Defined (X), High (H), Medium (M), Low (L) - это можно заполнять на основе EPSS. Я думаю, что EPSS пока ещё полный шлак, но возможно такие системы скоро станут гораздо лучше и неплохо бы заранее их поддержать.

Кажется с такими метриками по эксплуатации можно будет не упахиваться ручным описанием и получить приоритизацию с учётом того, что нужно зафиксить ASAP.

3. Инфраструктурные думаю лучше взять ровно как в методике ФСТЭК, чтобы повысить шансы на официальное признание. 😉 Кроме того, они в принципе неплохие. Во всяком случае всяко лучше абстрактного CVSS Environmental. Хотя и придется все активы покрыть VM-процессом и знать об активах хотя бы их тип и доступность на периметре.

Тип компонента информационной системы, подверженного уязвимости
- Не определено
- Компоненты ИС обеспечивающие реализацию критических процессов (бизнес-процессов), функций, полномочий
- Серверы
- Телекоммуникационное оборудование, система управления сетью передачи данных
- Рабочие места
- Другие компоненты

Количество уязвимых активов
- Не определено
- Более 70%
- 50-70%
- 10-50%
- Менее 10%

Влияние на эффективность защиты периметра системы, сети
- Не определено
- Уязвимое программное, программно-аппаратное средство доступно из сети «Интернет»
- Уязвимое программное, программно-аппаратное средство недоступно из сети «Интернет»

Конечно, нужно будет конкретные формулировки подправить, чтобы было единообразна с другими метриками, а подробности убрать в руководство по заполнению, но по смыслу должно быть ровно так как в методике ФСТЭК.

Как вам?

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0?

4 комментария

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0?

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0? Мне это тоже интересно.

Имхо, CVSS это не священная корова и держаться за него не стоит:

1. CVSS это результат заполнения довольно сомнительного и субъективного опросника. То, что у ресерчера, вендора и у NVD не совпадают CVSS для одной и той же уязвимости это норма.
2. CVSS v2, v3 и v4 несовместимы между собой. Сейчас в NVD есть уязвимости без CVSS, только с v2, с v2 и с v3, только с v3. Будьте уверены, что переход на v4 зоопарк усугубит. Нужно ли это и в БДУ тянуть?
3. Положа руку на сердце, кто при приоритизации уязвимостей полагается исключительно на CVSS? Это один из факторов. И не самый важный. Основная ценность CVSS, что Base метрики предоставляются NIST-ом открыто и бесплатно. А Temporal метрики никто не предоставляет, поэтому их и не используют. Не говоря уж об Environmental, которые надо самим заполнять.

Поэтому я бы рекомендовал не переходить на CVSS v4, а сделать следующее:

1. Создать свой опросник с калькулятором а-ля CVSS. Также с векторами (записываемыми в строчку) и скорами. Назвать как-нибудь оригинально, например "Общая Система Оценки Критичности Автоматизируемая" (ОСОКА). 😉 Какой конкретно это должен быть опросник - предмет отдельного обсуждения. Я бы делал его максимально простым и кратким, пусть даже в ущерб точности оценки. Лишь бы базовый скор явно критичных уязвимостей был около 10, а явно некритичных был около 0. Инфраструктурный компонент из методики оценки критичности уязвимостей также учесть в ОСОКА (сделать как в Environmental метриках CVSS).
2. САМОЕ ГЛАВНОЕ! Выпустить методические указания как использовать CVSS v2, v3, v4 в качестве входящих данных для получения вектора ОСОКА. Очень желательно, чтобы базовая часть ОСОКА автоматом получалась из Base метрик CVSS v2, v3, v4, иначе скорее всего это не взлетит.
3. В перспективе заменить все упоминания CVSS и методику оценки критичности уязвимостей ФСТЭК на ОСОКА.

8 июня прошло и появились подробности по CVSS 4.0 (PUBLIC PREVIEW)

3 комментария

8 июня прошло и появились подробности по CVSS 4.0 (PUBLIC PREVIEW)
8 июня прошло и появились подробности по CVSS 4.0 (PUBLIC PREVIEW)8 июня прошло и появились подробности по CVSS 4.0 (PUBLIC PREVIEW)

8 июня прошло и появились подробности по CVSS 4.0 (PUBLIC PREVIEW). На картинках сравнение с v3, полный вид калькулятора. Уже доступно много чтива, для тех, кому интересно разобраться в деталях. 🧐

➕ Calculator
📔 Specification
📓 User Guide

Не успели решить что же делать с необходимостью откуда-то брать Temporal и Environmental метрики CVSS 3 (3.1) для оценки критичности по ФСТЭК, как грядет CVSS 4.0, где всё переделали

2 комментария

Не успели решить что же делать с необходимостью откуда-то брать Temporal и Environmental метрики CVSS 3 (3.1) для оценки критичности по ФСТЭК, как грядет CVSS 4.0, где всё переделалиНе успели решить что же делать с необходимостью откуда-то брать Temporal и Environmental метрики CVSS 3 (3.1) для оценки критичности по ФСТЭК, как грядет CVSS 4.0, где всё переделали

Не успели решить что же делать с необходимостью откуда-то брать Temporal и Environmental метрики CVSS 3 (3.1) для оценки критичности по ФСТЭК, как грядет CVSS 4.0, где всё переделали. 😅 Доступно краткое описание изменений и более детальная презентация. На скрине калькулятора не показали групп Temporal (теперь называется Threat) и Environmental, но они остались в несколько измененном виде. Новая Supplemental Metric Group не влияет на общий расчёт скора CVSS-BTE (Base + Threat + Environmental). Ждем подробностей после 8 июня.

Про CVE_Prioritizer и Vulristics

Добавить комментарий

Про CVE_Prioritizer и Vulristics

Про 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! 🙂