Элементы управления DevSecOps

  • Статья

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

Схема элементов управления безопасностью и времени и влияния.

Профили элементов управления безопасностью

В этой статье приведены три уровня профилей элементов управления.

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

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

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

Элементы управления безопасностью DevSecOps

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

Дополнительные сведения см. в разделе "Путешествие DevSecOps".

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

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

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

Средства контроля безопасности

Элементы управления группируются на этапы разработки, к которым они применяются, и к общим элементам управления (критически важным основам), которые применяются на всех этапах разработки и профилях управления:

Каждый из этих элементов определен в следующих разделах:

Создание критически важных фундаментов

Этот элемент управления поддерживает непрерывную практику SDL 1. Установите стандарты безопасности, метрики и управление, практика 2. Требовать использования проверенных функций безопасности, языков и платформ, а также практики 10 — предоставление обучения безопасности.

Стандартный — эти элементы управления применяются ко всем этапам разработки и профилям элементов управления.

Предоставление обучения безопасности

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

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

В конечном счете, каждая роль должна понимать:

  • Почему важно устранить риски безопасности
  • Что им нужно сделать для обеспечения безопасности в их роли
  • Как сделать безопасность частью своей повседневной роли

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

Безопасность — это бесконечная игра, в которой угрозы, технологии и бизнес-активы для защиты всегда меняются, и субъекты угроз никогда не отдаются. Подход к обучению безопасности должен продолжаться и постоянно развиваться. Эффективное обучение соответствует политикам безопасности, рекомендациям по жизненному циклу разработки программного обеспечения (SDL), стандартам и требованиям к безопасности программного обеспечения. Учебный материал должен быть получен из аналитических сведений, полученных от данных и новых технических возможностей.

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

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

Включение безопасности в безвинные постмортимы

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

Создание стандартов безопасности, метрик и управления

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

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

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

Примечание.

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

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

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

Требовать использования проверенных функций безопасности, языков и платформ

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

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

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

Безопасность базовых удостоверений

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

Безопасность удостоверений имеет две формы для разработки:

  • Безопасность удостоверений для процесса разработки. Убедитесь, что все участники процесса разработки используют надежные методы проверки подлинности для повседневной работы и имеют права, необходимые только для выполнения задач задания. Дополнительные сведения см. в разделе "Управление доступом к удостоверениям и приложениям".
  • Безопасность удостоверений для систем и приложений — убедитесь, что системы, которые они разрабатывают и строят, следуйте рекомендациям по методам проверки подлинности и авторизации (и не строят собственные слабые имитации проверенных и поддерживаемых систем идентификации).

Примените безопасность удостоверений для систем и приложений, следуя инструкциям в следующих ресурсах:

Криптографические стандарты

Применяйте методы шифрования звука ко всем использованию криптографии. Следуйте всем рекомендациям, описанным в статье "Непрерывная практика SDL 4" — определение и использование криптографических стандартов.

Дополнительные сведения см . в рекомендациях по шифрованию шифрования Microsoft SDL.

Защита среды разработки

Этот элемент управления поддерживает непрерывную практику SDL 6. Защита среды разработки.

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

В текущем ландшафте злоумышленники расширяют свои операции, чтобы нацеливать компьютеры разработчиков и изменять процессы сборки. Ключевой пример этой атаки был одним из опытных в SolarWinds, где злоумышленник вставил вредоносный DLL до последних этапов сборки программного обеспечения. Фактически это привело к атаке, которая была распределена тысячам клиентов по всему миру через цепочку поставок. Дополнительные сведения о атаке SolarWinds см. в блоге Майкрософт По анализу Solorigate, скомпрометированном DLL-файле, который начал сложную кибератаку, и о том, как Microsoft Defender помогает защитить клиентов.

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

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

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

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

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

Безопасная конструкция

Выполнение моделирования угроз (проверка проектирования безопасности)

