Цикл популярности понятий из безопасности приложений, 2022 год. Из одноимённого отчёта Gartner. См. также обновление за 2023 год
В процессе внедрения системы безопасности в DevOps можно использовать многие инструменты, которые уже применяются в компании. Какие-то будут плотно интегрированы в процесс, а другие использоваться периодически.
Кроме старых, внедряются новые инструменты, чтобы устранить пробелы в инструментарии и дополнить возможности для автоматизации. Ключевые инструменты и процессы безопасности показаны на схеме вверху (из доклада Gartner).
Рассмотрим подробнее каждый этап автоматизации и внедрения новых инструментов в существующий рабочий процесс.
Этап 1: Планирование
- На этом этапе определяются ключевые приоритеты безопасности DevOps, включая соответствие нормативным требованиям (если нужно) и сроки внедрения.
- Совместно с командами безопасности моделируются возможные векторы атаки и риски (модель угроз), чтобы обеспечить разработчикам нормальный старт по внедрению. Проще запустить модель угроз с чего-то готового, чем с нуля.
- Обучение по вопросам безопасности, включая специфические инструменты и управление техническим долгом.
Интеграция инструментов безопасности во все стадии рабочего процесса DevOps. Источник: Gartner
Этап 2: Создание
- Оценка и внедрение инструментов и продуктов безопасности, которые интегрируются непосредственно в конвейер CI/CD и среду разработчика.
- Выявление типичных ошибок безопасности путём тестирования безопасности приложений (Application Security Testing, AST). Устранение типичных ошибок.
Разработчики инструментов AST. Из отчёта Gartner «Магический квадрант тестирования безопасности приложений»
- Дополнительное моделирование угроз и анализ архитектуры безопасности вместе с инструкторами по безопасности или отделами безопасности (для крупных проектов). Обзор открытых источников по этой теме: статьи и доклады, доступные в интернете.
Этап 3: Проверка
- Сканирование на наличие известных уязвимостей и неправильных конфигураций в существующем коде. При загрузке опенсорсных компонентов можно использовать инструменты SCA (Software Composition Analysis, анализ состава программного обеспечения).
- Сканирование уязвимостей в коде с использованием инструментов статической защиты приложений (static application security tools, SAST) и динамической защиты (DAST). Во время тестирования или атаки система генерирует данные, которые можно использовать для повышения безопасности или реагирования на атаки. Интерактивное тестирование безопасности приложений (IAST) выполняется на работающем коде и может быть интегрировано в общий процесс DevOps.
- Сканирование уязвимостей и неправильных конфигураций в инфраструктуре. Тестирование протоколов и входных данных, безопасности кода, тестирование безопасности мобильных приложений (MAST).
- Применение этих принципов ко всем конвейерам CI/CD.
Этап 4: Подготовка к выпуску
- Оценка решений для тестирования приложений, в том числе проверка известных атак и прогон недетерминированных тестов.
- Недетерминированный тест может работать неделями и не найти уязвимости, а может обнаружить её с первой попытки. Это отражает природу 0day-уязвимостей в реальном мире. Но поскольку DevOps делает упор на итеративную разработку, здесь код тестируется чаще, чем в классической разработке ПО по модели водопада.
- Не существует конкретных рекомендаций по частоте тестов.
- Оценка опенсорсных инструментов, которые используются в инфраструктуре.
Этап 5: Выпуск
- Проверка подписи метки времени — и деплой в CI/CD.
- Скорее всего, интегрированная среда безопасности потребует нескольких подписей для успешного завершения каждого теста (например, отдельные подписи для SCA, IAST и полного сканирования уязвимостей).
- Всё это должно быть автоматизировано на основе политик и процессов управления ИТ-рисками.
Этап 6: Предотвращение
- Проверка конфигурации и соответствия кода всем требованиям для выпуска в продакшн.
- Внедрение системы контроля приложений и списков разрешений для корректного распределения рабочей нагрузки на серверах в облаке (CWPP):
- Организация общих мер защиты (например, от DDoS). Сотрудничество между разработчиками, инструкторами по безопасности и отделами безопасности для согласования архитектуры разработки приложений с существующими мерами углублённой защиты.
- Для анализа сетевого трафика, определения намерений и развёртывания активных мер защиты можно использовать и другие технологии. К таким инструментам относятся системы обнаружения и предотвращения вторжений (intrusion detection and prevention systems, IDPS), анализ поведения пользователей и объектов (user and entity behavior analysis, UEBA), а также межсетевые экраны нового поколения (next-generation firewalls, NGFW).
Из отчёта Gartner «Магический квадрант для сетевых файрволов»
Этап 7: Обнаружение
- Некоторые уязвимости неизбежно попадут в продакшн. Поэтому приложения следует изначально проектировать таким образом, чтобы быстро выявлять проблемы во время работы.
- Система самозащиты приложений во время выполнения (runtime application self-protection, RASP) реагирует на атаку либо принятием мер защиты приложения, либо безопасным отказом.
- После деплоя приложения довольно сложно развернуть систему RASP из-за проблем с производительностью и совместимостью. Поэтому лучше спроектировать её на этапе разработки.
Этап 8: Реагирование
- Внедрение существующих инструментов по обеспечению глубокой защиты приложений. Например, производители маршрутизаторов и коммутаторов зачастую предлагают встроенную систему защиту от DDoS. Эти технологии зависят от файрволов веб-приложений и шлюзов API. Они определяют тип атаки, обеспечивают защиту, предупреждают об атаке и/или регистрируют её.
- Сбор данных в процессе атаки очень важен для создания правильной защиты и передачи разработчикам информации, как приложение ведёт себя в реальном мире.
- Эта информация передаётся на этап 1 «Планирование», обеспечивая обратную связь через мониторинг инцидентов и событий безопасности.
- Обратная связь включается в цепочку инструментов разработки для более эффективного реагирования на инциденты, внесения оперативных корректировок и минимизации технического долга.
Этап 9: Прогнозирование
- Информация и телеметрия с предыдущих этапов используется для предсказания, какие потребуются контрмеры.
- Данные об атаке должны быть собраны, проанализированы и включены в цикл планирования продукта. Они улучшат модель угроз и понимание требований безопасности для последующих продуктов.
- На этапе прогнозирования также важны сторонние источники информации об угрозах и аналитические данные. Например, когда находят новую уязвимость в популярном фреймворке, таком как Apache Struts. На основе этой информации создаётся рабочий процесс по устранению уязвимости. Если и уязвимость, и продукт критически важны, разработчики в приоритетном порядке выпускают новый автоматизированный релиз с использованием обновлённой библиотеки или фреймворка.
Этап 10: Адаптация
- Неизбежно появляются баги, уязвимости и области для улучшения. Используйте всю собранную информацию от системы и инструментария для формирования следующего раунда требований. Эта информация применяется как на уровне скрама (для событий критического уровня), так и на уровне планирования (для менее срочных проблем).
- Изменение конфигурации и уточнение тестов безопасности. Специалистам по безопасности следует постоянно пересматривать и совершенствовать свои инструменты и методы работы.
- Непрерывная обратная связь и развитие — это постоянная мантра для отделов инфраструктуры и безопасности. Они должны использовать все технические средства для получения фидбека — оповещения, логи и статистику — для улучшения процессов, инструментов и практик безопасности.
В целом, автоматизация создаёт более эффективный, бесперебойный рабочий процесс без ущерба для безопасности. Автоматизированные процессы не только поддерживают команды DevSecOps, но и уменьшают риски безопасности за счёт более быстрого сканирования, выявления и устранения брешей в защите.
Автоматизация полезна на всех этапах: от сервиса подписи документов до полноценной платформы PKI-as-a-Service.
Источники данных
Приведённые здесь рекомендации основаны на анализе запросов и ответов по безопасности от клиентов Gartner в 2022 году. Компания получила более 600 ответов от клиентов (индивидуальные встречи на конференциях и письменные опросы), в которых обсуждались DevOps, инициативы, успехи и неудачи по внедрению инструментов безопасности за последнее время. На основе этих данных и составлен данный план.
Термин "DevOps" регулярно входил в пятёрку самых популярных тем клиентских запросов Gartner в области IT-операций с июля 2021-го по июль 2022 года). Он также входил в пятёрку самых популярных поисковых запросов на сайте Gartner.com с 2017-го по 2022 годы.
Предыдущие части:
- Безопасность DevOps. Стратегическое планирование
- Безопасность DevOps. Обучение сотрудников
