Если вдруг вам негде провести код-ревью вашего проекта, присылайте код в программу Bug Bounty – там ваши наработки как минимум кто-нибудь посмотрит ???? 

Такой мем появился у нас в команде продуктовой безопасности Ozon после второго запуска Bug Bounty программы. Как и во многих шутках, в этой есть доля правды: нашу программу по поиску уязвимостей мы стараемся развивать так, чтобы каждый багхантер гарантированно получал адекватный ответ на свою заявку в разумные сроки.  

Давайте в этой статье заглянем в чёрный ящик – посмотрим, что происходит с вашим отчётом об уязвимости на нашей стороне, то есть в Ozon. 

История появления программы Bug Bounty в Ozon – достаточно стандартная. Команда информационной безопасности хотела узнавать об уязвимостях и была готова за это платить.  

Первая наша программа жила на площадке HackerOne примерно полтора года. После ухода HackerOne из России мы оказались перед выбором: создать собственную площадку для программы Bug Bounty или выбрать внешний сервис. Важно было учесть не только технические аспекты, но и юридическую и финансовую стороны выплат багхантерам, ведь нужно иметь возможность отправлять вознаграждения физлицам, которые могут быть не только из России. Мы решили сфокусироваться на сути программы, а бюрократические вопросы делегировать, и начали двигаться в сторону готовой внешней платформы. 

При выборе новой площадки нам было важно иметь возможность перенести на неё без потерь все существовавшие на тот момент процессы. Это выразилось в следующих требованиях:  

• API для автоматизации получения отчётов;  

• карточка отчёта с достаточным количеством информации: полями для прикрепления тикета из баг-трекера, указания уровня критичности бага в соответствии с Common Vulnerability Scoring System (CVSS), даты создания тикета;  

• возможность группировки отчётов по статусам.  

Мы изучили возможности разных площадок, поговорили с коллегами из других компаний, которые развивали программы Bug Bounty, обсудили вопрос внутри – и выбрали площадку BI.ZONE. 

Это что касается предыстории. А теперь давайте посмотрим, как сейчас устроена программа Bug Bounty Ozon.  

Внутри чёрного ящика: статусы отчётов  

Уведомления о новых отчётах мы получаем по двум каналам: почтовая рассылка и через поллинг.  

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

Процесс обработки отчёта выглядит так: 

• получаем отчёт;  

• проводим первичный анализ: 

  • если решили, что информация об уязвимости требует активных действий:

    • заводим RISK-тикет;

    • присваиваем отчёту статус «Пройден первичный триаж»; 

    • обсуждаем отчёт на еженедельной встрече в четверг;

    • обновляем RISK-тикет: уточняем уровень опасности уязвимости;

    • назначаем размер выплаты багхантеру;

    • переводим отчёт в статус «Уязвимость подтверждена»;

    • багхантер получает вознаграждение;

  • активных действий не требуется:

    • если отчёт содержит информацию об уязвимости, которая была описана ранее другим исследователем или о которой стало известно в результате внутреннего аудита безопасности, то переводим его в статус «Дубликат». Отчеты с таким статусам не подлежат выплате, но не стоит расстраиваться, в нашей Bug Bounty программе на площадке BI.ZONE всего 2 отчета получили такой статус;

    • если отчёт содержит информацию не об уязвимости, а о валидной ошибке интерфейса, то переводим его в статус «Информационный»;

    • если отчёт содержит информацию о поведении сайта или приложения, которое является нормальным, то переводим отчёт в статус «Не является уязвимостью»;

    • если отчёт не содержит информации об уязвимости и иной полезной информации, помечаем его как «Спам».

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

Управляешь тем, что измеряешь: внутренние метрики процесса обработки отчётов

Чтобы обеспечить заветное «ваш отчёт кто-то посмотрит», на нашей стороне в процессе обработки заявок мы мониторим две ключевые метрики: 

• Среднее время на первую реакцию – разница между моментом получения отчёта и временем нашего первого комментария;  

