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

• критический уровень опасности — $40 000;

• высокий уровень опасности — $20 000;

• средний уровень опасности — $5000;

• низкий уровень опасности — $0.

В одной из статей мы писали, что Bug Bounty — это не разовая услуга, которую можно приобрести и забыть, как в случае с пентестом. Компании должны понимать, что внедрение, поддержка и развитие этой практики обойдутся им недешево. Так, средняя стоимость годовой подписки на услуги платформ Bug Bounty начинается с $16 000 за рубежом и стартует с 600 000 ₽/год в России.

Мы решили поговорить с Лукой Сафоновым, чтобы узнать, могут ли компании сэкономить на Bug Bounty и не потерять в эффективности программ. Вот что из этого получилось.

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

Bug Bounty-программа — эффективный метод обнаружения и устранения уязвимостей, особенно если рассматривать Bug Bounty в качестве инструмента предотвращения потенциальных угроз.

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

Приведу еще один наглядный пример: в 2020 году хакеры атаковали SolarWinds, подробности можно найти в отчете по инциденту. С тех пор компания потратила на разгребание последствий около $60 000 000 (в 2021 году затраты составили 4,6% от оборота, а в 2022 году — 3,6%).

У руководства российских компаний есть несколько причин для скептического отношения к Bug Bounty. Многие опасаются выводить уязвимости в публичную плоскость из-за риска увеличения числа атак со стороны злоумышленников. Есть мнение, что объявление о старте Bug Bounty приведет к повышенному интересу со стороны хакеров, создаст повышенный риск вымогательства и утечки данных на черный рынок. Кроме того, у самих разработчиков есть страх, что они не смогут быстро реагировать на обнаруженные баги и исправлять их. В ряде случаев это может сказаться на метриках: например, времени выхода продукта на рынок (TTM). И то, и другое звучит как минимум спорно. Я бы смотрел на это с другой стороны: есть более актуальные риски.

Bug Bounty — сравнительно новая форма сотрудничества частных рисерчеров и юрлиц, поэтому многие боятся подводных камней и «сырости» со стороны регулировки деловых отношений на законодательном уровне. Плюс многие не понимают, в чем разница между Bug Bounty и пентестом. Дело в том, что это не просто две разные сущности, а два параллельных подхода к обеспечению ИБ.

Наверное, сюда стоит отнести и опасения, связанные с бюджетом?

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

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

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

Суммы серьезные, но большую часть расходов все равно берет на себя Bug Bounty-площадка. Причем для российских площадок, на мой взгляд, история с багхантингом пока не особо выгодна. Разработка платформы, маркетинг, поддержка комьюнити «съедают» гораздо больше денег, чем площадка получает за размещение программ от бизнеса.

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

Что касается политики выплат, то, например, BugBounty.ru стимулирует багхантеров, предоставляя им максимально возможное вознаграждение. Площадка получает оплату за услуги исключительно с самих компаний. Более консервативный подход — фиксированная выплата за найденные уязвимости и комиссия за использование платформы.

Сколько сейчас стоит найденная уязвимость? 

Среднее окно выплат на BugBounty.ru — от 30 000₽ до 500 000₽ с учетом текущего курса доллара. По статистике, текущий размер выплат мало сопоставим с размером вознаграждений на западе: в России зачастую 300 000₽ — это максимум, которого ещё нужно добиться.

Основной совет для компаний тут может быть только один: указывать вилку выплат за различные уровни багов. Например, 150 000₽ или 300 000₽ за критическую уязвимость и т. д. Предположим, багхантер получил доступ к какой-нибудь админке приложения или обнаружил RCE, которая позволила ему выполнить произвольный код на сервере. Во втором случае последствия могут быть более серьезными, и оплата за найденный баг должна быть выше. Здесь еще играет роль полнота отчета, то как он написан и насколько применим.

В 2022 году Яндекс выплатил этичным хакерам 35 млн рублей, в 2023 — 70 млн рублей. В 2024 году компания планирует выделить уже 100 млн рублей на вознаграждение.

А как проходит процесс оплаты, есть ли здесь какие-то сложности?

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

У иностранных багхантеров есть интерес к работе на российских площадках?

