Применение подхода непрерывного жизненного цикла разработки безопасности (непрерывный SDL)

Инновации — это основа организации в цифровую эпоху; их следует как обеспечить, так и защитить. Инновационная безопасность защищает процессы и данные инноваций от кибератак. Инновации в цифровом веке принимают форму разработки приложений с помощью метода DevOps или DevSecOps . Такой подход позволяет организациям быстро внедрять инновации, не ожидая традиционных расписаний каскадных судов, которые могут занять месяцы или годы между выпусками.

Успешные возможности и приложения соответствуют трем различным типам требований:

• Функциональные (разработки): ваше приложение должно соответствовать потребностям бизнеса и пользователей, которые часто быстро развиваются.
• Secure (Sec): ваше приложение должно быть устойчивым к атакам от быстро развивающихся злоумышленников и воспользоваться преимуществами инноваций в защите безопасности.
• Reliable (Ops): ваше приложение должно быть надежным и эффективно работать.

Объединить эти три требования и создать общую культуру критически важно, но зачастую несложно. Руководители команд по разработке, ИТ и безопасности должны стать движущей силой этих изменений.

Просмотрите следующее видео, чтобы узнать больше о методе DevSecOps для обеспечения безопасной и быстрой инноваций.

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

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

Риски безопасности (и необходимость их устранения) могут возникать в любой момент жизненного цикла разработки:

• Проектирование — убедитесь, что дизайн не позволяет злоумышленникам легко получить несанкционированный доступ к рабочей нагрузке, его данным или другим бизнес-ресурсам в организации.
• Код . Убедитесь, что написание кода (и повторное использование) не позволяет злоумышленникам легко управлять приложением для выполнения несанкционированных действий, которые повреждают клиентов, сотрудников, систем, данных или других бизнес-ресурсов. Разработчики также должны работать в защищенной среде, которая не позволяет злоумышленникам управлять без их знаний.
• Сборка и развертывание . Убедитесь, что процессы непрерывной интеграции и непрерывного развертывания (CI/CD) не позволяют несанкционированным пользователям изменять код и разрешать злоумышленникам скомпрометировать его.
• Запуск — убедитесь, что среда, в которой выполняется код (облако, серверы, мобильные устройства, другие) следует рекомендациям по обеспечению безопасности для людей, процессов и технологий, чтобы избежать ущерба и злоупотреблений рабочей нагрузкой злоумышленниками. Этот процесс включает в себя внедрение хорошо установленных рекомендаций, конфигураций базовых показателей безопасности и многое другое.
• Архитектура нулевого доверия и управление. Все эти этапы должны следовать принципам нулевого доверия, чтобы предположить нарушение (предположить компрометацию), явно проверить доверие и предоставить наименьшие привилегии, необходимые для каждой учетной записи пользователя, удостоверения компьютера или службы и компонента приложения.

Что такое DevSecOps?

Технологии инноваций часто разрабатываются в контексте быстрого, гибкого и гибкого подхода к развитию, объединяющего разработку и операции вместе в процесс DevOps и интеграцию безопасности в этот процесс, является критически важным для снижения рисков для процесса инноваций, роста организации и существующих активов в организации. При интеграции в процесс безопасности создается процесс DevSecOps.

Безопасность по умолчанию и сдвиг влево

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

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

В каскадной модели безопасность, как правило, представляла собой этап контроля качества после завершения разработки.

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

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

Методология организации Cloud Adoption Framework обеспечивает дальнейший контекст в структурах DevSecOps в организации. Дополнительные сведения см. в статье Общие сведения о функциях безопасности приложений и DevSecOps.

Почему следует применять именно DevSecOps?

DevOps обеспечивает гибкость, а DevSecOps — безопасную гибкость.

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

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

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

• Атаки разработки с использованием слабых мест в процессе разработки и разработки приложений. Например, злоумышленники могут найти код, который не проверяет входные данные (разрешая распространенные атаки, такие как внедрение SQL), или они могут найти, что приложение использует слабое шифрование (или без шифрования) для обмена данными. Кроме того, злоумышленники могут имплантировать внутренние двери в код, который позволяет им позже вернуться к ресурсам в вашей среде или в среде клиента.
• Атаки инфраструктуры, которые компрометируют элементы конечной точки и инфраструктуры, размещенные в процессе разработки, с использованием стандартных атак. Злоумышленники также могут проводить многоступенчатые атаки с использованием украденных учетных данных или вредоносных программ для доступа к инфраструктуре разработки из других частей среды.

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

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