• Среднее время триажа – разница между моментом получения отчёта и моментом его перевода в статус «Не является уязвимостью»/«Дубликат»/«Информационный»/«Спам» или моментом создания тикета на устранение уязвимости. 

Прямо сейчас среднее время первой реакции на отчёт составляет менее четырёх часов, а среднее время оценки триажа – менее суток. 

Эволюция процесса реагирования на отчёты  

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

Версия 1: как-нибудь само 

Сразу после запуска нашей программы Bug Bounty заявки мог взять в работу любой человек из группы. Мы составили довольно подробные инструкции, что и как делать с отчётами: куда посмотреть, с кем поговорить, что написать. А вот кто конкретно должен обрабатывать отчёт, не стали жёстко регламентировать.  

В итоге обнаружили: отчёт, который может взять в работу любой, не берёт никто.  

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

Версия 2: дежурный 

Окей, мы создали регламент распределения отчётов. Составили график дежурств: дежурный должен был брать в работу все отчёты, поступившие за день. 

Для автоматизации решили опрашивать платформу по расписанию, находить отчёты со статусом «Новый» без назначенного исполнителя и отправлять оповещения о них в специальный канал в корпоративном мессенджере.  

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

Такой подход решил проблему с назначением ответственных за обработку отчётов. Однако проблема с неравномерной нагрузкой не исчезла: в какие-то дни приходило много отчётов разного уровня сложности – и дежурный мог по объективным причинам довольно надолго зависнуть на этапе триажа.  

Кроме того, случались конфликты с другими событиями из рабочего календаря дежурного. 

Версия 3: дежурные по циклу 

Новая итерация процесса случилась во время переезда с HackerOne на BI.ZONE. Переход на новую площадку послужил поводом для того, чтобы пересмотреть подход к дежурству. Мы стали распределять отчёту с помощью алгоритма round-robin: все люди из группы продуктовой безопасности получают заявки по очереди. 

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

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

Перед отправкой отчёта: шесть быстрых советов для багхантеров 

Давайте рассмотрим не только то, что происходит после отправки отчёта, но и то, что происходит до. Есть несколько советов, с оглядкой на наш опыт работы с программой Bug Bounty.  

Совет 1: не пренебрегайте предварительной подготовкой  

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

Для этого есть специальные ресурсы: PortSwigger, Hack The Box, TryHackMe и другие.  

Совет 2: ознакомьтесь с существующими отчётами  

Прежде чем формировать свой отчёт, есть смысл заглянуть в уже существующие (например, в отчёты со статусом «Disclosed» на HackerOne, доступные для просмотра даже без авторизации). Это поможет решить проблему боязни белого листа, когда неочевидно, что и как писать в заявке. Открытые отчёты других исследователей можно и нужно использовать для самообучения.  

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

Совет 3: читайте правила 

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

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

Совет 4: изучайте советы по багхантингу 

Несколько полезных ссылок от коллег, у которых в компаниях есть программа Bug Bounty:  

• Как начать заниматься Bug Bounty (OTUS). 

• Как заработать на Bug Bounty (VK) – обязательно ознакомьтесь с советами по составлению отчётов.; 

• Как начать зарабатывать больше на поиске уязвимостей (Positive Technologies). 

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

Совет 5: обращайте внимание на свой рейтинг 

На площадке BI.ZONE, если вашему отчёту присвоен статус «Спам», то от вашего рейтинга отнимут десять баллов, а за успешный триаж отчёта можно получить семь баллов.  

Правда ли рейтинг важен и зачем он вообще нужен – дело вкуса. Но мне известны случаи, когда рейтинг багхантера становился аргументом в пользу более крутой должности в компании или при устройстве на новое место работы. Также рейтинг влияет на возможность получения приглашений в приватные программы Bug Bounty, к которым имеет доступ ограниченный круг исследователей. 

Совет 6 (главный): пробуйте! 

Выплаты, рейтинг, возможность внести вклад в улучшение продуктов, которыми пользуешься сам, – важные аспекты участия в программе Bug Bounty, но есть и кое-что ещё.  

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

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

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

Программа Bug Bounty Ozon – вот тут. Заглядывайте!