Перевод: Принципы работы программ Bug Bounty

Программы Bug bounty позволяют компаниям взаимодействовать с сообществом безопасности и извлекать выгоду из широкого спектра навыков. Занимаясь несколькими различными программами, я много думал о том, как быть справедливым, щедрым и благодарным по отношению к исследователям.

Вот мои личные принципы работы, которые помогут другим начать или улучшить свои программы. Я надеюсь, что они также помогут исследователям получить представление о том, как другая сторона принимает решения.

1. Определите четкую область применения, но будьте снисходительны к исключениям

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

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

Обычно я запрещаю социальную инженерию, отказ в обслуживании (DoS), брутфорс/спам и другие атаки, которые могут быть более рискованными для сторонней организации. Это довольно стандартно, но сложнее сказать, должен ли я принимать отчет о CVE в Jira. Мы не писали код, но, возможно, мы не обновляли систему несколько месяцев. Или, возможно, CVE был выпущен вчера, и исправление уже идет полным ходом.

Хорошее эмпирическое правило гласит: если кто-то внутри компании еще не знает о проблеме, ее стоит принять. Вполне нормально отклонить сообщение и отметить, что ваша команда занимается устранением вчерашнего CVE. Однако если кто-то сообщает о проблеме, которая уже давно открыта, я часто принимаю ее как новую проблему и благодарю исследователя за то, что он обратил на нее наше внимание. Это заставляет нас исправлять проблемы, и исследователи остаются довольны.

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

2. Расширяйте возможности исследователей и принимайте тестирование в прод

Вы должны стремиться предоставить наилучшие ресурсы для изучения ваших систем и их эффективного тестирования. Но как бы вы ни упростили тестирование в режиме staging, вы станете тем счастливее, чем быстрее примете тот факт, что люди все равно будут тестировать в режиме prod.

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

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

3. Выполняйте сортировку самостоятельно и очищайте отчеты для внутренних команд

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

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

4. Практикуйте благодарность и давайте исследователям преимущество сомнения

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

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

5. Общаться честно и прозрачно и на одном техническом уровне

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

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

6. Устанавливайте диапазоны вознаграждения в зависимости от зрелости объема работ и будьте последовательны в своих решениях.

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

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

Независимо от диапазонов, важно проявлять уважение к исследователям и придерживаться их. Старайтесь использовать объективные ресурсы для определения степени серьезности, такие как Bugcrowd's Vulnerability Rating Taxonomy или CVSS scores. Тем не менее, наличие диапазонов вознаграждения дает определенную гибкость, и не помешает назначить большее вознаграждение за хорошо написанные отчеты или проблемы, поиск которых потребовал больших усилий. При снижении уровня серьезности позвольте исследователю подать апелляцию или прийти к соглашению.

7. Найдите способы сделать вашу программу уникальной и сделать ее интересной для исследователей

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

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

8. Работайте над тем, чтобы стать публичным и иметь показатели, которыми можно гордиться

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

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

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

Заключительные мысли

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

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

Если у вас есть контраргументы или собственные советы, не стесняйтесь оставлять комментарии. Я всегда стремлюсь узнать больше и улучшить свои методы!

Оригинал статьи - здесь.
Поддержите автора хлопками на Medium.

Перевод статьи был выполнен проектом перевод энтузиаста:

• 📚 @Ent_TranslateIB - Телеграмм канал с тематикой информационной безопасности
• 🔥 @Ent_Translate - Инстаграм проекта