Помогаем CISO: как выбрать сканер уязвимостей

Изображение: recraft
До того, как ряд зарубежных вендоров прекратил своё функционирование в Российской Федерации, выбор сканеров осуществлялся на основе опыта мирового коммьюнити и рейтингов в международных изданиях. Новая реальность подтолкнула отечественных производителей к заполнению освободившейся ниши и развитию собственных VM-платформ.
Таким образом, для CISO появилась нетривиальная задача в части выбора инструмента из десятка, представленных на рынке. Казалось бы — что еще надо: сканер имеет базу из 2 миллионов уязвимостей, сканирует в считанные минуты, что еще может понадобиться для организации качественного сканирования? Однако не все сканеры одинаково полезны, потому как используют разные механизмы обнаружения уязвимостей. Рассмотрим внимательнее, какие ключевые критерии продуктов этого класса можно использовать при выборе.
Процесс управления уязвимостями
Давайте вспомним классический процесс обнаружения угроз, который применялся в компаниях несколько лет назад. Активы сканировались с определенной периодичностью (например, раз в месяц), после чего в ИТ передавался огромный PDF на устранение, и факт исправления проверялся во время следующего сканирования. Таким образом, у менеджмента, а что еще хуже, в самом отделе ИБ создавалось ложное чувство защищенности.
Время изменилось, сейчас подобный подход неприменим — эксплойты к уязвимостям возникают в считанные дни. Например, CVE-2025-53770 и CVE-2025-53771 (Microsoft SharePoint — ToolShell), эксплойты к которым появились в считанные дни.
Инструмент для поиска проблем в инфраструктуре должен иметь возможность запускаться по требованию ИБ или бизнеса и проводить качественный анализ. Важным фактором для реализации успешного процесса управления уязвимостями является технический специалист, который работает с выдачей результатов сканера. Он должен обладать высоким уровнем экспертизы в трендовых уязвимостях и управлять применимостью риска в каждом конкретном случае. К сожалению, на рынке довольно мало таких специалистов, а стоимость их весьма высока.
Способы анализа
Это первый вопрос, который должен быть задан вендору при презентации продукта. Выделяют следующие варианты: баннерный анализ, активные проверки уязвимостей и фаззинг. О чём вообще все эти термины?
Баннерный анализ базируется на информации о версии используемого на хостах ПО. Получив эти данные, сканер сопоставляет их с базой имеющихся для этой версии ПО уязвимостей и выдает соответствующий вердикт. С одной стороны, а почему бы и нет? База CVE является общепризнанной. Соответственно, как можно скорее закрываем уязвимости с высоким рейтингом и ждём следующего сканирования.
Однако, на практике такой способ анализа имеет много недостатков. Во-первых, высокий процент ложноположительных срабатываний (false positive). Например, производитель признал уязвимость, обновил версию программы, а мажорный номер версии оставил таким, как и до доработки. В этом случае, при каждом сканировании эта версия ПО будет помечаться как уязвимая. Во-вторых, при таком анализе нет никакого подтверждения возможности удалённой эксплуатации выявленной уязвимости. В-третьих, по одному приложению может быть найдено сразу несколько уязвимостей, что вызывает проблемы с приоритезацией устранения выявленных угроз. Ориентация только на рейтинг CVSS не даст должного понимания существующих проблем в инфраструктуре.
Таким образом, используя баннерный анализ, высока вероятность ложноположительных срабатываний, в результате чего трудозатраты IT-отдела на устранение выявленных уязвимостей будут использованы впустую. В результате компания строит свою безопасность на поверхностном анализе, который не показывает объективную картину происходящего, и создаёт ложное ощущение защищенности.
Активное сканирование давно используется в продуктах зарубежных вендоров. Этот метод заключается в том, что инструмент не только сканирует открытые порты, но и отправляет безопасную атакую на целевой сервис. На основании ответа сервера, принимается решение о включении выявленной уязвимости в итоговый отчет.
Самый главный плюс, который получает обладатель инструмента — минимизация времени, затрачиваемого на приоритезацию и определение ложных сработок. Таким образом, бреши в инфраструктуре будут устранены намного раньше.
Главный минус такого подхода — влияние на производительность, в частности возрастает нагрузка на сеть и сервера.
Фаззинг применяется для выявления уязвимостей путем отправки некорректных, случайных или специально сформированных запросов: как правило, в анализе веб-приложений. Это позволяет выявлять такие проблемы как поиск скрытых файлов и папок, SQL-инъекций, и т.п.
База уязвимостей
Вторым важным аспектом при выборе сканера уязвимостей является оценка используемой в продукте базы уязвимостей. Главные вопросы, которые надо задать вендору — какие источники используются для формирования базы уязвимостей? Как часто она пополняется? Кто разрабатывает эксплойты для сканера? Сколько времени требуется для подготовки эксплойта после выхода информации об уязвимости в системе?
Еще один, весьма важный вопрос, это скоуп тех систем, которые может сканировать инструмент. Например, если в инфраструктуре компании есть как Windows и Cisco, так и Astra Linux и 1С? Кроме того, необходимо помнить что современные инфраструктуры отечественных предприятий долгое время будут содержать системы как российских, так и зарубежных производителей, ведь импортозамещение — весьма небыстрый процесс. В следствии чего от сканера уязвимостей требуются широкие возможности по сканированию систем разных производителей.
Немаловажно то, что кроме классических хостов необходимо сканировать контейнеры, облачные ресурсы, IoT, API — то, о чем в первое время многие забывают, но по мере популяризации технологий такая потребность возникает.
Архитектура
Выбираемая система должна иметь возможность масштабироваться в соответствии с инфраструктурой компании. Для этого необходимо оценить как можно будет развернуть сканер уязвимостей для предприятия с филиалами в разных регионах. Поддерживает ли это вендор? Если да, то как должна быть реализована архитектура сканера уязвимостей? Как система будет себя вести, если по каким-то причинам связь с филиалом оборвется? Потребуется ли запуск нового сканирования?
Важно проработать потенциальные интеграции с другими системами, которые есть или планируются в инфраструктуре: ITSM, SIEM, SOAR, SGRC и иными, позволяющими выстроить бесшовный процесс управления уязвимостями. Для интеграции могут применяться как стандартные коннекторы, так и API-интерфейс.
Удобство использования
Для быстрого освоения сканера уязвимостей необходимо оценить ее графический интерфейс, наличие документации и ее понятность человеку, который ранее не администрировал подобные системы.
Еще один немаловажный момент — отчетность, предоставляемая по итогам работы сканера. Необходимо обращать внимание на качество отчетов и их содержание, а также возможность кастомизации под запросы ИТ и бизнеса.
Безопасность системы
Сканер уязвимостей — кладезь бесценной информации о том, какие проблемы есть в инфраструктуре. Если к нему получит доступ злоумышленник, он узнает о том, какие информационные системы используются в компании, долю устаревших ОС и оборудования. В связи с этим, этот инструмент должен удовлетворять современным тенденциям в части обеспечения их безопасности и безопасности процессов информационной безопасности.
Во-первых, в продукте должна быть возможность включения двухфакторной аутентификации для администраторов и операторов.
Во-вторых, должна быть реализована гибкая ролевая модель, которая позволит точечно предоставлять доступ к сканируемым ресурсам.
Желательно, чтобы хранимые данные о выявленных брешах были зашифрованы.
Заключение
Сканеры уязвимостей являются критически необходимым инструментом для обеспечения безопасности, т.к. эксплуатация уязвимостей — основной способов для проникновения злоумышленников в инфраструктуру. Баннерный метод детектирования угроз может привести к тому, что отчет о выявленных проблемах “ляжет в стол”, приоритезация при устранении уязвимостей будет основана на догадках, и в результате возникнет парадокс защиты, когда постоянная работа на устранением угроз приведет к нулевому результату.
Таким образом, выбираемый инструмент должен обеспечивать выполнение принципа Парето, при котором закрытие 20% выявленных уязвимостей приведет к минимизации 80% векторов атак на инфраструктуру и повышать эффективность работы команды без найма новых людей. Именно реальное снижение риска важно для Бизнеса, а не отчеты о закрытии большого количества уязвимостей, которые в реальности не могли быть проэксплуатированы хакерами.
При выборе инструмента необходимо оценить способы выявления уязвимостей, возможности в части интеграции с другими системами, интуитивности в части управления и реализованные мероприятия в части безопасности этой системы.
