Установка дисциплины "Безопасность разработки"

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

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

Почему эта дисциплина?

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

Без эффективной дисциплины безопасности разработки организации обычно испытывают следующие возможности:

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

Надежная дисциплина безопасности разработки гарантирует, что каждый выпуск снижает риск, а не составляя его.

Миссия и результаты

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

Организации, которые зрелы в этой дисциплине, достигают следующего:

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

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

Изменения в работе команды

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

Этот подход часто описывается как сдвиг влево, вводя мышление безопасности ранее в идеях, проектировании и реализации, когда проблемы проще и менее затратно устранять. Сдвиг влево не означает говорить «нет» на более ранних этапах процесса. Вместо этого он предполагает обсуждение с учётом вопросов безопасности на раннем этапе, чтобы улучшить решения по продукту и обеспечить, чтобы решения соответствовали требованиям безопасности и бизнеса.

К ключевым принципам относятся:

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

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

Как применить эту дисциплину

Чтобы эффективно применять дисциплину "Безопасность разработки", сосредоточьтесь на создании и обслуживании безопасных приложений и служб в организации:

1. Определение стратегии безопасного развития, согласованной с бизнес-риском
   Создайте четкий подход к разработке, созданию и обслуживанию приложений и поддержке для снижения риска компрометации и защиты критически важных бизнес-функций.
2. Внедрение безопасности в процессы разработки и проектирования
   Убедитесь, что рекомендации по обеспечению безопасности интегрированы в планирование, проектирование, разработку и развертывание, а не применяются после факта.
3. Создание стандартных методов безопасной разработки
   Предоставьте четкое руководство, чтобы обеспечить согласованное применение безопасных методов программирования, тестирования и выпуска в командах и проектах.
4. Выравнивание безопасности разработки с критически важными ресурсами и бизнес-сценариями
   Приоритеты защиты приложений и служб, которые поддерживают высокоценные активы и ключевые бизнес-операции.
5. Непрерывно улучшается на основе рисков, уязвимостей и отзывов
   Используйте аналитические сведения об уязвимостях, инцидентах и результатах тестирования, чтобы укрепить методики разработки и снизить риск с течением времени.

Управление изменением

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

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

Защита дизайна . Используйте проверенные шаблоны проектирования безопасности и проверяйте проекты с помощью моделирования угроз. Защита кода . Следуйте безопасным методикам написания кода и проверяйте программное обеспечение и зависимости. Защита конвейера — проверка процесса конвейера и защита систем CI/CD от компрометации и несанкционированного изменения. Обеспечьте отслеживаемость изменений в конвейере и программного обеспечения, проходящего через конвейер. Безопасная эксплуатация – Убедитесь, что развернутые рабочие нагрузки соответствуют рекомендациям по настройке, установке исправлений и эксплуатации.

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

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

Определение процесса DevSecOps

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

Большинство организаций проходят следующие этапы:

Разработка (Dev) — первый релиз в продуктивной среде нацелен на выпуск минимально жизнеспособного продукта (MVP), который соответствует основным бизнес-требованиям. DevOps — после первоначального выпуска команды сосредоточены на быстрой итерации, стабильности работы и управлении с помощью непрерывной доставки. DevSecOps — по мере развития сотрудничества команды разработки, безопасности и эксплуатации работают вместе, чтобы постоянно совершенствовать процессы и обеспечивать баланс между скоростью, рисками и надежностью.

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

Создание безопасной базовой платформы MVP

Ключевым шагом в этой модели является определение того, что представляет собой минимальный жизнеспособный продукт (MVP) с точки зрения разработки, безопасности и операций. Создание этой общей базовой базы создает ясность между командами и обеспечивает согласованное улучшение с течением времени.

Компонент	Сведения
Dev(elopment)	Убедитесь, что программное обеспечение соответствует минимальным бизнес-требованиям и функциональным требованиям.
Sec(urity)	Убедитесь, что программное обеспечение соответствует минимальным требованиям к безопасности и соответствию требованиям.
Op(eration)s	Убедитесь, что программное обеспечение соответствует минимальным требованиям к качеству, надежности и готовности к эксплуатации.

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

Непрерывное улучшение программного обеспечения

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

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

Этот подход соответствует обучению Microsoft Secure Future Initiative (SFI), таким как pr Проложенные пути, где безопасные методики встроены в платформы и процессы, а не применяются во внешних средах.

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

Роли по дисциплинам и соавторы

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

Основные роли в этой дисциплине обычно включают:

• Технологические менеджеры по доставке и продуктам
• Разработчики программного обеспечения (включая разработку ИИ)
• Инженеры по безопасности программного обеспечения
• Инженеры DevOps и платформенные инженеры
• Роли в тестировании и обеспечении качества
• Роли безопасности цепочки поставок и зависимостей

К ключевым участникам совместной работы относятся:

• Бизнес и техническое руководство— предоставление спонсорства и приоритета
• Роли архитектуры— руководство по безопасному проектированию и интеграции
• Роли дисциплины "Стратегия безопасности", "Интеграция" и "Управление" — обеспечение политики, образования и надзора
• Команды инфраструктуры и платформ — обеспечьте безопасные среды разработки
• Операции безопасности (SecOps) — мониторинг и реагирование при атаках приложений

Выравнивание с другими дисциплинами

Безопасность разработки тесно интегрирована с другими дисциплинами SAF:

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

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

Соответствие технологическим направлениям

Реализация стратегии в рамках дисциплины безопасности разработки требует применения мер безопасности в нескольких технологических направлениях.

Согласование с технологическими столпами включает в себя:

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

Такая широта позволяет этой дисциплине охватывать реальные векторы атак.

Что дальше?

Дополнительные рекомендации по стратегии безопасности разработки приведены в стратегии безопасности разработки.

Посетите семинар

Microsoft Unified предлагает экспертные семинары, помогающие организациям модернизировать свою дисциплину безопасности разработки. К этим семинарам относятся следующие:

• Семинары по архитектуре и стратегии — Платформа внедрения безопасности (SAF) — сеанс проектирования архитектуры: семинар по обеспечению безопасности инфраструктуры и развития сосредоточен на ускорении модернизации безопасности разработки и интеграции с безопасностью инфраструктуры. Этот семинар проводится в формате обсуждения продолжительностью менее четырёх часов и посвящён ключевым выводам и лучшим практикам.
• семинары по внедрению Technology: Microsoft Unified содержит семинары, помогающие организациям узнать, планировать, реализовывать и оптимизировать использование технологии безопасности разработки Microsoft, как показано на этой схеме.

Просмотрите жизненный цикл разработки защищенных приложений (Майкрософт)

Жизненный цикл непрерывной разработки безопасности Microsoft предоставляет методологию для безопасного разработки программного обеспечения. Жизненный цикл разработки безопасности (SDL) — это подход, Microsoft используется для интеграции безопасности в процессы DevOps (иногда называемый подходом DevSecOps). Руководство по безопасности разработки SAF помогает адаптировать подход и методики SDL для вашей организации.

Вы можете применить методики, описанные в подходе SDL ко всем типам разработки программного обеспечения и всем платформам, от классического каскада до современных подходов DevOps. Этот подход, как правило, применяется к обеспечению безопасности программного обеспечения в любом типе программного обеспечения и платформы.

Дополнительные сведения см. в разделе жизненный цикл разработки защищенных приложений (Майкрософт) (SDL).

Для эффективной безопасности разработки требуется выполнение жизненного цикла разработки безопасности (SDL), например жизненный цикл разработки защищенных приложений (Майкрософт) (SDL)

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

Узнайте о переходе с DevOps на DevSecOps.