Сканеры уязвимостейВзгляд со стороны вендора и со стороны пользователя

Любой сканер уязвимостей содержит формализованные знания об уязвимостях ПО и методах их определения. Детальная информация об уязвимостях, как правило, распространяется публично вендорами ПО в виде бюллетеней безопасности. Методы определения уязвимостей также несложны: сканер по каким-то признакам определяет версии ПО, установленные на сканируемом узле сети. Если установленная версия ПО меньше безопасной, известной из бюллетеня, значит, ПО необходимо обновить, если больше или равна, значит, все в порядке. Как правило, сканер угадывает версии установленного ПО по открытым портам и баннерам сервисов или, что предпочтительнее, получает доступ к удаленному хосту и выполняет на нем необходимые команды.

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

Если сделать сканер так просто, почему все не пишут сканеры?

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

Основной частью сканера уязвимостей является база знаний. Поддерживать ее в актуальном состоянии – непростая задача. Актуальность можно рассматривать с нескольких сторон. Рынок ИT-систем непрерывно развивается и усложняется. Появляются новые технологии и продукты, в которых обнаруживаются уязвимости. Разработчик сканера уязвимостей должен постоянно следить за тем, какие системы используются у клиентов, и реализовывать поддержку этих систем в своих продуктах с минимальной задержкой. А пользователю, в свою очередь, следует учитывать при выборе разработчика сканера уязвимостей его компетентность в тех технологиях и системах, которые используются у пользователя.

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

Неполнота базы может касаться как новых уязвимостей, так и старых. В случае появления новых громких, "именных" уязвимостей, таких как Heartbleed, Shellshock или Ghost, ведущие разработчики сканеров зачастую устраивают негласные соревнования – кто быстрее выпустит описание и правила обнаружения этой уязвимости в продукте. Но на уязвимостях, которые не так известны, нельзя сделать себе имя и использовать в маркетинге, и поэтому правила обнаружения таких уязвимостей могут реализовываться в продукте с большими задержками.

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

Определение уязвимостей

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

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

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

Дело выбора

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

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

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

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

Хранение данных

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

Функциональность

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

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

Причем, как мне видится, последние 2 пункта невозможно эффективно реализовать силами вендора в рамках коробочного решения, а значит, у продукта должно быть развитое API, позволяющее сделать это самим пользователям.