Перед тем как написать этот пост, я расспросил знакомых из разных IT-компаний и столкнулся с полярными мнениями. Одни горячо топили за bug bounty и говорили, что это чуть ли не лучший способ поддерживать безопасность (правда часто оказывалось, что программу открыли еще до их найма), другие уверены, что это слишком рискованно.

Истина, как всегда, где-то посередине. Спешный запуск bug bounty будет опасной авантюрой. Вдумчивый — становится контролируемым мероприятием, которое приносит предсказуемую пользу, но в любом случае такую программу нельзя назвать универсальным ответом на киберугрозы.

Минусы баг-баунти

У bug bounty есть очевидные недостатки. Прежде всего, такая программа — это не услуга, которую можно приобрести и забыть, как в случае с пентестом. Это практика, которую придется целенаправленно внедрять, поддерживать и развивать.

Программой нужно управлять

Необходимо, чтобы специально обученные сотрудники координировали работу программы, поддерживали коммуникацию между баг-хантерами и разработчиками. Чем больше скоп, тем больше уйдет сил и ресурсов.

Баг-баунти имеет низкое соотношение сигнал/шум

Я имею в виду соотношение полезных и бесполезных сообщений об ошибках. Публичные программы вознаграждения за уязвимости создают много недостоверных и повторяющих друг друга отчетов. Компании редко раскрывают статистику, но, по данным Bugcrowd за 2015 год, среднее соотношение сигнал/шум составляло 20 на 80. Google и вовсе пишет только о 10% полезных отчетов. Естественно, множество ложных сообщений снижает рентабельность программы.

Программа баг-баунти создает дополнительные риски

Это то, чего часто опасаются руководители. Плохо спланированная программа может привести:

• к перерасходу и бесполезным тратам;

• к перегрузке разработчиков, вынужденных разрываться между устранением багов и написанием новых фич;

• к разнообразным пиар-рискам и репутационным потерям;

• к путанице, в которой служба безопасности не сможет отличить работу баг-хантеров от реальной угрозы.

Плюсы баг-баунти

Надеюсь, вы еще не закрыли статью, потому что преимущества bug bounty обычно перевешивают недостатки.

Большое число исследователей

В команду пентестеров в среднем входит около 10 человек. Баг-хантеров сотни, если не тысячи, и их легко привлечь к работе. Большое число потенциальных исследователей решает проблему ротации, которая характерна для штатных безопасников и пентестеров. Когда раз за разом проверяешь один и тот же сервис, взгляд постепенно замыливается. В случае bug bounty этого не происходит, потому что исследователи постоянно сменяются.

Бесконечный пентест

Отчет пентестеров — это снапшот состояния системы безопасности. Можно приглашать их раз в год или раз в квартал, но, если релизный цикл короче, останутся окна, в которые приложение или сервис остались без проверки. Баг-хантеры же работают 24 на 7. Они не ограничены по времени и порой присылают отчеты о неявных сложных ошибках, на поиски которых, вероятно, уходят месяцы.

Разнообразные навыки

Некоторые баг-хантеры специализируются на отдельных видах ошибок и очень хорошо их находят. Другим нравится искать баги в конкретных технологиях, например, браузерных расширениях или протоколах IoT.

Положительный PR-эффект

При должном освещении, запуск общедоступной bug bounty-программы — быстрый способ убедить общественность в том, что вы серьезно относитесь к информационной безопасности.

Тренировка для безопасников

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

«Страховка» от хакеров

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

Стоимость программы баг-баунти

Разберем на примере. По словам Игоря Булатенко, пару лет назад QIWI тратила на bug bounty за год примерно столько же, сколько и на один комплексный пентест. Поскольку речь идет о непрерывной программе, в целом это так, но на деле все несколько сложнее.

Стоит иметь в виду, что стоимость запуска и владения программой сильно зависит от того, насколько хорошо отлажено управление уязвимостями. Если выстраивать эти процессы с нуля, потребуется много подготовительной работы, и запуск обойдется недешево. Правда, если действовать поэтапно, то эти расходы распределяются по времени. И лишь затем объем затрат снижается и стабилизируется.

Как подготовиться к запуску программы

Открытие программы вознаграждения за найденные ошибки — это уйма организаторской работы. Поэтому стоит начать с выбора DRI (directly responsible individual) — человека, ответственного за проект. Ведь кто-то должен всех обойти и предупредить, что грядет. Bug bounty-программа затронет всю компанию сверху донизу.

Предупредите бизнес

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

Привлеките к проекту финансовый отдел

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

Привлеките PR-службу

PR придется работать сразу в трех направлениях:

• На Хабре легко найти позитивные кейсы, примеры того, как рассказ об устранении той или иной уязвимости стал крутой нативной рекламой компании. Bug bounty дает много таких инфоповодов.

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

• Опыт PR-службы (особенно если в ней работают комьюнити-менеджеры) пригодится в общении с багхантерами.

Привлеките юристов

Они помогут проработать правила для программы bug bounty, написать оферту и гарантируют, что все по закону.

Привлеките безопасников, если еще не сделали этого

Их опыт пригодится в составлении таблицы наград за уязвимости. Кроме того, им предстоит подготовить IT-инфраструктуру к старту программы и придется участвовать в разборе отчетов баг-хантеров.

Предупредите разработчиков

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

Не забудьте про SRE

Старт bug bounty наверняка отразится на метриках. Наверняка начнет прыгать общее число запросов и количество ошибок. Будет лучше, если команда мониторинга будет к этому готова.

