Основанная в Украине IТ-компания Grammarly создает онлайн-сервис на основе искусственного интеллекта для помощи в написании текстов на английском языке. Ежедневно им пользуются свыше 20 млн человек во всем мире.

Grammarly доступен в нескольких интерфейсах — как вебредактор, браузерные расширения, десктопные приложения, мобильные клавиатуры и надстройки для Microsoft Office. А эта сфера очень требовательна к приватности данных. Поэтому безопасность в компании рассматривается как основополагающая часть работы над продуктом.

Чтобы привлечь дополнительную экспертизу и усилить инициативы, направленные на повышение безопасности, Grammarly запустила программу Bug Bounty на площадке HackerOne — сначала в приватном, а спустя некоторое время — и в публичном режиме. 

В колонке для AIN.UA менеджер Security-команды Grammarly Андрей Деревянко рассказал, почему программа по обнаружению уязвимостей нужна каждой продуктовой компании, как в Grammarly проходила подготовка к запуску приватной и публичной программ Bug Bounty и какие результаты они принесли. 

Что такое Bug Bounty

Bug Bounty — это общее название для программ, в рамках которых компании обращаются за помощью к «белым хакерам» для обнаружения уязвимостей программного обеспечения. Исследователи изучают продукт, составляют отчеты по найденным багам и получают вознаграждение в соответствии с критичностью уязвимости. Хакеры не имеют права публично раскрывать уязвимость до ее устранения. Компании, в свою очередь, должны быстро реагировать на отчеты исследователей и закрывать найденные баги. 

Bug Bounty может работать в приватном и публичном режиме. В первом случае, она открыта для избранного круга хакеров на выбранной площадке. А в случае публичной программы — любой исследователь может отправить свой отчет и претендовать на вознаграждение.

Как запустить приватную программу Bug Bounty

Для начала, компании необходимо выбрать удобную площадку для работы и определить, что именно она будет отдавать на тестирование. Затем — выбрать тарифный план, заключить договор и оплатить подписку. 

В качестве площадки мы выбрали HackerOne — крупнейшую платформу для сотрудничества с «белыми хакерами». На этой площадке зарегистрировано более 300 000 хакеров, что позволяет в любой момент масштабировать программу поиска уязвимостей. HackerOne используют крупнейшие IT-компании мира, как, к примеру, AirBnB, Uber и Dropbox. 

Кроме перечисленных выше шагов, потребуется дополнительная работа. Вот о чем нужно побеспокоиться:

  1. Прописать правила.
    Одно из требований HackerOne — составление подробного свода правил для сотрудничества компании и хакеров. В нем нужно перечислить, что именно вы хотите тестировать, назвать требования к подаче отчетов и размеры вознаграждений. На этапе запуска менеджеры HackerOne консультируют, как лучше составить правила. Помимо этого, можно взять за основу программы других компаний.

    К примеру, чтобы популяризировать Bug Bounty движение и поднять индустриальные стандарты работы над безопасностью, компания Dropbox разрешает свободное использование и изменение своих правил другим компаниям. К подготовке правил нужно подойти очень тщательно (мы дополнительно консультировались с юристами) и не спешить – чем лучше вы их опишете, тем меньше времени после запуска программы потратите на нерелевантные или неточные отчеты.
  2. Отобрать участников.
    По условиям приватной программы компания-заказчик выбирает, какие специализации и уровень хакеров ее интересуют, а HackerOne осуществляет подбор и высылает личные приглашения. Первыми их получают исследователи с высокой репутацией. Отчеты от них будут наиболее точными.

    Работая с приватной программой, вы можете легко контролировать количество участников и, соответственно, отчетов которые вам приходят. Поначалу многие из них будут дублировать уже известные вам уязвимости. По рекомендациям платформы HackerOne, вы не должны выплачивать за них вознаграждение, но мы иногда поощряли очень старательных хакеров за особо качественные отчеты.
  3. Подготовиться к первоначальному наплыву отчетов.
    Первый месяц после запуска приватной программы — самый сложный. Отчеты начинают приходить уже спустя полчаса после открытия программы. Чтобы не утонуть в этом потоке, мы последовали рекомендации HackerOne и организовали ротацию инженеров для первичной обработки.

    Это позволило оперативно просматривать все отчеты, распределять их по командам разработчиков и, главное — оперативно отвечать хакерам. В целом, не менее 60% инженерной команды Grammarly приняло участие в сопровождении приватной программы и процессе подготовки к выходу на публичный уровень. 

