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

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

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

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

Важно ли, что именно у сканера уязвимостей "под капотом"? На презентации Сканер-ВС 7 Александр Дорофеев поднял интересную тему сравнения подходов к детектированию уязвимостей. Поделюсь своим мнением:

🔹 Я видел много разных сканеров уязвимостей, и у меня сейчас нет предпочтений в том, как должна описываться логика детектирования уязвимостей. Глядя со стороны клиента, мне без разницы, что у сканера "под капотом": NASL/NSE/NucleiTemplates, SCAP/OVAL/NVD CPE Configurations, свои форматы описания логики на основе XML и YAML, любые таблички с версиями или произвольные скрипты. 🤷‍♂️

🔹Я даже не против, если для разных типов сканирования и/или разных типов активов будут использоваться различные подходы к детектированию. Вообще пофиг - хоть на таро гадайте. 🃏😏

Определяющим для меня является только одно - итоговое качество детектирования: чтобы количество ошибок первого и второго рода в результатах было минимальным. А как этого добивается VM-вендор - его проблемы.

О сертификации 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.