Есть ли у вашей организации файл Security.txt?

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

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

Пример файла security.txt. Изображение: Securitytxt.org.

Идея, лежащая в основе Security.txt, проста: Организация размещает файл под названием security.txt в предсказуемом месте – например, example.com/security.txt или example.com/.well-known/security.txt. Содержание файла security.txt несколько варьируется, но большинство из них включает ссылки на информацию о политике раскрытия уязвимостей организации и адрес электронной почты для связи.

Например, файл security.txt, предоставленный USAA, содержит ссылки на программу “bug bounty”; адрес электронной почты для раскрытия информации по вопросам безопасности; публичный ключ шифрования и политику раскрытия уязвимостей; и даже ссылку на страницу, где USAA благодарит исследователей, сообщивших о важных проблемах кибербезопасности.

Другие раскрытия security.txt менее многословны, как в случае с HCA Healthcare, где указан контактный адрес электронной почты и ссылка на политику “ответственного раскрытия информации” HCA. Подобно USAA и многим другим организациям, опубликовавшим файлы security.txt, HCA Healthcare также включает ссылку на информацию о вакансиях в области ИТ-безопасности в компании.

Наличие файла security.txt может облегчить организациям реагирование на активные угрозы безопасности. Например, только сегодня утром надежный источник переслал мне учетные данные VPN для крупной компании по продаже одежды, которые были украдены вредоносным ПО и стали доступны киберпреступникам. Обнаружив отсутствие файла security.txt на сайте ритейлера с помощью сайта gotsecuritytxt.com (который проверяет домен на наличие этого контактного файла), KrebsonSecurity отправил предупреждение на свой адрес электронной почты “[email protected]” для домена ритейлера.

Многие организации уже давно неофициально используют (если не рекламируют) адрес электронной почты [email protected][companydomain] для приема сообщений об инцидентах безопасности или уязвимостях. Возможно, этот конкретный ритейлер тоже когда-то так делал, однако мое сообщение было возвращено с примечанием о том, что электронная почта была заблокирована. KrebsOnSecurity также отправил сообщение главному информационному директору (CIO) этой розничной компании – единственному человеку на руководящей должности в этой розничной компании, который был в моей ближайшей сети LinkedIn. Я до сих пор не знаю, прочитал ли его кто-нибудь.

Хотя security.txt еще не является официальным интернет-стандартом, утвержденным рабочей группой по разработке Интернета (IETF), его основные принципы на сегодняшний день приняты по меньшей мере восемью процентами компаний из списка Fortune 100. Согласно обзору доменных имен последних компаний из списка Fortune 100, проведенному на сайте gotsecuritytxt.com, к ним относятся Alphabet, Amazon, Facebook, HCA Healthcare, Kroger, Procter & Gamble, USAA и Walmart.

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

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

ПРИГОТОВЬТЕСЬ К НАПЛЫВУ

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

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

Эдвин “EdOverflow” Фудил, соавтор предложенного стандарта уведомлений, признал, что нежелательные отчеты являются основным недостатком для организаций, предлагающих файл security.txt.

“Об этом говорится в самой спецификации, и невероятно важно подчеркнуть, что организации, внедряющие это, будут завалены”, – сказал Фудил в интервью KrebsOnSecurity. “Одна из причин успеха программ вознаграждения за ошибки заключается в том, что они, по сути, являются прославленным спам-фильтром. Но независимо от того, какой подход вы используете, вы будете завалены этими дрянными, некачественными отчетами”.

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

По словам Фудила, несмотря на проблемы, связанные со спамом, он слышал положительные отзывы от ряда университетов, внедривших security.txt.

“В университетах, которые, как правило, имеют много старых, унаследованных систем, это принесло невероятный успех”, – сказал он. “В этом контексте мы получили массу ценных отчетов”.

Фудил говорит, что он рад тому, что восемь компаний из списка Fortune 100 уже внедрили security.txt, несмотря на то, что он еще не утвержден в качестве стандарта IETF. Когда и если security.txt будет утвержден, он надеется потратить больше времени на продвижение его преимуществ.

“Я не пытаюсь делать деньги на этом проекте, который появился после общения со многими людьми на DEFCON [ежегодной конференции по безопасности в Лас-Вегасе], которым было трудно сообщать поставщикам о проблемах безопасности”, – сказал Фудил. “Главная причина, по которой я не стараюсь продвигать его сейчас, заключается в том, что это еще не официальный стандарт”.

Рассматривала ли ваша организация или внедряла security.txt? Почему или почему нет? Выскажитесь в комментариях ниже.

Оставьте комментарий