Как подготовиться к выходу на багбаунти? Как общаться с комьюнити исследователей и правильно рассчитывать стоимость уязвимостей? На эти и другие вопросы отвечает Петр Уваров, руководитель направления Bug Bounty в VK.
Начнем с основ: что вообще такое багбаунти?
- Программа вознаграждения за обнаружение уязвимостей.
- Инструмент для повышения защищенности компании.
- Работа 24/7, подразумевающая оплату только за результат.
- Точка соприкосновения бизнеса и белых хакеров.
С одной стороны, в процессе участвуют багхантеры, которые ищут критичные для бизнеса уязвимости. С другой — представители компаний-заказчиков (вендоров), которые получают отчеты исследователей и пытаются понять, сколько за них нужно платить. Плюс команды триажеров, которые выступают мостиком между багхантерами и вендорами (оказывают компаниям профессиональный сервис по обработке отчетов). Наконец, есть разработчики, которые в итоге исправляют найденные уязвимости.
Для багхантера процесс выглядит достаточно просто: выбираем подходящую программу, ищем уязвимости, готовим отчет, сдаем его и получаем деньги. Либо не получаем — да, такое тоже случается...
А с точки зрения вендора?
Все немного сложнее. Вендор не просто собирает отчеты и сразу платит исследователям, а проверяет всю полученную информацию по следующей схеме:
- Проверяет валидность отчета: действительно ли исследователь прислал информацию об уязвимости? К примеру, репорт сканера — это не уязвимость. Кроме того, нужно проверить, не поступал ли отчет об этой уязвимости раньше.
- Воспроизводит уязвимость: иногда она удивительным образом воспроизводится только у исследователя :)
- Оценивает уровень опасности уязвимости: критический, высокий, средний или низкий.
- Ставит таск для разработчиков и проводит внутреннее обсуждение: сколько стоит конкретная уязвимость? После этого вендор платит багхантеру и контролирует процесс ее исправления.
- Сообщает багхантеру, что уязвимость исправлена.
Здесь важно задать себе два вопроса. Почему уязвимость появилась? И в каких еще системах она может быть? В этот момент багбаунти перестает быть просто поиском уязвимостей — становится понятно, что проблема глубже… Уязвимости — это следствие неправильно выстроенных ИБ-процессов, которые рано или поздно дают о себе знать. Проведу аналогию: когда болит зуб, нужно не купировать боль лекарствами, а идти к стоматологу.
Проще говоря, багбаунти — это инструмент для анализа проблем (поиска уязвимостей) независимыми исследователями в уже выстроенных ИБ-процессах. Штука довольно эффективная, но, как говорится, нельзя просто так взять и внедрить ее ;)
Уязвимости — это следствие неправильно выстроенных ИБ-процессов, которые рано или поздно дадут о себе знать
Почему нельзя? Что может пойти не так?
Если вы неправильно запустите программу багбаунти либо некорректно будете с ней работать, это выльется в перманентный ад. Багбаунти — это комплексный внутренний процесс, который состоит из нескольких элементов: самого кибербеза, финансов, менеджмента и работы с комьюнити. Каждый из этих блоков нужно тщательно проработать.
Анатолий Иванов, Руководитель направления Standoff 365 Bug Bounty, Positive Technologies
Компаниям, запускающим программу багбаунти в первый раз и не готовым разбираться во всем самостоятельно, эксперты Standoff 365 Bug Bounty помогают рассчитывать бюджет, валидировать уязвимости и вести коммуникацию с исследователями. Заказчикам останется устранить причину уязвимости и определить сумму денежного вознаграждения
Начнем с первого: что вендору необходимо сделать с точки зрения ИБ?
Нужно ответить на четыре вопроса. Первый: проводятся ли у вас регулярные сканы инфраструктуры? Есть ли у вас открытые порты, которые не должны светиться, слишком простые пароли, которые можно подобрать с помощью сканеров, а также банальные уязвимости и CVE. Регулярные сканы помогут решить эти проблемы и сократить затраты на услуги багхантеров.
Второй вопрос: работают ли в компании сканеры уязвимостей SAST/DAST? С их помощью можно заранее найти захардкоженные секреты, простейшие XSS и уязвимости на забытых доменах, отчеты о которых вам будут прислать багхантеры.
Третий вопрос: есть ли у вас внутренний аудит проектов? Речь о ручном сканировании, когда специалисты ищут уязвимости, которые не удалось обнаружить на предыдущих этапах разработки. Например, уязвимости, приводящие к атакам SSRF (Server-Side Request Forgery), IDOR (Insecure Direct Object References) или возможности загрузки файлов с доступом к веб-шеллу, — со всем этим сканеры справляются плохо.
И последний вопрос: как давно вы проводили пентесты? И проводили ли вообще? :) Если последний тест на проникновение был пять лет назад, его данные уже неактуальныа: слишком многое могло поменяться в ИТ-инфраструктуре.
Анатолий Иванов
Это хорошие пункты, но для старта не обязательно полностью их закрывать. Например, можно прописать в правилах, что компания готова много платить только за критические уязвимости. А за низкие и средние — на порядок меньше. Так можно сфокусировать внимание исследователей на целевых задачах, например поиске векторов, связанных с утечками персональных данных
Можно ли запустить багбаунти без всего этого?
Конечно можно, но в этом случае ваша программа проживет недолго. В первый же день вас завалят отчетами с простенькими косяками в духе «логин/пароль — admin/admin». Вы потратите на них все деньги, и багбаунти закончится, так и не принеся ощутимого результата.
Анатолий Иванов
Чтобы бюджет не закончился быстро, нужно грамотно распределять размеры вознаграждений. Это подтверждает опыт запуска десятков багбаунти-программ. Например, при относительно небольшом бюджете в 500 000 руб. на год можно установить максимальное вознаграждение за уязвимость на уровне 25 000 руб. Исследователи все равно будут приносить критические уязвимости, а бюджет при этом закончится не сразу. При желании обещанное вознаграждение можно повысить
Переходим ко второму пункту: что нужно продумать с точки зрения финансов?
Снова сформулирую основные вопросы :) Первый: сколько уязвимостей вы нашли за последний год с помощью внешних источников? Например, по результатам пентеста, в рамках аудитов и сканирований или благодаря независимым исследователям. Второй вопрос: какие это были уязвимости и как статистически они были распределены? Допустим, сколько было XSS, были ли у вас RCE или уже упомянутые SSRF и IDOR? Ответы на эти вопросы помогут лучше рассчитать бюджет.
Третий вопрос: как найденные уязвимости делятся по четырем уровням критичности?
Четвертый вопрос: информацию о каких уязвимостях вам самим хотелось бы получать? Если в компании есть сервис для работы с клиентами, логично в первую очередь смотреть в эту сторону — клиенты всегда должны быть в безопасности. Если же речь о веб-странице со сложной ИС под капотом, нужно ориентироваться на уязвимости на серверах.
Пятый и самый сложный вопрос: какую максимальную стоимость уязвимости вы готовы установить? От ответа на него зависит методика расчета бюджета. К примеру, у нас в VK есть семь грейдов для классификации программ, согласно которым самая низкооплачиваемая — до 50 000 руб., а самая дорогая — до 3,6 млн руб. Но с Bounty pass мы отменили лимиты на максимальное вознаграждение, поэтому теперь можно зарабатывать в разы больше.
Анатолий Иванов
Альтернативный вариант запуска предполагает оплату за критичность или поиск уязвимостей, приводящих к определенным бизнес-рискам. Например, если компанию интересуют утечки персональных данных, а уязвимости, связанные с дополнительными кликами пользователей по ссылкам, — нет. Если у компании нет опыта запуска программ багбаунти, а считать все параметры не хочется, эксперты Standoff 365 Bug Bounty сделают программу под ключ
Что важно предусмотреть с точки зрения менеджмента?
Первый вопрос: вы планируете запускаться self-hosted или на сторонней платформе? С одной стороны, self-hosted проще контролировать. С другой — на сторонней платформе будет больше багхантеров, которых вам не придется привлекать своими силами.
Второй вопрос: есть ли в компании ответственный за багбаунти? Когда за процесс отвечают все, за него не отвечает никто. Нужен человек, который будет общаться с багхантерами, решать вопросы со скоупом, триажем и т. д.
Третий и четвертый вопросы связаны: кто будет ставить таски для разработчиков? Готовы ли ваши разработчики к дополнительной нагрузке со стороны багбаунти? Они могут быть загружены внедрением новых фич и попросту не успеют разобраться с багами.
Последний вопрос: планируете ли вы установить SLA в части ответов багхантерам? Чем раньше вы отвечаете исследователям и чем качественнее с ними коммуницируете, тем лучше для вас.
Подробнее ознакомиться с расчетом стоимости уязвимостей можно в статье на «Хабре». А сейчас разберем пример сферической компании в вакууме.
Пусть компания N за год нашла 100 уязвимостей на внешнем периметре. Из них 70 были средне-низкого уровня, 20 высокого и 10 критических. Получается, что одной критической уязвимости соответствуют две высоких и семь средне-низких. Далее заводим уязвимости в специальную таблицу, рассчитываем коэффициент от RCE, суммируем их, умножаем на нашу пропорцию и получаем общий коэффициент для одной критической уязвимости. После этого умножаем на цену RCE и получаем бюджет на одну критическую уязвимость. Умножаем ее на то количество критов, которое находили за год, и получаем итоговый бюджет
Наконец, как правильно работать с комьюнити?
В этот раз не будет никаких вопросов, зато дам пять советов по мотивам нашей десятилетней практики. Самый главный — никогда не обманывайте багхантеров. Не занижайте стоимость выплат и всегда выполняйте свои обещания, будьте честными.
Второй совет — общайтесь вежливо. Даже если исследователь неправ и говорит какую-то дичь, проявите эмпатию. Он действительно может считать, что RCE через HTML Injection — это критическая уязвимость. Даже в этом случае нужно говорить понятно и предельно вежливо :)
Третий — будьте готовы к постоянным спорам. Багхантеры будут спорить, при этом иногда будут неправы они, а иногда вы. Это нормально — примите как должное и разбирайтесь в каждом кейсе до конца. Нельзя просто упереться и сказать: «Я прав, потому что я владелец программы!»
Четвертый — подробно объясняйте любые свои решения, например когда планируете заплатить меньше, чем ожидает багхантер. Исследователь должен понимать, почему компания считает его находку не столь критичной. И напротив, если вы проанализировали отчет и поняли, что должны заплатить за уязвимость больше ожидаемого, это тоже нужно объяснять.
Последний совет — когда не знаете, что делать, обратитесь к третьей стороне. Если хоститесь на сторонней платформе, не стесняйтесь привлекать ее экспертов в спорных ситуациях. Если же вы self-hosted, обратитесь к коллегам. Мир ИБ довольно маленький, и в нем всегда можно выйти на кого-то, кто знает больше.
Если компания является достаточно зрелой в плане коммуникации с багхантерами, то у нее могут быть свои программы лояльности для поощрения исследователей за поиск уязвимостей. К примеру, в VK это уникальная механика Bounty pass, где нет фиксированных максимальных выплат. Багхантеры могут увеличивать свои вознаграждения, накапливая бонусы с каждым оплачиваемым отчетом.
Напоследок бонусный совет — будьте пусечками, и багхантеры к вам потянутся ;)
Будьте пусечками, и багхантеры к вам потянутся ;)
