Архив метки: ФСТЭК

Завершаю серию постов про свой мини-ресерч уязвимостей БДУ без ссылок на CVE следующими выводами

Завершаю серию постов про свой мини-ресерч уязвимостей БДУ без ссылок на CVE следующими выводами

Завершаю серию постов про свой мини-ресерч уязвимостей БДУ без ссылок на CVE следующими выводами.

🔹 Vulristics теперь умеет работать с БДУ, его можно использовать для приоритизации продетектированных уязвимостей и поиска аномалий в базе БДУ.
🔹 Уязвимостей в БДУ без ссылок на CVE около 2.4% от общего количества, но они представляют большой интерес, т.к. они в других базах уязвимостей не описаны. Особенно интересны уязвимости в отечественных продуктах и те, что с эксплоитами и эксплуатацией вживую.
🔹 Уязвимости в БДУ без CVE это не только уязвимости в отечественных продуктах, но и в Open Source, и в западных проприетарных продуктах.
🔹 Иногда для «уязвимости без CVE» на самом деле есть CVE. 🤷‍♂️ Нужно выявлять такое и репортить.

Для дальнейшего анализа было бы интересно собрать детальную статистику по уязвимым продуктам (тип, назначение, лицензия и т.д), но это осложняется отсутствием формализованных источников данных с описанием продуктов. 🤔

Продолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсов

Продолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсов

Продолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсов.

🔹 Почему так много уязвимостей Astra Linux? Upd 0704. В основном это результат собственного ресёрча.
🔹 Для EMIAS OS уязвимости Linux Kernel, но даже без ссылки на бюллетень. Откуда именно уязвимость непонятно.
🔹 Откуда уязвимости Windows? Их Microsoft выпускали не как CVE-шки, а как ADVisories. Потом для них могут добавлять CVE, которые не пробрасываются в БДУ. 🤷‍♂️
🔹 Для уязвимостей Debian Linux аналогично. Они заводятся по бюллетеням DSA без ссылки на CVE на момент публикации. Затем ссылка добавляется, но в БДУ она не пробрасывается. 🤷‍♂️
🔹 Почему много уязвимостей Open Source продуктов? Потому что они заводятся по эксплойтам, в описании которых нет ссылки на CVE.
🔹 Некоторые виндоры не любят заводить CVE идентификаторы. Например, SAP часто выпускают только непубличные SAP Notes.

К сегодняшнему докладу на конференции Территория Безопасности я выпустил 3 отчёта Vulristics по БДУ уязвимостям без ссылки на CVE

К сегодняшнему докладу на конференции Территория Безопасности я выпустил 3 отчёта Vulristics по БДУ уязвимостям без ссылки на CVEК сегодняшнему докладу на конференции Территория Безопасности я выпустил 3 отчёта Vulristics по БДУ уязвимостям без ссылки на CVEК сегодняшнему докладу на конференции Территория Безопасности я выпустил 3 отчёта Vulristics по БДУ уязвимостям без ссылки на CVEК сегодняшнему докладу на конференции Территория Безопасности я выпустил 3 отчёта Vulristics по БДУ уязвимостям без ссылки на CVE

К сегодняшнему докладу на конференции Территория Безопасности я выпустил 3 отчёта Vulristics по БДУ уязвимостям без ссылки на CVE.

🔹 Уязвимости без CVE с инцидентами (зафиксированной эксплуатацией вживую): 17
🔹 Уязвимости без CVE с эксплоитами (публичными или приватными): 584
🔹 Уязвимости без CVE: 1364 (1365)

Лучше всего я, естественно, "причесал" первый отчёт по 17 уязвимостям с известными инцидентами в 16 продуктах. 🙂 Но даже он общую картину даёт. Среди уязвимостей без CVE идентификаторов есть не только уязвимости в российских продуктах (что естественно предположить), но и в Open Source проектах, и в проприетарных западных продуктах. Некоторые причины рассмотрю.

Все 1364 уязвимости без CVE касаются уже 377 продуктов (руками не раскидаешь). Количество отечественных продуктов можно крайне грубо оценить по использованию кириллицы в названиях - таких продуктов 63. В лидерах Astra Linux (причина на поверхности, в докладе указываю 😉).

Презентую расширенную поддержку БДУ ФСТЭК в моей утилите для приоритизации уязвимостей Vulristics

Презентую расширенную поддержку БДУ ФСТЭК в моей утилите для приоритизации уязвимостей Vulristics
Презентую расширенную поддержку БДУ ФСТЭК в моей утилите для приоритизации уязвимостей VulristicsПрезентую расширенную поддержку БДУ ФСТЭК в моей утилите для приоритизации уязвимостей Vulristics

Презентую расширенную поддержку БДУ ФСТЭК в моей утилите для приоритизации уязвимостей Vulristics. 🎉

