1
✍️ Откуда взялся security.txt ?
• 10 лет назад, ИБ-исследователь и бывший аналитик компании HackerOne Эд Фодил, предложил реализовать стандарт security.txt. Он описывает содержимое специального файла - того самого security.txt - который размещается в директории /.well-known и включает контактную информацию и инструкции для оповещения об уязвимостях. По сути, это - аналог robots.txt, только для специалистов по информационной безопасности.
• Сама идея сформировалась после посещения конференции DEF CON и соревнований по кибербезопасности. Он размышлял о вкладе участников подобных мероприятий в развитие инфобеза. По его словам, источником вдохновения также послужили SECURITY.md и BUG-BOUNTY.md - файлы с политиками безопасности, которые разработчики добавляют в репозитории. В свою очередь, IETF-драфт нового стандарта был предназначен для более широких задач и включал следующие поля:
➡Contact - для указания email, номера телефона, URL специальной формы на сайте и других каналов коммуникации по теме уязвимостей.
➡Encryption - содержит ссылку на ключ шифрования, который ИБ-специалисты должны использовать для передачи сообщений.
➡Acknowledgements - компания может указать ссылку на веб-страницу, где она говорит спасибо исследователям, которые ей помогли.
➡Disclosure - формат предоставления информации об уязвимости.
• При этом в репозитории, где автор делал заметки, изначально были отмечены и другие поля - например, In-scope, Out-of-scope-vuln, Rate-limit, Platform, Reward, Payment-method, Currency, Donate и Disallow. Они, помимо прочего, предоставляли больше информации о программах bug bounty, вознаграждении для этичных хакеров и декларировали, отчеты о каких уязвимостях не будут рассматриваться ИБ-специалистами компании, разместившей security.txt на своем сайте.
• Разработчик решил не включать данные поля в драфт, потому что представители крупной технологической фирмы рекомендовали ему посмотреть, как владельцы сайтов отреагируют на новый стандарт. И уже потом корректировать его, анализируя обратную связь. В апреле 2022 года security.txt был опубликован как RFC 9116, и финальный список полей был действительно модернизирован. Например, было убрано поле Disclosure, вместо него появилось поле Policy со ссылкой на политики раскрытия информации - как стоит действовать ИБ-исследователям, желающим сообщить об уязвимости. Также появились поля:
➡Expires - дата, после которой файл считается устаревшим.
➡Hiring - информация о ИБ-вакансиях у компании-владельца сайта.
➡Preferred-Languages - языки, на которых стоит сообщать о найденных уязвимостях.
• При этом стоит отметить, что стандарт security.txt должен был не заменить, но дополнить RFC 2142, который, помимо прочего, рекомендует владельцам сайтов завести почтовый ящик security@domain<