Да, причем, интерес существенный и обоюдный. Есть много запросов иностранных сервисов на экспертизу от отечественных специалистов. 

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

С оформлением документации по выплатам тоже есть трудности? Как формируются закрывающие документы?

У каждой площадки свои наработки. Я знаю, что некоторые платформы когда-то хотели оформлять выплаты в соответствии со ст. 1057 ГК РФ «Организация публичного конкурса», но это очень бюрократизированная процедура. Условно, по каждой выплате нужно делать специальное положение о конкурсе, собирать комиссию, которая рассматривает, проходит ли найденный баг по конкурсной оценке. Можно поступить проще, оформив выплаты по агентской схеме, но не все хотят разбираться в этом. Бизнесу удобнее прийти на централизованную площадку, а не запускать частную программу.

Вернемся к вопросу о динамике затрат бизнеса в целом. Со временем затраты на Bug Bounty растут, падают или остаются на одном уровне?

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

Где-то 10% критичных уязвимостей багхантеры находят в первый месяц, средних — 20-30% от общего числа обнаруженных. Дальше, с течением времени, их количество немного снижается.

После третьего месяца наблюдается спад интереса к платформе, поскольку багхантеры замечают, что многие уязвимости уже были обнаружены и закрыты — низко висящих плодов не осталось. В этой ситуации компании начинают стимулировать участников программы деньгами. Например, возрастают суммы выплат или появляются новые возможности, чтобы привлечь внимание. Этот цикл может повторяться сколько угодно.

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

Я бы предложил сперва запускать программу в приватном режиме в формате частного пентеста. Компания может предложить багхантерам фиксированную сумму за объем обнаруженных уязвимостей. Например, заказчик платит 100 000₽, но багхантер отдает отчет по всем найденным уязвимостям за один раз. Как правило, в таких акциях участвуют целые команды. Примеров подобного багхантинга довольно много: вознаграждение делится на всех и задача закрывается быстро — все в плюсе.

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

Какие ещё могут быть особенности у этого шага? Общедоступная программа должна быть с тем же скоупом или шире, возможна ли здесь фиксированная оплата?

Всё зависит только от самой компании. После приватной программы обычно появляется понимание, чего можно ожидать, какой объем багов могут принести и какой бюджет на это понадобится. Опять же, пентест — это «слепок» инфраструктуры за какой-то период, а Bug Bounty позволяет получать фидбэк на постоянной основе. Предположим, появилась новая уязвимость или практика, под нее уже не придется отдельно искать пентестеров, а багхантер всегда держит руку на пульсе.

Например, до обнаружения CVE-2014-0160, HTTPS был лучшей технологией для обеспечения безопасной передачи данных по сети. Но в день обнаружения Heartbleed использование HTTPS превратилось в худший совет для бизнеса, пусть и ненадолго.

Баги, которые относятся к Zero-Day уязвимостям, могут быть найдены в любой момент. Здесь не важно, публичная это программа или приватная. У большинства платформ довольно строгая политика на этот счет. Но специалист, который первым отправил репорт о подобной уязвимости, не всегда может получить вознаграждение. Например, если уязвимость была обнаружена при анализе общедоступных данных: некоторые просто подписываются на рассылку обновлений, здесь даже багхантером быть не обязательно. Ситуация двоякая, поскольку специалисты по ИБ компании тоже могут быть подписаны на эти рассылки; получается, что у бизнеса есть фора в ±20 дней, чтобы все исправить.

Такой «блэкаут», когда платформа дает время на оценку уровня критичности бага и принятие мер по его устранению, является нормальной практикой. Конечно, есть компании, которые предпочитают реагировать на информацию о появлении уязвимости мгновенно, но большинству нужно время, чтобы все проанализировать. Получается, блэкаут позволяет эффективно использовать бюджет и ресурсы компании.

А какие еще есть хитрости для экономии бюджета?

Есть довольно неочевидная и классная история про то, как хороший мерч может работать эффективнее, чем финансовая мотивация. За примерами далеко ходить не нужно. Facebook раздавал багхантерам дебетовые карты White Hat Hacker, выпущенные ограниченным тиражом — это и форма признания, и работа с PR со стороны компании. Лично знаю ребят, которые за серьезные баги получили майку от Sony и были этим довольны. Я сам получал выплату от Telegram, но для меня были важны не деньги, а именно факт сотрудничества с брендом. Например, Apple не платили за багхантинг, но добавили информацию о хакерах в Зал Славы — я считаю это вопросом престижа. Хороший мерч бывает дороже денег. 

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

