Как проверить качество сканера VM-системы на практике

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

При оценке качества сканирования ИБ-команды отошли от парадигмы, что «хороший сканер» — это просто тот, который находит больше всего уязвимостей. Наше предыдущее исследование показало: на пилотных проектах 74% организаций в первую очередь оценивают точность детектирования, рассматривая её как ключевой показатель зрелости решения.

Кроме того, почти все компании — 92% — углубляются в анализ документации и заявленного покрытия, чтобы понять, насколько сканер соответствует реальным сценариям их инфраструктуры. 86% проверяют содержание карточек уязвимостей: наличие CVSS, EPSS, ссылок на патчи и эксплойты, а также дополнительных артефактов. 81% обращают внимание на качество и актуальность базы, а 64% — на скорость появления новых записей. Более половины (62%) проверяют ещё один важный параметр: корректность фиксации изменений после устранения уязвимостей.

Понимание этих практик подтолкнуло R-Vision к созданию прикладной методики оценки качества сканирования. Она помогает систематизировать весь процесс: от анализа покрытия и полноты описаний до проверки актуальности базы и точности детектирования. По сути, это инструмент, который позволяет компаниям измерять качество работы сканера не интуитивно, а системно.

1. Проверка покрытия сканера

При оценке качества сканера важно учитывать, насколько его функциональность охватывает реальные задачи и потребности сканирования ИТ-инфраструктуры компании. Ключевые параметры, на которые стоит смотреть:

• Состав ИТ-инфраструктуры. Перечень используемых ОС, прикладного ПО, СУБД, сетевого и специализированного оборудования.
• Поддерживаемые режимы сканирования. Анализ доступных режимов (например: Audit, Pentest, Compliance) и их соответствия задачам компании.

Пример карты покрытия сканера уязвимостей R-Vision VM.

2. Карточка описания уязвимости. Ключевые атрибуты

Чтобы понимать, как оценивать, приоритизировать и устранять уязвимость, карточка должна содержать ключевые данные для всестороннего анализа и принятия решений.

Среди них:

• Идентификатор уязвимости — уникальный внутренний ID, который обеспечивает отслеживание уязвимости в системе, связывает ее с тикетами и отчетами. Без него возможны дубли и путаница при работе с результатами.
• Название и описание — короткий и понятный заголовок (например, RCE в модуле X) и развёрнутое пояснение сути проблемы: где она возникает, при каких условиях и с какими последствиями. Помогает быстро оценить контекст и потенциальное влияние.
• Критичность и метрики CVSS — оценка опасности уязвимости на уровне вендора или по системе CVSS (версии 2–4). Эти данные дают технический ориентир по риску и помогают проводить последующую самостоятельную оценку приоритета устранения.
• Пользовательский рейтинг — самостоятельно рассчитанная оценка критичности с учетом особенностей инфраструктуры и других атрибутов уязвимости. Позволяет более точно определить приоритет устранения.
• Результаты сканирования — описание оснований, по которым сканер определил уязвимость. В карточке должны быть приведены понятные доказательства логики детектирования — например, какая версия ПО обнаружена на хосте и с какой версией выполнялось сравнение.
• Эксплойты и ссылки на них — указывают, можно ли эксплуатировать уязвимость на практике. Наличие эксплойта и ссылка на него подтверждают реальность риска и помогают воспроизвести проблему при тестировании исправления.
• Рекомендации и ссылки на патчи — конкретные действия по устранению уязвимости: обновление версии, изменение конфигурации, патчи (не все вендоры уязвимого ПО/ОС включают такую информацию в свои базы). Наличие прямых ссылок на патчи и инструкции экономит время специалистов и снижает риск ошибок.
• Идентификаторы и ссылки на внешние источники (CVE, БДУ ФСТЭК России и др.) — идентификаторы во внешних базах уязвимостей позволяют однозначно определить уязвимость, обеспечивая единое понимание между участниками процесса. Они помогают корректно выстраивать приоритеты устранения и находить дополнительную информацию об уязвимости во внешних источниках.
• Данные из БДУ ФСТЭК России — дополнительный контекст: от рекомендаций по устранению уязвимостей до сведений о проверке обновлений безопасности на наличие программных закладок.
• EPSS (Exploit Prediction Scoring System) — вероятность эксплуатации уязвимости в ближайшее время. Помогает расставлять приоритеты при устранении уязвимостей.
• Трендовые уязвимости — это те уязвимости, которые активно эксплуатируются злоумышленниками в атаках. Используются также при определении приоритетов устранения. Наличие собственных данных по трендовым уязвимостям показывает, что вендор обладает достаточным ресурсом и экспертизой для формирования качественной базы уязвимостей.
• Перевод на русский язык — важен для удобства работы с зарубежным ПО и ускоряет обработку результатов внутри команды.

