Поиск ошибок своими силами или силами сторонних консультантов (аудиторов) — необходимая часть процесса обеспечения безопасности. Ничто в безопасности не является панацеей, все измеряется эффективностью затрат. В данном случае, оплата по факту обнаружения уязвимости оправдана. Многие компании — например «Фейсбук» — выдают премии своим сотрудникам при обнаружении уязвимостей в своих же продуктах, так как по правилам они не могут участвовать в bug bounty. Весь краудсорсинг затевается, чтобы снизить риск человеческого фактора и «замыленности» глаз. При большой массе исследователей, bug bounty дает возможность сделать аудит приложений непрерывным. Плохо, что параметры этого процесса никак нельзя контролировать (багхантеры работают хаотично), но сама идея хороша. Здесь я отвечу на распространённые вопросы о программах bug bounty.
Иван Новиков, CEO Wallarm
Кому стоит вводить программы bug bounty?
Всем компаниям с продуктами в интернете. Но важно следить за стоимостью уязвимостей, чтобы не разорить себя и не обидеть исследователей.
С чего стоит начать?
Прежде всего стоит изучить свой сетевой периметр и приложения, которые планируется выставлять на всеобщий взлом. Важно четко прописать в правилах программы, какие сетевые сервисы и приложения попадают в программу, а какие нет. Это называется out-of-scope. Представьте себя на месте человека, который нашел критическую уязвимости в вашем блоге, а потом узнал, что не получит выплату, так как блог не находится в программе поиска уязвимостей. Таким нюансы должны быть четко прописаны.
После запуска программы стоит ожидать большого потока очевидных уязвимостей, например, отсутствия или проблем конфигурации SSL, несоблюдений правил базовых настроек безопасности и прочего. Чтобы минимизировать этот поток, стоит исключить в правилах программы такие уязвимости. Их находит любой стандартный сканер, так что стоит запустить его самостоятельно и исправить все рекомендации до запуска программы.
А это вообще работает?
Очень часто хантеры находят критические уязвимости и «спасают» компании. Из последнего — критическая уязвимость LinkedIn, которая давала возможность читать файлы от «рута» и выполнять запросы от имени сервера. Или вот Facebook взломал хантер и увидел, что ранее его уже взломали черные хакеры ровно так же. Это было феерично. ☺
Bug bounty поможет обезопасить себя от «плохих» хакеров?
Всегда есть риск, что человек найдёт ошибку и отдаст её конкурентам, независимо от того, есть у компании программа bug bounty или нет. Поэтому нужно внедрять такие процессы безопасности, как повышение осведомленности сотрудников, непрерывный мониторинг, обнаружение атак, поиск уязвимостей, проверку кода и другие меры обнаружения атак и уязвимостей.
Как компании обычно реагируют на «белых» хакеров?
Как правило, все решается миром, так как исследователи не шантажируют компании, а сразу предоставляют информацию об обнаруженных уязвимостях бескорыстно. Даже если нет программы bug bounty, то исследователь, который сразу предоставляет информацию об уязвимости, редко встречает негатив со стороны компании. Но бывает всякое, так как тут играет роль человеческий фактор и политика внутри компании. Чтобы немного формализовать общение с вендором, можно использовать практику работы через CERT. В этом случае, негативный эффект нивелируется, так как с вендором общаются представители CERT, а не исследователь. Например, я купил машину и нашел уязвимости, но сдавал их в Audi через CERT, а не напрямую. CERT уже сам связывался с VW-group.
Уговорили, делаем. Сколько я должен заплатить за каждую уязвимость?
Сумма вознаграждения за уязвимость зависит от степени риска ошибки. Причем этот риск определяется постфактум на стороне держателя программы, что часто приводит исследователей в замешательство. И да, ситуация с торгами очень распространена. Лучше максимально четко описать суммы и примеры уязвимостей в правилах, так вы заработаете положительную репутацию в кругу исследователей. Очень важно также прописать, что считается уникальной уязвимостью. Например, у меня был примечательный случай с одной крупной социальной сетью. Я отправил уязвимость доступа к базе данных через один из сетевых сервисов и получил награду около $1000. Затем через несколько дней после ее исправления нашел точно такую же уязвимость в другом сервисе этой же компании (на другом IP адресе) и получил ответ, что выплаты не будет, так как это та же самая (заметим, уже исправленная несколько дней назад) уязвимость. По негласному правилу, которого придерживаются все компании — это две разные уязвимости, если вы не можете сразу исправить все. Чтобы таких конфликтов не случалось — лучше прописывать правила максимально четко.
Большие суммы вознаграждения, как правило — реальное желание улучшить продукт посредством привлечения к его исследованию лучших из лучших. Так делают Google, Mozilla, Apple, Tesla и другие большие игроки. Они привлекают внимание большими суммами и проводят дополнительные конкурсы, помимо bug bounty.
Если вы тоже хотите привлечь больше внимания к своей программе, можно сделать высокой минимальную сумму выплаты. Этот параметр куда важнее, чем максимальная сумма вознаграждения. Будет очень здорово если вы строго пропишете какие-то измеримые параметры самых критических для вас уязвимостей и выплаты за них. Например, перехват контроля управления автомобилем нашей марки через интернет без контактного вмешательства в салон — $100 000. Чем подробнее будут описаны правила, тем больше лояльных исследователей вы получите в числе своих хантеров.