Этот элемент управления поддерживает непрерывную практику SDL 3— выполнение моделирования угроз.

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

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

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

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

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

Этапы моделирования угроз:

  1. Определение вариантов использования, сценариев и ресурсов . Начните с понимания того, какие бизнес-функции и варианты использования система позволяет оценить потенциальное влияние любого компрометации системы и сообщить о дальнейших обсуждениях.
  2. Создание обзора архитектуры— создание визуальной сводки приложения (или использование существующего) для четкого понимания системы и ее работы. Этот обзор должен включать в себя схему бизнес-процессов, компоненты и подсистемы, границы доверия, механизмы проверки подлинности и авторизации, внешние и внутренние интерфейсы, а также потоки данных между субъектами и компонентами.
  3. Определение угроз. Используйте общую методологию для перечисления потенциальных угроз безопасности, таких как модель STRIDE или моделирование угроз OWASP.
  4. Выявление и отслеживание рисков . Отслеживайте обнаруженные недостатки проектирования и отслеживайте их с помощью существующих процессов разработки и средств, чтобы обеспечить реализацию и документирование исправлений. Этот процесс должен включать в себя приоритеты, которые необходимо выполнить в первую очередь, чтобы команды провели свое время на наиболее важные усилия. Этот процесс обусловлен риском, и у вас может не быть ресурсов, чтобы полностью устранить все риски в первом цикле. Тщательно рассмотрим, какие способы устранения рисков, включая частичные устранения рисков, повышают затраты злоумышленника на наименьшие оборонительные затраты и ресурсы. Цель безопасности — это сбой злоумышленника, который может принимать форму полной блокировки метода атаки, обнаруживая их, чтобы включить ответ защитника, замедляя их, чтобы дать защитникам время реагирования, ограничение область повреждения и многое другое.

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

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

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

Безопасный код

Анализ кода

Этот элемент управления поддерживает непрерывную практику SDL 7— выполнение тестирования безопасности.

Этот элемент управления фокусируется на повышении безопасности кода, так как разработчики записывают и вводят его в интегрированную среду разработки (IDE) или как они проверка в коде. Этот элемент управления является краеугольным камнем практики DevSecOps, так как он напрямую обращается к уязвимостям, которые злоумышленники используют регулярно.

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

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

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

Средства SAST сканируют существующую базу кода и имеют полный доступ к коду. Средства SAST могут выявлять основные недостатки в самом коде. DAST с другой стороны выполняется в развернутом приложении. В результате он не имеет доступа к коду и выполняется для имитации и выявления слабых мест безопасности во время выполнения.

Примечание.

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

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

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

Стандартный — убедитесь, что вы полностью сканируете все компоненты со всеми применимыми инструментами SAST/DAST и выявляет слабые места. Обеспечение полного покрытия безопасности по коду приложения. Убедитесь, что вы выполняете документированную процедуру исправления и имеете стандарт ошибки, соответствующий допустимости риска вашей организации.

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

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

Защита конвейера CI/CD

Цепочка поставок и управление зависимостями

Этот элемент управления поддерживает непрерывную практику SDL 5. Защита цепочки поставок программного обеспечения.

Этот элемент управления фокусируется на защите цепочки поставок разработки с помощью средств и платформ анализа композиции программного обеспечения (SCA), таких как Secure Supply Chain Consumption Framework (S2C2F). Эти процессы помогают снизить риск компрометации с помощью кода, отличного от Майкрософт.

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

Сбой управления цепочкой поставок программного обеспечения предоставляет значительные уязвимости, представленные кодом, который вы не контролируете. Известный пример — уязвимость log4J/Log4Shell, которая позволила удаленному выполнению кода в любой системе или приложении с помощью этого пакета. Такие уязвимости могут возникать случайно или злонамеренно.

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

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

