17.09.2007

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

image

Куда обратиться, если вы нашли дыру на сайте какой-либо компании? Как сообщить пользователям, что вы уделяете внимание их безопасности и безопасности своих активов?

Пару лет назад на этом сайте была опубликована статья, в которой автор приводил результаты своих исследований в области защищенности сайтов известных российских компаний. При этом даже при наличии серьезных уязвимостей автор открыто называл имена этих компаний, провоцируя тем самым потенциальных злоумышленников на повторное «исследование» уже по проторенной дорожке. Оставим в стороне этическую сторону вопроса и посмотрим на мотивацию автора. Он утверждал, что направил каждой компании сообщение об уязвимости их сайта. В ряде случаев он получил ответ, в ряде случаев - нет, но результат один – его исследование, не скрывая имен, увидело свет. Тема раскрытия информации об уязвимостях возникает регулярно и чтобы дать на нее окончательный ответ несколько лет назад, в 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.

или введите имя

CAPTCHA
Страницы: 1  2  3  
1
17-09-2007 09:53:53
Во первых - в современном мире как правило к "владельцу" добавляется еще одна группа: разработчик ИС. Особенно в том случае - вынесеном в заголовок статьи - веб сайты в 90% случаев разрабатываются внешней компанией, и утсранение уязвимости в нем - не в компетенции владельца системы. (только не надо про отвественность владельца, сквозные процессы, SLA и прочий крап - мы живем в реальном мире). Хотя после чтения EULA Microsoft возникает ощущение, что именно они - владельцы всех Windows Во вторых - Cisco PSIRT - не координатор. Это контактная группа одного из вендоров (либо владелец, либо разработчик). В третьих - идея координаторов не работает на практике. Я думаю со мной согласится любой пытавшийся работать через CERT или подобные. Единственный вариант координаторов, которы реально помогает - это коммерческие скупщики уязвимостей а-ля iDefense или TP ZDI, но в случае с уязвимостью сайта - они не помогут. Ну и в четвертых - давным-давно существует RFPolicy v2, в которой описан процесс рагзлашения уящвимостей, и там указаны приведенные в статье адреса электронной почты. Но в большинстве случаев на них ни кто не реагирует
0 |
1
20-09-2007 03:22:55
http://www.securitylab.ru/news/303017.php Хоть один пользователь обратился в суд? Нет. Всё, вопрос снят, так как пользователи претензий не имеют, а следовательно Майкрософт был прав. http://www.securitylab.ru/news/303017.php Причём, первый из России, обратившийся в суд по данному вопросу, был пользователь Алкснис. Затаив дыхание, ждём решения суда.
0 |
1
21-09-2007 21:52:24
Например когда вендор (он же "владелец" в идеологии автора) чуть не засудил "исследователя" не смотря на то, что был предупрежден об уязвимости заранее: http://www.securitylab.ru/news/215836.php - зарубежный опыт http://www.securitylab.ru/contest/239833.php - отечественный вариант
0 |
17-09-2007 09:56:02
Конечно, компании должны иметь некий интерфейс для сбора сообщений об инцидентах и уязвимостях из внешнего мира, но с чего бы им это делать в соответствии с отчетом рабочей группы при Комитете по национальной инфраструктуре США? Я бы не сказал, что любое иное решение (например, часто практикуемый "принцип одного окна", когда для любых вопросов есть один телефон/факс/имейл, а внутренняя маршрутизация осуществляется операторами) неправильно. Неправильно - это не обрабатывать вообще, а копировать ли при этом американцев - дело хозяйское. Но за познавательный материал спасибо: в варианте, практикуемом NIAC, определенно есть хороший тон и информация к сведению.
0 |
17-09-2007 11:38:09
Принцип одного окна - это не сюда. Увы. Покажу на примере. Даже на трех. Первый. Обнаруживается дыра. Пишем на info@example.ru. Письмо получает секретарша какая-нибудь. Она не понимает о чем речь и редиректит знакомому Васе-админу или подружке Оле из бухгалтерии. Слово за слово, сообщение доходит до адресата только через пару дней ;-( А может и совсем не доходит. Второй пример. Ты находишь критическую дыру на сайте. Пишешь на support@example.ru. Если в компании реализована система приоритезации кейсов поддержки, то данное сообщение получает минимальный приоритет (по умолчанию). За это время сайт уже сломают. Третий пример. Пару недель назад мы проверяли ряд наших партнеров, СПЕЦИАЛИЗИРУЮЩИХСЯ на ИБ, - насколько качественно они реагируют на запросы от потенциальных клиентов. Письмо с запросом на приобретение продуктов Cisco на 100-200К посылались на адреса, указанные на сайте. Из 13 отправленных писем правильный ответ мы получили только от 3-х. 4 вообще не ответили. У одного партнера ситуцация вообще комическая - на письмо, отправленное на info@exavple.ru ответила сотрудница отдела оргтехники На ней письмо и закончили свой путь в компании. Конечно пример немного из иной области - партнеры всего лишь недосчитались денег от клиента, но он показателен и показывает как у нас работает принцип одного окна. Все-таки безопасность - вещь более чем серьезная и пускать ее по тем же каналам, что приходят приглашения о спонсорстве какого-либо мероприятия, спам, резюме и т.д., не совсем правильно.
0 |
17-09-2007 11:41:39
Или еще пример. Нефтяная компания. Мне стало известно, что на такой-то платформе в Северном море планируется диверсия. На какой адрес мне сообщать? На info? К тому времени, как информация дойдет до нужного адресата, диверсия произойдет ;-(
0 |
1
17-09-2007 13:11:40
Или в управление УФСБ Некорректные парралели.
0 |
17-09-2007 14:08:51
Так ведь дело не в адресе, а в том, насколько хорошо организован процесс на другом конце провода. Безопасники тоже, знаете-ли, могут три дня почту не проверять, потом три дня спорить, какое из субподразделений должно этой проблемой заняться, а потом скрыть, что предупреждение к ним поступало. Потенциально, одна круглосуточная диспетчерская дешевле и контролируемее двадцати. Ваша статья, кстати, тоже кончается примером единой точки входа.
0 |
20-09-2007 17:50:11
Ничего подобного. Для вопросов безопасности у нас есть /security
0 |
20-09-2007 18:57:06
Ваша статья кончается единым телефоном пожарных/милиции/скорой/...
0 |
20-09-2007 23:31:52
Не-а. 01 - это спасатели и пожарные. У милиции по-прежнему 02. У скорой - 03.
0 |
1
18-09-2007 21:57:11
> Третий пример. Пару недель назад мы проверяли ряд наших партнеров, СПЕЦИАЛИЗИРУЮЩИХСЯ на ИБ, - насколько качественно они реагируют на запросы от потенциальных клиентов. Хакали пару конкурентов?
0 |
1
21-09-2007 00:51:38
Лукацкий - ты тут лукавишь... Я чувствую
0 |
1
17-09-2007 11:53:38
че-т вспомнилось... ломанул, помница, сайт четопобиологии.mit.etu накатал админу тот прислал ответ, что мол все гут, спасибо, что оказался гут-гаем и дальше в том же духе а вот када сделал то же самое с каким-то провом, то он мне прислал письмо с угрозами, что мол дескать если я еще раз попробую это сделать, то мне ппц - засудять по самые помидоры. причем дырку так и не закрыли. пришлось прописать им в крон ежедневный дефейс ихней морды сайта... мда... большинство же контор вообще никак не реагирует на сообщения на уязвимостях. особенно китай, япония... - отослал письмо - как все-равно в /dev/null отправил. ни привета ни ответа. в целом, по моим прикидкам, хорошо если пятая часть контор пытается отреагировать на сообщения о дырках. остальные толи письма не получают, то ли просто им все пофиг. что касается сканера, то тут надо девелоперов нормальных на работу брать. сканер, конечно, сканером, но грамотная архитектура и нормальный код, имхо, главное. что касается "обратной связи", то автору сей новеллы неплохо было бы обратить внимание на формы фидбека или мыла, начинающиеся с support@... admin@... webmaster@... - они есть почти на каждом сайте. ну если так свербит в заднице, что не хватает терпения найти эти мыльники, то можно накатать регистратору домена или воспользоваться найденной уязвимостью, что бы обозначить админу сайта косяки. и вообще, автору неплохо было бы, что называется, сходить в народ. поработать пару недель админом, если квалификация позволяет... ну или хотя бы посидеть при проектировании движка сайта... или, даже лучше, интерфейсов к нему. а то с горы плевать на головы мы все молодцы...
0 |
18-09-2007 16:45:43
а бывает, что нет админа сайта. ну нет его просто. если рассматривать сайт как продукт конечный, то его создали/продали/пользуется покупатель. Он и знать не хочет о том, что еще что-то сайту должен, кроме как получать от него прибыль
0 |
18-09-2007 18:52:56
А мне больше нравится другая херня...типа пишешь владельцам на вид прибыльного сайта типа вот такие у вас есть бреши в безопасности..они типа спасибо вам большое и так далее. Предлагаешь провести аудит..естественно не бесплатно..и тут проявляется их жлобство в полной красе...
0 |
1
19-09-2007 11:53:44
это нормально
0 |
1
17-09-2007 12:36:17
Не хочешь получить Зло - не делай Добро. Пусть админы сами! заботятся о безопасности подведомственных им вещей.
0 |
1
17-09-2007 16:06:36
А еще можно вспомнить, что есть такая полезная весчь как whois и не плодить сущностей без надобности ... про контакты это туда.
0 |
Страницы: 1  2  3