🔻 Данные из БДУ выгружаются массово, а не по одному идентификатору. Если в data source указан "bdu" и значение rewrite-flag "True", то скачается и обработается вся выгрузка из БДУ (55879 идентификаторов). Кроме того, создадутся сущности по связанным CVE (47261), чтобы можно было использовать данные БДУ при приоритизации CVE-шек (см. скриншот). Вся процедура занимает несколько секунд. ⚡️ Затем можно приоритизировать любые наборы БДУшек в оффлайне (rewrite-flag "False").
🔻 Я использую эти данные БДУ для приоритизации: имя продукта, описание, cvss, cwe, признак активной эксплуатации (vul_incident, аналог CISA KEV❗️) и признак наличия публичного/приватного эксплоита (exploit_status).
🔻 Идентификаторы БДУ подаются на вход также как CVE (например через --cve-list-path), их можно миксовать.

Особенно полезно для приоритизации уникальных БДУ уязвимостей без ссылок на CVE. 😉

В четверг собираюсь выступать на конференции Территория Безопасности с докладом "За пределами NVD: уникальные уязвимости в БДУ ФСТЭК"

В четверг собираюсь выступать на конференции Территория Безопасности с докладом За пределами NVD: уникальные уязвимости в БДУ ФСТЭКВ четверг собираюсь выступать на конференции Территория Безопасности с докладом За пределами NVD: уникальные уязвимости в БДУ ФСТЭК

В четверг собираюсь выступать на конференции Территория Безопасности с докладом "За пределами NVD: уникальные уязвимости в БДУ ФСТЭК". В нём рассмотрю уязвимости БДУ без ссылок на CVE. Выступление будет коротким, минут на 15 вместе с вопросами. Пока буду выкладывать сюда некоторые моменты.

🔸 Сколько уязвимостей в БДУ без ссылок на CVE? Не очень много 1364 из 55805, т.е. где-то 2.4%.
🔸 Если количество новых БДУ идентификаторов с каждым годом увеличивается (как и количество CVE), то про количество новых БДУ идентификаторов без ссылок на CVE сказать что-то определенное сложно.

Дальше рассмотрим что же это за уязвимости.
Спойлер: .

Прожектор по ИБ, выпуск №23 (18.02.2024): Прощальный рэп

Прожектор по ИБ, выпуск №23 (18.02.2024): Прощальный рэп

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"

00:00 Здороваемся, смотрим статистику, Лев рассказывает почему больше не будет участвовать в Прожекторе по ИБ 😔
02:23 Дайджест трендовых уязвимостей за январь 2024 от Positive Technologies
05:22 Новый бэкдор для Ivanti Connect Secure и анализ апплаенса Ivanti
10:42 Февральский Microsoft Patch Tuesday, ошибочный временный взлёт RCE Outlook и взлёт уязвимости Exchange
15:17 Фишинговые рассылки на тему выплат за детей от 3 до 16 лет
18:24 Cтатистика по мошенничествам на сервисах знакомств в День святого Валентина
20:40 0day уязвимость EventLogCrasher в Windows
25:50 Драфт "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации" в контексте Управления Уязвимостями
34:35 Обсуждение руководства по управлению уязвимостями от британских регуляторов
38:37 🎤 Лев зачитывает прощальный рэп, вспоминаем/осуждаем Peiter Zatko (бывший CISO Twitter)

Вышел драфт "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации"

Вышел драфт Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации

Вышел драфт "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что там с Управлением Уязвимостями?

Есть 2 показателя безопасности, зависящие от оперативности устранения уязвимостей:

🔸 3.2. "На устройствах и интерфейсах, доступных их сети Интернет, отсутствуют уязвимости критического уровня опасности с датой публикации обновлений (компенсирующих мер по устранению) в банке данных угроз ФСТЭК России, на официальных сайтах разработчиков, иных открытых источниках более 30 дней"

🔸 3.3 "На пользовательских устройствах и серверах отсутствуют уязвимости критического уровня с датой публикации обновления (компенсирующих мер по устранению) более 90 дней (не менее 90% устройств и серверов)"

❓Во втором случае не указано откуда дату публикации обновления брать. Наверное нужно сделать единообразно.
❓"доступных их сети Интернет" - опечаточка, "из".

Из пунктов следует, что нужно:

🔻 покрывать все активы детектами уязвимостей
🔻 понимать какие именно активы опубликованы в Интернет
🔻 уметь оценивать критичность уязвимостей по методике ФСТЭК
🔻 отслеживать дату публикации обновления (а не дату публикации самой уязвимости!) в разных источниках 😲

Последнее выглядит как нетривиальная задача, т.к. общего реестра данных по обновлениям не наблюдается, получается ведение такого реестра и наполнение его ляжет на организацию. На практике, скорее всего, придется ориентироваться именно на дату публикации уязвимости, т.к. её гораздо проще определять (непосредственно в NVD/BDU) и, по идее, она должна быть всегда более ранней или равной дате публикации обновления. 🤔 Поэтому, возможно, имеет смысл подкрутить формулировочку, например на "дата публикации уязвимости или обновления (компенсирующих мер по устранению)". И сделать пометочку, что допустимо взять наибольшую из имеющихся дат.

И, в идеале, хотелось бы ещё видеть аналог CISA KEV с непосредственно указанными датами, когда конкретные уязвимости должны быть исправлены.