Close

Наш подход к управлению уязвимостями


Наш подход к обработке уязвимостей безопасности в Atlassian

Компания Atlassian признает, что на некотором уровне уязвимости безопасности являются неотъемлемой частью любого процесса разработки программного обеспечения. Однако мы постоянно стремимся снизить как опасность, так и частоту появления уязвимостей[1] в наших собственных продуктах и сервисах.

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

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

Обзор нашего процесса выявления и устранения уязвимостей

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

Identifying vulnerabilities

Мы используем множество лучших в своем классе инструментов выявления уязвимостей, которые регулярно применяем к нашим продуктам и инфраструктуре для автоматического поиска и обнаружения уязвимостей. Проверке подвергаются продукты Atlassian Cloud и Server, образы Docker, служебные, мобильные и сторонние приложения, а также наша инфраструктура, развернутая как локально, так и в облаке. Эти инструменты ищут уязвимости, выполняя автоматическое сканирование следующих видов.

  • Сканирование сети. В настоящее время нашим главным инструментом управления уязвимостями является сервис Nexpose, с помощью которого мы определяем активные сервисы, открытые порты и запущенные приложения в среде, а также выявляем любые уязвимости на уровне сети.
  • Непрерывный поиск и выявление внешних ресурсов. С помощью Assetnote мы ведем непрерывный поиск и выявление ресурсов, а также анализ безопасности по внешнему периметру.
  • Сканирование образов контейнеров. Развертывание многих наших приложений выполнено с помощью контейнеров Docker, и мы проводим комплексное сканирование системы безопасности, которое предполагает тщательный анализ содержимого этих контейнеров при каждом их развертывании в нашей рабочей среде или среде для подготовки к релизу. В этом нам помогает инструмент Anchore. Подробнее о нем написано далее на этой странице.
  • Сканирование сторонних компонентов (зависимостей) с открытым исходным кодом. Мы используем SourceClear для выявления уязвимостей в открытом исходном коде или сторонних компонентах, которые могут использовать наши разработчики. Подробнее об этом читайте ниже.
  • Мониторинг конфигураций AWS. С помощью Cloud Conformity обеспечивается непрерывный мониторинг конфигураций в наших средах на базе AWS для их проверки на соответствие установленным стандартам.

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

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

Наша программа вознаграждения за найденные ошибки (Bug Bounty). Для обеспечения работы программы вознаграждения за найденные ошибки (Bug Bounty) используется сервис Bugcrowd. Bugcrowd предоставляет нам доступ к надежному экспертному сообществу, состоящему из десятков тысяч исследователей в области кибербезопасности, которые постоянно тестируют наши продукты и сообщают о любых обнаруженных ими уязвимостях. Программа Bug Bounty была признана лучшей в отрасли за последние два года (2018–2019 гг.).

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

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

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

«Красная команда» Atlassian. – У нас есть внутренняя «красная команда», роль которой состоит в имитации злоумышленников, пытающихся выявлять и эксплуатировать существующие в наших системах, процессах и средах уязвимости, чтобы мы могли обеспечить их выявление и устранение в максимально короткие сроки.

Отслеживание и устранение уязвимостей

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

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

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

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

Предотвращение возникновения уязвимостей в процессе разработки

Сканирование образов контейнеров

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

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

Для решения этой проблемы компания Atlassian интегрировала процесс полного сканирования безопасности контейнеров в конвейер CI/CD для всех контейнеров, которые развернуты в нашей среде разработки, а также промежуточной или рабочей средах. Для этой цели используется модуль с открытым исходным кодом — Anchore. Anchore предоставляет набор инструментов, которые выполняют глубокую проверку всех образов контейнеров, развернутых разработчиками компании Atlassian. Сюда входит подробный анализ этих образов с целью выявить входящие в их состав различные компоненты (в том числе операционную систему и пакеты приложений, сторонние библиотеки, а также файлы конфигурации).

Зависимости с открытым исходным кодом

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

Затем для всех уязвимостей, выявленных с помощью инструмента Anchore или SourceClear, автоматически создается официальная заявка Jira, которая назначается соответствующей команде по продукту согласно процессу управления уязвимостями, описанному в этой статье ранее.

Прочие мероприятия, которые мы проводим для борьбы с уязвимостями

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

Программа «Чемпионы безопасности»

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

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

Инженеры по безопасности продуктов

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

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

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

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

Система оценки безопасности

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

Резюме

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

Хотите узнать больше?

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

[1] При упоминании «уязвимостей» в этом документе данный термин может использоваться как синоним термина «баги», который мы используем в отдельном документе о нашем подходе к тестированию безопасности.