Александр КравченкоИсходя из выбранного формата реализации программы bug bounty — классического или APT bug bounty — процесс верификации отчетов будет несколько отличаться.
Классический формат bug bounty
В этом случае все отчеты, присылаемые по программе bug bounty, следует подвергнуть первичной сортировке для выявления и исключения дубликатов, отчетов об уязвимостях низкого уровня опасности или просто некорректно оформленных отчетов. Организация, которая реализует программу, должна внимательно изучить оставшиеся отчеты и убедиться, что они соответствуют требованиям программы (срок, действие в рамках границ проведения работ и т. п.).
Далее необходимо проверить, что найденные уязвимости действительно существуют и могут быть проэксплуатированы при атаках на систему. Организация должна провести проверку силами службы информационной безопасности и ИТ-подразделений (в ручном режиме или с применением автоматизированных средств). Если собственных сил организации недостаточно, имеет смысл привлечь исследователя кибербезопасности для верификации найденных уязвимостей или запросить у него дополнительную информацию, которая поможет в проверке.
Если организация подтверждает наличие уязвимости, она должна связаться с исследователем, чтобы обсудить детали и возможные способы ее устранения. Каждой найденной уязвимости необходимо присвоить уровень опасности. Это можно сделать, например, воспользовавшись методикой CVSS 3.1. Размер вознаграждения рассчитывается исходя из уровня опасности уязвимости.
APT bug bounty
Этот формат предполагает схожие действия по верификации отчетов, но с некоторыми отличиями. Поступающие отчеты также подвергают сортировке, чтобы исключить те, которые не подходят под обозначенные требования.
Затем необходимо проверить, что возможность реализации одного или нескольких недопустимых событий действительно существует, учитывая утвержденные в организации критерии их реализации и описанный в отчете вектор атаки. Проверить необходимо всю цепочку действий исследователя, которая привела к реализации недопустимого события. Для верификации отчета рекомендуется помимо собственной службы информационной безопасности и ИТ-подразделений привлечь представителей профильных подразделений, участвующих в бизнес-процессах, в которых может произойти рассматриваемое недопустимое событие, — к примеру, тех, кто привлекался на этапе составления перечня недопустимых событий и определения способов их реализации.
Если организация подтверждает возможность реализации недопустимого события, ее представители должны связаться с исследователем, чтобы обсудить детали, актуальные уязвимости и возможные способы их устранения.