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

Продолжу разбирать "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-специалист должен понимать ограничения используемых средств анализа защищённости и выбирать наиболее адекватные из них (а не самые дешёвые 😉).

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

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

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

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

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

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

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

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

В августе этого года Pentest Tools выпустили сравнение сканеров уязвимостей по качеству детектирования

В августе этого года Pentest Tools выпустили сравнение сканеров уязвимостей по качеству детектирования

В августе этого года Pentest Tools выпустили сравнение сканеров уязвимостей по качеству детектирования. Очень круто, когда VM-вендор делает ставку на качество детектов. 👍 Но к методологии сравнения есть вопросы. 🤷‍♂️

Таргеты для сканирования взяли на vulhub. Этот репозиторий docker-compose файлов позволяет запускать Docker-контейнеры с сервисами, содержащими известные уязвимости. Далее эти сервисы проверяли разными сканерами в black-box pentest-режиме (без аутентификации) и делали выводы о возможностях детектирования.

Т.е. сравнение сканеров свели к сравнению их пентест-режимов. Уязвимости, для детектирования и эксплуатации которых требуется доступ к хосту (тот же PwnKit), - мимо. 😏

Кроме того, сравнение провели на очень небольшом скоупе уязвимых софтов (167 уязвимых сред). Это опенсурсные софты, которые свободно распространяются в виде Docker-образов. Т.е. там нет Exchange или Bitrix. Но есть, например, Gogs - Git-сервис популярный, в основном, в Китае. 🤷‍♂️