Стандартный — анализ всех уязвимостей OSS и автоматическое исправление их с помощью автоматических запросов на вытягивание. Этот элемент управления также можно достичь с помощью Dependabot и графа GitHub Dependency graph/review.

Высокая безопасность — активно блокируют все небезопасные пакеты с уязвимостями, которые используются в приложении.

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

Проверка кода безопасности

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

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

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

Временный минимум — этот элемент управления рекомендуется для этого профиля.

Стандартный — этот элемент управления рекомендуется использовать для этого профиля.

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

Проверка учетных данных и секретов

Этот элемент управления поддерживает непрерывную практику SDL 7— выполнение тестирования безопасности.

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

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

Если требуется использование секретов, необходимо защитить их через весь жизненный цикл, включая их создание, использование, регулярное поворот и отзыв. Избегайте непосредственного использования секретов в коде и храните их только в защищенной системе хранения ключей и секретов, таких как Azure Key Vault или аппаратный модуль безопасности (HSM). При каких-либо обстоятельствах обычные текстовые ключи и секреты никогда не хранятся в коде, даже временно! Злоумышленники будут находить и использовать эти секреты.

Внимание

Внутренние репозитории исходного кода небезопасны!

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

Стандарт - Хорошая секретная гигиена является важной и требуется во всех профилях.

Примечание.

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

Дополнительные сведения и ресурсы включают:

Примечание.

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

Безопасный конвейер

Этот элемент управления поддерживает непрерывную практику SDL 5. Защита цепочки поставок программного обеспечения.

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

Конвейеры являются важной частью автоматизации основных повторяемых действий в жизненном цикле DevSecOps. В CI/CD команда объединяет код разработчика в центральную базу кода в обычном расписании и автоматически выполняет стандартные сборки и тестовые процессы, включая наборы инструментов безопасности.

Использование конвейеров для запуска скриптов или развертывания кода в рабочих средах может привести к уникальным проблемам безопасности. Убедитесь, что конвейеры CI/CD не становятся способами запуска вредоносного кода, разрешают кражу учетных данных или предоставляют злоумышленникам любую область для доступа. Кроме того, необходимо убедиться, что развертывается только код, который ваша команда намерена выпустить. Этот процесс включает артефакты конвейеров CI/CD, особенно артефакты, совместно используемые между различными задачами, которые могут использоваться в рамках атаки.

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

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

Примечание.

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

Стандартный — этот элемент управления должен оцениваться на уровне доступа к каждому ресурсу проекта. Это обязательный элемент управления на всех уровнях профилей DevSecOps.

Дополнительные сведения о безопасности конвейера см. в статье "Защита Azure Pipelines".

Защита операций

Тестирование на проникновение веб-сайтов в режиме реального времени

Этот элемент управления поддерживает непрерывную практику SDL 7— выполнение тестирования безопасности.

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

Мы рекомендуем выполнить это тестирование на всех уровнях профилей безопасности DevSecOps.

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

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

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

Интеграция результатов и отзывов этих действий для улучшения процессов и средств безопасности.

Элементы управления доступом к удостоверениям и приложениям

Этот элемент управления поддерживает непрерывную практику SDL 8. Обеспечение безопасности операционной платформы и практики 6 — обеспечение безопасности среды разработки.

Убедитесь, что рекомендации по обеспечению безопасности для управления удостоверениями и доступом, включая обеспечение привилегированного доступа , применяются ко всем техническим элементам среды разработки, конвейеру CI/CD, операционной рабочей нагрузке и другим системам разработки. Субъекты угроз имеют сложные методы и автоматизацию для атак удостоверений, которые они часто используют как в производственных системах, так и в процессах разработки. Управление удостоверениями и доступом является основой модели "Нулевое доверие", рекомендуемой корпорацией Майкрософт.

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

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

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

