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

Алексей Лукацкий вкинул сегодня вопрос: "Почему вендора, делающие вклад в развитие CVSS, сами его не используют, стараясь придумать что-то свое?"

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

Алексей Лукацкий вкинул сегодня вопрос: Почему вендора, делающие вклад в развитие CVSS, сами его не используют, стараясь придумать что-то свое?

Алексей Лукацкий вкинул сегодня вопрос: "Почему вендора, делающие вклад в развитие CVSS, сами его не используют, стараясь придумать что-то свое?" Он проиллюстрировал это тем, как Microsoft проставляет свой уровень критичности для уязвимости без привязки к CVSS, учитывая, среди прочего, вероятность реализации успешной брутфорс-атаки.

Имхо, ответ на поверхности:

1. CVSS это не священная корова. CVSS это просто опросник. С довольно произвольными полями. С довольно произвольной формулой расчёта скоринга. И сами авторы из First регулярно шатают CVSS только в путь.

2. Сделать свою систему приоритизации уязвимостей не rock­et sci­ence, а свой пиар-эффект среди ширнармасс оно даёт. Особенно если написать про "внутри у ней нейронка" и про миллион анализируемых параметров.

То, что "систем приоритизации уязвимостей сегодня уже под десяток от разных компаний, организаций и регуляторов" и это "мешает установлению некоего единого языка общения между специалистами" действительно так, не поспоришь. Но это объективная реальность. От призывов, допустим, сплотиться вокруг наступающего CVSS 4.0 она не изменится.

Как мне кажется, нам в России тоже следовало бы отойти от прямого использования CVSS as is в сторону чего-то более практичного и опирающегося на отечественные методические рекомендации, но с возможностью использовать CVSS-векторы в качестве источника данных.

Моя ОСОКА здесь как пример. 😉 Про неё не забываю. После адаптации инфраструктурных метрик понимание как должен выглядеть полный вектор уже есть. Следующей этап — накодить калькулятор.

Инфраструктурные метрики ОСОКА

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

Инфраструктурные метрики ОСОКА

Инфраструктурные метрики ОСОКА. Предлагаю вот такие метрики с маппингом на показатели/значения из методики оценки уровня критичности уязвимостей ФСТЭК.

Т.е. инфраструктурная часть вектора для "десктопной уязвимости, которой подвержены 20% десктопов, без возможности эксплуатации на периметре" будет выглядеть так:

AT:D/AS:M/PS:N

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

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

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

1. Оценка и приоритизация продетектированных уязвимостей (как для отдельных хостов, так и для инфраструктуры в целом!).
2. Оценка расхождений в результатах детектирования уязвимостей VM-продуктами и слепых пятен в базах знаний (детектов) VM-продуктов.
3. Vul­ner­a­bil­i­ty Intel­li­gence — анализ всего входящего потока уязвимостей. Возможно с фокусом только на тех продуктах, которые используются в организации и без привязки к детектам в VM-решении.

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

Какие дополнительные поля нужны Vul­ris­tics:

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

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

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