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

VM Dev Tasks: Разработка консольной утилиты - сканера уязвимостей

Добавить комментарий

VM Dev Tasks: Разработка консольной утилиты - сканера уязвимостей

VM Dev Tasks: Разработка консольной утилиты - сканера уязвимостей. Сканер уязвимостей взаимодействует с сетевыми хостами в инфраструктуре организации и определяет для них известные (CVE, БДУ) уязвимости. Взаимодействие может подразумевать выполнение команд на самом хосте (подключение к установленному на хосте агенту или безагентное подключение по SSH, WinRM и т.д.) или не подразумевать этого (взаимодействие с сервисами на открытых портах хоста).

В рамках проекта потребуется реализовать:

🔹 парсеры для источников информации об уязвимостях для некоторого набора софтов/ОС/сетевых устройств (лучше выбирать не самое очевидное и распространённое, но при этом востребованное); на основе этой информации сгенерировать формальные правила детектирования уязвимостей (например, на языке OVAL)
🔹 скрипты инвентаризации состояния хоста
🔹 скрипты детектирования уязвимостей по сгенерированным ранее правилам

В идеале попробовать реализовать генерацию правил детектирования с помощью LLM.

Возможно ли использовать AI для детектирования уязвимостей?

Добавить комментарий

Возможно ли использовать AI для детектирования уязвимостей?

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

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

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

Сравнение сканеров уязвимостей по качеству детектирования - важная тема

Добавить комментарий

Сравнение сканеров уязвимостей по качеству детектирования - важная тема

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

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

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

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

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

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

Можно ли заниматься Управлением Уязвимостями без бюджета?

Добавить комментарий

Можно ли заниматься Управлением Уязвимостями без бюджета?

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

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

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

Про конкуренцию и тестирование

Добавить комментарий

Про конкуренцию и тестирование

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

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

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

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

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

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

No Boot - No Hacker!

1 комментарий

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 файл

Ещё одним аспектом инцидента с CrowdStrike является то, что Windows хосты сломало не функциональное обновление агента, а обновление "контента обнаружения"

1 комментарий

Ещё одним аспектом инцидента с CrowdStrike является то, что Windows хосты сломало не функциональное обновление агента, а обновление контента обнаружения

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

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

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

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

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