Архив рубрики: Уязвимость

Продолжаю рассказ про уязвимости БДУ без ссылок на 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.

Отчитался-отвыступался на Территории Безопасности

Отчитался-отвыступался на Территории Безопасности
Отчитался-отвыступался на Территории БезопасностиОтчитался-отвыступался на Территории БезопасностиОтчитался-отвыступался на Территории БезопасностиОтчитался-отвыступался на Территории БезопасностиОтчитался-отвыступался на Территории Безопасности

Отчитался-отвыступался на Территории Безопасности.

🔹 Аналитический блок открыл Рустэм Хайретдинов. Его основные тезисы: 1. Низкая конкуренция на российском рынке VM, высокие цены, прямое импортозамещение невозможно (не соглашусь, цена/качество Nessus это был демпинг, да и для российских инфраструктур западные решения перестают быть актуальными). 2. Облачным сервисам никто больше не верит (имхо, иностранным да, а российским вроде норм 🤷‍♂️) 3. Российские вендоры в меньшей степени заинтересованы в публикации информации об уязвимостях.

🔹 Дальше я раскрывал тему уязвимостей в БДУ ФСТЭК без ссылок на CVE, среди которых значительная часть и есть уязвимости российских вендоров. 😉

🔹 Дискуссия по VM-у понравилась. Попушил тему с управлением активами, безусловными обновлениями, приоритизацией и выделением трендовых уязвимостей. 👍

Зрителей на дискуссии было не особо много, т.к. в параллель было ещё 2 дискуссии и одна с Алексеем Лукацким 🙂. Ещё и кейтеринг был обильный и разнообразный. 😉

К сегодняшнему докладу на конференции Территория Безопасности я выпустил 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 (причина на поверхности, в докладе указываю 😉).

Вышел номер журнала InformationSecurity со спецпроектом по Управлению Уязвимостями

Вышел номер журнала InformationSecurity со спецпроектом по Управлению Уязвимостями

Вышел номер журнала InformationSecurity со спецпроектом по Управлению Уязвимостями. Я сам в нём участия не принимал, но постараюсь на досуге почитать и покомментировать. Темы выглядят очень занимательно. 🙂

🔹 Павел Попов. Управление уязвимостями в новых реалиях: что изменилось и как перестроить процесс
🔹 Андрей Селиванов. Приоритизация – ключ к эффективному управлению уязвимостями организаций в условиях большого количества активов
🔹 Сергей Уздемир. Управление уязвимостями: ожидание, реальность, рекомендации
🔹 Александр Дорофеев. Подходы к поиску уязвимостей: хороший, плохой, злой
🔹 Владимир Тележников. Управление уязвимостями при разработке ОС Astra Linux
🔹 Владимир Михайлов. Современные технологии в решениях для управления уязвимостями
🔹 Ольга Гурулева. Главное, чтобы исследователь не ушел от нас с негативной реакцией
🔹 Андрей Макаренко. Управление уязвимостями с помощью ИИ
🔹 Любовь Ермилова. Управляем поверхностью атаки: лучшие практики и подводные камни
🔹 Николай Степанов. Attack Surface Management: с чего начинать управление уязвимостями
🔹 Александр Подобных. Управление уязвимостями в криптокошельках

🔸 Таблица российских решений класса Vulnerability Management
🔸 Эволюция систем управления уязвимостями. Круглый стол.

Что делать VM-щику, чтобы быть эффективным?

Что делать VM-щику, чтобы быть эффективным?

Что делать VM-щику, чтобы быть эффективным? Исходя из того, что он должен выполнять в организации роль инспектора без каких-либо реальных полномочий, а коллеги из IT в основном считают, что он творит дичь. 🤔

🔻 1. Досконально знать требования и рекомендации регуляторов в части управления уязвимостями. Парадоксально, но именно это самый надёжный инструмент VM-щика и самый недооцененный. 😏 Вряд ли в организации кто-то будет разбираться в этом лучше. Кроме, возможно, методологов ИБ, но они естественные союзники и с ними проблем обычно не бывает. Конечно, не стоит постоянно потрясать выписками из регуляторики и грозить неизбежными карами. Это глупо, а главное вызывает привыкание и уменьшает эффект. Ну либо наоборот приводит к тому, что коллеги из IT начинают осознавать степень своей реальной ответственности в случае инцидента и бегут массово увольняться, чего тоже хотелось бы избежать. 😉 Поэтому лучше приберегать такие аргументы на случай серьезного конфликта. Чтобы, когда договориться по-хорошему не получается, эффектно и адресно бахнуть из всех стволов. Понимание, что такие железобетонные аргументы есть и они заранее заготовлены, даёт опору и уверенность. Это даже в качестве аутотренинга неплохо работает. "- Кто ты? - Vulnerability Management специалист. - Что ты здесь делаешь? - Внедряю в организации Vulnerability Management процесс согласно лучшим практикам, рекомендациям и требованиям регуляторов в целях повышения уровня защищенности организации."

🔻 2. Разбираться в уязвимостях, инструментах детектирования и эксплуатации. Этот пункт как раз ожидаем. 🙃 Раз VM-щик, то значит должен разбираться в "vulnerability", очевидно. Но тут важно делать акценты: а для чего? Для того чтобы самому находить цепочки атак и демонстрировать реальную эксплуатабельность уязвимостей инфраструктуры? Так это задача внутреннего пентеста/redteam-а. Для того чтобы эффективней убеждать админов? Возможно иногда и имеет смысл, но главное не скатиться в "докажи-покажи" и исправление только тех уязвимостей, которые получается эффектно продемонстрировать. Для того чтобы детектировать все уязвимости, лучше их приоритизировать и выделять те, которые представляют наибольшую опасность для организации? Вот это пожалуй самое главное. Не теряем фокус на том, что мы здесь для того, чтобы внедрять работающий процесс детектирования и исправления уязвимостей, а остальное вторично (ещё раз см. п.1).

🔻 3. Стараться творить поменьше дичи. 🙂 Это значит, что для того, чтобы эффективно коммуницировать с админами, девопсами, разработчиками нужно и самому иметь сопоставимую квалификацию. Иначе требования сделать харденинг или установить обновления будут парироваться простым раздражённым "это невозможно сделать, у нас всё сломается". 😱 Возможно с добавлением какой-то тарабарщины из незнакомых терминов. Задача VM-щика понимать предметную область настолько, чтобы отличать, когда тебе вешают лапшу на уши, а когда за этим реально что-то есть. То есть самому быть в какой-то степени админом/девопсом/разрабом, но с расширенными знаниями в области уязвимостей систем и ИБ вообще. 😉

Презентую расширенную поддержку БДУ ФСТЭК в моей утилите для приоритизации уязвимостей 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 сказать что-то определенное сложно.

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