Как стать автором
Обновить

Комментарии 10

Bug Bounty - это прямо почти самая моя любимая тема для споров в ИБ

Начну с конкретного и перейду к абстрактному:

> Помимо колоссального увеличения программ — почти на 60%, также произошло общерыночное повышение цен, а максимально возможное вознаграждения по итогу выросла в 2 раза.

Так получилось, что я принимал участие в одной из программ, которая была представлена сначала на HackerOne, а потом на отечественной платформе. И получилось так, что максимальное вознаграждение выросло настолько, что сейчас максимальная выплата в рамках этого проекта примерно в 4 раза меньше, чем я получил от него же на старой платформе (не максимальную), а выплата за ту категорию, за которую я получил вознаграждение ранее - в 8 раз меньше. Действительно знатное и мотивирующее повышение

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

В том числе и поэтому многие люди "держат" те уязвимости, которые найти непросто. Условно, зачем сдавать что-то за 50 тысяч, когда велика вероятность, что расценки на уязвимости вырастут (понятно, что есть элемент риска, что кто-то закроет ее, но тут вопрос опыта и оценок)

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

Нашел корявую XSS на не очень важном сервисе - держи деньги. Нашел способ вскрывать практически любой аккаунт из-за неправильного процесса - держите заслуженный 0, технической проблемы на нашей стороне нет, Bug Bounty неприменимо

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

И местами получается комичная ситуация, что если хочешь зарабатывать именно на программах, тогда есть смысл прикладывать усилия к поиску технических проблем, когда рядом есть очевидно более простые и опасные нетехнические, которые проще найти и эксплуатировать. Довольно сложно сказать злоумышленнику, что у компании есть какие-то Bug Bounty Rules and target policies, в которых указано, что он должен ломать только определенные сервисы и не использовать украденные пароли, которые у него есть в огромном количестве

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

Я сравнивал именно максимальную стоимость 23 и 24 года. О том, что было раньше на hackerone не стоит говорить - цены были больше. Мы, со своей стороны, прикладываем усилия, чтобы повышать не только максимально возможные выплаты, но и в принципе стоимости в программах. Вот к примеру, недавно увеличили стоимость вознаграждений во всех наших программах. Если сложить это с накопительным бонусом от Bounty pass, то получается прям вкусно.
А если говорить про принцип вознаграждения, то тут я согласен - багбаунти стоит рассматривать именно как инструмент для возможности отслеживания проблем во внутренних процессах ИБ. И по факту не важно какого рода проблема: связана она с внедрением CSP или с обучением персонала основам культуры ИБ - платить надо в зависимости от угрозы и риска которую несет уязвимость

технической проблемы на нашей стороне нет, Bug Bounty неприменимо

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

Больше интересно :) - политики скажем так работы приводят к тому что:

  • пользователи стремятся использовать максимально простые но соответствующие требования пароли (Ytrewq123$456 соответствует) - а потому что 3 разных пароля, надо менять каждые N месяцев, в некоторых местах можно ввести только с клавиатуры

  • терминальная сессия блокируется по таймауту - можно либо ввести пароль либо закрыть клиент и тут же подключится (ладно - это не угроза безопасности хоть)

  • пароли в файликах на рабочем столе - это прошлый век. Теперь пароли в файликах в профиле пользователя и в переменных окружения. А потому чт доступ к репозиторию артефактов - только по паролю и логину. Хотя app-specific пароли - это сложно.

  • при определенном количестве неверных вводов пароля - блокировка учетки и пиши заявку/звони. Ах да - см выше про истечения срока действия и ту мелкую деталь что некоторые инструменты разработки - игнорят 401-й код ответа и просто долбят еще раз. Сделать кнопку для разблокировки этой учетки если ты все равно можешь зайти в терминальную сессию (там другая учетка) - ой это сложно.

Это при том что вся работа идет из под VPN для запуска которого нужен токен (и там конечно же свой пароль и сертификат, обновление этого сертификата идет каждый год новым способом, последний раз пришлось в один из офисов ехать, спросить при выдаче токена нового паспорт (а не попросить записать данные) - ой а зачем?)

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

Тут есть технический и организационный момент

Если сотрудник реально рассказал что-то за пивом, то это одна история. Но чаще - это различные файлы, доступные снаружи. И тут уже много вопросов:

Как файл прошёл мимо DLP, плохо работают фильтры? Или его выгрузили по другому каналу?

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

В утёкших файлах не было паролей от других систем? А их точно все сменили?

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

Почему сотрудник использует для заметок с паролями открытый ТГ-канал?

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

А организационный вопрос в том, что одна из задач Bug Bounty - создать альтернативу продаже уязвимостей или способов нанесения ущерба компании на чёрный рынок. Поэтому, если руководитель по безопасности готов выйти к руководству компании или на публику и сказать, что он осознанно принял решение не платить за условные утёкшие пароли, так как это не технические уязвимости, в результате этот пароль нашли и украли деньги/данные/зашифровали инфраструктуру, то ОК, подход одинаковый, хотя и неоднозначный. Человек готов сказать, что принял на себя риски, и они внезапно сработали

И есть отдельная интересная ситуация, связанная с маркетингом многих платформ (тут я бы сказал, что зарубежные в этом плане находятся в гораздо более плохом состоянии, чем отечественные):

Маркетологи, которые приходят к клиентам, рассказывают, что Bug Bounty - это прямо эталонный способ обеспечить безопасность, толпа людей проверит все возможные уязвимости, ведь у всех своя методика, а платить надо только за подтвержденные, да еще и столько, сколько сами решите и только за интересные цели (а в более приватных презентациях рассказывается, что если не попрет или будет очень много уязвимостей, то программу можно быстро прикрыть и не платить слишком много)

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

И периодически сталкиваются люди, которым рассказывали, что им будут платить почти за все, с людьми, которым рассказывали, что можно почти ни за что не платить

И периодически сталкиваются люди, которым рассказывали, что им будут платить почти за все, с людьми, которым рассказывали, что можно почти ни за что не платить

Звучит так, будто базово эти две группы людей хотят друг друга нагреть, просто разными способами: первые хотят получить всё, не заплатив ничего; вторые хотят за халтуру грести бабло лопатой. В итоге потери несут обе стороны, что становится очевидно в том числе и из этой статьи.

Просто следуйте на punkration.ru

Это не реклама

Это комментарий

Про Bug Bounty (и свой опыт) неплохо написали ребята из Ozon.
https://habr.com/ru/companies/ozontech/articles/731700/

Есть ещё одна площадка - bdu.fstek.ru, но это бесплатно :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий