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

Продолжу разбирать "10 неудобных вопросов Product Manager-у по VM" из подкаста коллег из R-Vision

Продолжу разбирать 10 неудобных вопросов Product Manager-у по VM из подкаста коллег из R-Vision

Продолжу разбирать "10 неудобных вопросов Product Manager-у по VM" из подкаста коллег из R-Vision.

Вопрос 2: Вы можете гарантировать, что в вашем сканере уязвимостей не будет фолзов?

💬 Андрей Селиванов сначала пошутил, что можно гарантировать отсутствие фолзов, если просто не проводить сканирование. 😏 Далее сказал, что фолзы (некорректные детекты каких-то уязвимостей) есть в абсолютно любом решении. Причин для этого может быть масса: от некорректной информации по детектированию уязвимости в источнике данных об уязвимости (например, бюллетене RHSA вендора Red Hat или на странице с описанием уязвимости Microsoft) до ошибок при написании правил детектирования на стороне VM-вендора. Важны два параметра: процент допустимых фолзов в решении VM-вендора и то, как быстро VM-вендор их устраняет (принимая от клиентов через форму обратной связи).

#️⃣ С этим тоже не поспоришь. Но я бы посмотрел несколько шире. Фолзы - это не только про то, что какие-то конкретные правила детектирования были реализованы некорректно. Хотя, безусловно, и это тоже, и хотелось бы, чтобы такие проблемы VM-вендор ловил самостоятельно, а не только после того, как их зарепортят клиенты. 😉 Это ещё и про зрелое восприятие возможностей VM-продукта и зрелое позиционирование VM-продукта вендором.

🔹 Если сканер не детектирует какие-то уязвимости в инфраструктуре, потому что не поддерживает те или иные продукты или способы установки, это со стороны клиента может выглядеть как false negative. А может как вполне осознаваемые ограничения детектирования VM-продукта.

🔹 И с другой стороны, то, что упомянул вскользь Андрей "многое зависит от окружения, от специфических условий", когда сканер детектирует уязвимости в библиотеке, которая по факту не используется, это может восприниматься со стороны клиента как жуткие false positive ошибки. А может как особенность детектирования "потенциальных" уязвимостей сканером.

Тут, наверное, хотелось бы, чтобы мы (как VM-комьюнити) отходили от восприятия любых средств анализа защищённости как волшебных оракулов, которые выдадут все 100% имеющихся уязвимостей в инфраструктуре. Конечно же, нет. 🤷‍♂️

Детектирование всех уязвимостей конкретной инфраструктуры - это сложная задача. За которую ответственен в первую очередь VM-специалист. И VM-специалист должен понимать ограничения используемых средств анализа защищённости и выбирать наиболее адекватные из них (а не самые дешёвые 😉).

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) "10 неудобных вопросов Product Manager-у по VM"

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) 10 неудобных вопросов Product Manager-у по VM

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) "10 неудобных вопросов Product Manager-у по VM". Естественно, обсуждение шло в контексте решения R-Vision VM. Интересный формат и подборка вопросов. 🔥 Собираюсь их постепенно разобрать и добавить свои комментарии. 😉

Вопрос 1: Класс Vulnerability Management решений - это маркетинговая обёртка сканеров уязвимостей или за этим есть какие-то дополнительные технологии?

💬 Андрей Селиванов ответил в духе, что VM-решения - эволюционное развитие сканеров уязвимостей, потребность в которых возникла с увеличением количества активов (сказал, что у них есть клиент с 300 000 конечных точек и сотней миллионов уязвимостей) и увеличением разнообразия типов активов. Все уязвимости на этих активах необходимо эффективно детектировать, приоритизировать и ставить задачи на устранение. С простым сканером уязвимостей с таким объёмом справляться сложно, требуется более функциональное решение. "Но сканер - это то, по чему встречают решение в любом пилоте и у любого клиента". Важно, насколько качественно выявляются уязвимости, насколько широкое покрытие. "Если у тебя не будет нормального сканера, называться полноценным VM-решением - ну такое себе".

#️⃣ В целом, согласен со сказанным. Особенно в части качества детектирования. 👍 Единственное я бы выделил такие формальные признаки сканера уязвимостей и VM-решения: если средство анализа защищённости (САЗ) работает в парадигме отдельных сканов - это сканер уязвимостей. Классический пример - Nessus. А если САЗ хранит картину текущего состояния всей инфраструктуры (активов и уязвимостей на них), позволяет делать выборки по уязвимостям, делать приоритизацию уязвимостей, заводить и отслеживать задачи на устранение (через встроенную тикетницу или через интеграции) и производить прочую высокоуровневую обработку, то это уже решение класса Vulnerability Management. Потому что это решение реализует внутри себя Vulnerability Management процесс. Ну или, во всяком случае, вендор решения это декларирует и к этому стремится. 😉

При этом я НЕ считаю, что любое VM-решение априори лучше любого сканера уязвимостей и должно стоить дороже.

🔹 И сканер уязвимостей может быть оправданно дорогим, если он реализует востребованную, крутую и качественную экспертизу по детектированию. Даже если он поставляется в виде консольной утилиты, а то и вовсе в виде фида с контентом.

🔹 В свою очередь VM-решение может лишь формально реализовывать заявленную функциональность и, к примеру, не справляться с реальной нагрузкой (особенно если его навайбкодили за выходные 😉). VM-решение вообще может быть опенсурсным проектом, типа Faraday Security или DefectDojo, и стоить (ну, в теории 😏) 0 руб.

Так что маркетинговые категории мало чего значат на самом деле. Нужно смотреть в суть.

Как работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимости

Как работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимости

