Ну что, пойдем дальше разбирать выступления на PHDays. Я не буду оценивать каждое видео, каждый доклад, каждую дискуссию, — это не очень интересно и неправильно. Как отдельный IOC оценивать, в отрыве от серии индикаторов, определяющих целую кампанию 🙂 Посмотрим на то, что говорилось на тему багбаунти, то есть поиска слабых мест за вознаграждение. Я про эту тему уже не раз писал, поэтому сегодня нет смысла повторять, что такое классическая программа багбаунти и зачем она нужна. Интересно посмотреть на другое — на то, как на практике реализуют проекты по багбаунти в коммерческих и, что немаловажно, в государственных организациях.
В дискуссии «Багбаунти! Есть ли результат?!» под управлением Димы Кима из Positive Technologies мне очень понравилась позиция Дмитрия Гадаря из Тинькофф-банка, который смотрит на ББ гораздо шире, чем обычно, и задается небанальными вопросами с точки зрения CISO, а не просто багхантера:
Если была найдена уязвимость на багбаунти, то почему процессы безопасной разработки ее не нашли? Почему внутренние сканеры ее не нашли? Что делал исследователь внутри и почему SOC не среагировал на него? Насколько далеко багхантер дошел внутри?
Так как представителям госвласти у нас теперь нельзя пользоваться англицизмами, то по версии Владимира Бенгина из Минцифры, багбаунти — это публичный поиск уязвимостей за вознаграждение! Думаю, стоит ждать появления такого определения в нормативных актах 🙂 А еще Владимир поделился опытом запуска такой программы на портале госуслуг — это заняло 365 дней, так как потребовало кучи согласований и обоснований «зачем все это надо». Интересно, что у Дмитрия Гадаря есть опыт запуска такой программы за 1 (один!) день!
Но все участники дискуссии, а также иных мероприятий по ИБ, которые проходили относительно недавно, соглашаются с тем, что стартовать оценку своей реальной защищенности с багбаунти не стоит — организация может быть просто незрелой в этом вопросе и число дыр у нее может быть просто зашкаливающим. Поэтому сначала стоит наладить процессы поиска уязвимостей, безопасной разработки (если она есть), а уж потом приглашать внешних хакеров для поиск слабых мест. Об этом же в другой секции говорил и Виталий Лютиков, заместитель директора ФСТЭК России, заявивший, что рановато еще включать требование багбаунти в процесс сертификации средств защиты информации. По мне, так это как раз заставит вендоров лучше заниматься своими продуктами и сервисами и поднимет уровень реальной безопасности, предоставляемый их заказчикам. Но, видимо, регулятору лучше знать о качестве продуктов, которые подаются на сертификацию.
Как проверить, что вы готовы к багбаунти? Рецепт от Владимира Бенгина: если вы прошли нормальный пентест и в течение месяца после него смогли устранить все выявленные уязвимости, то значит вы готовы к багбаунти!
Вообще опыт Минцифры в этом вопросе достаточно интересен. И тем, как они вообще на это согласились, и как они решали вопрос вознаграждение, и планы по развитию и переносу этого опыта на другие госорганы и государственные информационные системы. Сразу отмечу, что планов включать эту тему в 676-е Постановление Правительства пока нет. Но шаблоном ТЗ, шаблоном договора, описанием процесса Минцифры уже готово делиться с другими госорганами, которые захотят повысить безопасность своих систем.
Илья Сафронов из VK поделился опытом не только участия на внешних платформах Bug Bounty, но и организации внутренней истории, когда сами сотрудники могут найти баги в системах, зарепортить их на внутренний портал и получить внутреннюю валюту, за которую потом можно получить что-то нужное и полезное. При этом опасения, что разработчики будут специально оставлять критические уязвимости и потом получать за это деньги, разбиваются о практический опыт и VK, и Тинькофф, которые с этим не сталкивались. Ну и, судя по дискуссии, есть свои методы оценки возможных злоупотреблений, которые существуют, но которые коллеги не стали раскрывать публично, дав некоторые подсказки во время дискуссии.
Дмитрий Гадарь поделился и другими лайфхаками, которые были реализованы в Тинькофф:
- Month of bug — ежегодный месяц поиска багов, в течение которого сотрудники ищут баги внутри систем и получают за это призы (ноутбуки, пылесосы и т.п.).
- Внутренний CTF для сотрудников.
- «Дневники хакера» — регулярно рассылаемые разработчикам описания уязвимостей.
- Data Breach Bounty — обнаружение процессов, использующих ПДн больше, чем надо, обнаруженные данные на внутренних порталах, способы обхода DLP, расширенные права в разных внутренних системах и т.п.
- По ходу дискуссии Дмитрий придумал новую историю — «фишбаунти«, когда оплачивается успешный фишинг организации.
Схожие местами проекты реализовывались и в VK, но они еще подключают и рядовых пользователей, которые репортят о тех или иных проблемах, найденных в различных сервисах компании, например, VK ID. А Wildberries, вместе с VK, активно участвовала в Standoff Hacks, закрытом конкурсе легальных хакеров по поиску уязвимостей в своих системах. И все эти истории объединяет одно — оплата за результат, а не как в пентесте — оплата за процесс с непонятным заранее результатом. При этом все участники сходятся в мнении, что это самый дешевый вариант оценки своей защищенности (при соблюдении условия наличия хоть какого-то выстроенного процесса ИБ, который позволит устранять выявленные дыры).
Но поиск уязвимостей или ошибок в процессах обработки ПДн — это не все, где может помочь идея с багбаунти. Например, Минцифры манит более интересная история — запуск инфраструктурного багбаунти, он же пентест на максималках или redteaming по открытой оферте, когда целые команды белых хакеров соревнуются не в поиске уязвимостей на периметре, а в проникновении внутрь него, что более приближенно к реальным опасениям бизнеса, который мало что понимает в уязвимостях и эксплойтах для вебсайта, но при этом прекрасно понимает, что такое проникновение внутрь организации. Пока Минцифры такую историю не реализовало, но хочет идти в этом направлении.
А вот Positive Technologies этот этап прошла, запустив в прошлом году багбаунти на недопустимые события, в рамках которого команды исследователей должны не просто найти уязвимость на периметре, и не успешно реализовать фишинг, попав внутрь инфраструктуры, а сделать то, что бизнес посчитал для себя недопустимым — кражу денег, останов производства, кражу аудиторских отчетов, внедрение вредоноса в код для последующей реализации атак supply chain, прекращение подачи электроэнергии и т.п. Это требует не только более высокой квалификации, но и понимания бизнеса, который ты ломаешь. Но это именно то, что понимает бизнес без каких-либо вопросов, то, за что он готов платить, и то, что проверяет реальный уровень ИБ в компании.
А для исследователей ИБ это способ сразу получить много денег. В отличие от выплат сотен тысяч рублей за найденные баги в рамках классического багбаунти, в программе ББ на недопустимые события сумма вознаграждения измеряется уже десятками миллионов рублей.
Но это далеко не все, что говорилось на PHDays про багбаунти. Мне зашел еще один доклад в треке по блокчейну, который был посвящен поиску уязвимостей за вознаграждение в, что неудивительно, распределенных реестрах и смартконтрактах. Учитывая молодость этой технологии и низкий уровень безопасности в процессе разработки, это очень перспективное направление, как было показано в докладе Александра Мазалецкого. Миллионы долларов выплат, четверть уязвимостей — критические…
Есть чем заинтересоваться багхантерам, которые могут заработать на своих компетенциях абсолютно легально и вполне себе достойные суммы, заодно продемонстрировав бизнесу, что недооценка вопросов ИБ может привести к недопустимым событиям. Например, до сих пор не очень понятно, что произошло c криптовалютной биржей Mt. Gox в 2014-м году, когда после возможной кражи 740000 биткойнов (6% всех существующих в мире) и невозможности отвечать по своим обязательствам перед клиентами она была вынуждена объявить о своем банкротстве.
Наверное на этом я завершу свой обзор отдельных, но офигенных историй про багбаунти, которые прозвучали на PHDays. Но на самом деле в программе было еще несколько выступлений, связанных с этой темой и которые раскрывают другие аспекты связанные с этой темой:
- Как люди пришли в багхантеры и можно ли на этом зарабатывать?
- Как выйти на багбаунти-платформу или запустить свою внутреннюю программу?
- Сколько стоит запуск багбаунти и как сформировать годовой бюджет этой программы?
- Что лучше — внешняя платформа и своя программа?
- Как файл security.txt в корне сайта привлекает багхантеров?
- Как косячат компании, запускающие собственные программы багбаунти, и плющат багхантеров?
- Цифры и статистика российских программ багбаунти
- Правовые вопросы и общение с бизнесом относительно привлечения хакеров к своим системам
- Работа с комьюнити
- Используют ли блэкари легальные платформы багбаунти?
- Лайфхаки
Уффф, вроде все описал. Можно и выдохнуть!
