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

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

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

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

Доводя до абсурда, можно написать утилиту, которая будет детектировать одну 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. Или, что агентное сканирование сделают по-человечески, нормально и прозрачно. Но высказываться в эту сторону, имхо, нужно. А то так и продолжим терпеть с улыбочкой всю эту лютую дичь. 😬