Речь пойдёт о трудностях работы инженеров по безопасности в крупной компании – как команда выстроила AppSec и как выбранный подход помог сделать безопаснее “бирюзовую” команду и огромный Enterprise в целом. Это история о самоорганизации, зрелости и уменьшении количества явных контролей в угоду «безопасных» процессов.
Статья написана на основе доклада директора департамента мониторинга и реагирования на инциденты ИБ VK Дмитрия Куколева для DevOps Conf 2023. У него 12-летний опыт построения процессов безопасного производства. Сейчас он директор департамента мониторинга и реагирования на инциденты ИБ VK.
Цели команды инженеров безопасности в огромном Enterprise
Перед командой помимо непосредственно задач ИБ были поставлены классические бизнес-цели — нужно было придумать, как сделать так, чтобы при безопасной разработке продуктов сохранились:
низкий Time to Market
легкое масштабирование
возможность наращивания дополнительных ценностей
И что было особенно важно, так это достичь такого уровня безопасности и защищенности продуктов, чтобы он не только учитывал бизнес-задачи, но и качественно рос.
В результате пришли к 5 основным принципам построение сервисов ИБ:
Максимальная автоматизация и безопасность «по дизайну»;
Готовность к инновациям и постоянно меняющимся требованиям — необходимо понимать конечные цели и пути их достижения;
Прозрачность и цифровое потребление — всё, что делается должно быть понятно и доступно другим командам. Они должны видеть все активности и понимать, зачем они нужны. Должны понимать, что происходит с их продуктом со стороны информационной безопасности.
Ускорение ИБ и работа на опережение – быть быстрее ИТ. Если ИБ будет работать на той же скорости, отставание будет неизбежно.
Отсутствие задержек и трений при взаимодействии ИТ с ИБ. Классическая история, когда ИТ создаёт продукты, а ИБ обнаруживает там проблемы и требует их исправления, что в итоге приводит к конфликтам: разработчики не хотят этим заниматься. Этих проблем можно и нужно избегать ещё на стадии дизайна.
Эти принципы переросли в два больших блока, в рамках которых и работала команда – автоматизация и концепт Security Highway.
Автоматизация
Фокус на автоматизацию означал уменьшение ручных контролей и явных Security Gates. Ручной контроль — это заявки, письма, долгие согласования. Всё, что заставляет ждать. Чтобы решить проблему, нужно было перейти на функционал Self-Service — единого окна, куда может зайти любая команда, чтобы увидеть текущие данные метрик и внести необходимые контроли для информационной безопасности.
Добавив принципы «безопасность в процессе», можно получить непрерывные сканирования вне зависимости от того, что в реальности попадает в релиз. Таким образом, контроли сдвигают не на shift+left, как раньше, а на shift+everywhere, чтобы получать полноценную картину того, что происходит в процессе.
Security Highway
Со временем была сформирована концепция реализации сервисов ИБ с фокусом на автоматизацию, удобство и прозрачность, где большое количество контролей “скрыто под капот”. В процессе SSDLC необходимо реализовать контроли безопасности на всех этапах производства – архитектура, создание кода, тестирование, сборка, доставка и развертывание. Также каждый из этапов сам по себе можно разделить на большое количество подэтапов и процессы, чтобы сформировать большой набор артефактов.
Один из наиболее эффективных методов управления безопасностью продукта – это управление через единую платформу ИБ, когда все данные агрегируются и коррелируются в одном месте. В итоге команды ИБ и ИТ работают не с разрозненным набором объектов, а со скоррелированными данными и реальными уязвимостями, которые можно отследить. Благодаря такой интеграции ИБ в процессы ИТ, команды могут максимально быстро создавать безопасные продукты. Именно поэтому эту концепцию мы между собой и назвали Security Highway.
Преимущества концепции Security Highway
Единый подход. В большом Enterprise много процессов и очень часто есть нюансы, из-за которых стандартный флоу не работает. Единая платформа и большое количество методов интеграции позволяет добиться, чтобы ИБ-контроли и процесс производства продуктов могли универсально встраиваться в любой процесс.
Необходимость убрать контроли под капот. В противном случае возникнет проблема, что контроли могут быть отключены, убраны вообще или не работать в том объёме, который нужен.
Интеграции. Необходимо встраиваться в процессы ИТ нативно и прозрачно для команд.
Показывать результаты в реальном времени. Это единственный способ сделать так, чтобы продуктовые команды и ИБ работали вместе.
Создавать единый флоу. Для этого нужно собрать всю необходимую информацию в рамках метрик в одном месте и показывать её в текущий момент, отображая развитие процессов. Если показывать ретроспективу или гипотетические «космические корабли», это вызовет большое количество споров и недопонимания, разговоров, которые не влияют на общий процесс и тратят время.
Как встроить платформу AppSec и контроллеры в процесс
В самом обобщенном виде основной принцип в том, чтобы использовать API там, где возможно. Причем встраиваясь не в пайплайн, а через API вGitLab, TFS, SVN, Bitbucket и т.д., чтобы собрать оттуда данные по событиям или релизным веткам, или по веткам, которые потенциально могут стать релизными. Эти данные нужно сканировать, чтобы понимать уровень безопасности на уровне исходного кода. Такие сканы занимают в среднем 20 минут.
Встраивать плагины следует на уровне артефакториев и репозиториев, чтобы также прозрачно отслеживать текущий уровень безопасности артефактов. Агенты же надо расставлять на тестовые и продсреды, чтобы:
контролировать, что на среду прилетает проверенный артефакт, который подписан и с ним всё нормально;
отслеживать software bill of materials и смотреть, какие пакеты есть в реальности. Это нужно для обеспечения патч-менеджмента, поиски реальных уязвимостей хоста и прочее.
Все это поможет следить за информационными потоками и видеть текущее состояние интеграций.
Как это работает для команд
Команды регистрируют свой продукт через единое окно, и это максимально быстрый и удобный процесс: нужно зайти и ввести название продукта, ID в платформе и краткое описание, а после – добавить пользователей. Это может быть команда разработки, Product Owner или другие заинтересованные лица, например, юристы из IP-Compliance. Дальше добавляются метаданные — репозиторий, артефакторий, тестовые стенды.
Всё это сливается и превращается в артефакт продукта. На этом же этапе могут быть добавлены стенды для динамического тестирования и фаззинга API. После этого можно выбрать, как будет запускаться анализ – по событию или по клику, и запустить сами анализы. Доступ на платформу предоставляется не только из web-интерфейса, но и полноценное REST API и CLI. Все это позволяет разработчику работать с платформой “руками”, либо автоматизировать, например, встраиваясь в пайплайн.
Если после этого результаты становятся доступны в UI, то проводится экспертный анализ и собираются рекомендации. Это позволяет выгрузить данные во внешние системы компании, которые нужны для просмотра общих метрик по продуктам.
Бонусы
Платформы могут принести бенефиты и бонусы не только ИБ, но и всей команде продукта, включая С-Level:
Руководители кластеров, CTO, продуктов могут в любой момент самостоятельно увидеть, что происходит с продуктом и принять решения.
Снижается количество отчётностей для предоставления менеджменту.
API-Compliance позволяет снизить большую нагрузку на отдел по интеллектуальной собственности и повысить удовлетворенность команды в целом.
Появляется возможность наблюдать, что происходит в процессе SDL.
Выстраивается профиль каждого разработчика по анализу созданного им исходного кода: какие совершает уязвимости, как это влияет на продукт, сколько из них справляет. В результате можно определить наиболее частые ошибки, объединить их в группу, показать проблемные места и разобрать, как их исправить на примере реального кода.
Требуется кратно меньше инженеров ИБ. Но важно, чтобы они досконально понимали метрики платформы и как в реальности управлять защищенностью продукта, а также умели программировать. Если инженер информационной безопасности не умеет разговаривать с разработчиком на одном языке, то он не сможет дорабатывать платформу, а это приведет к тому, что вся концепция не сработает.
А если применить этот подход в бирюзовой компании?
В бирюзовой компании больше самоорганизации и понимания, зачем строить AppSеc, какой продукт они делают, какую пользу приносят, получая больше обратной связи от клиентов. Но есть и обратная сторона – зачастую в такой компании меньше централизованных процессов, больше проблем связанных с организацией, что плохо отражается на ИБ. С помощью гибких подходов настроить можно всё.
Если AppSec отсутствует в принципе, то для начала нужно выбрать один базовый инструмент, который принесет наибольшую пользу. Например, самый простой SAST для поиска SQLi или SCA для выявления уязвимых OSS-библиотек. Попробовать внедрить это совместно с продуктовой командой и показать реальные результаты, чтобы привить ценность ИБ команде продукта.
После того как процесс уже начат, можно задуматься о внедрении одной из существующих AppSec-платформ или о разработке собственной. Благодаря преимуществам подхода, можно всегда встроить уже существующие инструменты в новую платформу, что позволит оптимизировать процесс работы с ними, и без сверх затрат получить быстрый результат. А дальше постепенно повышаете уровень зрелости.
Почему этот подход работает
В бирюзовой компании архитектура продумана зачастую благодаря техлиду. SAST’ы учитываются и даже есть попытки встроить их и SCA, но их пока недостаточно. Чтобы это исправить, нужно интегрировать основные контроли хотя бы для того, чтобы следить за ключевыми этапами — дизайном, написанием кода, его сборкой, доставкой, насколько это возможно с точки зрения software bill of materials. А дальше смотреть, что есть в рантайме.
Через платформы можно увидеть весь процесс. Например, когда был запущен продукт и в какой момент у него появилась архитектура. Когда команда написала код, а когда появился артефакт и с ним начали работать. Такой процесс позволяет, по крайней мере, управлять хотя бы в больших реперных точках.
Применение платформенного подхода в AppSec позволяет обеспечить требуемый уровень безопасности и контроля над продуктом, не сильно влияя на бизнес-метрики и не снижая удовлетворенность команд процессами ИБ. Но такой подход не «серебряная пуля» – бизнесу необходимо инвестировать в развитие внутренних компетенций ИБ и в собственную разработку или внедрение уже существующих ASOC платформ.
Смотрите видео выступления Дмитрия Куколева на DevOps Conf 2023 — там всё ещё интереснее: