Оценка адекватности используемых решений по детектированию уязвимостей. Заканчиваю отвечать на пост Алексея Лукацкого с критикой БОСПУУ. Согласен, что оценивать полноту базы детектов уязвимостей и достаточность способов детектирования непросто, и это имеет смысл только в контексте инфраструктуры конкретной организации.

Как оценивать?

🔹 Видим актив в инфре. Задаём вопрос: он в принципе поддерживается средством детектирования?

Если нет, то чешем репу, что делать: стимулировать VM-вендора, покупать другую детектилку / делать её самим, менять инфру.

Если да, идём глубже.

🔹 А как именно происходит детектирование?

Допустим, это Linux хост, и сканер детектирует уязвимости ТОЛЬКО в пакетах установленных из официального репозитория.

Нам этого достаточно? У нас там точно нет софта, установленного по-другому? 😏

Если достаточно, то всё ок.

Если нет - чешем репу как расширить способы детекта (пентест/WEB, анализ контейнеров и т.п.). Или меняем инфру. 🤷‍♂️

Далее

@avleonovrus #БОСПУУ #VMprocess #Detection

А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей. Безусловно, недостаточно одной констатации VM-вендором, что тот или иной способ детектирования уязвимостей реализован в полной мере. Нужно идти ещё глубже.

Берём тот же базовый пример: детектирование уязвимостей на Linux хосте в пакетах из официального репозитория. Казалось бы - чего проще. Парсишь бюллетени безопасности (или даже готовый OVAL-контент Linux-вендора берёшь) и сравниваешь версии пакетов.

В реальности ошибиться можно много где. Самое частое:

🔹 Функция сравнения версий пакетов (например, эпоху не учитывают)
🔹 Источник безопасных версий пакетов (когда в бюллетенях source пакеты, а от них нужно перейти к версиям бинарных пакетов).

Особенно наглядно бывает, когда один хост проверяется несколькими сканерами. И в случае расхождений каждый вендор говорит, что их результаты правильные. 🤷‍♂️🤪 Пока не будет доказано обратное. 😏

@avleonovrus #БОСПУУ #VMprocess #Detection

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

Да можно. 🙄 Я вообще мало знаю людей, кто этим заморачивается. К сожалению, большинство относится формально. Принимают всё на веру, VM-вендоров лишний раз не стимулируют. 🤷‍♂️

К чему это приводит? Маркетинг VM-вендоров решает, что детекты это коммодити, качество их никому не интересно и продажи не улучшает. Разработчики в VM-вендорах расслабляются. Главное же, чтобы на полностью обновлённой системе всё зелёненькое было, а на необновлённой красненькое. Остальное не так и важно, правда? 😏 VM-продукты деградируют.

Весь пафос VM-специалистов сыпется от того, что источник продетектированных уязвимостей неадекватный. И так оно тянется вплоть до реальных инцидентов, в которых VM-щики становятся крайними. 🤷‍♂️

В итоге имеем порочный круг лени и наплевательства, который гробит всю идею VM-а. 😔

@avleonovrus #БОСПУУ #VMprocess #Detection

Верный признак хорошего вендора средств детектирования уязвимости - это то, что его сотрудники делится экспертизой по детектированию уязвимостей на конференциях, в статьях, видео-роликах и т.д.

Когда люди всерьёз занимаются какой-то темой, они неизбежно сталкиваются с проблемами (иногда весьма курьёзными), приходят к каким-то решениям и у них возникает желание поделиться опытом.

А когда этого нет, возникают вопросы:

🔹 Может детектирование уязвимостей это примитивная сфера деятельности и обсуждать там нечего? Но мы-то знаем, что сложностей там хватает. 😉

🔹 Или, возможно, для вендора качество и полнота детектирования уязвимостей не являются приоритетом? 😏 Разработчики правил детектирования что-то пилят на расслабоне. Клиентам вроде норм. В этом случае акцентировать лишнее внимание на детектах невыгодно, так ведь? 🙈🙊

