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

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

Ещё немного про то, что не все сканеры одинаково хороши

Ещё немного про то, что не все сканеры одинаково хороши

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

Доводя до абсурда, можно написать утилиту, которая будет детектировать одну CVE-шку, приделать к ней вебгуй с дашбордами и презентовать это как "сканер уязвимостей", альтернативу ТОП-овым решениям на рынке. Уязвимость ищет? Ищет! А то что одна - а сколько вам надо? Не знаете? Ну так чего теперь. 🤪

А если перелицевать и соединить опенсурсные утилиты, которые уязвимости действительно детектят (GVM/OpenVAS, OpenSCAP/Wazuh, Nmap с плагинами, Nuclei и т.д.), вообще не прикопаешься. 😉 С хостами софтина взаимодействует, список уязвимостей выдаёт. Достаточно ли хорошо? А фиг его знает. 🤷‍♂️

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

Не сканер детектирует уязвимости, а VM-щик детектирует уязвимости с помощью сканера

Не сканер детектирует уязвимости, а VM-щик детектирует уязвимости с помощью сканера

Не сканер детектирует уязвимости, а VM-щик детектирует уязвимости с помощью сканера. Такая вот невероятно глубокая мысль. 🙂 Сканер уязвимостей это просто инструмент. Если этот инструмент не выполняет заявленные функции, это не снимает ответственность с того, кто этот инструмент закупил и использует.

Представим ситуацию: сканер фолснегативил при детекте уязвимости, через неё поломали организацию. VM-щик бежит с претензией к VM-вендору. После боданий, если получилось доказать проблему, вендор извиняется и выпускает обновлённый детект. И всё. А из-за этой уязвимости возможно всю инфру пошифровали. 🤷‍♂️ И кто в этой ситуации будет крайним и будет иметь бледный вид?

Пока нет обязательной сертификации VM-решений, предъявляющей требования к детектированию уязвимостей, и/или ответственности за некачественный детект, оценка качества работы решений целиком лежит на клиенте. И, к сожалению, делать это нужно не только перед закупкой, но и в течение всего периода эксплуатации.

Про Endpoint Vulnerability Detection

Про Endpoint Vulnerability Detection

Про Endpoint Vulnerability Detection. Поделюсь некоторыми соображениями, болями и хотелками по поводу отечественных средств детектирования уязвимостей инфраструктуры.

1. Если брать только ОС-и, то основная боль детектирования уязвимостей это Windows и macOS. Особенно Windows: и по KBшкам, и для Third-Party. Я верю, что в какой-то перспективе от этого в российском энтерпрайзе откажутся, но пока оно есть и требует поддержки. С Linux, особенно в той части детектов, которые обычно реализуют VM-вендоры, детект только по бюллетеням безопасности и версиям пакетов, можно сказать, терпимо.
2. Архитектура и интерфейсы управления отечественных VM решений (я намеренно не буду никого конкретного называть, считайте, что это в среднем по больнице) это просто беда. Трудно развертывать, трудно эксплуатировать, трудно дебажить. Лучше бы этого переусложненного безобразия не было вовсе. 😔
3. Функциональности по детектированию уязвимостей, которая есть в бесплатном ScanOVAL ФСТЭК в принципе было бы достаточно, если бы он не был специально ограничен с точки зрения автоматизации работы. Понятно почему ограничен - забесплатно и так очень круто, тут вопросов нет. Но если бы был, допустим, сканер аналогичный ScanOVAL, но позволяющий запускаться в неинтерактивном режиме с возможностью подложить ему OVAL-контент (или в другом формате - не важно) и получить результаты детектирования - это был бы отличный продукт, за который можно было бы платить вменяемые деньги. Поддержание работы движка и наполнение контента это тяжёлая, важная и трудоемкая работа, это должно финансироваться, тут тоже без вопросов. Я бы топил за такое. Назовем такой класс продуктов, например, Local Vulnerability Scanner.
4. Допустим у нас есть консольная сканилка из предыдущего пункта. Как должно выглядеть вменяемое взаимодействие агента и сервера? Максимально просто и прозрачно для конечного пользователя (№*?@%#$🤬💪)!!! Агент на устройстве должен периодически брать адрес сервера (обычного web-сервера, REST API) из текстового конфига, спросить у сервера "есть у тебя новый контент?", если есть, то скачать его, запустить детект и залить результаты детекта на сервер. Всё! Это тривиально запиливается на скриптах за неделю. И агентная часть, и серверная. И дебажится в случае непоняток ручным выполнением тех же самых запросов с таргет-хоста. И агентная обвязка, и сервер это вообще может быть опенсурс. Вменяемому клиенту все эти интерфейсные красивости, на которые VM-вендоры палят столько ресурсов либо вообще не нужны, либо абсолютно второстепенны.

Сомневаюсь я, конечно, что кто-то из VM-вендоров прислушается и выпустит базовое решение для детекта уязвимостей а-ля ScanOVAL, но с возможностями для автоматизации. Или, что возможности автоматизации добавят непосредственно в ScanOVAL. Или, что агентное сканирование сделают по-человечески, нормально и прозрачно. Но высказываться в эту сторону, имхо, нужно. А то так и продолжим терпеть с улыбочкой всю эту лютую дичь. 😬