Оцените готовность компании

Основная причина проблем с bug bounty — слишком быстрый запуск. Стартуя вы добавляете новый поток ошибок в процесс управления уязвимостями. Если этот поток будет слишком большим или неконтролируемым, можно запросто захлебнуться. Да, в теории, найденные ошибки можно проигнорировать, но отчеты по ним продолжат приходить. К тому же, каждая неустраненная критическая уязвимость, о которой вы знаете, — это дополнительная ответственность и, следовательно, дополнительный риск.

Прежде чем стартовать, стоит убедиться в том, что система управления уязвимостями готова к масштабированию и работает как часы. Это важно еще и потому, что платформы bug bounty заключают с компаниями соглашения, в которых указаны максимальные сроки обработки отчетов.

Распределите обязанности

Хорошая практика — заранее распределить обязанности по общению с баг-хантерами, обработке отчетов, выплате вознаграждений. HackerOne рекомендует распределить эти обязанности между компетентными членами команды: выделить 20–30% рабочего времени и проводить еженедельную ротацию. Получится нечто вроде дежурства по bug bounty-программе. Думается, что эта практика подходит для небольших компаний.

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

Заведите систему отслеживания репортов

Чтобы эффективно обрабатывать отчеты, потребуется система учета, классификации и линковки, которая позволит находить дубли. Если связать валидные отчеты с таск-трекером, можно будет отслеживать исправление уязвимостей. Для этого не нужны специальные решения, подойдут привычные Jira или Zendesk. Конкретный инструмент не так важен — главное, чтобы он позволял поддерживать порядок.

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

Подумайте о том, чтобы создать песочницу для баг-хантеров

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

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

Напишите правила для баг-баунти программы

Эти правила определяют то, как будут работать баг-хантеры, так что чем больше времени потратите на их составление, тем лучше.

Ограничьте область действия программы

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

Также в правилах bug bounty формируют список исключений, ограничивают скоп, перечисляя домены, IP-адреса, приложения службы или типы атак, которые не входят в программу.

В число исключений часто попадают:

• уже известные или неинтересные уязвимости, например, те, что легко находят автоматические сканеры;

• DoS-атаки;

• взаимодействия с клиентами компании и их данными. В качестве целей для баг-хантеров обычно заводят ряд фейковых учетных записей;

• социальная инженерия, в том числе проверка физической безопасности офисов (это задачи для пентестеров).

Также, возможно, вы захотите запланировать перерывы в программе, чтобы синхронизировать ее с планом релизов или создать запас времени на разбор отчетов.

Назначьте награды

С точки зрения исполнителей, хорошая bug bounty-программа должна иметь прозрачную, внутренне непротиворечивую систему оплаты. Простой способ добиться этого — привязать размер награды к серьезности уязвимости. Для этого лучше ориентироваться на OWASP TOP10. Впрочем, никто не запрещает делать поправку на скоуп, устанавливать одни расценки за уязвимости на основном сайте и другие для мелких lending-pages или, например, выдавать увеличенные вознаграждения за баги, которые интересуют вас больше всего.

Что касается самих наград, то баг-хантеры хотят за проделанную работу денег, но выплаты можно сочетать с другими поощрениями:

• Различными сувенирами типа футболок и стикеров. Они служат неплохой рекламой вашей программы в профессиональном сообществе.

• Повышением рейтинга — как правило, исследователи с высоким рейтингом имеют доступ к более интересным bug bounty-программам на отдельно взятой площадке.

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

• Признанием. Стена славы на сайте компании, грамота, официальная благодарность — все это также ценится.

Сформулируйте требования к отчетам об ошибках

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

Напишите оферту

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

Учитывая распространенность bug bounty, нет необходимости изобретать велосипед. При разработке оферты стоит ориентироваться на опыт других компаний, например соседей по bug bounty-площадке .

Определитесь с площадкой

Некоторые компании объявляют об открытии bug bounty-программы на сайте и общаются с баг-хантерами напрямую. Однако, специализированные платформы все же удобнее, так как они дают больше возможностей для управления программой, предоставляют инструменты для менеджмента отчетов и помощь в общении с баг-хантерами.

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

Из международных площадок отмечу наиболее крупные: Hackerone, Cobalt и Bugcrowd. Доступ к ним для российских компаний сейчас затруднен или вовсе не возможен, так что начали активно развиваться локальные платформы bugbounty.ru и The Standoff 365.

Старт программы

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

Сейчас платформы для bug bounty предлагают сперва запустить приватную программу и пригласить туда ограниченное число баг-хантеров. Это самый простой способ стартовать.

Сперва стоит ограничить скоп только критическими уязвимостями и позвать 10–20 опытных исследователей на проверку основных доменов. Заодно протестируете обработку отчетов. Затем можно расширить скоп и увеличить число участников. И вновь проверить, что все работает как надо, и при необходимости внести изменения в условия программы. И лишь затем пора объявлять о программе публично и открывать ее для всех желающих.

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

Программа баг-баунти запущена — что дальше?

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

Общайтесь с баг-хантерами

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

Выплачивайте награды

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

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

Также не стоит жадничать. Напротив, поощряйте авторов качественных отчетов, даже если вы уже знаете об этой уязвимости. Это поможет удержать талантливых исследователей в вашей программе. Также имеет смысл платить за отчеты об опасных уязвимостях, которые находятся вне области действия программы. Однако, важно объяснить баг-хантеру, что это нарушение условий оферты, и, возможно уменьшить выплату.

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