Если вдруг вам негде провести код-ревью вашего проекта, присылайте код в программу 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 – вот тут. Заглядывайте!
