Когда сканер врёт: как неточные данные создают видимость контроля

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

Но вся эта логика работает только при одном условии: исходным данным можно доверять. Любой зрелый VM-процесс опирается на данные. Именно на них дальше строятся приоритизация, постановка задач, контроль SLA, проверка устранения и отчетность. Если данные сканирования неточны, устарели или плохо применимы к реальной инфраструктуре весь процесс начинает опираться на искаженную картину.

В этом смысле сканер уязвимостей похож на измерительный прибор. Неточность в данных сама по себе кажется технической мелочью, но именно от нее зависят дальнейшие действия. Одни отклонения создают лишнюю тревогу и заставляет тратить ресурсы команды там, где это не нужно. Другие — наоборот, формируют ложное спокойствие и могут скрыть серьезную проблему.

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

Почему «нашел больше» не всегда значит «просканировал лучше»

В VM-системах количество обнаруженных уязвимостей часто воспринимается как самый простой критерий сравнения сканеров. Один инструмент показал 500 уязвимостей, другой — 900. Кажется, что второй сработал лучше. Но в данном случае все не так однозначно.

Сравнивать сканеры только по количеству обнаруженных уязвимостей — все равно что выбирать тонометр по принципу “этот показывает давление выше, значит он точнее”. В реальности важна не максимальная цифра, а достоверность измерения.

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

Качество сканирования — это не только количество обнаруженных уязвимостей. Это способность сканера дать данные, которым можно доверять и которые можно использовать в дальнейших действиях. Это подтверждается и пользовательскими ожиданиями: в исследовании R-Vision, посвященном критериям качества сканирования, на первое место среди характеристик результата сканирования вышли контекст и рекомендации по устранению уязвимостей. То есть пользователям важен не просто перечень обнаруженных уязвимостей, а понимание, насколько результат достоверен, что с ним делать дальше и как расставить приоритеты.

Где именно искажается картина

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

На практике проблема редко сводится к одной причине. Даже качественный сканер работает в условиях постоянно меняющейся инфраструктуры, множества версий ПО, особенностей конфигурации и ограничений самих методов детектирования. Именно на этом этапе и появляются искажения, которые влияют на итоговую картину.

Вот лишь несколько самых распространенных причин:

• уязвимость формально обнаружена, но в конкретной конфигурации она неприменима;
• Ошибки в логике детектирования как со стороны вендора сканера (который неточно пишет детекты и плохо верифицирует ее), так и со стороны источника разработчика уязвимого ПО, который предоставляет фиды с уязвимостями.
• версия ПО определена некорректно;
• данные по активам устарели после изменений в инфраструктуре;
• рекомендации по устранению требуют дополнительной проверки;
• часть данных об активе отсутствует, поэтому уязвимость может быть пропущена.

На практике это приводит как минимум к двум типам ошибок.

Первый — ложноположительные срабатывания (False Positive). Команда получает задачи, которые приходится перепроверять, оспаривать или закрывать как нерелевантные.

Стоит отметить, что сами по себе ложноположительные срабатывания могут восприниматься по-разному. По данным R-Vision, большинство пользователей VM-решений допускает небольшой уровень ложных срабатываний, если система остается актуальной и обеспечивает широкое покрытие инфраструктуры: 46% участников считают приемлемым уровень FP до 5%, ещё 19% — до 10%. А 30% респондентов отметили, что наличие FP для них не является проблемой, если система дает максимальную видимость по инфраструктуре.

Это важный нюанс: в реальной эксплуатации нулевой уровень FP редко бывает единственным критерием качества. Небольшой объем спорных результатов может быть приемлемой “платой” за полноту покрытия. Но если таких результатов становится слишком много, команда начинает тратить время на перепроверку, а доверие к задачам от ИБ постепенно снижается.

Второй тип ошибок — пропущенные уязвимости (False Negative). Они опаснее тем, что не попадают в отчет, не участвуют в приоритизации и не доходят до процесса устранения. В итоге страдает не только качество отчетности, но и доверие к VM как к управляемому процессу.

Что ломается дальше

ИТ перестает доверять задачам от ИБ

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

В результате команды тратят время не на устранение уязвимостей, а на выяснение, существует ли проблема в заявленном виде.

Приоритизация становится спорной

CVSS, EPSS, трендовость, критичность актива — все это помогает расставлять приоритеты. Но даже хорошая модель приоритизации не спасает, если на входе некорректные или неполные данные. В VM формула приоритизации может быть корректной, но если данные об активе, версии ПО или применимости уязвимости ошибочны, рассчитывать она будет не то, что нужно.

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

