Привет, Хабр! Эту статью пришлось отложить на целый год по ряду причин… Но сейчас мне удалось выдохнуть, найти время и поделиться моим прошлым опытом руководства Bug Bounty программой VK, сокрыв всю чувствительную для компании информацию (мы же с вами за этику, аналитику и чистую математику 😉).
В этот раз я посмотрю на Bug Bounty глазами управляющего менеджера и попробую коротко рассказать об опыте расчета стоимости вознаграждения! Если тебе интересно, как попадать в бюджет, опираясь на статистику и теорию вероятности, как привлекать Хантера для охоты на твоей программе, и как невидимая рука рынка управляет уровнем вознаграждений на Ru-сегменте — велкам под кат.
Данные решают все!
Качественную аналитику без качественных данных не построить — база, которую оспорить сложно. Моим накопленным данным уже более 15 месяцев, а это значительный срок в современном цифровом мире, поэтому я обратился к коллегам по цеху, с целью собрать данные для этой статьи.
Данная статья и расчеты в ней будут базироваться на трех китах наборах данных:
Аналитика Bug Bounty VK 2022-2023 годов, собранная и согласованная для чернового варианта этой статьи;
Выгрузка публичной информации по отчетам с Bug Bounty Bi.Zone за 2022-2024 год, любезно размеченная и анонимизированная Андрем Левкиным;
Парсинг данных с Bug Bounty Standoff 365 и сайта bugbounty.ru за 2023-2024 год в качестве контрольной выборки, предоставленной одним из активных участников российского сообщества исследователей на уязвимости, но пожелавшего остаться анонимным.
Набор данных кажется непредвзятым, охватывающим все площадки и достаточно объемным, чтобы отследить изменения 2022 - 2024 годов. В первую очередь мы будем смотреть на мерки качества, по которым я всегда определял, что программа Bug Bounty работает хорошо, это:
среднее количество отчетов за промежуток времени – неделю, месяц, квартал;
распределение отчетов по группам, критичности (CVSS);
типизация уязвимостей по вектору применения (CWE): XSS, RCE, взлом аккаунта и т.д.
Результативность программ и активность исследователей
Общее количество отчетов, сдаваемых исследователями, ежегодно растет. К сожалению, сейчас полноценно сравнить рост числа отчетов не получается, так как старт 2х из 3х российских программ был летом 2022 года, и аналитика по программам не насчитывает двух полных лет существования. Сейчас мы можем прогнозировать рост числа отчетов на более чем 20% от года к году.
Качество отчетов, получаемых на Bug Bounty снизилось, это обусловлено ростом числа участников российского сообщества исследователей ИБ. Молодые исследователи заинтересованы в поиске уязвимостей, но создаваемые ими отчеты низкого качества.
Вознаграждения за найденные уязвимости в 2024 году почти в 2 раза больше, чем вознаграждения за аналогичные баги в 2022 году. Хотя деньги всегда будут оставаться основным мотиватором для исследователей, на количество репортов также очень сильно влияет:
PR-активность вендора: участие в конференциях, статьи и публикации в СМИ, анонсы изменений в чатах;
Регулярность коммуникаций: постоянное общение с комьюнити в чатах, урегулирование вопросов по программам, скорость и корректность ответов Bug Bounty аналитиков.
Как пример рассмотрим график активности исследователей в рамках программы VK:
Пики активности графика ярко демонстрируют, что руководитель Bug Bounty должен относиться к своей программе, как к полноценному продукту, заранее планируя бюджет не только на выплаты исследователям, но и PR-план, а также регулярно проводить работы по контролю качества триажа и отработку претензий внутри сообщества.
Про выплаты, бюджеты и расчеты, которые понравятся финансистам…
Прогнозировать затраты – одна из основных задач руководителя. Давайте разберемся, как рассчитать бюджет Bug Bounty программы в ситуации неизвестности количества (и критичности) принесенных багов.
Как мы помним из статистики, программа в первые 2-3 месяца после запуска потратит примерно 40-50% годового бюджета. Потому что все новое привлекает повышенное внимание. В последующие месяцы траты пойдут на спад, скорее всего, в 2 раза.
История индивидуальна для каждой из компаний, но классическая схема распределения при запуске в январе такова:
Q1 | Q2 | Q3 | Q4 |
40% | 20% | 20% | 20% |
Для мотивации хакеров рекомендуем проводить дополнительные активности спустя 3-5 месяцев. Это поможет удержать внимание исследователей. Например, компания VK раз в 3 месяца обновляет бонусы, а Тиньков проводил яркие ивенты для студентов.
P.S.: PR и Маркетинговые мероприятия в данном бюджете учитываться не будут, да и рассчитывает их каждая организация по сугубо индивидуальной форме 😉.
Как рассчитать первоначальную стоимость крита (RCE)?
Если вам не хочется сильно погружаться в процесс расчетов, следующие разделы не для вас, используйте простую формулу: стоимость RCE не может превышать бюджет программы за квартал. Заполняйте таблицу прошлого раздела и переходите к заключению.
Для тех, кто хочет рассмотреть процесс подробнее, давайте перейдем к построению вашей модели с определения максимально допустимого размера выплаты.
Рынок задает цену, цена в свою очередь привлекает исследователей. Если не ориентироваться на выплаты других программ, то исследователей будет мало, и аналитические данные просто не сработают. Поэтому вам необходимо вычислить среднюю стоимость RCE “сейчас”. Сделать это просто: суммируем максимальный размер выплаты со всех публичных программ и делим сумму на их число.
В России средняя цена за RCE чуть более 360 000 руб. (на момент написания статьи). Для того чтобы корректно установить цену на RCE в своей программе, нам необходимо понять, насколько ваши подходы к безопасности соответствуют уровню лидеров рынка. Для такой оценки введем ряд критериев сравнения:
Регулярность проведения пентестов или внутренних аудитов безопасности.
Периодичность сканирования инфраструктуры на публично известные уязвимости.
Присутствие своего или коммерческого SOC.
Наличие практик и процессов исправления багов.
Организованность процессов коммуникации с исследователями.
Наличие средств защиты (антивирус, мониторинг, WAF и т.д.).
Соответствие практикам безопасной разработки и развертыванию приложений.
Disclaimer: Далее все оценки сознательно упрощены для читателя и даны на моем опыте выведения новых Bug Bounty программ. Они могут быть субъективными или неприменимы в вашем случае.
Честно ответив на критерии, выбираем одну из стратегий:
Если хотя бы на 70% вы закрываете эти критерии, то можно рассчитывать RCE как у опытного вендора Bug Bounty (от 250 000 до 350 000 руб).
Если же вы их закрываете чуть больше, чем на 50%, то ставьте стоимость примерно вполовину меньше (от 100 000 до 200 000 руб).
Если вы оцениваете свое соответствие от 30% до 50%, то подумайте о приватной программе Bug Bounty, обязательно посоветовавшись с площадкой об исследователях, которых стоит пригласить.
Если же результаты соответствия менее 30%, то вам не стоит еще выходить на Bug Bounty — вы потратите слишков много денег на исправление уязвимостей, которые могли быть найдены более эффективным способом.
Как рассчитать бюджет от стоимости RCE?
Методика далее будет базироваться на одной известной величине — стоимость RCE в вашей программе как самого большого вознаграждения. На основании наибольшей платы мы создаем таблицу коэффициентов для потенциально возможных угроз в соответствии с принятой моделью злоумышленника.
Например:
Распределяем коэффициенты модели следующим образом:
Уязвимость | Пропорция | Важность |
Remote code execution (RCE) | 1 | Критичная |
Injections (SQLi or equivalent) | 0.75 | Критичная |
Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions | 0.75 | Высокая |
RCE in dev. infrastructure / isolated or virtualized single-purpose process (e.g. text-to-speech) | 0.25 | Средняя |
SSRF, non-blind (with ability to read reply text), except dedicated proxies | 0.25 | Высокая |
SSRF, blind, except dedicated proxies | 0.05 | Средняя |
Server Side vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, credit cards, e-mail messages) | 0.3 | Высокая |
Server Side vulnerability with information disclosure (e.g. memory Leaks / IDORs) of protected personal data or sensitive client information | 0.15 | Средняя |
Server Side vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive application or infrastructure data | 0.1 | Низкая |
Admin / support interface authentication bypass | 0.15 | Низкая |
Admin / support interface blind XSS | 0.15 | Низкая |
Disclaimer: Данная таблица приведена исключительно в качестве примера методики и учитывает интересовавшие меня баги, основываясь на модели внешнего нарушителя. В каждом конкретном случае виды уязвимостей и коэффициенты могут быть изменены под задачи компании.
При выходе новой программы Bug Bounty каждая компания должна определить для себя, какое количество уязвимостей разного типа критичности она хочет получить за год и какие уязвимости с каким типом критичности соотносятся.
Таблиц соответствий может быть несколько, а сами ресурсы могут отличаться по уровню важности, но это отдельная тема для разговора. Если статья будет популярна, обещаю выпустить следующую, в которой рассмотрим Tier-ресурс и влияние мотивационных выплат новичкам.
Опираясь почти на двухлетнюю аналитику, мы получаем такую статистику распределения уязвимостей из примера таблицы выше: 5% — прийдется на уязвимости критичные и высокой важности, 20% — на средние, 75% — на низкие.
Например: если вы хотите получить 2 критических уязвимости, то рассчитывайте на 8 уязвимостей средней важности и 30 рядовых проблем ИБ.
После определения целей формируем средневзвешенный коэффициент каждого из цветов.
Например:
(1+0.75+0.75+0.25+0.3)/5 = 0,61 – Критичная/Высокая;
(0.25+0.05+0.15)/3 = 0.15 – Средняя;
(0.1+0.15+0.15)/3 = 0.13 – Низкая.
Определив средний коэффициент, надо рассчитать потенциальную стоимость каждой уязвимости путем прямого перемножения коэффициента и стоимости.
Например:
0.612 + 0.158 + 0.13*30 = 1.22 + 1.2 + 3.9 = 6.32
Это примерный бюджет на год в RCE, если мы за год ожидаем 2 штуки.
На последнем этапе переводим бюджет в деньги и выполняем его поквартальное распределение.
Например:
Мы решили что соответствуем на 70%, следовательно стоимость RCE – 250 000 руб. Значит полный бюджет на Bug Bounty составит
1 580 000 руб.
Q1 | Q2 | Q3 | Q4 |
632 000 руб | 316 000 руб | 316 000 руб | 316 000 руб |
Disclaimer: Я напоминаю, что к полученной сумме нужно добавить цену на аренду платформы (о ней вам надо договориться отдельно), а также заложить не менее 10%-30% на PR.
Заключение
Вы всегда можете выполнить обратную задачу, если у вас есть сформированный бюджет на год, и вы примерно знаете, как часто находили проблемы в системе не только в рамках программы Bug Bounty (например, с помощью сканирования, пентестов и тд.).
2 простых совета по управлению бюджетом:
если вы не уверены в своих расчетах, сперва выходите на приватную программу и проверяйте свою теорию. На ограниченном наборе исследователей вам будет сильно проще;
динамически управляйте ценой за уязвимости: если вы перерасходуете бюджет квартала, то снижайте цены, если вам не приносят баги – увеличивайте.
Не пытайтесь решить проблему деньгами и не бойтесь низких цен (начинающие исследователи будут рады любой оплачиваемой практике). Принимайте решения с умом и постоянно анализируйте накопленные знания! Очень надеюсь, что моя аналитика была вам полезна, а методика понятна 😊.
