23.12.2023 19:11
GlobalSign_admin 0 3900 Источник

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

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


Комментарии (0)