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

Выпустил ролик на 12 минут по итогам октября для своих англоязычных ресурсов

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

Выпустил ролик на 12 минут по итогам октября для своих англоязычных ресурсов. Интенсивный и интересный месяц был. Я вышел на новую работу, активно дорабатывал Vulristics, запустил Linux Patch Wednesday (пока не получил значительного отклика, но вижу здесь перспективы), традиционно проанализировал Microsoft Patch Tuesday, разобрался с кучей других уязвимостей и даже тему с обучением VM-у дальше продвинул. И ноябрь тоже бурно начался. Посмотрим, что в итоге выйдет. 🙂

---

Hello everyone! October was an interesting and busy month for me. I started a new job, worked on my open source Vulristics project, and analyzed vulnerabilities using it. Especially Linux vulnerabilities as part of my new Linux Patch Wednesday project. And, of course, analyzed Microsoft Patch Tuesday as well. In addition, at the end of October I was a guest lecturer at MIPT/PhysTech university.

00:29 Back to Positive Technologies
00:59 Vulristics NVD Data Source
02:20 Vulristics Custom Data Source
03:22 Linux Patch Wednesday Project
04:16 Linux Patch Wednesday October 2023
05:49 Microsoft Patch Tuesday October 2023
09:12 Other Vulnerabilities October 2023
10:14 Miercom released a report "Vulnerability Management Competitive Assessment"
10:54 Vulners presented AI Score v2
11:31 My PhysTech Lecture

🎞 Video
🎞 Video2 (for Russia)
📘 Blogpost

Изменения в источнике данных NVD для Vulristics

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

Изменения в источнике данных NVD для Vulristics

Изменения в источнике данных NVD для Vulristics. В NVD стали гораздо менее толерантно подходить к использованию своего API. После 5 последовательных запросов начинает отдаваться такое:

Это аффектило, в том числе и мой скрипт в Vulristics, который запрашивает данные из NVD. 😐

Согласно документации:

Публичный rate limit (без ключа API) составляет 5 запросов в скользящем 30-секундном окне; rate limit с ключом API составляет 50 запросов в скользящем 30-секундном окне.

Поэтому, если вы используете NVD API, ставьте sleep-ы. 🤷‍♂️

✅ Для Vulristics сделал поддержку аутентификации по ключу NVD и sleep-ы в 0.6 секунд при использовании ключа и 6 секунды без использования ключа.

Для получения ключа NVD API нужно указать организацию, тип организации и email в форме. Через несколько секунд на email придёт одноразовая ссылка, по которой отдаётся ключ.

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

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

Про историю Vulnerability Management-а

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

Про историю Vulnerability Management-а. Иногда люди говорят публично что-то странное, но делают это настолько уверенно, что сам начинаешь в себе сомневаться. Вдруг они лучше знают? Ну или может ты их не так понял? Вот, например, посмотрел ролик "Traditional Vulnerability Management is Dead!" с Stefan Thelberg, CEO Holm Security. Это те ребята, которые считают, что без встроенного Антифишинга VM уже не VM.

В начале Stefan Thelberg заявляет про историю Vulnerability Assessment-а (Vulnerability Management-а) буквально следующее:

1. Оригинальная идея Vulnerability Assessment-а появилась в гайдлайнах NIST-а.
2. Прошло 20 лет и появились первые Vulnerability Assessment продукты.
3. Большая часть Vulnerability Assessment продуктов родились из опенсурсного проекта OpenVAS.
4. Один из наиболее распространенных продуктов на рынке, Nessus, это коммерческий форк OpenVAS.
5. Прошло ещё несколько лет и около 2000-го появилось несколько больших компаний: Rapid7, Tenable, Qualys.

То, что VA/VM родился из каких-то публикаций NIST-а не проверишь особо, организация в 1901 году основана, вполне вероятно что-то и было в 80х. Но заявление, что сначала был OpenVAS, а потом Nessus это очень странно. Первая версия The Nessus Project вышла в 1998 как GPL проект. Первая версия XSpider (тогда Spider) также появилась в 1998, а в 2000 он стал публично доступным. Компания Qualys была основана в 1999, Rapid7 в 2000, Tenable в 2002, Positive Technologies в 2002. Проект OpenVAS (GNessUs) появился не раньше 2005-го как форк последней опенсурсной версии Nessus-а, т.к. сам Nessus с 2005 года стал проприетарным продуктом Tenable.

Вот и думай теперь, то ли Stefan Thelberg говорит о том, о чем понятия не имеет. То ли он как-то странно называет OpenVAS-ом оригинальный Nessus 1998-го года. Но даже говорить, что другие VM продукты родились из Nessus-а или OpenVAS-а более чем странно, как минимум потому что другие продукты (Qualys, Rapid7 Nexpose, XSpider/MaxPatrol) не используют и не использовали NASL-скрипты, которые составляют основу Nessus. Может, конечно, у самих Holm Security движок это OpenVAS и они всех по себе меряют, не знаю. 😏

Немного про остальной ролик. Само обоснование почему традиционный VM уже не живой это отличный пример борьбы с "соломенным чучелом". Определяют "традиционный VM" так, как удобно. Что он, дескать, не поддерживает новые технологии (облака, IoT, SCADA). Добавляют свой спорный тезис, что обучение пользователей через Антифишинг это тоже обязательная часть VM. И дальше получившееся удобное "соломенное чучело" атакуют. Хотя чего бы "традиционному VM-у" не поддерживать все типы активов, которые в организации есть - непонятно. Да и какой-то проблемы прикрутить к VM-у Антифишинг, если так уж хочется, тоже нет.

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском

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

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском. На русском было тут.

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей

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

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей

Ещё один пример того, что NIST и MITRE не справляются с ведением базы уязвимостей. И американским регуляторам, включая CISA, видимо наплевать.

Mozilla Foundation Security Advisory 2022-09
Announced March 5, 2022
CVE-2022-26486: Use-after-free in WebGPU IPC Framework

Эта уязвимость есть в CISA Known Exploited Vulnerabilities Catalog. Значит эта критичная уязвимость эксплуатируется в реальных атаках.

Но если вы попробуете перейти по ссылке на CVE-2022-26486, например из той же CISA KEV, на сайт на NVD, то вы увидете "CVE ID Not Found". В MITRE аналогично: "RESERVED". Статус 9 месяцев не менялся (и видимо не поменяется). Что-то где-то пошло не так.

Могли бы CISA попушить NIST, MITRE или Mozilla, чтобы с этой критичной CVE навели порядок? Запросто. Но они это не делают. Им видимо норм ссылаться в никуда.

А вот в БДУ ФСТЭК для CVE-2022-26486 видим вполне адекватное описание с CVSS и всем, что нужно. ФСТЭК молодцы. 👍