Путь к DevSecOps

Большинство организаций считают, что DevOps или DevSecOps для любой конкретной рабочей нагрузки или приложения фактически является двухэтапным процессом. Идеи сначала инкубируются в безопасном пространстве и позже выпускаются в производство как минимальный жизнеспособный продукт (MVP). Затем они итеративно и постоянно обновляются.

На этой схеме представлен жизненный цикл такого рода подхода к производству инноваций:

Безопасность инноваций — это интегрированный подход для обоих этапов.

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

Требование к руководству: смешение культур

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

Интеграция этих культур и целей в полноценный подход DevSecOps может вызвать трудности, однако в конечном счете окупит вложения. Многие организации сталкиваются с высоким уровнем трений между независимыми командами разработки, ИТ-операций и безопасности, что приводит к возникновению следующих проблем.

• Медленное создание ценности и низкая гибкость.
• Проблемы с качеством и производительностью.
• Проблемы с безопасностью

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

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

Методы руководства

Эти ключевые методы помогут руководству сформировать общую культуру.

1. Никто не выигрывает все споры. Руководители должны убедиться, что при принятии решений не преобладает одна-единственная позиция — это может привести к дисбалансу и негативно повлиять на бизнес.
2. Ожидайте постоянного улучшения, а не совершенства. Руководители должны сформировать ожидания постоянного улучшения и постоянного обучения. Создание успешной программы DevSecOpsтребует времени. Это непрерывный путь с постепенным прогрессом.
3. Отмечайте как общие интересы, так и уникальные индивидуальные ценности. Следите за тем, чтобы команды видели, что они стремятся к достижению общих результатов и каждый пользователь обеспечивает что-то свое. Все типы требований относятся к созданию и защите одной и той же ценности для бизнеса. Команда разработки пытается создать новую ценность, тогда как команды операций и безопасности — защитить и сохранить эту ценность в различных сценариях риска. Руководители на всех уровнях организации должны напоминать об этой общности и о том, насколько важно соблюдать все типы требований как для немедленного, так и для долгосрочного успеха.
4. Разработка общего понимания: все участники команды должны иметь базовое представление:
   • Срочность для бизнеса. Команда должна иметь четкое представление о доходе, о котором идет речь. Это представление должно включать текущий доход (если служба находится в автономном режиме), а потенциальный будущий доход, затронутый задержкой доставки приложений и функций. Это представление должно быть непосредственно основано на сигналах со стороны заинтересованных лиц руководства.
   • Вероятные риски и угрозы. На основе входных данных команды по аналитике угроз, если таковая имеется, команда должна составить представление о возможных угрозах, с которыми столкнется портфель приложений.
   • Требования к доступности. Команда должна иметь общее представление об операционных требованиях, таких как требуемое время доступности, ожидаемое время существования приложения, а также требования к устранению неполадок и обслуживанию, например, исправление при подключении службы к сети.
5. Демонстрируйте требуемое поведение. Руководители должны открыто демонстрировать поведение, которого хотят добиться от своих команд. Например, проявлять скромность, заниматься обучением и ценить другие дисциплины. Другой пример — менеджеры по разработке обсуждают преимущества обеспечения безопасности и высококачественных приложений, или менеджеры по безопасности обсуждают преимущества быстрого внедрения инноваций и производительности приложений.
6. Отслеживайте уровень трений касательно безопасности. Безопасность естественным образом создает трения, которые замедляют процессы. Важно, чтобы лидеры отслеживали уровень и тип трений, которые генерирует безопасность:
   • Здоровые трения. Подобно тому, как упражнение укрепляет мышцы, интеграция правильного уровня трений, связанных с безопасностью, в процесс DevOps укрепляет приложения за счет принудительного обращения к критическому мышлению в нужный момент Если команды учатся и используют эти учебные курсы для повышения безопасности, например, учитывая, почему и как злоумышленник может попытаться компрометировать приложение, а также найти и исправить важные ошибки безопасности, то они находятся на пути.
   • Нездоровые трения. Ищите трения, которые, скорее, препятствуют созданию ценности, чем защищают ее. Это часто происходит, когда ошибки безопасности, созданные инструментами, имеют высокую ложноположительный коэффициент или ложные оповещения, или когда усилия по обеспечению безопасности для устранения чего-то превышает потенциальное влияние атаки.
