Баг-баунти в нашей IT компании мы используем как способ поощрения сотрудников. В этой статье расскажу, как способы оптимизации процессов помогут вам разбогатеть. Что такое баг-баунти, зачем нужна эта программа, сколько денег она сэкономит вашей компании и как с ее помощью заработать на ламборджини в 25 лет, работая в IT компании тестировщиком.

Что же такое баг-баунти?

Сегодня многие IТ-компании пользуются баг-баунти. Это программа, с помощью которой люди могут получить признание и вознаграждение за нахождение уязвимостей. У программы есть три типа:

  1. Внутренняя - та, где найти и устранить уязвимости могут сотрудники компании;

  2. Закрытая - в ней участвуют определенные люди с площадок баг-баунти;

  3. Открытая - здесь принять участие могут все пользователи, естественно, за вознаграждение.

Программу баг-баунти мы взяли из мировой практики и адаптировали под свою компанию. В нее входят баги (далее уязвимости), которые связаны с безопасностью приложений. 

Любые уязвимости приводят к большим потерям: финансовым, репутационным и другим. Баг-баунти для нашей компании довольно актуальная тема. Так каждая уязвимость обходится дешевле, ведь ее находим мы, а не пользователи. Стараемся устранить проблему до ее появления и до релиза проекта.

Искать уязвимости внутри компании эффективно еще и потому, что разработчики хорошо знают свой продукт. Ребята из команды проекта ищут в нем слабые места и то, как ими можно воспользоваться, за что мы их и поощряем.

Подробнее про уязвимости

Все уязвимости мы делим на следующие группы: критические, блокирующие, минорные и незначительные.

  1. Критические уязвимости включают в себя: вывод средств больше положенного, утечку логинов/паролей, доступ к внутренним ресурсам, удаленное исполнение кода, нарушение бизнес-логики проекта;

  2. Блокирующие: получение доступа к чужому аккаунту, нарушение механизма авторизации/регистрации;

  3. Минорные: уязвимости нарушающие работу внутренних механизмов, нарушение стабильности и/или доступности кошельков, раскрытие деталей устройства внутренней сети;

  4. Незначительные: потенциальное нарушение безопасности, не влияющие на проект в данный момент времени, угроза репутации.

Как награждаем за найденные уязвимости?

Баг-баунти – заимствованный подход к безопасности продукта. Однако есть в нем и авторская нотка – это система распределения денежных премий, которая придумана внутри нашей компании.

У нас никто никогда не остается без премии: есть дополнительный фонд оплаты, из которого поощряются сотрудники в рамках баг-баунти. Когда ребята из проектов находят уязвимость – им достается сумма, соответствующая критичности найденных уязвимостей. Если за квартал уязвимостей не обнаружено, премию между собой делят специалисты по безопасности. Награда может быть равна половине среднего оклада разработчика, третьей, четвертой или пятой его части. Размер вознаграждения напрямую зависит от критичности найденной уязвимости. Нашел в каждом проекте хотя бы по одной блокирующей уязвимости, заработал еще одну зарплату.

Как определяется сложность уязвимости? 

Чем опаснее уязвимость для пользователей, тем критичнее. Ну а если положить наш сервис можно одним действием – значит проблема максимально критичная. 

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

Также оцениваем по следующим критериям: нужно ли находиться внутри нашей офисной сети, чтобы воспользоваться багом и нужно ли взаимодействовать с другими пользователями для совершения атаки. Например, необходимо ли скинуть ссылку или можно совершить преступное действие из своего аккаунта так, чтобы другой участник системы об этом не узнал? При этом, если у хакера не так много прав, но он смог принести какие-либо потери, тем серьезнее уровень угрозы.

Как сотрудники ищут уязвимости? 

Чтобы найти уязвимость, надо думать как уязвимость. Вот и наши сотрудники выступают в роли злоумышленника. При поиске уязвимостей они пользуются сайтом и мобильным приложением через собственные личные аккаунты. Существует несколько вариантов развития событий: например можно посмотреть код и сделать вывод о возможной уязвимости или не смотреть код, а действовать исключительно как пользователи. Их задача – отыскать пути, как можно обмануть систему. 

Как предоставить отчет о найденной уязвимости? 

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

 Чтобы убедиться в наличии проблемы, специалист обязательно попробует повторить действие со своего компьютера. Если попытка удалась – уязвимость засчитывается, а нашедшего сотрудника ждет вознаграждение.  

