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

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

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

В самом общем понимании, управление уязвимостями (Vulnerability Management) – процесс, направленный на предотвращение использования известных уязвимостей, потенциально существующих в защищаемой системе или сети. Основной ожидаемый результат – значительное затруднение или полное исключение возможностей использования этих уязвимостей для нарушителей, и, соответственно, снижение затрат на ликвидацию последствий атак.

Число уязвимостей, обнаруживаемых ежегодно, 2005-2009 гг.

Источник: National Vulnerability Database, 2009

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

И это только уязвимости реализации, а есть еще ошибки проектирования и эксплуатации. Ведь в процессе эксплуатации система может меняться, из-за чего могут появиться уязвимости. Разумеется, потенциальный ущерб от использования конкретной уязвимости в защищаемой системе может быть довольно различным (от нулевого до значительного). Поэтому процесс управления уязвимостями должен обеспечивать не только своевременное выявление очередной "дыры", но и адекватную оценку степени ее опасности для защищаемой системы, а также выбор соответствующего варианта реагирования. Фактически управление уязвимостями позволяет контролировать и поддерживать на определенном уровне степень защищенности системы, обеспечивая своевременное выявление ее слабостей. Этот процесс можно разложить на отдельные составляющие – и прежде всего это инвентаризация информационных активов.

Инвентаризация информационных активов

Инвентаризация информационных активов подразумевает создание и поддержание в актуальном состоянии единой базы ИT-ресурсов (иногда используется термин Configuration Management Database, CMDB). Для ее создания необходимо определить характер размещаемой там информации и механизмы ее накопления.

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

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

Описание объекта в базе данных системы управления уязвимостями, 2009

Источник: Leta, 2009

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

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

Мониторинг состояния защищенности

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

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

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

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

Раздел ресурса SecurityFocus с информацией о новых уязвимостях, 2009

Источник: Leta, 2009

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

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

Пример набора требований для контроля соответствия, 2009

Источник: Leta, 2009

Проблема здесь только в формулировке этих требований или в выборе готового набора (стандарта), которому необходимо соответствовать.

Правда, в некоторых случаях выбор осуществить достаточно просто. Например, для компаний, которым нужно соответствовать требованиям PCI DSS (Payment Card Industry Data Security Standard) или других регуляторов, в том числе и государственных, появляется возможность оценить текущее состояние дел, а в дальнейшем – поддерживать уровень соответствия своей инфраструктуры данным требованиям.

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

Например, в целях обеспечения безопасности вводится требование использования исключительно SSH версии 2.0 для управления сетевым оборудованием. Факт нарушения позволит выявить соответствующая скорректированная проверка.

Пример настройки параметров проверки, 2009

Источник: Leta, 2009

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

Устранение уязвимостей

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

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

На практике обычно приходится выбирать один из следующих вариантов. Во-первых, обновление системы: установка "патча", переход на новую версию. Во-вторых, изменение конфигурации ("workaround"). В-третьих,  отказ от использования уязвимого ПО.

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

Таким образом, на этом этапе система должна обеспечить соответствующий "workflow", начиная c принятия решения по уязвимости и заканчивая формированием заявки и назначением ответственного за ее обработку.

Контроль

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

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

Пример отчета с информацией об устраненных уязвимостях, 2009

Источник: Leta, 2009

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

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

Общие характеристики решений по управлению уязвимостями, 2009

Вендор (поставщик решения)		Positive Technologies	IBM ISS	Tenable Network Security	eEye Digital Security	Qualys	McAfee
Типы агентов сканирования (по расположению)	Сетевые (network-based)	+	+	+	+	+	+
	Локальные (host-based)	-	-	-	+	-	-
	Пассивные	-	-	-	+	-	-
Типы агентов сканирования (по назначению)	Общего назначения	+	+	+	+	+	+
	Специализированные	-	+	-	+	+	-
Вариант поставки (для агентов)	Аппаратно-программный комплекс	Планируется	+	-	+	+	+
	Программное обеспечение	+	+	+	+		+
	Виртуальный образ	+	Планируется	+	-	-	-
Платформа для агентов (для программного обеспечения)		Windows	Windows	Windows/UNIX	Windows	-	Windows
Варианты поставки (для компонентов управления)	Аппратно-программный комплекс	Планируется	+	-	+	-	+
	Программное обеспечение	+	+	+	+	-	+
	Виртуальный образ	+	-	-	-	-	-
	Securiry-as-a-service	Только внешнее сканирование	Только внешнее сканирование web-приложений	-	+	+	Только внешнее сканирование
Платформа для компонентов управления (для программного обеспечения)		Windows	Windows	Windows/UNIX	Windows	-	Windows

Источник: Leta, 2009

Кроме того, важна и комплексность, т.е. поддержка различных вариантов сканирования ("баннерные" проверки сетевых сервисов, аудит с использованием учетных записей и локальных проверок, тестирование веб-приложений). Использование локальных проверок влечет за собой необходимость поддержки различных систем (от сетевого оборудования до ERP-систем). В отдельных случаях бывает важно наличие русскоязычных интерфейса и базы знаний, а также сертификации ФСТЭК России.