Александр КравченкоКакие сложности могут помешать верифицировать отчет
В процессе верификации отчетов по программе bug bounty специалист по информационной безопасности может столкнуться со множеством проблем и спорных моментов. Каждая неоднозначная ситуация может повлиять на результат, выплату исследователю и репутацию компании.
Основные затруднения могут быть следующими:
- недостаток информации в отчете;
- выход за границы программы;
- дублирование отчетов;
- невоспроизводимость результатов;
- спорные уязвимости;
- уровень опасности уязвимости;
- сроки выполнения.
Рассмотрим каждое затруднение подробнее.
Недостаток информации
Команде организатора программы следует установить правила оформления отчетов. Можно, например, создать специальную веб-форму для подачи отчета с фиксированными правилами заполнения или приложить пример отчета, доступный для скачивания. Это сократит количество отчетов с недостающей информацией и поможет новым исследователям. Отчет в формате - «Ребята, у вас сервер по адресу XYZ позволяет загружать произвольные файлы. Проверьте сами», однозначно является негативным примером.
Может возникнуть ситуация, когда команде организатора, кроме нехватки информации в отчете, недостает компетенций в определенной области. В этом случае команда организатора может поручить обработку отчета команде площадки bug bounty (если программа размещается на такой площадке) или обратиться к сообществу исследователей кибербезопасности, которые могут предоставить дополнительные пояснения к отчету с найденными уязвимостями.
Выход за границы программы
Если в отчете, предоставленном исследователем, описаны действия, которые выходят за установленные программой bug bounty границы испытаний, то в выплате вознаграждения за описанные в таком отчете проблемы может быть отказано. Безусловно, задача команды организатора — максимально точно и подробно описать границы испытаний, которые исследователи должны строго соблюдать.
Возможны случаи, когда исследователь уверен, что найденная уязвимость потенциально может затронуть или тиражироваться в системах, находящихся за границей испытаний. Команде организатора стоит явно указать, что в таких случаях исследователям нужно отдельно связаться с организатором и предоставить соответствующие факты.
Дублирование отчетов
Иногда два исследователя могут предоставить информацию об одной и той же уязвимости. Выплату, как правило, получает тот, кто прислал отчет первым. Однако отчет второго исследователя может содержать дополнительную информацию, раскрывающую способы и возможности использования уязвимости. Общего правила, как действовать в таких случаях, нет, однако часто компания-организатор не оставляет такие отчеты без выплат, считая информацию в них полезной.
Невоспроизводимость результатов
Команде организатора следует уделить особое внимание воспроизведению результатов, полученных в отчете исследователя кибербезопасности. Если получить результаты не удалось, прежде чем отказывать исследователю в вознаграждении, следует учесть широкий спектр условий: версию программного обеспечения, используемого для получения результатов, минимальную и максимальную нагрузку на систему, время суток и даже часовой пояс.
Спорные уязвимости
Такие затруднения могут проявляться в разных формах.
1. Информация в отчете исследователя может указывать на уязвимость в программном обеспечении или на критическую ошибку, однако это может быть вариантом штатной работы системы. Например, когда уязвимость является следствием архитектурных решений, на которых построена система, или ее небезопасной конфигурации.
Такие уязвимости могут не устраняться сиюминутно в силу дороговизны необходимых действий или других причин. Оптимальным решением для таких ситуаций может быть составление долгосрочного или поэтапного плана устранения таких уязвимостей, в котором стоит определить сроки и ответственных за их устранение.
2. Заявленная уязвимость основана на информации, находящейся в открытом доступе, а команда организатора не признает ее как уязвимость. Например, уязвимость связана с определенной CMS. Компания осознает опасность, связанную с эксплуатацией этой системы, и не засчитывает связанные с ней уязвимости.
Для подобных ситуаций организатору программы bug bounty следует выработать единую позицию и честно и прозрачно донести ее до исследователей кибербезопасности.
3. Заявленная исследователем уязвимость относится к системе, которая была свернута или продана другой стороне.
Если компания-организатор остановила или продала систему, в отношении которой проводится исследование кибербезопасности, но не обновила информацию об этом в программе bug bounty, ситуацию следует трактовать в пользу исследователя, так как выявленные уязвимости по-прежнему могут присутствовать в системе, а старт исследованию был дан именно компанией-организатором.
Уровень опасности уязвимости
Методы и способы выставления уровня опасности для заявленной уязвимости у исследователя и команды организатора могут существенно различаться, что особенно заметно, когда дело касается уязвимостей, приводящих к утечке персональных данных и другой конфиденциальной информации. Более того, компания-организатор может установить нечеткие рамки в части оценки уязвимостей, в результате чего исследователь кибербезопасности не может правильно сформировать свои ожидания по возможному вознаграждению.
В связи с этим команде организатора следует учитывать требования законодательства, требования руководства компании, предъявляемые к обрабатываемой в системе информации, тиражируемость уязвимости, сложность ее эксплуатации, рекомендации CVSS и другие параметры, которые компания считает для себя важными.
Сроки выполнения
В рамках программы bug bounty соблюдение сроков требуется не только от исследователей кибербезопасности, но и от команды организатора, которая должна предоставить обратную связь. Поэтому на каждый принятый отчет стоит завести тикет внутри компании, который позволит всем заинтересованным лицам централизовано работать с отчетом.