Хотите историй из жизни нашей компании? Ловите

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

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

У нас есть две версии системы: Веб и Мобильная. Если пользователь заблокирован в системе, то на вебе это было видно сразу, а вот в мобильной версии пользователь мог осуществлять свою деятельность дальше.

Еще один случай с кодом. В мобильной версии системы была уязвимая API. Мы исправили не ту же API, а создали новую - безопасную. Старую отовсюду выпилили, но работать она продолжала. В результате на нее можно было слать запросы и пользоваться уязвимостью.

После таких случаев мы ввели в компании баг-баунти и предугадали множество уязвимостей. Процесс продолжается, и эти, на первый взгляд, неприятные случаи, стали настоящим стимулом внести изменения, которые сегодня позволяют нам тщательнее следить за безопасностью проектов. Один из программистов, во время рефакторинга нашел API, которая была способна остановить деятельность любого пользователя системы. Нужно было лишь авторизоваться и передать в API нужный ID пользователя. Это legacy функционал, которым никто не пользовался в новых версиях системы. При желании можно было остановить деятельность всех пользователей системы простым перебором ID.

Подход положительно влияет на качество продукта в целом. Однако риск для безопасности любой, даже самой надежной системы, остается всегда.

Какие плюсы имеем от использования баг-баунти и что в планах?

За год работы этой программы в компании, имеем только плюсы. Смотрите сами:
На саму программу мы потратили около 2 млн рублей, а сохранили в десятки, а то и сотни раз больше. Нашли и устранили уязвимостей: 18, из которых 13 были блокирующими. В среднем раз в месяц мы находили уязвимость, которая несла огромную угрозу. Поощрили 20 сотрудников, которые нашли и устранили уязвимости.

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

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

Комментарии (5)


  1. mixsture
    30.11.2021 15:34
    +2

    Большая проблема баг-баунти в том, что это рынок одного покупателя. Который как хочет, так и оценивает вознаграждение.
    Как только туда подтягиваются другие покупатели, то позиция компании меняется сразу на «уволю, засужу» вместо поощрения — хотя эти покупатели, очевидно, сдвинут цену в сторону реально-обоснованной рынком.
    Это выливается в довольно странные рабочие отношения: либо тебе копеечка вместо нормальной суммы, либо ничего, либо тюрьма. Как будто тут есть какой-то выбор.
    Простая правда в том, что компания не собирается платить реальную стоимость, иначе ее бы не страшило участие других покупателей — она бы легким движением руки выставила цену выше остальных.

    Отсутствие конкуренции со стороны покупателей, естественно, порождает занижение стоимости бага. Это может выражаться как в сумме, так и просто в нежелании прилагать дальнейший труд к раскрытию бага.
    Пример из вашей же статьи:

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


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


    1. aleks_raiden
      30.11.2021 15:46

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


  1. desertkun
    30.11.2021 19:24
    +1

    Чтобы убедиться в наличии проблемы, специалист обязательно попробует повторить действие со своего компьютера. Если попытка удалась – уязвимость засчитывается, а нашедшего сотрудника ждет вознаграждение.  

    Я вижу конфликт интересов. Специалист по безопасности, по сути, выплачивает со своего кармана, т. к., в противном случае, фонд вознаграждений делится между такими специалистами. Как только цена доходит до хотябы четырех цифр в долл эквиваленте, сразу возникают палки в колеса, ой не могу повторить, а это мы уже закрывали и тд.


    1. nvtorushin
      01.12.2021 09:19
      +1

      Для этого должен быть процесс, который просто это фиксит на этапе зарождения мысли конфликтов)
      Исходя из расчетов 2kk₽ на 18 уязвимость, а это значит в среднем = 111111₽ = 1500$ и делаем логичный вывод, что процесс построен и проблем нет.
      Для кейсов, где есть конфликты всегда можно привлечь третью сторону - "Арбитр", который решит ваш конфликт конструктивно)


    1. Smart_Team Автор
      01.12.2021 18:45

      У нас в компании это действительно выстроено как процесс и конфликт интересов разрешается очень легко (при необходимости подключаюсь лично и разбираюсь в ситуации). Для того, чтобы не было спорных моментов как только мы поправили уязвимость - мы публикуем внутри проекта это и показываем, что именно было исправлено.

      Важно, что мы не отбираем ни у кого деньги, а наоборот вознаграждаем) Т.е. фонд выделен отдельный от всех остальных премий в компании.