Внедрение императивов планирования безопасного развития

В этой статье определены ключевые императивы интеграции безопасности в методики разработки в рамках дисциплины "Безопасность разработки".

Современные организации полагаются на быстрое развитие программного обеспечения для обеспечения инноваций, удовлетворения бизнес-требований, поддержания конкурентного преимущества и реагирования на изменение бизнес-потребностей. Хотя DevOps обеспечивает гибкость, она также представляет новые риски безопасности в виде кода, инфраструктуры и процессов развертывания.

Чтобы безопасно внедрить методики DevOps, организации должны интегрировать безопасность в стратегию разработки, рабочие процессы и процессы доставки, а также внедрить методики DevSecOps, которые обеспечивают безопасность доставки приложений в течение жизненного цикла.

Результаты

Внедрение императивов планирования в этой статье позволяет организациям:

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

Определите границы безопасности разработки

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

Организации должны учитывать риски безопасности в разных странах:

• Логика приложений и службы
• Развертывания автоматизации инфраструктуры и инфраструктуры как кода (IaC)
• Конвейеры сборки и выпуска
• Конфигурации развертывания и операционные скрипты
• Среды разработки и идентификаторы служб
• Сторонние зависимости и компоненты цепочки поставок

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

Учет ключевых рисков

Организации должны явно включать следующие риски при определении требований:

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

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

Интеграция безопасности в стратегию и жизненный цикл

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

Организации должны определять требования безопасности вместе с функциональными требованиями и соответствовать следующим требованиям:

• Стратегия разработки
• Планирование архитектуры
• Рабочие процессы доставки
• Модели операционной поддержки

Результаты безопасности — это общие обязанности, принадлежащие инженерным и операционным ролям, поддерживаемым специалистами по безопасности.

Безопасность способствует инновациям; это не барьер, который ставят после выпуска.

Организации должны применять непрерывный подход жизненного цикла безопасной разработки (SDL), который включает в себя:

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

Безопасность необходимо постоянно оценивать и совершенствовать по мере развития архитектур приложений, изменения рисков и моделей поставки.

Определение минимальных критериев жизнеспособности рабочей среды

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

• Разработка (dev): заинтересованные стороны, отвечающие за разработку, определяют минимальные функциональные требования, необходимые для удовлетворения потребностей бизнеса и обеспечения ценности для клиентов и пользователей.
• Безопасность (sec): заинтересованные стороны безопасности определяют минимальные требования, необходимые для выполнения нормативных обязательств, поддержания состояния безопасности организации и поддержки обнаружения и реагирования на активные угрозы.
• Эксплуатация (ops): заинтересованные стороны, отвечающие за эксплуатацию, определяют минимальные требования к производительности, надежности и сопровождаемости, необходимые для того, чтобы нагрузка надежно работала в продуктивных средах.

Критерии пригодности для промышленной эксплуатации:

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

Критерии пригодности к промышленной эксплуатации меняются в зависимости от изменений в:

• Модели доставки приложений.
• Условия угрозы.
• Терпимость к рискам организации.
• Требования к соответствию требованиям.

Интеграция безопасности в рабочие процессы разработки

Безопасность должна быть внедрена непосредственно в процессы разработки и доставки. Организации должны:

• Определите требования к безопасности в рабочих процессах разработки.
• Интеграция действий безопасности в:
  • Процессы проектирования
  • Построение конвейеров
  • Рабочие процессы развертывания (CI/CD)
• Реализуйте такие механизмы проверки безопасности, как:
  • Проверка кода
  • Проверка зависимостей
  • Проверки конфигурации

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

Проверка безопасности должна выполняться непрерывно через доставку, а не только на контрольных точках выпуска.

Баланс и согласование требований

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

• Бизнес-функции.
• Устойчивость безопасности.
• Скорость инноваций.
• Операционная надежность и производительность.

Организации должны определять общие цели доставки и метрики производительности, которые:

• Выравнивайте общие цели производительности и доставки в рамках разработки, безопасности и операций.
• Избегайте доминирования одним доменом.
• Определите приоритет результатов на основе следующих показателей:
  • Терпимость к рискам организации.
  • Нормативные обязательства.
  • Подотчетность бизнеса.

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

Создание общей подотчетности

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

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

Применяйте ограничения безопасности на основе политик

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

• Требования к удостоверениям и доступу.
• Стандарты конфигурации и соответствия.
• Средства управления развертыванием и релизами.

Ограничения должны быть:

• Интегрировано в базовые компоненты платформы (например, зоны приземления).
• Внедренные в рабочие процессы разработки и развертывания.
• Применяется автоматически, когда это возможно.

Этот подход обеспечивает согласованное применение требований к безопасности при сохранении скорости доставки.

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

Поддержание и улучшение

Безопасность не остается эффективной в качестве статического набора элементов управления и должна развиваться с течением времени.

Организации должны постоянно оценивать и обновлять методики безопасности разработки в ответ на изменения:

• Условия угроз и поведение злоумышленника.
• Архитектуры приложений и модели доставки.
• Нормативные обязательства.
• Терпимость к рискам организации.
• Критерии готовности к промышленной эксплуатации.
• Процессы доставки разработки.
• Методы управления безопасностью.

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

Методы выравнивания

Команды должны соответствовать следующему:

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

Выравнивание рабочих процессов с требованиями к безопасности

Безопасность должна быть встроена в процессы разработки. Организации должны определять и выравнивать рабочие процессы для:

• Работы по архитектурному проектированию.
• Процессы сборки и развертывания.
• Рабочие процессы отслеживания и исправления проблем.

Выводы по безопасности должны быть следующими:

• Приоритизировано и отслеживается.
• Управляются вместе с дефектами в продакшене.
• Включено в решения о готовности к выпуску.

Выравнивание рабочих процессов гарантирует, что требования к безопасности постоянно применяются во время доставки.

Дальнейшие действия

Узнайте о разработке на основе принципов "Никому не доверяй"