Как работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимости. Есть готовые интеграции с Security Vision или R-Vision (+ компании предоставили урезанные бесплатные версии продуктов только для инвентаризации), BiZone TDR и GRC, Ansible.

Для уязвимостей есть признаки эксплуатации вживую и публичные эксплоиты, есть расчёт критичности по методике ФСТЭК, есть проверенные патчи (они там появляются раньше и их больше, чем на БДУ ФСТЭК), можно заводить задачи на устранение с автоматическим закрытием при перескане.

Напоминает зародыш российского "Qualys-а". 🤔 Не хватает только облачных агентов и апплаенсов. И неплохо было бы загружать не только инвентаризацию, но и уязвимости продетектированные сторонним сканерами. 😉

Учитывая, что это всё бесплатно, всему нашему VM-рынку стоит обратить внимание и задуматься, чем это крыть.

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening. 😉 По поводу этой картинки Mads Bundgaard Nielsen-а, о которой писали Александр Редчиц и Алексей Лукацкий, у меня вопросов нет. Ну, во всяком случае, по моей части. 😏

Видим у Vulnerability Management-а и Compliance Management-а (Наrdening-а) очень высокую эффективность при средней цене. И это должен быть первый приорититет у CISO. ⚡️

После Firewall-а. 🙄 Тут спорно, но пусть будет так. Без NGFW заниматься безопасностью действительно не сладко.

В общем, одобряю картинку. 🙂👍

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким. У Алексея Викторовича очень необычный взгляд на вопросы Vulnerability Management-а и мастерские формулировки. 👍🙂📝 Отметил для себя 3 темы, которые было бы интересно подробнее разобрать:

🔻 VM и облачные SaaS-провайдеры. Как контролировать, что провайдер имеет адекватный VM-процесс (да и вообще ИБ) у себя, учитывая, что в случае инцидента отвечать будет не провайдер, а клиент-жертва.

🔻 Статьи о гос. измене / шпионаже (УК РФ 275, 276) и репортинг уязвимостей зарубежным вендорам, организациям и базам уязвимостей. Насколько реальна опасность для исследователя, как поступать правильно и безопасно?

🔻VM-вендорам интересно поддерживать не все продукты. Что делать клиентам (навскидку: пушить VM-вендора, пилить свои детекты, выбирать решения с учётом возможностей VM)?

"Патчить абсолютно всё невозможно и безыдейно" меня, конечно, триггернуло. 🙄

Стоит ли использовать в вашей организации пиратское VM-решение?

Стоит ли использовать в вашей организации пиратское VM-решение?

Стоит ли использовать в вашей организации пиратское VM-решение? На аргументах про этичность и законность останавливаться не буду (см. 146, 272, 273 УК РФ и штрафы для юрлиц). 🙂 По технике:

🔻 Как вы можете гарантировать, что в скаченную откуда-то сборку не внесли НДВ? Троян, майнер, криптолокер с отложенным запуском. Это вполне естественный способ монетизации для релиз-команды. И чем вы оправдаетесь в случае инцидента?
🔻 В развернутое VM-решение будут забивать учётки для сканирования. Оно будет заходить на таргет-хосты и выполнять произвольные команды (как правило, с привилегиями рута/админа). Вы точно хотите "ZVER-сборку" туда пускать?
🔻 Если у вас правила детектирования уязвимостей не обновляются, то вы сможете определить с помощью такого решения только старый ли таргет-хост как гуано мамонта или нет. Полезность сомнительная. 🙂

А главное нафига рисковать, если можно официально запросить у вендора триалку и тестить сколько потребуется с поддержкой и прочим. 😉

После продолжительного перерыва выпустил англоязычную видяшку и блогопост

После продолжительного перерыва выпустил англоязычную видяшку и блогопост. Разбираю там то, что произошло за последние 3 месяца. В первую очередь в плане улучшений Vulristics. Во вторую - смотрю какие были интересные уязвимости в Microsoft Patch Tuesday, Linux Patch Wednesday и из остальных. Ну и подвожу итоги 2023, а также намечаю направления работы на 2024.

Из занимательного:

🔻 Подсветил 7 уязвимостей из Microsoft Patch Tuesday, для которых за последние 3 месяца появились PoC-и/эксплоиты. Как правило это совсем не те уязвимости, на которые указывали VM-вендоры в своих обзорах. 😏
🔻 В Linux Patch Wednesday за последние 3 месяца было 90 уязвимостей с PoC-ами/эксплоитами (и это не считая тех, про которые известно, что они в активной эксплуатации). 🙈

Постараюсь по англоязычным блогопостам с видяшками вернуться в ежемесячный режим. 😇 Формат хоть и муторный, но полезный.

———

November 2023 – January 2024: New Vulristics Features, 3 Months of Microsoft Patch Tuesdays and Linux Patch Wednesdays, Year 2023 in Review

Hello everyone! It has been 3 months since the last episode. I spent most of this time improving my Vulristics project. So in this episode, let’s take a look at what’s been done.

Also, let’s take a look at the Microsoft Patch Tuesdays vulnerabilities, Linux Patch Wednesdays vulnerabilities and some other interesting vulnerabilities that have been released or updated in the last 3 months. Finally, I’d like to end this episode with a reflection on how my 2023 went and what I’d like to do in 2024.

New Vulristics Features
00:32 Vulristics JSON input and output
02:37 CPE-based vulnerable product names detection
04:16 CWE-based vulnerability type detection

3 Months of Vulnerabilities
07:03 Linux Patch Wednesday
11:22 Microsoft Patch Tuesdays
13:59 Other Vulnerabilities

16:14 About the results of 2023
18:45 What about 2024?

📘 Blogpost
🎞 VKVideo