3. Качество базы уязвимостей

Если карточка отражает, насколько полно и понятно представлены данные, то база уязвимостей показывает, насколько точно и своевременно они добавляются в продукт. В R-Vision мы рассматриваем качество базы через несколько ключевых характеристик:

Частота обновления

Чем чаще выходят обновления базы уязвимостей, тем меньше вероятность пропустить критичные уязвимости, о которых стало известно лишь недавно. Рекомендуем ориентир — обновления как минимум один раз в сутки (а лучше быстрее).

Источники данных

Важно знать, из каких источников формируется и чем обогащается база уязвимостей. Ключевой момент — поддержка фидов вендоров уязвимого ПО/ОС, чтобы обеспечивать качественное определение уязвимостей.

Принципы детектирования

Некоторые сканеры определяют уязвимости только по правилам, описанным в базах агрегаторов уязвимостей (например, NVD), не опираясь на данные и рекомендации производителей ПО. Из-за этого часть проверок может быть некорректной — логика определения уязвимостей у разных вендоров часто отличается. Качественная база формирует детект комплексно: учитывает не только версии ПО или ОС, но и дополнительные параметры. Примеры некоторых из них мы приведем ниже.

Технологические партнерства

Некоторые вендоры предоставляют данные по своим уязвимостям через закрытые партнерские каналы и не публикуют их открыто. Если в VM-решении заявлена поддержка обнаружения уязвимостей в конкретном источнике (например, отечественном производителе), желательно убедиться в существовании партнерства между ними или получить иные доказательства наличия доступа вендора VM к этим данным.

Развитие базы уязвимостей

Одним из важных параметров является скорость добавления новых источников — как по плану развития (RoadMap) самого вендора, так и по запросам клиентов. Если компании требуется поддержка дополнительных источников, уточните у вендора, предусмотрено ли их добавление и в какие сроки он готов реализовать такую интеграцию.

4. Качество детектирования уязвимостей

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

• Обновления пакетов вендором

Некоторые производители ОС (например, RHEL, Ubuntu, Debian) исправляют уязвимость, не меняя основную версию пакета — только номер сборки. Если сканер ориентируется лишь на версию, он может ошибочно посчитать систему уязвимой. Качественный сканер учитывает номер сборки и историю изменений пакета, поэтому не отмечает исправленные версии как уязвимые.

Например, в базе NVD указано, что уязвимости CVE-2023-4736 уязвимы все версии vim ниже 9.0.1833:

Однако в Debian 12 (bookworm) эта уязвимость уже исправлена в пакете vim 9.0.1378-2+deb12u2

Соответственно, если сканер не учитывает наличие подобных обновлений для пакетов и ориентируется только на данные NVD, он посчитает ПО уязвимым, хотя на самом деле проблема уже закрыта.

• Учет окружения

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

Например, критическая уязвимость CVE-2021-24078 связана со службой DNS-сервера в Windows и позволяет нарушителю выполнить произвольный код.

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

Такие случаи показывают, что без анализа окружения — статуса служб, модулей и зависимостей, зачастую сложно однозначно определить, действительно ли система подвержена уязвимости.

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

• Кумулятивные обновления Microsoft

В Windows уязвимости часто устраняются через кумулятивные апдейты, которые включают десятки исправлений сразу. Сканеры, не умеющие корректно учитывать такие обновления, могут ошибочно отмечать закрытые уязвимости как актуальные. Надежный сканер определяет наличие установленных KB (Knowledge Base) или номер актуальной сборки Windows и корректно интерпретирует, какие уязвимости уже устранены.

Андрей Селиванов, руководитель продукта R-Vision VM:

«Как показывает опыт наших пилотных проектов последних лет, уход ряда зарубежных решений и одновременное появление большого числа отечественных VM-продуктов привели к тому, что заказчики стали выделять больше ресурсов на качественное тестирование выбираемых инструментов. На рынке сформировался устойчивый спрос на продукты, соответствующие требованиям ушедших западных решений, поэтому внимательное сравнение и проверка поставляемых решений стали нормой.

Практика последних двух лет демонстрирует: проверки стали глубже — от запроса подтверждений наличия партнерских соглашений по предоставлению баз уязвимостей у вендоров до тщательного разбора логики детектирования».