Архив метки: ОСОКА

На прошлой неделе на сайте РезБеза вышел большой обзор методов приоритизации уязвимостей от Алексея Лукацкого

На прошлой неделе на сайте РезБеза вышел большой обзор методов приоритизации уязвимостей от Алексея Лукацкого

На прошлой неделе на сайте РезБеза вышел большой обзор методов приоритизации уязвимостей от Алексея Лукацкого. Нашлось там место и для предложенной мной альтернативы CVSS под названием ОСОКА ("Общая Система Оценки Критичности Автоматизируемая"), а также там упоминается моя утилита для приоритизации уязвимостей Vulristics. Видимо действительно пора доводить ОСОКу от разрозненных заметок до спецификации, делать калькулятор и интегрировать её в Vulristics. 🤔

Рассматриваемые в статье методы разбиты на 3 группы:

🔹Зарубежные: CVSS, EPSS, CISA SSVC, CISA KEV, CVEShield (CVE Crowd, CVETrends), CMU SSVC, CVE Prioritizer, Vulners AI Score, Zoom VISS, SSPP

🔹 Российские: методика ФСТЭК, алгоритм НКЦКИ, трендовые уязвимости Positive Technologies, ОСОКА

🔹Проприетарные / закрытые: Coalition ESS, Tenable VPR, Qualys TruRisk, MVSF, PRIOn. Здесь же упоминаются внедряемые технологии приоритизации (VPT): Vulnera VSCORE, Outpost24 VPT, Vulcan, Ridge RidgeBot

1 ноября официально вышел CVSS v4.0, который и так-то никому не нужен, а особенно он не нужен в России

1 ноября официально вышел CVSS v4.0, который и так-то никому не нужен, а особенно он не нужен в России

1 ноября официально вышел CVSS v4.0, который и так-то никому не нужен, а особенно он не нужен в России. Технические детали были известны ещё у июне, так что тут мало интересного. В чём там суть? Есть такая организация FIRST (пионЭры). Они с 2005 года занимаются развитием  стандарта CVSS для оценки уязвимостей через заполнение опросников. Тема прижилась, стала использоваться в американской National Vulnerability Database, где можно бесплатно получить оценки для CVE уязвимостей в формате CVSS (только базовые метрики).

В принципе и отлично. Но нет покоя одержимым и FIRST периодически выкатывает новую версию CVSS. Причём каждый раз всё более сложную и несовместимую с предыдущей. Строго говоря, нельзя автоматом получить CVSS v3/3.1 из CVSS v2 и наоборот, нужно садиться и перезаполнять опросник. И не просто заполнять, а ориентируясь на разъяснения и примеры заполнения указанные в стандарте.

И ладно бы ещё результат этой оценки был годный, так нет. Поныть на тему того, что оценки по CVSS это какая-то субъективная ерунда это любимое развлечение безопасников. Аз грешный и сам в этом был неоднократно замечен. Достаточно просто погуглить "CVSS critique", чтобы погрузиться в пучины отчаянья.

Станет ли CVSS 4.0 лучше? Посмотрим. Но, имхо нет, т.к. CVSS остаётся таким же опросником, заполняемым субъективно, но теперь несколько иначе и сложнее. Теперь исследователям и аналитикам NIST NVD придётся разобраться в правильном заполнении очередного опросника. Естественно только базовых метрик - остальным никто опять по собственной воле пользоваться не будет. 🙃 На NVD для старых уязвимостей будет только заполнение на CVSS 2.0/3.0/3.1, для новых с какого-то времени будет 3.1 и 4.0, потом только 4.0. Пока First через несколько лет опять всё не поменяют с новым стандартом. 😏🤷‍♂️

А пользователи как лазили на NVD за цифирей от 0 до 10 (Base Score), так и будут лазить. Ну да, этих цифирей теперь будет несколько для разных версий стандарта. Ну наверное будут брать по максимальной версии стандарта или по максимальному значению. 🌝

Теперь о главном: как это заденет методику ФСТЭК по оценке критичности уязвимостей. Тут, как мне кажется, могут быть 3 пути:

1) Игнор. Ну записано в методике 3.0/3.1, делаем как записано. Всё равно, что у американцев другая версия актуальная. Но понятно, что такое положение дел бесконечно продолжаться не может.

2) Признание 4.0. Ну то есть в тексте добавят 3.0/3.1/4.0 или вообще изменят на 4.0 и будьте любезны всю эту методику CVSS 4.0 для оценки уязвимостей у себя имплементировать as is (всё, а не только базовые метрики!) Кажется наиболее вероятным вариантом, хотя мне он решительно не нравится. 😔

3) Отказ от CVSS в пользу своего аналога с долгосрочной поддержкой и бережным переходом на новую версию (с возможностью автоматического пересчёта метрики). Мне кажется это был бы наиболее правильный вариант. И пусть американцы меняют свои опросники хоть каждый месяц, если им так хочется. Вместе с прочей шизой типа переименования терминов "MiTM", "master/slave" и прочее. У них там своя атмосфера. 🤷‍♂️

Как можно реализовать российский аналог CVSS в щадящем режиме без особых изменений методики я уже описывал в рамках своего проекта ОСОКА: форкаем базовые метрики CVSS v3, вместо временных метрик CVSS v3 вводим свои простые и автоматизируемые метрики по эксплуатабельности (самое важное!), оформляем Iinfr в инфраструктурные метрики, делаем рекомендации как получать наши базовые метрики из базового вектора CVSS v2/3/4. Всё прозрачно и является по факту упрощением работы с методикой ФСТЭК, чем усложнением.

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

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

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

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

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

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

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

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

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

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

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

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

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

AT:D/AS:M/PS:N

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

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

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

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%

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

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

Как вам?

Проекты, над которыми я сейчас размышляю

Проекты, над которыми я сейчас размышляю. Возможно кому-то тоже захочется поучаствовать.

1. CVE Mentions. Переводить аналитические отчёты с упоминанием CVE-идентификаторов в формализованный вид, использовать их для приоритизации уязвимостей в Vulristics.

2. Свой Vulnerability Feed. Анализировать все CVE/БДУ, детектировать тип уязвимости и уязвимый продукт, наличие эксплоита и факта эксплуатации вживую. Использовать фид в Vulristics.

3. Linux Patch Wednesday. Формировать ежемесячные обзоры по Linux-овым уязвимостям. Написать скрипт для формирования скоупов CVE с разбивкой по месяцам.

4. ОСОКА. Система оценки критичности уязвимости на основе CVSS v3 и методики оценки критичности ФСТЭК. Расписать метрики, формулу расчета, автоматическую генерацию базовых метрик из CVSS Base v2, v3, v4.

5. Scanvus OVAL. Добавить в Scanvus возможность детектирования уязвимостей с использованием OVAL-контента без доступа к внешним платным API.

6. Scanvus Docker. Добавить возможность детектировать уязвимости Docker images без запуска контейнера, только через анализ SBOM.

7. Telegram2WordPress. Написать обвязку, которая будет раскидывать посты из телеграмма в блог на WordPress. Для упрощения навигации, улучшения индексации и на случай если Телеграмм снова начнут блокировать.

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

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на 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 и методику оценки критичности уязвимостей ФСТЭК на ОСОКА.