Высокая безопасность— реализация полной стратегии нулевого доверия, которая включает MFA, обнаружение угроз идентификации и реагирование, а также управление правами облачной инфраструктуры (CIEM). Выполните модель угроз, зависящей от рабочей нагрузки, системы идентификации и компоненты, поддерживающие каждую рабочую нагрузку с высокой безопасностью.

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

Дополнительные сведения и ресурсы включают:

Элементы управления узлами, контейнерами и средой

Этот элемент управления поддерживает непрерывную практику SDL 8. Обеспечение безопасности операционной платформы и практики 6 — обеспечение безопасности среды разработки.

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

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

  • Общие ИТ-рабочие станции и операционные рабочие станции и среды
  • Выделенные рабочие станции разработки и среды
  • Инфраструктура конвейера CI/CD
  • Среды размещения рабочей нагрузки
  • Любые другие системы разработки.

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

  • Узлы и виртуальные машины виртуальной машины
  • Контейнеры и инфраструктура контейнеров
  • Платформы размещения приложений, скриптов и кода
  • Облачные подписки, учетные записи и регистрации
  • Рабочие станции разработчика, пользователя и ИТ-Администратор

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

Временный минимум — применение стандартных корпоративных конфигураций для узлов и подписок.

Стандарт . Убедитесь, что инфраструктура соответствует рекомендациям по обеспечению безопасности, описанным в Microsoft Cloud Security Benchmark (MCSB).

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

Дополнительные сведения и ресурсы включают:

Средства контроля сетевого доступа

Этот элемент управления поддерживает непрерывную практику SDL 8. Обеспечение безопасности операционной платформы и практики 6 — обеспечение безопасности среды разработки.

Убедитесь, что рекомендации по обеспечению безопасности для управления доступом к сети выполняются для всех технических элементов среды разработки, конвейера CI/CD, рабочей рабочей нагрузки и других систем разработки. Субъекты угроз имеют сложные методы и автоматизацию для атак удостоверений, которые они часто используют как в производственных системах, так и в процессах разработки. Безопасность сети является основой модели нулевого доверия, которую корпорация Майкрософт рекомендует.

Сетевая безопасность должна включать:

  • Защита внешней сети — изоляция от незапрошенного внешнего или интернет-трафика и устранения известных типов атак. Эта изоляция обычно принимает форму брандмауэра Интернета, брандмауэра веб-приложения (WAF) и решений безопасности API.
  • Внутренняя защита сети — изоляция от незапрошенного внутреннего трафика (из других сетевых расположений предприятия). Эта изоляция может использовать аналогичные элементы управления как защиту внешней сети и может быть детализирована для рабочей нагрузки или для определенных отдельных компонентов и IP-адресов.
  • Устранение рисков типа "отказ в обслуживании" — защита от атак распределенного типа "отказ в обслуживании" (DDoS) и других атак типа "отказ в обслуживании".
  • Пограничный сервер безопасности (SSE) — использование микросегментации на стороне клиента для обеспечения безопасного доступа непосредственно к ресурсам, включая применение политик нулевого доверия.

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

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

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

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

Дополнительные сведения и ресурсы включают:

Мониторинг, реагирование и восстановление

Этот элемент управления поддерживает непрерывную практику SDL 9. Реализация мониторинга безопасности и реагирования.

Убедитесь, что команды по обеспечению безопасности (SecOps/SOC) имеют процедуры видимости, обнаружения угроз и реагирования на рабочие нагрузки (API и приложения), а также инфраструктуру, в которую они размещаются. Убедитесь, что меж командные процессы и средства между SecOps и командами инфраструктуры и рабочей нагрузки обеспечивают быстрое восстановление после атаки.

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

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

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

Временный минимум — развертывание возможностей XDR в среде для мониторинга трафика устройств конечных пользователей.

Стандартный — развертывание XDR и пользовательских обнаружения SIEM, которые определяют аномальное поведение относительно общей среды. Этот профиль может включать пользовательские обнаружения для отдельных рабочих нагрузок.

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

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

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

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

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