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

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

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

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

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

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

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

Прибыл на Территорию Безопасности

Прибыл на Территорию БезопасностиПрибыл на Территорию БезопасностиПрибыл на Территорию БезопасностиПрибыл на Территорию Безопасности

Прибыл на Территорию Безопасности. Первый раз в Hyatt Regency Moscow Petrovsky Park. Дорого-богато-просторно. 👍 Зона выставки и кейтеринга прям здоровенная. Хорошая площадка. Зал тоже отличный и вместительный. Ну разве что экран можно было бы поконтрастнее, но это уже придирки.

На Территории Безопасности собираюсь чуть менее чем всё время провести в VM-треке

На Территории Безопасности собираюсь чуть менее чем всё время провести в VM-треке
На Территории Безопасности собираюсь чуть менее чем всё время провести в VM-трекеНа Территории Безопасности собираюсь чуть менее чем всё время провести в VM-трекеНа Территории Безопасности собираюсь чуть менее чем всё время провести в VM-трекеНа Территории Безопасности собираюсь чуть менее чем всё время провести в VM-треке

На Территории Безопасности собираюсь чуть менее чем всё время провести в VM-треке. Галочками пометил то, где планирую быть. Вопросиками пометил то, где мне кажется может быть оффтоп и что я, возможно, смотреть не буду (безусловно, субъективно, но вдруг вам тоже интересно 😉). Также на карте выставки отметил места вендоров связанных с Vulnerability Management / Compliance Management.

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