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

На сайте CISA 22 сентября опубликовали документ "Программа CVE: формирование фреймворка эры качества"

На сайте CISA 22 сентября опубликовали документ Программа CVE: формирование фреймворка эры качестваНа сайте CISA 22 сентября опубликовали документ Программа CVE: формирование фреймворка эры качества

На сайте CISA 22 сентября опубликовали документ "Программа CVE: формирование фреймворка эры качества". В оригинале "CVE Program: Establishing a Quality Era Framework". Основная проблема, которую они там фиксируют: CVE Program быстро масштабируется, вместе с объёмом уязвимостей растёт нагрузка на процессы публикации, проверки и сопровождения CVE-записей.

По состоянию на 18 сентября 2026 года опубликовано более 67 тыс. новых CVE. По данным NVD, число CVE, поступивших на обработку, выросло на 263% в 2020-2025 годах. За первые три месяца 2026 года на обработку поступило на треть больше CVE, чем за тот же период 2025 года.

"Ускорение выявления и публикации информации об уязвимостях действительно может повысить её ценность - при условии, что сведения полны, непротиворечивы, своевременны и пригодны для практического использования. Однако более быстрый темп работы одновременно может обнажить недостатки в процессах, инструментах, взаимодействии между участниками и распределении ответственности - особенно если качество поступающих данных сильно различается."

Руководство CISA выделяет четыре направления работы:

🔹 управление CVE Program;
🔹 участие представителей экосистемы - CNA, Roots, CNA-LR, исследователи, вендоры, поставщики инструментов и государственные организации;
🔹 инфраструктура данных - API, схемы, библиотеки проверки и CVE Org;
🔹 качество записей CVE - полнота, точность, своевременность и практическая применимость данных.

Для этих направлений определены показатели качества (на иллюстрации) - от времени принятия управленческих решений и надёжности API до доли записей CVE, соответствующих установленным критериям качества, и количества исправлений после публикации (или скорости внесения исправлений? 🤔 Имхо, тут неоднозначно: "Rate of corrections/updates needed post-publication").

"Эпоха качества требует согласованного развития по четырём направлениям: управление программой CVE, участие представителей экосистемы, инфраструктура данных и содержание записей CVE.

🔻 Улучшение содержания записей CVE зависит от чётких требований к данным, эффективных инструментов и активного участия CNA.
🔻 Развитие инфраструктуры данных требует постоянных инвестиций, защищённых и масштабируемых систем, а также обратной связи от пользователей, которые используют эти данные.
🔻 Расширение участия в экосистеме зависит от широкого представительства технологий, отраслей, регионов и сообществ, которые обслуживает программа CVE.
🔻 Совершенствование управления программой зависит от прозрачного управления, дальнейшего организационного развития, совместного участия, эффективности и способности оперативно реагировать на потребности мирового сообщества, занимающегося управлением уязвимостями."

Этот документ задаёт рамку для следующего этапа развития CVE Program (читай: по большей части вода-водичка, правильные общие слова и благие намерения без какой-либо конкретики 😉). Описания конкретных изменений обещают выложить в ближайшие месяцы: "в этой серии публикаций будут описаны текущие и планируемые улучшения ключевых компонентов инфраструктуры, обеспечивающих работу программы CVE".

Коллегам из ФСТЭК тоже стоит к этой движухе присмотреться и, возможно, что-то перенять для развития БДУ.

На прошлой неделе CISA запустили публичную форму "номинации новых KEV"

На прошлой неделе CISA запустили публичную форму номинации новых KEV

На прошлой неделе CISA запустили публичную форму "номинации новых KEV". Форма предназначена для безопасной подачи информации об уязвимостях, эксплуатируемых в атаках, для их включения в каталог CISA KEV. В целом это изменение выглядит позитивно, но с оговорками:

🟢 Плюсы: CISA могут получить более быстрый и более структурированный поток данных об уже эксплуатируемых уязвимостях, что может ускорить их проверку и добавление в KEV. Это особенно важно, поскольку исследование и эксплуатация уязвимостей сейчас сильно ускорились, в том числе за счёт использования AI.

🔴 Минусы: появляется зависимость от качества поступающей информации, а также возникает дополнительная нагрузка на её проверку со стороны аналитиков CISA. Если валидация будет слабой, достоверность каталога KEV снизится, если слишком строгой, может снизиться скорость наполнения каталога. А ведь ради увеличения скорости всё это и затевается.

А возможно, это первый шаг в сторону децентрализации процесса классификации уязвимостей как эксплуатируемых. Появятся какие-нибудь KNA - KEV Nominating Authorities, по аналогии с CVE CNA? 🤔 Посмотрим. 🙂

Для добавления уязвимости нужны:

🔹 CVE-ID
🔹 Рекомендации по устранению
🔹 Подтверждения эксплуатации

Сначала нужно ответить да/нет на вопросы:

🔹 Есть ли доказательства того, что CVE уязвимость, о которой вы сообщаете, активно эксплуатируется или эксплуатировалась в прошлом?
🔹 Считаете ли вы, что эта уязвимость затрагивает несколько вендоров или продуктов?

Затем нужно заполнить текстовые поля:

🔹 CVE-ID, о котором вы сообщаете (пожалуйста, ещё раз проверьте, что CVE-ID указан правильно)
🔹 Доказательства эксплуатации
🔹 Ссылка на патч или меры по устранению

На странице содержится предупреждение: "Не отправляйте в этой форме секретную или конфиденциальную информацию".

Последнее поле опционально: "Пожалуйста, предоставьте любую дополнительную информацию, которую вы хотите добавить. Не указывайте в этой форме персональные данные. Если у вас есть дополнительные доказательства, которые вы хотите предоставить, свяжитесь с нами напрямую по электронной почте kev@cisa.dhs.gov. Если у вас есть конфиденциальная информация для отправки, пожалуйста, сначала согласуйте с нами, чтобы мы могли организовать безопасную передачу данных."

Для отправки заявки нужно пройти reCAPTCHA. Авторизация не требуется. В случае успеха показывают сообщение: "Благодарим вас за время, потраченное на прохождение этого опроса. Ваш ответ был записан."

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким. У Алексея Викторовича очень необычный взгляд на вопросы Vulnerability Management-а и мастерские формулировки. 👍🙂📝 Отметил для себя 3 темы, которые было бы интересно подробнее разобрать:

🔻 VM и облачные SaaS-провайдеры. Как контролировать, что провайдер имеет адекватный VM-процесс (да и вообще ИБ) у себя, учитывая, что в случае инцидента отвечать будет не провайдер, а клиент-жертва.

🔻 Статьи о гос. измене / шпионаже (УК РФ 275, 276) и репортинг уязвимостей зарубежным вендорам, организациям и базам уязвимостей. Насколько реальна опасность для исследователя, как поступать правильно и безопасно?

🔻VM-вендорам интересно поддерживать не все продукты. Что делать клиентам (навскидку: пушить VM-вендора, пилить свои детекты, выбирать решения с учётом возможностей VM)?

"Патчить абсолютно всё невозможно и безыдейно" меня, конечно, триггернуло. 🙄