Что такое "Device Vulnerability Management" у IDC? Почему Device? Оно только для сетевых устройств что ли? Цисок, джуниперов, фортиков и прочих апплаенсов? 🤔

Ну на самом деле нет. 🙂 Хорошо, что в отчёте IDC есть отдельный небольшой раздел про определение рынка, который я сейчас разберу.

"Управление Уязвимостями Устройств [Device vulnerability management] включает в себя сетевые или локальные сканеры/агенты, которые сканируют серверы, рабочие станции, другие устройства и приложения для выявления уязвимостей безопасности в виде известных [known] дыр в безопасности (уязвимостей) или параметров конфигурации, которые могут быть проэксплуатированы."

То есть всё ок, "устройства" толкуют максимально широко, как практически все инфраструктурные активы. Фактически описывают таргеты как для СДУИ (Средства Детектирования Уязвимостей Инфраструктуры). Чтобы не припахать сюда ещё сканеры приложений делают акцент на "известных" уязвимостях, то есть детектировать должны в основном CVE-шки.

"Они могут

🔹 иметь доступ к устройствам с использованием учетных записей (имен пользователей и паролей)

или

🔹 предоставлять взгляд но устройство без использования учётных записей (hacker's view).

Сканеры с использованием учетных записей могут глубоко погрузиться в устройство, чтобы найти известные уязвимости, а hacker view имитирует атаки, чтобы понять, может ли устройство быть проэксплуатировано."

То есть фиксируют 2 типа сканирования: с аутентификацией и без. Замечаем, что тут довольно жёстко сформулированы типы сканов. Нет "пассивного сканирования" на основе анализа трафика или логов. Забыли или посчитали, что это тоже hacker view? Имхо, скорее забыли.

Дальше новый абзац:

"Эти сканеры анонимно ищут [search out] и обнаруживают [discover] устройства и пытаются найти известные уязвимости в целевых системах."

Это "анонимно" меня смутило. Но наверное имеется ввиду, что раз при сетевых сканированиях (PING или SYN) мы учётку не указываем, значит взаимодействуем с узлами "анонимно". Возможно они хотели подчеркнуть, что решение должно уметь детектить активные хосты и сервисы самостоятельно, а не полагаться только на интеграции. Но то, что это необязательное требование будет видно ниже.

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

Функциональность по приоритизации активов (которая невозможна без приоритизации уязвимостей) и оценке риска эксплуатации уязвимости является желательной, но видимо необязательной.

"Сканирование уязвимостей также распространилось на устройства интернета вещей (IoT, internet of things) / промышленной автоматизации (OT, Operational technology), а также облачные контейнеры и инфраструктуру."

Набор типов активов из первого предложения здесь дополняется. Причём включаются и "эфемерные" (в терминах BOD 23-01) активы, такие как контейнеры. Весьма интересно что выше задаются 2 типа сканирования, которые вряд ли кто-то будет использовать для OT (т.к. будут смотреть по трафику) и для облачных активов (т.к. будут использовать API).

"Помимо вендоров, предлагающих сканеры, есть и другие вендоры, которые принимают [ingest] результаты работы сканеров в свои платформы, объединяют их с другими данными и определяют приоритетность проблем [issues], которые необходимо решить. Поскольку результаты сканирования уязвимостей устройств являются основой их платформы, они включены [в DVM]."

Таким образом IDC расписываются в том, что сознательно мешают разные вещи: поставщиков информации об обнаруженных уязвимостях и обработчиков этой информации. То есть в моих терминах Средства Детектирования Уязвимостей Инфраструктуры (СДУИ) и Средства Анализа Уязвимостей (САУ). Правильно ли так делать? На мой взгляд, неправильно. Когда в одном отчёте Tenable или Qualys с выдающейся экспертизой по детекту уязвимостью и Balbix, у которых её вообще нет, это выглядит странновато. 🤷‍♂️

Итого: DVM = СДУИ + САУ 😉