Безопасность DevOps. Автоматизация и новые инструменты23.12.2023 22:15

Цикл популярности понятий из безопасности приложений, 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: Предотвращение

Этап 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 годы.

Предыдущие части: