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

Важное уточнение по поводу БДУ уязвимостей Astra Linux без CVE идентификаторов

Важное уточнение по поводу БДУ уязвимостей Astra Linux без CVE идентификаторов

Важное уточнение по поводу БДУ уязвимостей Astra Linux без CVE идентификаторов. Я пообщался в личке с руководителем анализа защищённости ОС Astra Linux Олегом Кочетовым по поводу кейса из вчерашнего поста.

🔹 Это может выглядеть как уязвимость, исправление которой пришло из апстрима Bash, которую зачем-то завели в БДУ по бюллетеню Астры, потеряв по дороге CVE. Но ситуация там совсем другая! Эту уязвимость обнаружили специалисты Астры, но так как она аффектила только Astra Linux, то в апстрим её не репортили (и не получали CVE), а зарепортили только в БДУ. Такие уязвимости можно отличать по идентификаторам "ASE" (ранее "ALV").

🔹 В бюллетенях, исправляющих CVE-шные уязвимости, ссылки на CVE проставляются, но могут быть накладки, когда одну и ту же уязвимость репортят разные вендоры.

Подробнее Олег расскажет 12 апреля на CISO Forum в докладе "Как не утонуть в море уязвимостей или как мы управляем кораблем «ОС Astra Linux»"

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

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

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

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

🔹 Аналитический блок открыл Рустэм Хайретдинов. Его основные тезисы: 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-щика понимать предметную область настолько, чтобы отличать, когда тебе вешают лапшу на уши, а когда за этим реально что-то есть. То есть самому быть в какой-то степени админом/девопсом/разрабом, но с расширенными знаниями в области уязвимостей систем и ИБ вообще. 😉