Если вдруг вам негде провести код-ревью вашего проекта, присылайте код в программу 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 отчета получили такой статус; если отчёт содержит информацию не об уязвимости, а о валидной ошибке интерфейса, то переводим его в статус «Информационный»; если отчёт содержит информацию о поведении сайта или приложения, которое является нормальным, то переводим отчёт в статус «Не является уязвимостью»; если отчёт не содержит информации об уязвимости и иной полезной информации, помечаем его как «Спам». После обработки отчёта мы связываемся с коллегами из команды, ответственной за функциональность, о которой идёт речь в отчёте, и передаём им всю информацию для устранения уязвимости.  Чтобы обеспечить заветное «ваш отчёт кто-то посмотрит», на нашей стороне в процессе обработки заявок мы мониторим две ключевые метрики:  Среднее время на первую реакцию – разница между моментом получения отчёта и временем нашего первого комментария;   Среднее время триажа – разница между моментом получения отчёта и моментом его перевода в статус «Не является уязвимостью»/«Дубликат»/«Информационный»/«Спам» или моментом создания тикета на устранение уязвимости.  Прямо сейчас среднее время первой реакции на отчёт составляет менее четырёх часов, а среднее время оценки триажа – менее суток.  К таким показателям ключевых метрик мы пришли не сразу. Сейчас у нас в ходу уже третья версия процесса реагирования на отчёты об уязвимостях.  Сразу после запуска нашей программы Bug Bounty заявки мог взять в работу любой человек из группы. Мы составили довольно подробные инструкции, что и как делать с отчётами: куда посмотреть, с кем поговорить, что написать. А вот кто конкретно должен обрабатывать отчёт, не стали жёстко регламентировать.   В итоге обнаружили: отчёт, который может взять в работу любой, не берёт никто.   Всё ещё не регламентируя распределение отчётов, мы попробовали раздавать их вручную – и поймали эффект «как ни старайся, одни люди более загружены, чем другие».  Окей, мы создали регламент распределения отчётов. Составили график дежурств: дежурный должен был брать в работу все отчёты, поступившие за день.  Для автоматизации решили опрашивать платформу по расписанию, находить отчёты со статусом «Новый» без назначенного исполнителя и отправлять оповещения о них в специальный канал в корпоративном мессенджере.   Мы договорились, что дежурный в качестве реакции будет оставлять комментарий к сообщению. Если комментария не было в течение одного часа, то дежурный получал автоматический звонок на телефон. Если комментарий не появлялся в течение ещё одного часа после звонка, то оповещение улетало к руководителю группы.  Такой подход решил проблему с назначением ответственных за обработку отчётов. Однако проблема с неравномерной нагрузкой не исчезла: в какие-то дни приходило много отчётов разного уровня сложности – и дежурный мог по объективным причинам довольно надолго зависнуть на этапе триажа.   Кроме того, случались конфликты с другими событиями из рабочего календаря дежурного.  Новая итерация процесса случилась во время переезда с HackerOne на BI.ZONE. Переход на новую площадку послужил поводом для того, чтобы пересмотреть подход к дежурству. Мы стали распределять отчёту с помощью алгоритма round-robin: все люди из группы продуктовой безопасности получают заявки по очереди.  Гипотетически при таком подходе возможна ситуация, когда один человек получает в работу заметно более сложный отчёт, чем другой. Но в реальности пока это не становилось блокером и у нас получается обеспечивать целевые значения ключевых метрик.  Сложности возникают в периоды сезонных обострений появления большого потока спам-отчётов: вся группа обрабатывает новые заявки, а на выходе мы получаем мало полезной информации. Попробуем побороться с этим в четвёртой версии процесса.  Давайте рассмотрим не только то, что происходит после отправки отчёта, но и то, что происходит до. Есть несколько советов, с оглядкой на наш опыт работы с программой Bug Bounty.   Если вы только хотите войти в мир информационной безопасности, то перед отправкой отчёта есть смысл попрактиковаться в поиске уязвимостей в песочнице: поупражняться на тестовых серверах и в тестовом окружении, набить руку, освоить подходы и уже после этого переходить к поиску реальных уязвимостей.   Для этого есть специальные ресурсы: PortSwigger, Hack The Box, TryHackMe и другие.   Прежде чем формировать свой отчёт, есть смысл заглянуть в уже существующие (например, в отчёты со статусом «Disclosed» на HackerOne, доступные для просмотра даже без авторизации). Это поможет решить проблему боязни белого листа, когда неочевидно, что и как писать в заявке. Открытые отчёты других исследователей можно и нужно использовать для самообучения.   Изучая отчёты, можно обнаружить, что уязвимости были обработаны не совсем корректным образом, а значит, их можно использовать ещё раз. Это повод отправить новый отчёт. Суть программы Bug Bounty заключается в выплате вознаграждений за найденные уязвимости, но не за всякую уязвимость полагается выплата: что-то прямо сейчас находится в процессе тестирования, какие-то домены в принципе менее важны, чем другие.  За что дают деньги, а также о других принципиальных моментах конкретной программы Bug Bounty обязательно написано в её правилах.  Несколько полезных ссылок от коллег, у которых в компаниях есть программа Bug Bounty:   Как начать заниматься Bug Bounty (OTUS).  Как заработать на Bug Bounty (VK) – обязательно ознакомьтесь с советами по составлению отчётов.;  Как начать зарабатывать больше на поиске уязвимостей (Positive Technologies).  Отдельно отмечу, что необходимо уделять внимание детальному описанию влияния найденной уязвимости, – это упростит разбор отчёта и обсуждение выплаты на нашей регулярной внутренней встрече. В худшем случае это может привести к тому, что багхантер получит меньшую выплату.  На площадке BI.ZONE, если вашему отчёту присвоен статус «Спам», то от вашего рейтинга отнимут десять баллов, а за успешный триаж отчёта можно получить семь баллов.   Правда ли рейтинг важен и зачем он вообще нужен – дело вкуса. Но мне известны случаи, когда рейтинг багхантера становился аргументом в пользу более крутой должности в компании или при устройстве на новое место работы. Также рейтинг влияет на возможность получения приглашений в приватные программы Bug Bounty, к которым имеет доступ ограниченный круг исследователей.  Выплаты, рейтинг, возможность внести вклад в улучшение продуктов, которыми пользуешься сам, – важные аспекты участия в программе Bug Bounty, но есть и кое-что ещё.   Багхантер до работы над составлением отчёта об уязвимости и после – немного разные люди. В процессе формирования отчёта вы иссследуете, агрегируете информацию, систематизируете её, строите гипотезы, проверяете их, экспериментируете.   Иногда у задач, которые вы пробуете решить, нет решения (по крайней мере желаемого). Но сам процесс его поиска помогает вам если не продвинуться в профессиональном развитии, то хотя бы неплохо провести время за интеллектуальным досугом.  Надеюсь, после прочитанного чёрный ящик, в котором происходит обработка отчётов об уязвимостях, – стал для вас не таким уж и чёрным.   Программа Bug Bounty Ozon – вот тут. Заглядывайте!