В 2023 г. в “Группе Астра" была запущена корпоративная программа BugBounty. Это первый опыт среди российских разработчиков операционных систем. Ольга Гурулева, директор департамента информационной безопасности “Группы Астра”, ответила на вопросы о ходе программы и ее результатах.
– Как вы оцениваете программу BugBounty для поиска уязвимостей в дистрибутиве операционной системы?
– Хотелось бы начать с того, что мы как разработчик средств защиты информации обязаны выполнять нормативные требования регулятора – ФСТЭК России в части работы с уязвимостями. К моменту публикации программы BugBounty в нашей компании уже был выстроен соответствующий процесс, а дополнительно на договорной основе привлекались сторонние организации, которые проводили аудит кода операционной системы, так называемый заказной пентест. Это достаточно затратная инициатива, которая обходилась в серьезную сумму за каждый контракт. При этом результаты мы получали не самые впечатляющие, а выявленные недостатки не относились к интересующей нас области – средствам защиты информации в составе ОС.
Выход на BugBounty позволил привлечь большой пул независимых исследователей различного уровня компетенций, которые осуществляют поиск уязвимостей в соответствии с нашими запросами, оформленными в виде оферты. Программа была запущена в августе 2023 г., и за это время мы получили уже 27 отчетов, 12 из которых признали полностью валидными, то есть отвечающими нашим требованиям. Проще говоря, мы получили в разы лучший результат, обнаружив для себя критически важные вещи. Так что это очень результативная программа.
Более того, я считаю, что BugBounty – наиболее эффективный метод сторонней ИБ-экспертизы.
– Какие типы уязвимостей чаще всего обнаруживаются с помощью BugBounty в вашем дистрибутиве операционной системы?
– Astra Linux Special Edition является деривативом (дистрибутивом на основе) операционной системы с открытым исходным кодом Debian и содержит в своем составе заимствованные компоненты с открытым исходным кодом, в связи с чем объявлять программу поиска уязвимостей (CVE) было бы непродуктивно.
Для выхода на BugBounty мы выбрали сценарий с реализацией недопустимых событий, за достижение которых готовы платить. Перечень таких событий мы сформировали заранее и корректируем его по мере поступления отчетов. Считаем данный подход наиболее эффективным, так как исследователь в своей работе может достигать того или иного события разными способами. И так мы устраняем не только выявленные ошибки, но и проделываем определенную работу по самому сценарию реализации. Таким образом, закрытие одного отчета позволяет устранить несколько потенциальных уязвимостей в системе.
– Каков процесс управления и анализа полученных отчетов о найденных уязвимостях?
– Как я уже говорила, до BugBounty в компании был выстроен процесс управления уязвимостями. Перед выходом в публичную плоскость мы по совету представителей площадки, компании BI.ZONE, опубликовали приватную программу, к участию в которой пригласили ограниченное количество исследователей. И хотя это не принесло какого-либо значимого результата, мы успели подготовиться и интегрировать процессы отработки отчетов, поступающих в рамках BugBounty, в корпоративные регламенты управления уязвимостями.
Работает все это следующим образом: площадка проводит первичную проверку отчета (триаж) и в случае признания его валидным передает информацию нашей команде, в которую входят в том числе сотрудники департамента анализа безопасности. Они анализируют отчет, осуществляют необходимые действия в соответствии с процессом и организовывают полное сопровождение выявленной уязвимости, с момента поступления информации и до выпуска необходимого обновления. Таким образом, мы не тратим лишние ресурсы, не создаем параллельный процесс. Ничего радикально нового не произошло, просто ко всем используемым ранее источникам информации об уязвимостях добавился еще один.
– Какие меры предпринимаются для быстрого реагирования и устранения обнаруженных уязвимостей? Какие есть особенности, если уязвимость критическая и исправить ее нужно во внеочередном порядке?
– Мы обязаны соблюдать конкретные сроки устранения уязвимостей, которые устанавливает регулятор. Могу заверить, что эти сроки нами выдерживаются.
– Какова роль внутренних команд безопасности в совместной работе с исследователями из BugBounty-программы?
– Прежде всего они проводят валидацию отчетов, проверяют релевантность обнаруженной уязвимости. Второе направление – диалог с исследователем, который провел определенную работу и ожидает за нее вознаграждение. Иногда на этом пути возникают сложности, когда выясняется, что уязвимость невалидная или является дублем, в связи с чем мы не можем принять отчет к рассмотрению. Соответственно, нужно отработать возражения "белого" хакера. Если мы не принимаем от него уязвимость, необходимо грамотно и корректно объяснить причины отказа. И при этом важно, чтобы исследователь не ушел от нас с негативной реакцией.
– Как происходит взаимодействие с исследователями в процессе решения обнаруженных проблем и устранения уязвимостей?
– Взаимодействие происходит непосредственно на площадке BI.ZONE через соответствующий портал. После первичной обработки отчета и передачи его к нам в работу мы проверяем всю присланную информацию и уточняем какие-либо детали, если это необходимо. На протяжении всего этапа работы с отчетом оставляем комментарии и ведем диалог с исследователем.
– Какие меры принимаются для обеспечения честности и справедливости в процессе награды и признания участников BugBounty-программы?
– После того как отчет отработают эксперты нашего департамента анализа безопасности, в процесс включается комиссия по назначению выплат, где коллегиально рассматривается отчет исследователя и отзыв наших экспертов на него. На основании этих сведений принимается решение о размере вознаграждения. Любой субъективный фактор здесь полностью исключен. При возникновении конфликтной ситуации в первую очередь мы стараемся разрешить ее собственными силами. В сложных случаях привлекается арбитры, которыми являются представители площадки BugBounty – сотрудники BI.ZONE. Они максимально объективны, поскольку заинтересованы в популяризации и хорошей репутации как своей площадки, так и всего движения BugBounty в целом.
– Каковы планы по дальнейшему развитию и улучшению BugBounty-программы в контексте обеспечения безопасности дистрибутива операционной системы?
– Особенность нашей программы BugBounty в том, что она охватывает конкретный перечень недопустимых событий. Мы планируем расширять этот перечень. Сейчас для анализа предоставлены два защитных механизма ОС – мандатное управление доступом и замкнутая программная среда, и этот список будет пополняться. Нам не нужно проверять весь код ОС, мы заинтересованы в корректности работы ее защитных механизмов.
Операционная система не единственный наш продукт, у нас есть и другое ПО, которое хочется охватить в рамках BugBounty. Например, один из следующих таких продуктов – платформа управления виртуализацией VMmanager компании ISPsystem. Коллеги уже имеют свою программу BugBounty, размещенную на собственном сайте, и мы хотели бы вывести ее на площадку BI.ZONE, чтобы поднять на новый уровень и привлечь еще больше исследователей.
– Как взаимосвязаны процессы РБПО (разработка безопасного программного обеспечения) и BugBounty? Будет ли эффективна BugBounty без внедренных процессов РБПО?
– Если предположить, что в компании процессов РБПО не существует и мы выпускаем продукт сразу на BugBounty, есть риск того, что багхантеры найдут достаточно большое количество уязвимостей, исправление которых волной захлестнет команду разработки, а совокупный размер выплат исследователям отразится на бюджете продукта. Все это, несомненно, повлияет на доработку имеющегося функционала, сдвинет Roadmap выпуска новых версий продукта, и в целом все это будет больше похоже на "выстрел в ногу".
Станет ли в таком случае эффективной программа BugBounty? На мой взгляд, нет. Ведь РБПО – это не только выстраивание процессов, но и внедрение программных средств, например статических/динамических анализаторов кода, что позволяет выявлять часть уязвимостей еще на ранних стадиях разработки. А как показывает практика, исправление уязвимости после релиза обходится значительно дороже.