7. Интегрируйте безопасность в планирование бюджета. Обеспечьте распределение бюджета на обеспечение безопасности пропорционально другим инвестициям в безопасность. Эта концепция аналогична физическому событию, например концерту, где бюджет событий включает физическую безопасность в качестве нормы. Некоторые организации выделяют 10 процентов общих расходов на обеспечение безопасности, чтобы обеспечить единообразное применение лучших методик по обеспечению безопасности.
8. Установите общие цели. Убедитесь, что метрики производительности и успеха для рабочих нагрузок приложения отражают цели разработки, безопасности и операций.

Примечание.

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

Выявление MVP DevSecOps

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

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

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

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

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

• Действия по проектированию, например моделирование угроз, необходимо интегрировать в этап проектирования.
• Средства проверки безопасности необходимо интегрировать в системы непрерывной поставки и непрерывной интеграции (CI/CD), такие как Azure DevOps, GitHub и Jenkins.
• Сообщать о проблемах безопасности следует с помощью тех же систем и процессов отслеживания ошибок, что используются для информирования о других ошибках, например, с помощью схемы приоритетов.

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

Дополнительные сведения о DevSecOps см. в статье Технические элементы управления DevSecOps.

Советы по прохождению пути

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

• Изменения образования и культуры являются критически важными ранними шагами: вы идете на войну с армией, у вас есть. Вашей команде придется часто овладевать новыми навыками и внедрять новые перспективы для понимания других составляющих модели DevSecOps. Эти изменения, связанные с образованием и культурой, требуют времени, внимания, финансовой поддержки со стороны руководства и стандартных проверок, чтобы сотрудники могли в полной мере понять и увидеть пользу изменений. Коренные изменения, связанные с культурой и навыками, иногда могут затрагивать профессиональное самоопределение отдельных сотрудников и потенциально вызывать сильное сопротивление. Важно понимать и объяснять, зачем нужно изменение, что оно даст каждому сотруднику и ситуации и каким образом оно будет осуществляться.
• Изменения требуют времени. Вы можете двигаться не быстрее, чем команда адаптируется к новым способам работы. В ходе трансформации командам всегда приходится выполнять уже имеющуюся работу. Крайне важно тщательно расставлять приоритеты и управлять ожиданиями в отношении скорости осуществления изменений. Ваша организация выиграет от применения стратегии "ползком, шагом и только потом бегом", которая в первую очередь учитывает самые важные и базовые элементы.
• Ограниченные ресурсы. Как правило, организации на ранних этапах сталкиваются с проблемой поиска специалистов по безопасности и разработке приложений. По мере повышения эффективности совместной работы в масштабах организации можно отыскать скрытые таланты, например, разработчиков с типом мышления, подходящим для работы в области обеспечения безопасности, или специалистов по безопасности с опытом разработки.
• Меняющаяся природа приложений, кода и инфраструктуры. Техническое определение и композиция приложения радикально изменяются с внедрением таких технологий, как бессерверные технологии, облачные службы, облачные API и приложения без кода, например Power Apps. Этот сдвиг меняет методики разработки, безопасность приложений и даже позволяет неразвитым пользователям создавать приложения.

Примечание.

Некоторые реализации объединяют обязанности команд по операциям и безопасности в роль инженера по обеспечению надежности сайта (SRE).

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

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

Следующие шаги

Ознакомьтесь со статьей Технические элементы управления DevSecOps, чтобы получить более подробные рекомендации по DevSecOps.

Сведения о том, как расширенные функции безопасности GitHub интегрирует функции безопасности в конвейеры непрерывной поставки и непрерывной интеграции (CI/CD), см. в статье Расширенные функции безопасности GitHub.

Дополнительные сведения о внедрении DevSecOps ИТ-организацией Майкрософт и использованных для этого инструментах см. в статье Набор средств для безопасного выполнения DevOps.