В общем, техническим статьям про детект уязвимостей всегда рад, стараюсь читать и подсвечивать. 😉 Если вдруг что-то пропустил, пишите в личку - исправлюсь.

@avleonovrus #VMprocess #Detection

Ещё одним аспектом инцидента с CrowdStrike является то, что Windows хосты сломало не функциональное обновление агента, а обновление "контента обнаружения". Дальше процитирую блогпост Алексея Лукацкого про CrowdStike (весьма годный 👍):

"Да и вообще, признайтесь, кто из вас проверяет прилетающий контент обнаружения в любом из ваших средств защиты — антивирусу, EDR, IDS, WAF, NGFW, SIEM, NTA, XDR?.. Ведь никто же!"

Я бы ещё и VM сюда добавил до кучи. 😉

И это беда. Почему-то считается, что "контенту обнаружения", который зачастую представляет собой те же мутные бинари, можно слепо доверять и автоматом пробрасывать его на хосты. BSODStrike показал к чему это может привести.

Имхо, необходимо разбираться, что же это за "контент обнаружения" такой и, при любой непрозрачности, также прогонять его на тестовом скоупе. А как иначе, если они и контентом хосты ушатывают. 🤷‍♂️🤦‍♂️ А на убеждения вендоров, что у них всё "просчитано до муллиметра", вестись не следует.

@avleonovrus #BSODStrike #SecurityContent #Detection

No Boot - No Hacker! Обновлённый трек. Кажется кейс с инцидентом CrowdStrike BSODStrike подходит к логическому завершению. По причинам уже всё более-менее понятно. Остались только долгие судебные тяжбы клиентов с вендором. Поэтому закрываю для себя эту тему обновлённым треком, сделанным в Suno.

Добавил свою позицию, что дело не столько в проблемах конкретной компании, сколько в проблемах облачных ИБ сервисов с агентами, архитектура которых уязвима, и которым клиенты слишком доверяют. 🤷‍♂️ Замалчивать это мне не кажется правильным, нужно пытаться хоть как-то это компенсировать. Следует понимать, что сейчас был всего лишь небольшой и относительно безобидный сбой, но когда-нибудь мы увидим кейс с полномасштабной атакой злоумышленников через облачного вендора. И, как мне кажется, в настоящий момент онпрем решения имеют свои преимущества.

CrowdStrike - это успех!
Поверь мне, это так.
Защищает он лучше всех
От любых кибератак.
Проактивный подход,
Секретное оружие:
Не справится хакер,
Если ОСь не загружена!

Припев:
Синий экран отражает атаки!
No boot - No Hacker!
No boot - No Hacker!

CrowdStrike работает по лучшей из схем,
С которой не может быть никаких проблем!
На ваших хостах Falcon сенсоры. Их привилегии максимальны.
А CrowdStrike управляют ими из своих облаков. И это нормально!
(Якобы...)
Команда CrowdStrike даже ночью не спит,
Автоматом заливает вам Rapid Response Content "at operational speed".
(Когда захочет...)

И если вам кажется, что всё это как-то страшновато,
Не переживайте: CrowdStrike пропускает контент через валидатор!
(Великий ВАЛИДАТОР!)

Не работает биржа, не летают самолёты - это всё детали...
Всего лишь маленький баг в апдейтах, злодеи через вендора вас не атаковали...
(Пока что...)
За полтора часа сломать 8.5 миллионов хостов - задача нелегка...
С таким не справится устаревший онпрем, для такого нужны облака...

А если серьёзно... В 22-ом CrowdStrike из России ушёл...
И, как по мне, это очень, очень, ну просто ооочень хорошо!

MP3 файл

@avleonovrus #fun #music #поёмCVE #CrowdStrike #BSODStrike #Microsoft #Windows #CloudAgent #SecurityContent #Detection #onprem