Как работать с «белыми хакерами» — главные правила

Успешность вашей программы Bug Bounty во многом зависит от того, как организована работа с исследователями. Вот несколько правил, которых мы придерживаемся:

  • Поддерживать коммуникацию. Нельзя пропускать сообщения от хакеров — важно всегда отвечать и детально расспрашивать о проделанной работе. Отчеты проходят предварительную проверку со стороны команды HackerOne, но лучше просматривать даже отклоненные варианты — иногда и там есть интересные кейсы.
  • Оперативно реагировать. Скорость ответа тоже очень важный показатель, на который обращают внимание хакеры. Нужно помнить, что не всем исследователям важны лишь деньги. Многие работают на свою репутацию или даже из интереса к продукту. И скорость вашей реакции и качество коммуникации также могут быть для них мотивирующими факторами.
  • Стимулировать участие в программе, выходя за рамки стандартных вознаграждений. Авторов качественных отчетов, пусть и не содержащих критических уязвимостей, лучше мотивировать бонусом ради дальнейшего участия. Важно помнить, что HackerOne и подобные ему площадки — это конкурентная среда, и если хакер не получает внимания и поддержки, он уйдет заниматься другими проектами.
  • Поощрять сложную аналитическую работу. Очень ценно, когда хакеры не просто сообщают про отдельные баги, а выстраивают сложные сценарии атак, состоящие из нескольких, на первый взгляд, малозначимых уязвимостей. Такую работу также можно поощрять дополнительными бонусами — как и таргетированный анализ (в нашем случае — целенаправленное исследование браузерных приложений).
Вознаграждения согласно программе Bug Bounty в Grammarly

Как самый эффективный хакер программы Bug Bounty стал инженером Grammarly

То, как важно правильно коммуницировать с «белыми хакерами», доказала история сотрудничества Grammarly и хакера под ником metnew. 

Мы обратили на него внимание благодаря качеству и уровню детализации отчетов — исследователь последовательно и подробно описывал уязвимости браузерных расширений. В общей сложности, мы обработали 15 его отчетов (из них два указывали на «критические» баги) — это индивидуальный рекорд нашей программы.

В ходе обсуждения его отчетов, выяснилось, что metnew (Владимир Метнев) по невероятному совпадению живет в Киеве. Мы пригласили его в офис, познакомили с командой и предложили несколько месяцев поработать консультантом в компании.

Через время Владимир присоединился к команде Grammarly как Application Security инженер. Сейчас он отвечает за поддержку публичной программы Bug Bounty, непосредственно работает с исследователями, а также драйвит внутреннюю инициативу security-чемпионов (в каждой инженерной команде выбирается один человек на роль «security-чемпиона», который активнее всего взаимодействует с командой безопасности, и затем делится информацией со своими коллегами). 

Как выйти на публичную программу Bug Bounty

Когда приватная программа Grammarly заработала в полную силу, в ней было около 700 участников. Несмотря на ротацию, постепенно сообщество стало менее активным, вследствии чего количество и качество отчетов сильно упало. В периоды затишья могло приходить по 2-3 отчета в неделю, в обычное время — около 10 отчетов.

Но нужно помнить, что чаще всего лишь 1 из 5 входящих отчетов после проверки переводится в работу. И это с учетом того, что мы закрываем даже потенциальные уязвимости, а не реальные кейсы атак. Другие отчеты отсеиваются как дубликаты или оказываются ложноположительными.

Чтобы повысить активность в приватной программе, мы увеличили количество участников до 2000. Это не требует дополнительных инвестиций, поскольку владелец программы может масштабировать ее на свое усмотрение. После этого количество отчетов, в первое время, возросло примерно до 40 в неделю. Из них 4-5 уходили в работу. Но постепенно и этот поток обращений иссяк. 

Конечно, мы могли и дальше приглашать новых хакеров в приватном режиме — многие компании идут именно таким путем. Но мы приняли решение о переходе на публичную программу. Для нас он стал важным шагом не только для того, чтобы масштабироваться, но и сделать безопасность нашего продукта более прозрачной для пользователей и укрепить их доверие. 