Контроль сроков становится формальностью

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

Это как доставка не того товара точно в срок. Формально обязательство выполнено: сроки соблюдены, статус закрыт. Но практической пользы для получателя нет.

Руководство получает красивую, но неполную картину

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

Если исходные данные ненадежны, отчетность может выглядеть лучше, чем фактическое состояние инфраструктуры.

Как понять, что результатам сканирования нельзя доверять полностью

Есть несколько признаков, которые стоит отслеживать:

• ИТ регулярно оспаривает результаты проверок;
• значительная часть задач закрывается как нерелевантная или неподтвержденная;
• одни и те же уязвимости регулярно появляются снова;
• отчетов много, но список критичных проблем не уменьшается;
• приоритет определяется только базовой критичностью (например, CVSS) без учета контекста актива и роли, которую он выполняет в бизнес-процессах ;
• перед постановкой задач требуется длительная ручная проверка;
• команда не может быстро ответить на вопрос “что исправлять первым и почему”;
• руководству показывают количество уязвимостей, но не динамику снижения риска.

Если команда больше времени тратит на проверку корректности результатов, чем на устранение уязвимостей, проблема может быть не только в процессе. Возможно, она начинается раньше — на уровне качества данных сканирования.

Когда результатам сканирования можно доверять

Качественное сканирование — это не самый большой отчет. Это результат, с которым можно работать.

Он должен быть:

Достоверным. Обнаруженные уязвимости должны соответствовать реальному состоянию активов.

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

Применимым. Уязвимость должна быть связана с конкретным активом, его конфигурацией, ролью и контекстом.

Понятным. Команда должна видеть не только факт уязвимости, но и рекомендации по устранению или применении компенсирующих мер.

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

В этом смысле качество сканирования видно не в момент формирования отчета, а позже — когда по результатам нужно принять решение.

Почему база уязвимостей — фундамент результата сканирования

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

Важно не только наличие CVE в базе. В статье “Как отличить качественную базу уязвимостей от справочника CVE” эксперты R-Vision подробно разбирали, какие признаки помогают оценить зрелость базы: источники данных, скорость обновления, информация о наличии эксплойтов, вероятность эксплуатации, сведения о трендовых уязвимостях, рекомендации по устранению и применимость к конкретным типам инфраструктуры — в том числе отечественным ОС, ПО, СУБД и сетевому оборудованию.

Исследование R-Vision о критериях качественного сканирования также показывает, что пользователи VM-систем оценивают базу шире, чем просто список CVE. Высокие оценки получили гибкость базы (добавление и исправление детектов), широта покрытия и прозрачность логики проверок. Почти 80% участников считают важным понимать, из каких источников формируется база уязвимостей. Для заказчиков это вопрос не только полноты данных, но и доверия к результатам сканирования.

Как проверять качество сканирования на пилоте

В исследовании, посвященном выбору VM решений, мы изучали, на какие критерии компании обращают внимание при оценке качества сканирования на этапе пилота. Большинство респондентов анализировали заявленное покрытие решения (92%), полноту карточек уязвимостей (86%) и качество базы уязвимостей (81%). При этом 74% назвали точность детектирования одним из ключевых показателей эффективности сканера, а 62% проводили повторное сканирование после устранения выявленных проблем.

Практика R-Vision также показывает, что оценка качества сканирования должна включать несколько ключевых направлений:

• Покрытие сканера — поддержка используемых ОС, прикладного ПО, СУБД, сетевого оборудования и необходимых режимов сканирования.
• Полнота карточек уязвимостей — CVSS, EPSS, рекомендации и ссылки на патчи, эксплойты, внешние источники, трендовые уязвимости, данные БДУ ФСТЭК России и другие параметры.
• Качество базы уязвимостей — частота обновлений, источники данных, принципы детектирования, наличие технологических партнерств и скорость добавления новых источников.
• Точность детектирования — способность учитывать особенности различных ОС, исправления в сборках пакетов, состояние сервисов и кумулятивные обновления.
• Корректность переоценки результатов — отсутствие уязвимостей в отчетах после установки обновлений и повторного сканирования.

Итог

Сканер уязвимостей — это приборная панель VM-процесса. Если приборы показывают неточно, даже самый красивый маршрут может привести не туда. Поэтому качество сканирования стоит оценивать не по размеру отчета, а по тому, можно ли на основе его результатов принимать рабочие решения: грамотно приоритизировать уязвимости, назначать задачи, контролировать устранение и видеть реальную картину риска.

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