Если бюджета нет совсем, можно попробовать зайти со стороны благотворительности. Бывают социально-значимые проекты, с которыми багхантеры работают не за деньги. Бывают и такие, как «Взломай Пентагон» (Hack the Pentagon), когда в рамках программы проверки кибербезопасности 1500 хакеров бесплатно сдали около 26 000 багов.

А может ли платформа пойти навстречу компании, предложить какие-то услуги со своей стороны, чтобы сэкономить время штатных специалистов?

Да, это тоже хороший вариант, когда экономят на обработке отчетов. Например, у нас на площадке разбор валидного не дублированного бага от эксперта стоит от 5 000₽. То есть проверка 30 багов обойдется компании в 150 000₽, и бизнесу не придется искать специалиста в штат, который будет стоить намного дороже. Еще один открытый вопрос — рекомендации для команды разработчиков. Даже если у компании есть сотрудник, который будет разбирать поступающие отчеты, все это нужно верно оформить: отследить возможные зависимости, разобраться в стеке и сформулировать какое-то техническое задание. Одному сотруднику это не под силу, значит, компании нужно 2-3 человека, которые обойдутся еще дороже, чем разбор отчета на условном «аутсорсе».

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

Какие еще роли играют платформы? В чем особенность их работы для багхантеров и в чем — для компаний?

Площадка может выступать в качестве квалифицированного арбитра. Любая платформа — это третья сторона между багхантером и компанией. Опять же, если багхантеру не нравится оценка бага, всегда можно вынести обсуждение ситуации в публичную плоскость. Когда «проблемы» возникают у компании, площадка сама успешно модерирует этот процесс. Допустим, багхантер ведет себя некорректно или пытается вымогать деньги у компании. Сомневаюсь, что такой человек сможет работать в дальнейшем на любой другой платформе, потому что все общаются между собой, есть негласный кодекс порядочности.

Это интересно. А какую еще дополнительную пользу может извлечь компания? 

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

Есть ли тут какие-то проблемы, связанные со злоупотреблениями со стороны багхантеров?

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

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

Подобные вопросы оперативно решаются, особенно если команда со стороны платформы вовлечена в разбор этих багов.

Как компании могут оценить эффективность от денежных вложений в Bug Bounty?

Готовой схемы у меня нет. Важную роль играет специфика бизнеса, и нужно учитывать показатель «допустимые потери»: они у каждой компании свои. Есть такие бизнесы, которые просто не ставят средства СЗИ, потому что вероятность взлома несет меньше рисков, чем вероятность простоя по вине СЗИ — простой съест больше финансов, чем атака хакеров.

Как сейчас законодательно регулируется сфера багхантинга?

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

Я много общался с официальными лицами, но всё ещё есть много вопросов к статьям, к формулировкам. Например, ст. 272. «Неправомерный доступ к компьютерной информации»: почему ее пытаются применять к действиям багхантеров? У багхантера правомерный доступ, он акцептировал оферту Bug Bounty программы, он правомерно приступил к изучению периметра. Начинается все с неверной трактовки определений: законодатель сам, мне кажется, не до конца разбирается в этом.

Что в такой ситуации может защитить багхантера? Если говорить о новичках, не о топовых специалистах — активная работа над пиаром, выход на конференции, на тот же Хабр, может ли все это работать для защиты репутации?

Думаю, да. Чем больше тебя знают, тем выше шанс, что к тебе могут прислушаться. Еще один важный момент, который иногда багхантеры игнорируют — соблюдение правил программы Bug Bounty. Если в правилах есть оговорка о том, что не нужно до конца эксплуатировать уязвимость или не нужно эксплуатировать те уязвимости, которые могут привести к падению инфраструктуры, к физическому ущербу на объекте заказчика, то багхантеру стоит соблюдать эти условия.Тогда он всегда сможет сослаться на то, что действовал в рамках, обозначенных самой компанией.

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