Что важно учесть при подготовке к переходу на публичную программу:

  1. Назначить DRI — ответственного за проект. К выходу на публичную программу стоит подойти с позиции проектного менеджмента. Такой шаг — это отдельный проект внутри компании со своими сроками и стоимостью, сопровождать который должен ответственный менеджер. Нельзя пускать процесс на самотек: менеджер и команда должны работать в эффективной связке.
  2. Закрыть типичные уязвимости. Для Grammarly достаточно значимым фактором готовности к публичной программе  выступило усиление защиты от CSRF-уязвимостей или, другими словами, — подделки межсайтовых запросов. Это распространенный тип атак на веб-приложения, который заключается в перехвате управления пользовательской сессией.
    Без закрытия таких уязвимостей выходить на публичную программу было бы попросту бессмысленно. Хакеры бы завалили нас однотипными отчетами, а в ответ на отклонение отчета как дубликата — разочаровались в программе. 
  3. Доработать условия. Чаще всего хакеры ориентируются на веб- и мобильные приложения. Другие же технологии требуют специфической экспертизы, и потому для них сложнее найти исследователей. Мы, например, получали мало отчетов по браузерным расширениям — это нишевая технология. Поэтому спустя некоторое время мы определили focus scope — список продуктов, по которым выплачивается удвоенное вознаграждение.
  4. Проработать механизм автоматических обновлений. Для клиентских приложений (например, мобильных) уязвимость можно исправить только выпустив обновление. Продуктовым компаниям, выходящим на публичную программу Bug Bounty, нужно обязательно проработать механизм автоматических обновлений. Это важно, поскольку исправление уязвимости может ограничить функциональность прошлых версий продукта. Кроме того, не все пользователи охотно обновляются — некоторых нужно мотивировать почтовыми рассылками или уведомлениями внутри приложения.

Публичная программа Bug Bounty запущена — что дальше

Наш переход на публичную программу состоялся в декабре 2018 года. Это увеличило потенциальное количество участников в 150 раз — с 2000 до 300 000 хакеров, зарегистрированных на площадке. После запуска публичной программы мы подготовились к большому потоку из новых отчетов: выделили ресурсы инженерной команды и время на обработку запросов. Но такого наплыва не случилось из-за длительной и качественной работы на приватном уровне.

После успешного запуска программы важно не сбавлять обороты и поддерживать уровень эффективности:

  • Активно общаться с исследователями и постоянно дорабатывать правила. Важно регулярно обновлять и при необходимости расширять описание программы, чтобы она оставалась актуальной, и участники знали, какие отчеты для нас более релевантны в данный момент.
  • Мотивировать исследование новых продуктовых фич за счет временного увеличения выплат. При выпуске новых функций или интерфейсов продукта можно и нужно дополнительно стимулировать их более активное тестирование — в первую очередь за счет приоритизации таких исследований и временного увеличения вознаграждений.

    Один из наших последних подобных кейсов — кампания по исследованию функции мультифакторной аутентификации (MFA). Чтобы повысить ее приоритет для хакеров, мы на один месяц удвоили вознаграждение за отчеты по ней. Для того, чтобы присоединиться к кампании, хакеры заполняли форму, а мы добавляли MFA-функцию как эксперимент в их тестовые аккаунты. В итоге, мы получили более 100 отчетов, из которых 11 были валидными.

    Суммарно, за найденные уязвимости мы выплатили исследователям около $14 000, а особо активным — дополнительно отправили наборы с брендированной сувенирной продукцией от Grammarly. Авторам отчетов, которые оказались дубликатами, мы также в качестве поощрения предоставили Premium-подписку на сервис Grammarly. Так эта кампания помогла нам закрыть возможные уязвимости еще до публичного релиза функции.  

И немного статистики за почти 1,5 года существования публичной баунти-программы Grammarly на HackerOne:

Для продуктовой компании — это несоизмеримое соотношение выгоды и полученного результата. За сравнительно небольшие деньги мы привлекли квалифицированных внешних экспертов и получили более 130 ценных отчетов от исследователей, которые помогли сделать продукт еще более безопасным для пользователей. 

Уверены, что усилия, потраченные на запуск и ведение Bug Bounty, — это отличная инвестиция с высоким уровнем возврата.

Автор: Андрей Деревянко, менеджер Security-команды в Grammarly