14 и 15 апреля принимал участие в форуме, организованном одним известным регулятором. Хочу порассуждать по теме одного доклада и услышать ваше мнение)

Один из докладов - «Быть или не быть в Bug Bounty» - представили с двух сторон: бизнес и регулятор

🔻 Кратко о докладе Позиция регулятора: ➡️ Bug Bounty — это угроза

Аргументы: ➡️ Непрозрачность участников: неизвестно, кто стоит за «белыми хакерами» и чьи интересы они могут представлять ➡️ Риск утечки: уязвимости становятся известны до их устранения ➡️ Ограниченность проверки: нет гарантии покрытия всех векторов атак ➡️ Ответственность: если что-то пойдёт не так — кто отвечает за ущерб?

Позиция бизнеса: ➡️ Bug Bounty — это инструмент

Плюсы: ➡️ Реальное выявление слабых мест инфраструктуры (не теоретическое, а «боевое») ➡️ Практические кейсы для обучения команд ➡️ Использование материалов в смежных системах

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

🔻 Мои мысли: ➡️ Слухи о недоверии к Bug Bounty слегка преувеличены

Bug Bounty используют крупные игроки: банки (Сбер, Т-Банк, Альфа), ИТ-компании (VK, Ozon, группа Астра) и даже государственные сервисы (пример – самый главный ресурс страны, который вечно хотят взломать) Причём многие из них - в публичном формате без жёсткого отбора участников. Это косвенно показывает, что риск признан управляемым

➡️ Информация о «сливе уязвимостей» не подтверждена

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

➡️ Технический довод

Bug Bounty снижает MTTR и расширяет покрытие атак Внутренние команды безопасности ограничены: временем, экспертизой и «замыленным глазом»

Bug Bounty даёт:

➡️ асимметричное покрытие атак: десятки/сотни исследователей тестируют систему параллельно, с разными подходами ➡️ поиск нетривиальных цепочек атак, которые часто не ловятся сканерами и пентестами по чек-листу ➡️ снижение времени обнаружения уязвимостей (MTTD) и, как следствие, времени до исправления (MTTR) ➡️ проверку реальной эксплуатируемости, а не просто наличие уязвимости

🔻 Вывод:

Регулятор прав: процесс должен быть управляемым и контролируемым Но я считаю, что проблема не в Bug Bounty как явлении, а в его реализации

Если есть:

➡️ правила раскрытия ➡️ SLA на обработку уязвимостей ➡️ сегментация тестируемых систем ➡️ юридическая рамка и мониторинг то Bug Bounty становится не угрозой, а одним из самых эффективных инструментов повышения безопасности

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