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

О сертификации VM-продуктов по качеству детектирования

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

О сертификации VM-продуктов по качеству детектирования

О сертификации VM-продуктов по качеству детектирования. Моё мнение - такая сертификация должна быть. Добровольная или обязательная, государственная или негосударственная. Но хоть какая-то должна быть. Это ненормально, когда вендор может начать продавать буквально любой треш, а задача оценки качества детектирования уязвимостей (равно как и ответственность в случае инцидента) целиком ложится на клиента. 🤷‍♂️ Рыночек тут не порешает.

Такая сертификация должна гарантировать приемлемый уровень качества детектирования уязвимостей для типичной IT-инфраструктуры российской организации.

И тут встают очень интересные вопросы:

🔹 Какая инфраструктура типичная? Кто это может решить? У кого есть такая статистика?

🔹 Результаты работы какого средства детектирования (с каким движком и контентом) должны браться за эталон?

🔹 Как будут решаться спорные вопросы?

Если с этим определиться, то создание автоматических тестов становится делом техники.

О сравнении VM-продуктов

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

О сравнении VM-продуктов

О сравнении VM-продуктов. Имхо, сравнение VM-продуктов по опросникам, а-ля Cyber Media, это, конечно, лучше, чем ничего, но не сказать, что особенно полезно. 🤷‍♂️

🔻 В таких сравнениях обычно уделяют мало внимания тому, уязвимости в каких системах умеет детектировать VM-решение (а это самое главное!).

🔻 Но даже если представить, что мы вынесем в опросник все поддерживаемые системы и аккуратненько сопоставим декларируемые возможности каждого VM-решения, то и этого будет недостаточно. Декларировать можно всё что угодно, а ты поди проверь качество реализации. 😏

Имхо, при проведении сравнений необходимо выполнять практическое тестирование хотя бы на минимальном количестве стендов:

🔹 Типичный Windows десктоп и сервер
🔹 Типичный Linux десктоп и сервер
🔹 Типичное сетевое устройство (на Cisco IOS?)

Провести их сканирование в режиме с аутентификацией разными VM-продуктами, сопоставить результаты и предложить VM-вендорам объяснить расхождения. Это будет уже хоть что-то. 😉

Следующее мероприятие, на котором я планирую выступить - форум "ТЕРРИТОРИЯ БЕЗОПАСНОСТИ 2025: все pro ИБ" 3 апреля

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

Следующее мероприятие, на котором я планирую выступить - форум ТЕРРИТОРИЯ БЕЗОПАСНОСТИ 2025: все pro ИБ 3 апреля

Следующее мероприятие, на котором я планирую выступить - форум "ТЕРРИТОРИЯ БЕЗОПАСНОСТИ 2025: все pro ИБ" 3 апреля. В рамках технологической панели "А ты точно умеешь это детектировать? Правила детекта уязвимостей" у меня будет 20-минутный доклад "Уровни сравнения качества детектирования уязвимостей".

О чём расскажу:

🔹 Зачем нужно заниматься оценкой качества детектирования уязвимостей и как это связано с БОСПУУ.

🔹 Примеры публичных сравнений качества детектирования. Спасибо Алексею Лукацкому за напоминание про сравнение Principled Technologies 2019 года. 👍 Оказывается у меня был про него содержательный пост в англоязычном канале. 😇 Ну и про сравнение PentestTools (2024) и Securin (2023) тоже добавлю.

🔹 Уровни сравнения: просто по CVE, по CVE с учётом метода детекта, практическое сравнение на стендах. Возможно какие-то ещё? 🤔

Если у кого есть что вкинуть по теме, пишите в личку - буду рад пообщаться. И до встречи на Территории Безопасности!

О детекте уязвимостей софтов, установленных не из официального репозитория Linux-вендора

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

О детекте уязвимостей софтов, установленных не из официального репозитория Linux-вендора

О детекте уязвимостей софтов, установленных не из официального репозитория Linux-вендора. У моего коллеги по PT ESC Владислава Молькова на прошлом PHDays был доклад про детектирование уязвимостей Linux-хостов. Один из кейсов там был про софт установленный не из официального репозитория Linux-вендора, а из сторонних пакетов вендора софта (допустим, nginx) или из исходников. Как для такого софта уязвимости искать? Ведь детект по бюллетеням или OVAL-контенту Linux-вендора тут не поможет. 🤷‍♂️

Инсталляцию и версию запущенного софта можно найти в "ps -eo pid,cmd". Для nginx будет а-ля "nginx/1.22.1".

А откуда брать для них известные уязвимости? Брать их придётся из бюллетеней вендора софта, таких как nginx security advisories.

Т.е. для каждого подобного софта, придётся:

🔹 написать "непакетные" детекты
🔹 найти бюллетени вендора этого софта и превратить их в правила детектирования

И всё это для того, чтобы найти уязвимости Linux-софтов там, где сканер попроще их не найдёт. 😉

Новый выпуск "В тренде VM": горячие уязвимости ноября, управление уязвимостями без бюджета и кто должен искать патчи

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

Новый выпуск "В тренде VM": горячие уязвимости ноября, управление уязвимостями без бюджета и кто должен искать патчи. Конкурс на лучший вопрос по теме VM-а продолжается. 😉🎁

📹 Ролик на VK Видео, RUTUBE, YouTube
🗞 Пост на Хабре
🗒 Дайджест на сайте PT

Содержание:

🔻 00:33 Уязвимость раскрытия хеша NTLMv2 в Windows (CVE-2024-43451)
🔻 01:20 Уязвимость повышения привилегий в Windows Task Scheduler (CVE-2024-49039)
🔻 02:20 Уязвимость подмены отправителя в Microsoft Exchange (CVE-2024-49040)
🔻 03:07 Уязвимости повышения привилегий в утилите needrestart (CVE-2024-48990)
🔻 04:15 Уязвимость удаленного выполнения кода в FortiManager (CVE-2024-47575)
🔻 05:23 Уязвимость обхода аутентификации в веб-интерфейсе PAN-OS (CVE-2024-0012)
🔻 06:36 Уязвимость повышения привилегий в PAN-OS (CVE-2024-9474)
🔻 07:46 Уязвимость обхода каталога в межсетевых экранах Zyxel (CVE-2024-11667)
🔻 08:41 Можно ли заниматься Управлением Уязвимостями без бюджета?
🔻 09:57 Кто должен искать патчи для устранения уязвимостей?
🔻 10:55 Полный дайджест с трендовыми уязвимостями
🔻 11:22 Бэкстейдж

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), произвести генерацию и оценить корректность правил. Не выглядит как что-то невероятное, но практических реализаций этого я пока не встречал. 🤷‍♂️