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

Выложил запись моего вчерашнего выступления на VK Security Сonfab Max 2024: Vulnerability Management, кризис NVD, трендовые уязвимости и БОСПУУ

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

Выложил запись моего вчерашнего выступления на VK Security Сonfab Max 2024: Vulnerability Management, кризис NVD, трендовые уязвимости и БОСПУУ. Доступно на VK видео, Rutube и YouTube.

В 2024 году NIST NVD перестал справляться с ускоряющимися темпами прироста уязвимостей, а общее количество CVE-уязвимостей уже перевалило за 250 000. Какие из этих уязвимостей стали активно эксплуатироваться злоумышленниками в этом году и какие могут начать эксплуатироваться в ближайшем будущем? Как построить Vulnerability Management процесс в организации, чтобы снизить риски эксплуатации критичных уязвимостей?

00:00 Представляюсь
01:09 NVD в 2024 году: безудержный рост количества CVE и его причины (CNA организации), кризис обогащения данных
04:25 Как CNA вендор может творить дичь на примере Linux Kernel и Linux Patch Wednesday
06:29 Трендовые уязвимости и как мы их отбираем
08:12 Про проект "В тренде VM": ролики, дайджесты, хабропосты
08:50 Как я анализировал 70 трендовых уязвимостей с помощью Vulristics
11:21 Пример успешного предсказания трендовости
11:50 4 уязвимости 2023 года: почему они здесь?
12:13 Почему нет трендовых уязвимостей в отечественных продуктах?
13:20 32 уязвимости Microsoft
13:51 2 уязвимости Linux
14:34 Остальные группы уязвимостей: фишинг, сетевая безопасность, бэкапы и виртуалки, разработка ПО, совместная работа, CMS
17:01 ТОП-3
17:50 Не уязвимости, но важно (2 кейса)
19:49 Прогнозы на 2025 год
21:10 Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ)
28:36 Вопрос про Vulnerability Management без бюджета
31:18 Вопрос про то, как выделять трендовые уязвимости
33:47 Вопрос про то, как заставить IT оперативно устранять уязвимости
36:20 Вопрос про отчёты о сканировании MaxPatrol VM
37:02 Вопрос про причины лавинообразного увеличения количества CVE (упоминаю BDU:2024-08516 от СайберОК)
38:50 Вопрос про хороший продукт по проблематике 0day

🗒 Полный отчёт Vulristics для трендовых уязвимостей 2024

Понравился доклад? 🗳 Проголосуй за него! 😉

Microsoft будут заводить CVEшки для уязвимостей своих облачных сервисов

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

Microsoft будут заводить CVEшки для уязвимостей своих облачных сервисов

Microsoft будут заводить CVEшки для уязвимостей своих облачных сервисов. Казалось бы, ну была уязвимость в какой-то облачной CRM-ке, они её зафиксили сразу для всех, никаких действий со стороны клиентов не требуется. Толку-то на это CVE заводить? 🤔

Но в Microsoft считают, что это требуется для большей прозрачности, а новые правила CNA (CVE Numbering Authorities) требуют заводить уязвимости, которые могут нанести существенный вред, независимо от того требуется ли клиентам совершать какие-то действия для устранения уязвимостей или нет. 🤷‍♂️ Microsoft обещают помечать такие уязвимости отдельно, как например CVE-2024-35260 "The vulnerability documented by this CVE requires no customer action to resolve". В CVEorg тоже будет специальный tag.

Нужно или не нужно заводить уязвимости облачных сервисов как CVE - вопрос спорный. Но то, что из-за этой практики количество идентификаторов в CVEorg/NVD станет прирастать гораздо быстрее - факт. 🤷‍♂️

VulnCheck выложили диаграмму по проблемам описания CWE в NVD

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

VulnCheck выложили диаграмму по проблемам описания CWE в NVD

VulnCheck выложили диаграмму по проблемам описания CWE в NVD. Я 7 лет назад тоже делал что-то подобное, но тут за прошлый год и в контексте топовых CNA (CVE Numbering Authorities). Выглядит прикольно. В чём суть: CNA часто не запариваются формальным описанием типа уязвимости (а CWE, Common Weakness Enumeration, это по сути он и есть) и либо оставляют это поле пустым, либо лепят туда "мало данных", "другое". 🤷‍♂️

Причём я подозреваю, что там, где CWE выставлены это, в основном, что-то неконкретное типа CWE-119 Buffer Errors (во всяком случае это был самый популярный CWE идентификатор 7 лет назад). Даже если на основании описания можно предположить и более конкретный тип уязвимости. Выглядит как направление для дальнейшего анализа и тыкания уважаемых CNA палочкой. 🤔😉

Ну и интересно, а как с этим дела в нашей БДУ.

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

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

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

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч? Подсмотрел занимательный вопрос в канале Алексея Лукацкого.

С одной стороны, ответ вроде и очевиден. CVE-шки заводят в основном на уязвимости в продуктах, разные версии которых могут находиться в эксплуатации у пользователей. А в скоуп багбаунти попадают в основном самописные веб-приложения доступные из Интернет, так что пользователи в любой момент времени пользуются определенной версией веб-приложения. В этом случае фикс уязвимости решает проблему сразу и полностью для всех пользователей веб-приложения и пользы от CVE-идентификатора в этом случае не будет.

С другой стороны, есть мобильные приложения, которые тоже часто попадают в скоуп багбаунти. А у мобильного приложения уже есть версия и пользователи могут использовать разные версии мобильного приложения. И, получается, для мобильных приложений уже может быть смысл заводить CVE.

В принципе, ничего не мешает сделать багбаунти программу вообще для любых приложений. Например, на hackerone есть багбаунти для Chrome/Chromium. И для этих уязвимостей Google заводит CVE. Ничего не запрещает самому вендору заводить CVE под найденные в рамках багбаунти уязвимости кроме нежелания этого вендора.

И не сказать, что это требует каких-то особенных усилий со стороны вендора, т.к. сама багбаунти платформа может заводить CVE уязвимости для своих клиентов. В списке CVE Numbering Authority (CNA) есть 11 организаций типа "Bug Bounty Provider", включая Bugcrowd, HackerOne, ZDI:

"Provides CVE IDs for its customers as part of its bug bounty and vulnerability coordination platform"

В общем, уязвимостей меньше, потому что не для всех уязвимостей есть смысл заводить CVE. А для тех уязвимостей, для которых смысл есть, CVE идентификаторы не заводят, т.к. сам вендор уязвимого продукта этого не хочет. 🤷‍♂️ А сам исследователь хоть и может добиться заведения CVE идентификатора помимо воли вендора, но это не массовая история.

PS: хороший вопрос для собеседования VM-щиков 😉