Привет, Хабр! Эту статью пришлось отложить на целый год по ряду причин… Но сейчас мне удалось выдохнуть, найти время и поделиться моим прошлым опытом руководства 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: 

1 - запуск программы на StandOff, 2 - добавлены новые программы, 3 - добавлены игровые проекты, 4 - повышение цен
1 - запуск программы на StandOff, 2 - добавлены новые программы, 3 - добавлены игровые проекты, 4 - повышение цен

Пики активности графика ярко демонстрируют, что руководитель 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 в своей программе, нам необходимо понять, насколько ваши подходы к безопасности соответствуют уровню лидеров рынка. Для такой оценки введем ряд критериев сравнения: 

  1. Регулярность проведения пентестов или внутренних аудитов безопасности.

  2. Периодичность сканирования инфраструктуры на публично известные уязвимости.

  3. Присутствие своего или коммерческого SOC.

  4. Наличие практик и процессов исправления багов.

  5. Организованность процессов коммуникации с исследователями.

  6. Наличие средств защиты (антивирус, мониторинг, WAF и т.д.).

  7. Соответствие практикам безопасной разработки и развертыванию приложений. 

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)

Критичная

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 простых совета по управлению бюджетом:

  • если вы не уверены в своих расчетах, сперва выходите на приватную программу и проверяйте свою теорию. На ограниченном наборе исследователей вам будет сильно проще;

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

Не пытайтесь решить проблему деньгами и не бойтесь низких цен (начинающие исследователи будут рады любой оплачиваемой практике). Принимайте решения с умом и постоянно анализируйте накопленные знания! Очень надеюсь, что моя аналитика была вам полезна, а методика понятна ?.

Комментарии (1)


  1. oshisl
    21.05.2024 21:00

    Комментарий