Как выбрать средство для тестирования защищенности?

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

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

В начале 2000-х тестирование защищенности систем проводилось в двух формах: тестирование на проникновение (penetration test) и анализ защищенности (vulnerability assessment).

До начала тестирования на проникновение перед аудиторами ставилась задача получить доступ к какой-то определенной информации (например, к excel-файлу с суммами премий топ-менеджерам компании) или административный доступ к критичным информационным системам.

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

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

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

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

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

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

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

Стоит отметить, что сканеры до сих пор обнаруживают не все виды уязвимостей. Так, в случае если вам необходимо протестировать безопасность «самописного» веб-приложения, вам придется познать все прелести манипулирования данными HTTP-запросов через интерфейс локального прокси-сервера.

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

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

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

В результате на свет появились такие методики, как Information Systems Security Assessment Framework (ISSAF), Open Source Security Testing Methodology Manual (OSSTMM) и другие.

Что касается инструментария этичного хакера, то количество утилит для взлома росло по мере распространения новых технологий и появления новых атак. Как правило, каждая утилита решала одну узкую задачу: сканирование портов (NMAP), подбор паролей к сетевым сервисам (THC-HYDRA), взлом хешей паролей учетных записей операционных систем (LCP) и другие.

Наборы утилит стали объединять в загружаемых с CD/DVD или USB-носителей операционных системах на базе Linux. Мировую известность получил дистрибутив BackTrack. В России же хорошо известен его аналог «Сканер-ВС» (разработка компании «Эшелон»), который прошел сертификацию во ФСТЭК России и Минобороны России и может применяться для контроля защищенности систем, в которых обрабатывается информация вплоть до уровня «совершенно секретно» включительно.

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

Наверное, многие помнят, что в ОС Windows 2003 Server неавторизованный пользователь мог получить список учетных записей через нулевую сессию. Наличие подобной уязвимости и неаккуратное обращение со сканером иногда приводили к беспощадной блокировке пользователей домена.

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

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

Сейчас в лидирующих на рынке продуктах можно найти функционал инвентаризации ИТ-ресурсов с возможностью определения уровня критичности ресурса (что очень полезно для реальной оценки опасности конкретной уязвимости), а также функции назначения задач по установке соответствующих обновлений ответственным ИТ-специалистам с последующим автоматическим контролем их выполнения.

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

Малый бизнес «покупает безопасность» в основном в составе услуг и решений, которые ему необходимы для выживания (например, хостинг для интернет-магазина), соответственно в группу потенциальных пользователей рассматриваемых продуктов не попадает.

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

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

Соответственно можно прийти к выводу, что в ближайшие несколько лет продукты наподобие Backtrack и «Сканер-ВС» заинтересуют и средние, и крупные компании. Они будут пополняться новыми средствами тестирования, станут улучшаться интерфейс и отчетность. Тяжеловесные сканеры уязвимостей продолжат свое движение в сторону интеграции в автоматизированную систему управления информационной безопасностью.

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

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

Один отзыв

Добавить комментарий