Вы обнаружили уязвимость на сайте! Куда податься?

Пару лет назад на этом сайте была опубликована статья, в которой автор приводил результаты своих исследований в области защищенности сайтов известных российских компаний. При этом даже при наличии серьезных уязвимостей автор открыто называл имена этих компаний, провоцируя тем самым потенциальных злоумышленников на повторное «исследование» уже по проторенной дорожке. Оставим в стороне этическую сторону вопроса и посмотрим на мотивацию автора. Он утверждал, что направил каждой компании сообщение об уязвимости их сайта. В ряде случаев он получил ответ, в ряде случаев - нет, но результат один – его исследование, не скрывая имен, увидело свет. Тема раскрытия информации об уязвимостях возникает регулярно и чтобы дать на нее окончательный ответ несколько лет назад, в 2002 году при Совете по национальной инфраструктуре США (National Infrastructure Advisory Council, NIAC) была создана рабочая группа по раскрытию информации об уязвимостях (Vulnerability Disclosure Working Group, VDWG). Ее возглавили президент и исполнительный директор Cisco Джон Чемберс и исполнительный директор Symantec Джон Томпсон. В работе группы также принимали участие такие известные люди в мире безопасности, как Мэтт Бишоп, Брюс Шнайер, Стив Беллоуин, Дэйв Дитрих и многие другие. Результатом работы этой группы стал 52-хстраничный документ «Vulnerability Disclosure Framework» (http://www.dhs.gov/xlibrary/assets/vdwgreport.pdf), который описывает жизненный цикл процесса раскрытия информации об уязвимостях, начиная с момента их обнаружения и заканчивая взаимодействием с производителем уязвимой системы.

Участники процесса управления уязвимостями

NIAC VDWG выделяет 4 основных группы участников процесса управления уязвимостями:

• Исследователи. Это они обнаруживают дыры в системах и продуктах. Их принято делить на 2 основных категории – «white hat» и «black hat». Вторые – это «черные исследователи», которые продают результаты своего труда на черном рынке или пользуются в своих недобрых целях.
• Владельцы. В документах VDWG эта группа названа «производители» (vendors). Однако, на мой взгляд это слишком сужает область применения рекомендаций рабочей группы. К какой, например, группе стоит отнести компанию, Web-сайт которой содержит ряд уязвимостей?
• Пользователи. Как ни странно, но в процессе управления уязвимостями участвуют и пользователи, которые не только вынуждены использовать уязвимые системы в своей работе, но и сами зачастую обнаруживают дыры в используемом программном обеспечении.
• Координаторы. К кому обратиться исследователю, если он боится преследования со стороны производителя или не способен довести исследование до конца? Для этого и существуют специальные группы или организации, координирующие весь процесс (например, CERT/CC, Cisco PSIRT, FIRST и т.д.). Их отличительными особенностями являются:
• Возможность быстро достичь правильную аудиторию – производителей и пользователей.
• Наличие экспертов для подтверждения факта уязвимости и для разработки мер противодействия.
• Возможность защищенного взаимодействия со всеми участниками процесса управления уязвимостями.
• Защищенная инфраструктура для предотвращения утечки данных и разделения (нераскрытия) информации об уязвимостях между участниками.
• Публичный интерфейс (например, сайт), через который координатор может донести до широкой общественности информацию об уязвимостях и методах их устранения.
• Независимость.

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

Жизненный цикл уязвимости

Каждая уязвимость уникальна, но каждая подчиняется определенным этапам жизненного цикла, которых, согласно Vulnerability Disclosure Framework (VDF), девять:

1. Исследование, результатом которого является превращение теоретической возможности совершить атаку через какую-либо дыру, в реальность, воплощенную т.н. эксплоитом (exploit).
2. Проверка позволяет удостовериться, что уязвимость – это не случайный результат функционирования системы, а свойство, которым можно воспользоваться в любой момент. На этом этапе обычно завершается работа
3. Уведомление владельца уязвимой системы, которое осуществляется с ним напрямую или через координатора.
4. Оценка владельца уязвимой системы позволяет подтвердить выводы исследователя.
5. Подтверждение является результатом положительной оценки и сигналом исследователю, что владелец будет поддерживать с ним дальнейший контакт для будущих исследований и обсуждения плана раскрытия информации.
6. Устранение заключается в разработке рекомендаций или патча для обнаруженной уязвимости.
7. Тестирование рекомендаций и патча подтверждает, что они негативно не повлияют на работу системы и ее окружения.
8. Выпуск патча и рекомендаций делает их доступными для пользователей.
9. Обратная связь и закрытие кейса завершают жизненный цикл уязвимости.

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

Slash Security

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

К счастью, VDF дает ответ и на этот вопрос. Основная рекомендация, которую дает Vulnerability Disclosure Framework – организовать на собственном сайте специальный раздел по безопасности, который послужит единой точкой контакта и получения информации по различным аспектам, связанным с безопасностью компании. Это раздел должен размещаться по адресу http://www.example.ru/security/. Поэтому он и получил название «slash security».

Рис. 1. Раздел по безопасности банка HSBC

Согласно VDF данная секция должна содержать 3 главных подраздела:

• Контакты по реагированию на инциденты. Именно этот раздел позволяет вам контактировать с компанией, если вам стало известно о каком-либо инциденте с ее активами. Причем активами различными – информационными, физическими, людскими и т.д. Поэтому на данной странице должны быть указаны контакты групп, ответственных за каждый из этих типов активов. В зависимости от деятельности компании этот раздел может содержать контакты людей, отвечающих за нарушение авторских прав, спам и т.д. В качестве наиболее распространенных примеров таких адресов можно назвать security@example.ru, security-alert@example.ru, secure@example.ru и abuse@example.ru (при этом на этой странице стоит также разместить и открытый ключ для конфиденциальной переписки). Также часто называемые в качестве вариантов адреса support@example.ru и info@example.ru являются не лучшим выбором, т.к. их обычно используют для совершенно иных целей. Адрес с приставкой support предназначен для получения технической поддержки, а info@example.ru – для получения информации о компании, взаимодействия с коммерческим отделом и т.д.

Рис. 2. Раздел по безопасности Университета Северной Каролины (США)

• Управление уязвимостями. Данный раздел, в отличие от предыдущего, является не только точкой входа, но и точкой выхода. В нем публикуется информация о том, как составить сообщение об уязвимости или инциденте («How to report»), какие последние уязвимости существуют и как с ними бороться. В качестве примера можно назвать компанию Cisco, которая в разделе безопасности публикует список не только уязвимостей в своих решениях, но и в решениях других производителей.

Рис. 3. Раздел по безопасности компании Cisco

• Ссылки и рекомендации. Этот раздел демонстрирует, что компания подходит к вопросу своей безопасности «не для галочки». В нем размещаются различные советы и рекомендации, ссылки и лучшие практики и т.д. Очень показателен в этом отношении сайт компании AT&T, который не только содержит самую последнюю информацию о червях и вирусах, но и рекомендует позволяет вам просканировать ваш компьютер с помощью специального онлайн-сканера, а также позволяет приобрести персональные системы защиты компании McAfee.

Рис. 4. Раздел по безопасности компании AT&T

При этом термин «безопасность» воспринимается разными отраслями по разному. Например, ИТ-компании в разделе /security публикуют информацию об уязвимостях в их продуктах. Финансовые организации ставят знак равенства между терминами «security» и «privacy» и посвящают разделы своих сайтов вопросам защиты от мошенничества, утечки информации, кражи персональных и идентификационных данных. В нефтяной промышленности или, более широко в ТЭК, основной упор делается на физической и экологической безопасности.

Рис. 5. Раздел по безопасности компании BP

О наболевшем или что стоит улучшить?

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

Какие еще важные проблемы можно выделить по результатам анализа сайтов нескольких десятков самых известных мировых компаний из различных отраслей? Во-первых, противоречивое или неочевидно расположение раздела по безопасности. Например, у компаний IBM, CA, Oracle, SAP или Nortel раздел /security ведет на страницу, описывающую продукты и решения, предлагаемые этими компаниями. Для компаний-продавцов это конечно закономерно, но если уж говорить о стандартизации, то лучше придерживаться единого принципа именования раздела по безопасности. Другая важная проблема – локализация. Очень редко когда такие разделы переводятся на языки тех государств, в которых представлена компания. Связана с локализацией региональная автономия. Например, если в браузере ввести адрес http://www.microsoft.com/security, то мы попадем на грамотно созданный раздел, описывающий различные аспекты безопасности. Однако стоит сменить домен и зайти на http://www.microsoft.ru/security, то мы увидим классическую ошибку 404 – «Файл не найден». И эта проблема большинства международных компаний, имеющих в разных странах мира свои региональные Интернет-представительства.

Рис. 6. Раздел по безопасности компании Microsoft

Еще одна частая проблема – ориентация только на одну целевую аудиторию – не всегда основную. Например, многие ИТ-компании ориентируются только на ИТ-профессионалов, исключая из виду домашних пользователей, разработчиков и другие категории пользователей. В других отраслях аналогичная проблема. Примером «правильного» сайта является портал по безопасности компании Microsoft.

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

Рис. 7. Раздел по безопасности Йельского университета (США)

Помимо защищенного доступа к разделу /security (как, например, на сайте Университета Северной Каролины) можно проявить и некоторый креатив – запустить на сайте дискуссионный форум или блог. Например, Chief Security Officer компании Oracle, Мэри Энн Дэвидсон, ведет такой блог. Аналогичные блоги и форумы по безопасности ведутся на сайтах Microsoft, Cisco и т.д.

Рис. 8. Блог CSO компании Oracle

Заключение

Когда я проводил экспресс-анализ западных сайтов, то не ограничился уже перечисленными выше именами. Я начал с простого - взял Gartner’овский список лидеров рынка сетевой безопасности и «прошелся» по нему. К моему удивлению далеко не все из этого списка имели такие раздела на сайте. Например, их не было у Check Point, McAfee, Forinet. Очень удивила компания ISS, которая также не имеет этого раздела, несмотря на то, что она входит в состав рабочей группы Vulnerability Disclosure WorkGroup и сама разрабатывала рекомендации VDF.

Посмотрев на вышеприведенные скриншоты и примеры, мне можно задать закономерный вопрос, а почему я опять лью воду на мельницу Запада, и ни разу не привел в пример российскую компанию? Ответ будет печален – я не нашел таких компаний. Пройдя по западным сайтам, я провел аналогичное блиц-исследование и по российским компаниям. В частности, я начал с лидеров рынка ИБ (список я взял из рейтинга Cnews Security 2007). К большому сожалению, такой раздел отсутствует у ВСЕХ до единого. Выборочное посещение сайтов и других известных российских компаний, являющимися лидерами в своих отраслях, привело к тому же плачевному результату.

Выпущенные 3 года назад рекомендации до сих пор не нашли своего применения у многих компаний. А ведь ничего сложного в них нет. Более того, эти рекомендации разумны. Как МЧС сейчас активно пропагандирует единый телефон спасателей 01, так и наличие раздела /security на сайте любой компании может стать таким стандартом в Интернет-безопасности.

Об авторе:
Алексей Викторович Лукацкий, бизнес-консультант по безопасности Cisco Systems. Связаться с ним можно по тел. (495) 961-1410 или e-mail: alukatsk@cisco.com.