Close
Хотите открыть эту страницу на своем языке?
Все языки
Выберите язык

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

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

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

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

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

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

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

Непрерывное обнаружение и присвоение ресурсов

Непрерывное внутреннее обнаружение ресурсов. Мы используем собственную систему для инвентаризации всех наших ресурсов AWS EC2 и Load Balancer, использующих AWSConfig, и присваиваем их соответствующим владельцам. Мы храним данные о ресурсах за год в количестве 50–60 миллионов единиц.

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

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

  • Сканирование хостов. В настоящее время мы используем Assetnote для непрерывного сканирования безопасности внешнего периметра и Tenable.io для непрерывного сканирования снаружи и внутри. Эти инструменты позволяют определять открытые порты, службы и запущенные в среде приложения, а также выявлять любые уязвимости на хостах сети.
  • Сканирование образов контейнеров. Развертывание многих наших приложений выполнено с помощью контейнеров Docker. Мы проводим сканирование безопасности образов контейнеров при их развертывании в нашей рабочей среде или среде для подготовки к релизу. В этом нам помогает инструмент Snyk. Подробнее о нем написано далее на этой странице.
  • Сканирование сторонних компонентов (зависимостей) с открытым исходным кодом. Для выявления уязвимостей в открытом исходном коде или сторонних компонентах используется Snyk. Подробнее об этом читайте ниже.
  • Мониторинг конфигураций AWS. Мы развертываем и интегрируем Lacework в среду Atlassian, размещенную в облаке AWS, чтобы осуществлять непрерывный мониторинг конфигураций в наших средах на базе AWS для их проверки на соответствие основам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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