Про конкуренцию и тестирование. Частенько натыкаюсь на размышления, что в России слишком много каких-то IT/ИБ продуктов (например, Linux-дистрибутивов или NGFW) и нужно их подсократить.

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

🔹 Отечественная ОС у вас? 👍 А кто апстримы? Пакеты сами собираете? А как быстро уязвимости апстримов фиксите? У нас тут тестовые эксплоиты есть, прогоним? 🙂 А где ваши бюллетени безопасности? А как вы проверяете, что от апстрима бэкдор не придёт? А у нас тут Challenge Projects, проверите бэкдоры в них? 😎

🔹 NGFW у вас? 👍 А что детектить умеет? А какую нагрузку держит? А у нас есть тестовый трафик с атаками, прогоним? 😉

🔹 Сканер уязвимостей у вас? 👍 У нас тут есть стенды с известными уязвимостями, просканим? 😏

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

@avleonovrus #competition #Linux #OS #NGFW #detection

Можно ли заниматься Управлением Уязвимостями без бюджета? Ну, в принципе да. Если посмотреть на схему БОСПУУ, то там большая часть работ не требует закупки каких-либо решений. Детектирование и описание активов вы можете делать самостоятельно. Согласовывать с владельцами активов SLA на устранение уязвимостей (и, желательно, регулярный патчинг) - тоже. Заведение тасков и отслеживание их статуса не так сложно заскриптовать.

Основной затык - детектирование уязвимостей. Сложно представить себе инфраструктуру организации, для которой будет достаточно одних бесплатных утилит. Разве что там используются только Linux хосты и софт ставится только из официального репозитария. Тогда да, хватит OpenSCAP с контентом от вашего Linux-вендора. 🙂

При использовании коммерческих решений тоже будут "слепые пятна" - инсталляции софта или железа, для которых уязвимости не детектируются. Но при использовании только бесплатных утилит это будет одно сплошное "слепое пятно". 🙈

@avleonovrus #БОСПУУ #VMprocess #Detection

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

"Получается можно купить дорогое VM-решение и НЕ получить надёжный поток продетектированных уязвимостей? Даже критичных и эксплуатабельных?" 😯

Вот представьте себе! 🤷‍♂️ VM-вендор может

🔹 вообще не поддерживать какие-то софты
🔹 не детектировать какие-то CVE для каких-то софтов
🔹 только декларировать, что детектирует какие-то CVE, а на самом деле детекты будут отрабатывать некорректно; или будут отрабатывать корректно только в определённых режимах (например, с аутентификацией)

Я не понимаю, когда говорят, что сканер детектирует слишком много уязвимостей в инфраструктуре и исправлять нужно 2%. Как по мне, беда в обратном - уязвимостей детектируется слишком мало, они детектируются не все. И среди недотектируемых могут быть самые опасные.

Upd. переформулировал

@avleonovrus #VMbenchmark #Detection

Возможно ли использовать AI для детектирования уязвимостей? Думаю да, но тут нужно определиться, что мы под этим понимаем.

🔻 Если речь идёт об обнаружении ранее неизвестных уязвимостей, о ресёрче, то здесь AI инструменты работают уже сейчас. Буквально на днях, 1 ноября, исследователи из Google Project Zero обнаружили первую реальную эксплуатабельную уязвимость с помощью своего LLM проекта Big Sleep. Это была stack buffer underflow в SQLite. Очень круто и многообещающе. 👍

🔻 Если же речь идёт об известных (CVE) уязвимостях, то задача сводится к генерации чётких правил их детектирования в инфраструктуре. AI должен взять на вход имя продукта и вендора, обнаружить источник данных об уязвимостях, понять структуру данных и как можно из них сгенерировать формальные правила для детектирования (например, на языке OVAL), произвести генерацию и оценить корректность правил. Не выглядит как что-то невероятное, но практических реализаций этого я пока не встречал. 🤷‍♂️

@avleonovrus #AI #SQLite #Google #OVAL #Detection