Цена ошибки: почему важно качественно детектировать уязвимости

В последние несколько лет растет количество успешных кибератак на компании во всем мире. По данным исследования Positive Technologies, эксплуатация уязвимостей является одним из основных методов кибератак на российские организации: по итогам трех кварталов 2024 г. уязвимости эксплуатировались практически в каждой пятой (19%) успешной атаке.

Автор: Александр Леонов, ведущий эксперт PT Expert Security Center, компания Positive Technologies

Не сканер детектирует уязвимости в ИT-инфраструктуре организации с помощью специалиста, а специалист по управлению уязвимостями (VM-специалист) детектирует уязвимости с помощью сканера. Сканер – это просто инструмент.

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

Рис. 1. По итогам трех кварталов 2024 г. уязвимости эксплуатировались практически в каждой пятой (19%) успешной атаке

Контроль средств детектирования уязвимостей как обязательная часть VM-процесса

К сожалению, на настоящий момент в России нет обязательной сертификации VM-решений, предъявляющей требования к качеству детектирования уязвимостей.

Сертификация ФСТЭК России проверяет отсутствие недекларируемых возможностей, но не учитывает качество реализации функциональных возможностей средств анализа защищенности (САЗ).

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

Доходит до абсурда: сейчас ничто не мешает недобросовестному вендору выпустить утилиту, которая будет детектировать одну CVE-уязвимость, а также добавить к этой утилите веб-интерфейс с дашбордами и презентовать это как "сканер уязвимостей" – альтернативу топовым решениям на рынке. Уязвимость он ищет? Ищет. То, что она одна... А сколько вам надо?

А уж если перелицевать и соединить опенсорсные утилиты, которые уязвимости действительно детектируют (GVM/OpenVAS, OpenSCAP, Wazuh, nmap с плагинами, nuclei и т.п.), то в этом случае становится сложно что-то возразить. С хостами сканер взаимодействует, список уязвимостей выдает. Непонятно только, насколько этот список уязвимостей достоверен.

Так что, как ни прискорбно, в настоящий момент оценка качества работы средств детектирования уязвимостей целиком лежит на VM-специалисте. Делать это нужно не только перед закупкой VM-решения, но и в течение всего периода эксплуатации.

Рис. 2. Уровень опасности уязвимостей, обнаруженных в российском ПО

Как оценивать качество используемых решений

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

Фактически при проведении такой оценки для всех типов активов в инфраструктуре организации следует задать вопрос VM-вендору: поддерживается ли этот тип актива средством детектирования? Если нет, то думаем, что делать: стимулировать VM-вендора к поддержке этого типа актива, покупать другое решение или реализовывать такие проверки на уязвимости самим. Крайний вариант – вовсе убирать этот тип актива из инфраструктуры. Если да, идем глубже. А как именно происходит детектирование? Достаточно ли реализованных способов детектирования для нашей конкретной инфраструктуры?

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

Ошибки при реализации базовых проверок

Возьмем, например, Linux-хосты. Детектирование уязвимостей для софта, установленного из официального репозитория Linux-вендора, – относительно простая задача. Эти уязвимости описываются в общедоступных бюллетенях безопасности или даже в виде формализованного OVAL-контента. VM-вендору нужно всего лишь правильно сравнивать версии пакетов, фактически установленных на хосте, и прописанных в бюллетене безопасности (OVAL-контенте). Казалось бы, чего проще. Но даже здесь могут быть ошибки. Назовем самые частые из них:

• Неправильная реализация функции сравнения версий пакетов (например, не учитывают эпоху – наиболее значимую часть версии пакета).
• Неправильный источник безопасных версий пакетов (когда в бюллетенях source-пакеты, а от них нужно перейти к версиям бинарных пакетов).

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

Но допустим, что эта часть детектов реализована у VM-вендора корректно. Достаточно ли детектов на основе бюллетеней безопасности Linux-вендора для того, чтобы VM-вендор мог со спокойной совестью заявлять о поддержке Linux-дистрибутива своим сканером? Не совсем.

Детектирование уязвимостей для Linux-софта не из официального репозитория вендора ОС

Софт в Linux может быть установлен разными способами, например:

• из подключенного стороннего репозитория;
• пакета (вендорского или собранного самостоятельно) стандартной пакетной системы дистрибутива (deb, rpm);
• альтернативных пакетов для распространения софта (Snap, Flatpak, AppImage и т. п.);
• средств распространения модулей (pip, conda, npm и т. п.);
• образа контейнера (Docker, Podman и т. п.);
• исходников софта, при этом сборка софта может происходить на том же хосте или собранный софт может быть перенесен в виде бинарных файлов.

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

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

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

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

О важности детектирования без аутентификации

Есть мнение, что при детектировании уязвимостей внутренней ИТ-инфраструктуры организации сканировать без аутентификации не нужно. Достаточно расставить агенты по хостам. А те хосты, на которые агенты установить невозможно, например сетевые устройства, достаточно сканировать с аутентификацией. Это аргументируется тем, что сканирование без аутентификации всегда менее достоверно, чем сканирование с аутентификацией, и требуется оно только для аудита сетевого периметра или первичной инвентаризации внутренней сети. Однако, именно из-за многообразия способов установки ПО сетевое сканирование без аутентификации часто оказывается полезным в качестве дополнительного способа детектирования, особенно в случае хостов с веб-приложениями.

Допустим, у нас есть коммерческий или опенсорсный софт на Linux-хосте (Zabbix, GitLab, Confluence, Jira). Получив доступ к хосту по SSH, этот софт не так-то просто найти за ограниченное время сканирования. А при взгляде на хост извне он ищется тривиально: сканируем порты, находим веб-интерфейс, зачастую на главной странице находим версию софта и по ней детектируем уязвимости. В этом случае детект вообще не зависит от конкретного способа установки и запуска софта на хосте. Главное, что веб-интерфейс приложения доступен для анализа.

Такие "внешние" правила детектирования гораздо проще разрабатывать. Кроме того, можно воспользоваться публично доступной экспертизой. Фингерпринтинг для получения CPE-идентификатора1 софта в сочетании с поиском уязвимостей в NVD по CPE-идентификатору – это, конечно, не самый надежный способ детектирования уязвимостей, зато простой и универсальный. И если улучшать и фингерпринтинг и правила детектирования по CPE-идентификаторам, то количество ошибок детектирования можно уменьшить до приемлемого уровня. А если еще добавить валидацию уязвимостей с помощью проверок с попыткой эксплуатации (например, используя nuclei), то для значительной части уязвимостей надежность детектирования станет еще выше. Именно такой способ баннерных детектов с подтверждением с помощью nuclei реализован в MaxPatrol VM начиная с версии 2.5.

Почему VM-специалисту важно проверять качество детектирования уязвимостей?

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

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

1. CPE – это структурированная схема именования информационных систем, программного обеспечения и пакетов.