Поделиться через

Безопасность DevOps

Безопасность DevOps интегрирует методики безопасности на протяжении всего жизненного цикла разработки программного обеспечения (SDLC) от первоначального проектирования и написания кода с помощью сборки, тестирования и развертывания в рабочей среде. В отличие от традиционных подходов к безопасности, которые рассматривают безопасность как окончательный шлюз, devOps security внедряет элементы управления безопасностью, автоматизированное тестирование и непрерывный мониторинг на каждом этапе конвейера разработки. Этот подход признает, что современная доставка программного обеспечения зависит от сложных конвейеров CI/CD, сторонних зависимостей, инфраструктуры как кода и автоматизированных развертываний, которые вводят потенциальные векторы атак, которые злоумышленники активно эксплуатируют. Применяя принципы нулевого доверия (предполагая нарушение, явно проверяйте) и многоуровневые стратегии защиты, безопасность DevOps гарантирует, что код, зависимости, конфигурации инфраструктуры и процессы конвейера остаются надежными и защищёнными от подделки от проектирования до производственной среды. Без комплексной безопасности DevOps организации сталкиваются с критическими рисками, включая атаки на цепочки поставок, утечку учетных данных в конвейерах, внедрение вредоносного кода, уязвимые образы контейнеров и несанкционированные изменения инфраструктуры, которые могут устанавливать постоянные бэкдоры, влияющие на всех конечных потребителей.

Ниже приведены три основных компонента домена безопасности DevOps Security.

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

Связанные элементы управления:

Перенос контроля безопасности влево: Перенос контроля безопасности на ранние этапы путем интеграции SAST, сканирования секретов, сканирования IaC и DAST в конвейер CI/CD. Централизовать управление секретами (например, Key Vault), ограничить полномочия на изменение конвейера и непрерывно сканировать и защищать артефакты (например, образы контейнеров и виртуальных машин) перед развертыванием.

Связанные элементы управления:

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

Связанные элементы управления:

DS-1. Моделирование угроз

Принцип безопасности

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

Риск для смягчения

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

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

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

MITRE ATT&CK

  • Первоначальный доступ (TA0001): эксплойт открытого приложения (T1190) использует недостатки архитектуры при проверке подлинности, управлении сеансами или проверке входных данных, которые будут определять моделирование угроз.
  • Повышение привилегий (TA0004): механизм управления повышением прав (T1548) использует недостаточное разделение привилегий или отсутствие проверок авторизации в системной архитектуре.
  • Обход средств защиты (TA0005): подрыв защитных механизмов (T1562) путем использования отсутствия журналов аудита, пробелов в мониторинге или умышленно ограниченной телеметрии безопасности, встроенной в систему.

DS-1.1. Реализация моделирования угроз на основе STRIDE

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

Реализуйте следующий структурированный подход для создания моделирования угроз:

  • Установление систематической методологии STRIDE: Создайте систематическое моделирование угроз как обязательную деятельность на этапе проектирования, используя методологию STRIDE (спуфинг, подмена, отказ от ответственности, раскрытие информации, отказ в обслуживании, повышение привилегий). Начните с создания схем потоков данных (DFD), которые сопоставляют системные компоненты, потоки данных, границы доверия и внешние зависимости. Для каждого компонента и потока данных следует систематически оценивать потенциальные угрозы во всех шести категориях STRIDE, приоритизировать риски, исходя из вероятности и воздействия, и документировать конкретные меры для их устранения перед началом разработки.

  • Используйте структурированные средства моделирования угроз: Используйте структурированные средства моделирования угроз, такие как средство моделирования угроз Майкрософт , для обеспечения согласованности и использования предварительно созданных шаблонов архитектуры (веб-приложения, API, микрослужбы, решения Интернета вещей). Это средство упрощает создание DFD, автоматическую идентификацию угроз на основе типов компонентов и потоков данных, а также создает рекомендации по устранению рисков с соответствующими элементами управления безопасностью. Храните модели угроз в виде версионированных артефактов в системе контроля версий вместе с документацией по архитектуре.

  • Интеграция с рабочими процессами разработки: Интеграция выходных данных моделирования угроз непосредственно в рабочие процессы разработки путем экспорта определенных угроз в рабочие элементы Azure DevOps с четким владением, приоритетом и критериями принятия. Реализуйте шлюзы рецензирования архитектуры, которые требуют завершенных моделей угроз перед утверждением проектирования, и настройте проверки pull request, которые инициируют рецензии моделей угроз при обнаружении изменений в архитектуре. Это гарантирует, что анализ угроз остается синхронизированным с развитием системы на протяжении всего жизненного цикла разработки.

DS-1.2. Автоматизация интеграции анализа угроз

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

Внедрите данные возможности автоматизации и расширения:

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

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

Автоматическая реализация анализа угроз:

  • Оценка на основе анкеты: Стандартизованные анкеты безопасности, интегрированные в шаблоны Azure DevOps для согласованной идентификации угроз
  • Программа чемпионов безопасности: Назначенные чемпионы по безопасности в каждой команде разработчиков, обученные по упрощению моделирования угроз
  • Автоматизация проверки архитектуры: Автоматическая проверка pull-реквестов для обновлений схемы архитектуры, которые требуют проведения проверки модели угроз
  • Модель угроз в виде кода: Определения модели угроз, контролируемые версиями, с помощью структурированных форматов (JSON/YAML) для автоматического анализа

Пример реализации

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

Вызов: Архитектура микрослужб с многочисленными API, развернутыми без проверки безопасности. Командам разработчиков не хватает опыта в области безопасности для выявления угроз. Проблемы безопасности архитектуры обнаружены только после рабочих инцидентов.

Подход к решению:

  • Моделирование угроз STRIDE:Реализовано средство моделирования угроз Майкрософт для всех микрослужб и конечных точек API с диаграммами потоков данных, показывающими архитектуру и потоки конфиденциальных данных.
  • Программа чемпионов безопасности: Обученные фасилитаторы по моделированию угроз в каждой команде разработчиков, которые позволяют встроить безопасность в проектирование без создания узких мест в центральной команде безопасности.
  • Автоматическая интеграция рабочих процессов: Интегрированные проверки модели угроз в рабочие процессы Azure DevOps для pull-запросов с обязательным утверждением безопасности при внесении архитектурных изменений.

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

Уровень критическости

Должно быть.

Сопоставление элементов управления

  • NIST SP 800-53 ред.5: SA-11, SA-15, PL-8, RA-3, RA-5
  • PCI-DSS версии 4: 6.3.1, 6.3.2, 12.3.1
  • Элементы управления CIS версии 8.1: 14.2, 14.3
  • NIST CSF версии 2.0: ID.RA-3, PR. IP-2
  • ISO 27001:2022: A.5.12, A.8.25
  • SOC 2: CC3.2, CC7.1

DS-2. Защита цепочки поставок программного обеспечения

Принцип безопасности

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

Риск для смягчения

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

  • Вредоносные зависимости: Злоумышленники внедряют бэкдоры в популярные библиотеки с открытым исходным кодом (атаки в стиле SolarWinds) или создают пакеты с опечатками в названиях, которые выполняют вредоносный код во время установки или времени выполнения.
  • Уязвимые сторонние библиотеки: Известные CVE в зависимостях (уязвимости Log4Shell, Heartbleed, Struts) остаются неисправленными в течение нескольких недель или месяцев из-за отсутствия видимости и автоматического управления уязвимостями.
  • Скомпрометированные артефакты сборки: Злоумышленники вмешиваются в скомпилированные двоичные файлы, образы контейнеров или пакеты развертывания во время хранения или транспортировки, внедряя вредоносные программы, которые обходят проверку исходного кода.
  • Атаки с путаницей зависимостей: Вредоносные субъекты отправляют пакеты в общедоступные репозитории с именами, соответствующими внутренним частным пакетам, используя логику разрешения диспетчера пакетов для замены вредоносного кода.
  • Риски транзитивной зависимости: Уязвимости в косвенных зависимостях (зависимости зависимостей) остаются невидимыми без глубокого анализа дерева зависимостей и создания SBOM.
  • Отсутствие проверки происхождения: Отсутствие криптографической проверки ведет к атакам подмены пакетов, где законные пакеты заменяются вредоносными версиями.

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

MITRE ATT&CK

  • Первоначальный доступ (TA0001): компрометация цепочки поставок (T1195.001) путем компрометации зависимостей программного обеспечения и средств разработки для получения первоначального доступа в целевые среды, а также эксплуатация доверительных отношений (T1199) между организациями и сторонними поставщиками программного обеспечения для доставки вредоносных обновлений.
  • Выполнение (TA0002): интерпретатор команд и сценариев (T1059), исполняющий вредоносный код, встроенный в скрипты установки зависимостей или постустановочные хуки.
  • Сохраняемость (TA0003): компрометация двоичного файла клиентского программного обеспечения (T1554) путем внедрения черных ходов в скомпилированные библиотеки, которые сохраняются после обновлений приложений.

DS-2.1. Реализация проверки зависимостей и управления

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

Создайте безопасность непрерывной зависимости с помощью этих основных возможностей:

  • Установите комплексную видимость и формирование SBOM: Установите непрерывное управление безопасностью зависимостей с тремя основными возможностями: комплексной видимостью, автоматизированным обнаружением уязвимостей и превентивным устранением. Начните с создания полных инвентаризаций зависимостей для сопоставления как прямых зависимостей (явно объявленных в манифестах пакетов), так и транзитивных зависимостей (зависимостей зависимостей) во всех репозиториях. Поддерживать список материалов программного обеспечения (SBOM) в стандартных отраслевых форматах (SPDX, CycloneDX) для соблюдения нормативных требований и готовности к реагированию на инциденты.

  • Реализуйте автоматическое сканирование уязвимостей и исправление: Реализуйте автоматическое сканирование уязвимостей, которое постоянно отслеживает зависимости от национальной базы данных уязвимостей (NVD), консультативной базы данных GitHub и помощников по безопасности на определенных языках. Настройте оповещения в режиме реального времени при обнаружении новых CVEs, влияющих на стек ваших зависимостей, направляя сообщения на основе уровня важности в соответствующие команды. Включите возможности автоматического обновления безопасности, которые создают пулл-реквесты с обновлениями версий зависимостей. Это включает в себя тестирование на совместимость и интеллектуальное разрешение конфликтов слияния, что снижает нагрузку ручного исправления.

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

  • Расширьте видимость рабочих сред: Расширьте видимость за пределами исходного кода в развернутых средах с помощью таких средств, как Microsoft Defender для Cloud DevOps Security , чтобы сопоставить зависимости кода с запущенными рабочими нагрузками, определить пути атаки через цепочки зависимостей и определить приоритет исправления на основе фактического воздействия рабочей среды, а не теоретических рисков. Такие инструменты, как GitHub Advanced Security , обеспечивают комплексную визуализацию графа зависимостей, автоматизированные обновления на основе Dependabot и поддержку пользовательских шаблонов уязвимостей для частных экосистем пакетов.

Пример реализации

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

Вызов: Тысячи зависимостей в сотнях репозиториев без видимости уязвимостей или вредоносных пакетов. Проверки зависимостей вручную занимали недели на каждое приложение. Аудит нормативных органов определил критические пробелы в цепочке поставок.

Подход к решению:

  • Автоматическое управление уязвимостями: Включена расширенная безопасность GitHub с помощью сканирования зависимостей Dependabot и автоматического создания запросов на вытягивание для обновлений безопасности.
  • Прозрачность цепочки поставок: Реализовано средство Microsoft SBOM, создающее список компонентов программного обеспечения в формате SPDX для соответствия нормативным требованиям и реагирования на инциденты.
  • Проверка пакета: Артефакты Azure настроены с функцией проверки подписи и закрепления зависимостей, предотвращающими атаки путаницы и несанкционированную подстановку пакетов.
  • Мониторинг безопасности DevOps:Развернута Microsoft Defender для безопасности Cloud DevOps для прослеживания кода до облака.

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

Уровень критическости

Должно быть.

Сопоставление элементов управления

  • NIST SP 800-53 ред.5: SR-3, SR-4, SR-6, SA-12, SA-15(9), RA-5
  • PCI-DSS версии 4: 6.2.4, 6.3.2, 6.3.3
  • Элементы управления CIS версии 8.1: 16.1, 16.2, 16.11
  • NIST CSF версии 2.0: ID.SC-2, ID.SC-4, DE. CM-8
  • ISO 27001:2022: A.5.19, A.5.22, A.5.23
  • SOC 2: CC3.2, CC8.1

DS-3. Защита инфраструктуры DevOps

Принцип безопасности

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

Риск для смягчения

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

  • Скомпрометированные конвейеры CI/CD: Злоумышленники получают доступ к конвейерам сборки с помощью украденных учетных данных, эксплойта уязвимостей или внутреннего доступа, позволяя внедрять код, изменять артефакты или манипулировать развертыванием, что влияет на всех нижестоящих потребителей.
  • Открытые секреты в журналах сборки и артефактах: Хардкодированные учетные данные, ключи API, сертификаты и строки подключения утекают через журналы потоков, сообщения об ошибках или скомпилированные артефакты, предоставляя злоумышленникам прямой доступ к рабочим средам.
  • Неавторизованные изменения конвейера: Отсутствие рабочих процессов управления изменениями и утверждения позволяет злоумышленникам изменять определения конвейеров, внедрять действия вредоносной сборки или изменять конфигурации развертывания без обнаружения.
  • Недостаточно элементов управления доступом: Чрезмерно широкие назначения ролей и отсутствие разделения обязанностей позволяют горизонтальное перемещение, эскалацию привилегий и постоянное установление доступа в инфраструктуре DevOps.
  • Небезопасные агенты сборки: Неподключенные, неправильно настроенные или скомпрометированные агенты сборки предоставляют злоумышленникам постоянный доступ к среде сборки и потенциальным точкам сводных точек в рабочих сетях.
  • Отсутствующие следы аудита: Неадекватное ведение журнала и мониторинг действий DevOps предотвращает обнаружение несанкционированного доступа, подозрительных изменений или внутренних угроз.

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

MITRE ATT&CK

  • Первоначальный доступ (TA0001): допустимые учетные записи (T1078) с использованием украденных учетных данных или секретов сервисного принципала для доступа к платформам и сборочным линиям DevOps.
  • Сохраняемость (TA0003): обработка учетных записей (T1098) создает субъекты-службы backdoor, личные маркеры доступа или ключи SSH для поддерживаемого доступа.
  • Доступ к учетным данным (TA0006): незащищенные учетные данные (T1552.001) извлечение секретных данных из переменных окружения, файлов конфигурации или журналов конвейера.
  • Defense Evasion (TA0005): нарушение защитных мер (T1562) отключает шаги сканирования безопасности, ведение журнала аудита или шлюзы утверждения в определениях конвейеров.

DS-3.1. Реализация управления секретами для пайплайнов

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

Настройте управление секретами с помощью этих элементов управления безопасностью:

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

  • Настройте динамическое извлечение секрета с помощью управляемых удостоверений: Реализуйте централизованное хранилище секретов с помощью таких решений, как Azure Key Vault , которые предоставляют зашифрованное хранилище секретов, детализированные политики доступа, автоматическую смену секретов и комплексное ведение журнала аудита. Настройте конвейеры для динамического извлечения секретов во время выполнения через безопасные подключения служб вместо их внедрения в определения конвейеров. Используйте управляемые удостоверения или федерацию удостоверений рабочей нагрузки для проверки подлинности доступа конвейера к хранилищам секретов, устраняя необходимость в длительных учетных данных субъекта-службы, которые сами становятся целевыми объектами кражи.

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

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

Пример реализации

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

Вызов: Строки подключения к базе данных и ключи API, закодированные в переменных конвейера. Чрезмерно допустимые разрешения конвейера позволили любому разработчику развернуть в рабочей среде. Компрометация агента сборки обеспечивает постоянный доступ к инфраструктуре.

Подход к решению:

  • Централизованное управление секретами: Реализована интеграция Azure Key Vault , устраняющая жестко закодированные секреты из конвейеров. Настроена аутентификация управляемых удостоверений, что устраняет риск обнародования учетных данных.
  • Элементы управления доступом к конвейеру: Установлены шлюзы утверждения и разрешения для конкретной среды с использованием Azure DevOps Environments, требующие утверждения команды безопасности для производственных развертываний.
  • Защищенные агенты сборки: Развернутые автономные агенты с обеспечением безопасности и сетевой изоляцией для конфиденциальных рабочих нагрузок, обрабатывающих регулируемые данные.
  • Проверка безопасности инфраструктуры: Встроенная проверка безопасности для шаблонов ARM и конфигураций Terraform, предотвращающая неправильное развертывание.

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

Уровень критическости

Должно быть.

Сопоставление элементов управления

  • NIST SP 800-53 ред.5: AC-2, AC-3, AC-6, SC-12, SC-13, AU-2, AU-6
  • PCI-DSS версии 4: 8.3.2, 8.6.1, 8.6.3, 12.3.3
  • Элементы управления CIS версии 8.1: 4.1, 4.7 , 6.1, 6.5
  • NIST CSF версии 2.0: PR. AC-4, PR. DS-5, DE. CM-7
  • ISO 27001:2022: A.5.15, A.5.16, A.8.3
  • SOC 2: CC6.1, CC6.6, CC6.7

DS-4. Интеграция статического тестирования безопасности приложений (SAST)

Принцип безопасности

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

Риск для смягчения

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

  • Уязвимости внедрения: Внедрение SQL, межсайтовое скриптирование (XSS), внедрение команд и недостатки внедрения LDAP позволяют злоумышленникам управлять логикой приложения, извлекать конфиденциальные данные или выполнять произвольный код.
  • Жестко закодированные учетные данные: Разработчики непреднамеренно фиксируют пароли, ключи API, сертификаты и строки подключения к репозиториям исходного кода, предоставляя злоумышленникам прямой доступ к рабочим системам и данным.
  • Небезопасные реализации криптографики: Слабые алгоритмы шифрования (DES, MD5), жестко закодированные ключи шифрования, неправильные векторы инициализации или недостаточно длины ключей компрометируют конфиденциальность и целостность данных.
  • Переполнение буфера и повреждение памяти: Небезопасные операции с памятью в приложениях C/C++ обеспечивают произвольное выполнение кода, эскалацию привилегий и атаки типа "отказ в обслуживании".
  • Недостатки бизнес-логики: Обход проверки подлинности, пробелы авторизации, условия гонки и недостаточная проверка входных данных ведут к повышению привилегий, мошенничеству и несанкционированному доступу.
  • Неправильно настроенные конфигурации инфраструктуры как кода (IaC): Небезопасные манифесты Terraform, шаблоны ARM или Kubernetes развертывают уязвимую инфраструктуру с чрезмерно неизрешимым доступом, отсутствием шифрования или общедоступными конечными точками управления.

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

MITRE ATT&CK

  • Первоначальный доступ (TA0001): эксплойт общедоступного приложения (T1190) с использованием уязвимостей внедрения или проверки подлинности в коде приложения.
  • Выполнение (TA0002): эксплуатация для выполнения клиента (T1203) с использованием уязвимостей на стороне клиента, таких как XSS или небезопасная десериализация.
  • Доступ к учетным данным (TA0006): учетные данные из хранилищ паролей (T1555), извлечение вшитых учетных данных из исходного кода, файлов конфигурации или скомпилированных двоичных файлов.
  • Эскалация привилегий (TA0004): эксплуатация для эскалации привилегий (T1068), использующая переполнение буфера или ошибки памяти для повышения уровня доступа.

DS-4.1. Реализация конвейера SAST с несколькими сканерами

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

Реализуйте автоматическое тестирование безопасности с помощью следующих компонентов:

  • Реализуйте многоуровневую стратегию сканирования: Внедрите автоматизированное статическое тестирование безопасности приложений в каждую сборку для того чтобы обнаруживать уязвимости до того, как код достигнет продакшена. Реализуйте многоуровневую стратегию SAST, которая объединяет несколько специализированных сканеров, так как ни один инструмент не обнаруживает все классы уязвимостей. Для комплексного покрытия требуются анализаторы для конкретных языков программирования (Python, JavaScript, C/C++), сканеры инфраструктуры как кода (Terraform, шаблоны ARM, манифесты Kubernetes), средства обнаружения секретов и семантический анализ кода для сложных уязвимостей потока данных.

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

  • Развертывание сканирования секретов с защитой при отправке: Реализуйте специализированное сканирование секретов с защитой при отправке, которая предотвращает коммиты учетных данных, ключей API, сертификатов или токенов в репозитории, перехватывая секреты во время коммита, а не обнаруживая их при аудиторских проверках неделями позже. Поддерживают стандартные шаблоны секретов (ключи AWS, маркеры Azure, строки подключения к базе данных) и пользовательские шаблоны для собственных механизмов проверки подлинности. При обнаружении секретов предоставьте немедленное руководство по исправлению, включая процедуры смены учетных данных и безопасные альтернативные варианты.

  • Используйте анализ семантического кода для сложных уязвимостей: Разверните средства анализа семантического кода, такие как GitHub CodeQL , которые выполняют глубокий анализ потока данных, чтобы определить сложные уязвимости, невидимые для сканеров сопоставления шаблонов, например внедрение SQL с помощью нескольких вызовов функций, проверку подлинности в бизнес-логике или небезопасные цепочки десериализации. Создайте настраиваемые запросы безопасности, адаптированные к платформам организации, требованиям безопасности и общим шаблонам уязвимостей, выявленным в ретроспективах инцидентов. Интегрируйте результаты SAST непосредственно в рабочие процессы разработчиков с помощью комментариев к запросам на внесение изменений, включая конкретные номера строк, объяснения уязвимостей и рекомендации по их устранению.

  • Оркестрация с унифицированными платформами: Унифицированные платформы SAST, такие как Расширение Microsoft Security DevOps, могут управлять несколькими специализированными сканерами (Антивредоносное ПО, Bandit, BinSkim, Checkov, ESLint, Анализатор шаблонов, Terrascan, Trivy) через одну задачу конвейера, стандартизируя управление конфигурацией и агрегацию результатов в разнородных экосистемах инструментов.

Пример реализации

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

Вызов: Проверки кода вручную поймали лишь небольшую часть уязвимостей. Разработчикам не хватает обучения безопасности для выявления недостатков внедрения и криптографических слабых мест. Автоматическое сканирование перед развертыванием в рабочей среде не выполняется.

Подход к решению:

  • САСТ с несколькими сканерами: Развернутое расширение Microsoft Security DevOps с помощью CodeQL, ESLint и Bandit, предоставляющее комплексное покрытие на разных языках и типах уязвимостей.
  • Защита секретов: Реализована система GitHub Advanced Security с проверкой секретов и защитой при отправке, предотвращающей утечку учетных данных в коммитах.
  • Семантический анализ: Настроен GitHub CodeQL с настраиваемыми запросами для уязвимостей бизнес-логики и шаблонов безопасности для конкретной платформы.
  • Шлюзы безопасности: Установленные шлюзы конвейера в Azure Pipelines блокируют развертывание результатов высокой серьезности.

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

Уровень критическости

Должно быть.

Сопоставление элементов управления

  • NIST SP 800-53 ред.5: SA-11, RA-5, SI-2
  • PCI-DSS версии 4: 6.3.2, 6.4.1, 11.3.1
  • Элементы управления CIS версии 8.1: 16.3, 16.6
  • NIST CSF версии 2.0: PR.IP-2, DE.CM-4
  • ISO 27001:2022: A.8.25, A.8.29
  • SOC 2: CC7.1, CC7.2

DS-5. Интеграция динамического тестирования безопасности приложений (DAST)

Принцип безопасности

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

Риск для смягчения

Уязвимости среды выполнения, невидимые для статического анализа, создают критические пробелы в безопасности, которые злоумышленники эксплуатируют после развертывания приложений. Без проведения комплексного динамического тестирования безопасности приложений (DAST):

  • Недостатки конфигурации развертывания: Неправильно настроенные поставщики проверки подлинности, слишком разрешительный CORS, слабые конфигурации TLS или отсутствующие заголовки безопасности (CSP, HSTS, X-Frame-Options) позволяют осуществлять атаки, которые невозможно выявить при анализе исходного кода.
  • Пробелы в безопасности API: REST и GraphQL API с обходом проверки подлинности, ошибками авторизации, избыточной утечкой данных, отсутствием ограничения количества запросов или незащищёнными прямыми ссылками на объекты (IDOR) разрешают несанкционированный доступ и извлечение данных.
  • Обход проверки подлинности и авторизации: Недостатки в управлении сеансами, потоках сброса паролей, реализации многофакторной проверки подлинности или логике управления доступом на основе ролей позволяют повышение привилегий и захват учетной записи.
  • Уязвимости управления сеансами: Прогнозируемые токены сеанса, недостаточный контроль времени ожидания, уязвимости фиксации сеанса или отсутствие отзыва токенов позволяют перехват сеансов и кражу учетных данных.
  • Проблемы безопасности для конкретной среды: Точки интеграции с базами данных, очередями сообщений, внешними API или сторонними службами представляют уязвимости среды выполнения, невидимые при разработке или изолированном тестировании.
  • Недостатки бизнес-логики: Условия гонки, уязвимости манипулирования состоянием, недостаточное количество входных данных в сложных рабочих процессах или проблемы целостности транзакций позволяют манипулировать мошенничеством и данными.

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

MITRE ATT&CK

  • Первоначальный доступ (TA0001): эксплуатация общедоступного приложения (T1190) с использованием обходов аутентификации, уязвимостей внедрения или небезопасных конечных точек API, обнаруженных с помощью тестирования в среде выполнения.
  • Доступ к учетным данным (TA0006): принудительное применение метода подбора (T1110) с отсутствием ограничения скорости, слабых политик паролей или прогнозируемых маркеров сеанса, обнаруженных во время DAST.
  • Эскалация привилегий (TA0004): допустимые учетные записи (T1078) используют обход авторизации или уязвимости манипуляции ролями в развернутых приложениях.
  • Коллекция (TA0009): данные из информационных хранилищ (T1213), извлечение конфиденциальной информации через чрезмерные ответы API, обход каталогов или уязвимости небезопасной ссылки на объект.
  • Эксфильтрация (TA0010): эксфильтрация через веб-сервис (T1567), эксплуатируя уязвимости безопасности API для масштабного извлечения данных без обнаружения.

DS-5.1. Реализация автоматизированного DAST в предрелизной среде

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

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

  • Дополните SAST проверкой среды выполнения: Дополните статический анализ динамическим тестированием безопасности приложений, которое проверяет безопасность в запущенных приложениях с рабочими конфигурациями. Хотя SAST идентифицирует уязвимости в исходном коде, DAST обнаруживает проблемы среды выполнения, невидимые для статического анализа: слабые места конфигурации развертывания (неправильно настроенные поставщики проверки подлинности, недопустимые политики CORS, отсутствующие заголовки безопасности), проблемы интеграции с конкретной средой (безопасность подключения к базе данных, авторизация API в развернутых контекстах) и уязвимости бизнес-логики, которые проявляются только в реальных условиях работы.

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

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

  • Сосредоточьтесь на высокорисковых поверхностях атаки: Фокусируйте специализированные усилия DAST на высокорисковых поверхностях атаки: REST и GraphQL API (обходы аутентификации, ошибки авторизации, уязвимости внедрения, чрезмерное раскрытие данных, небезопасные прямые ссылки на объекты), управление аутентификацией и сеансами (проверка безопасности маркеров, принудительное применение времени ожидания, функции выхода, процессы сброса пароля, многофакторная аутентификация) и рабочие процессы бизнес-логики (проверка на условия гонки, манипуляции состоянием, проблемы целостности транзакций). Установите рабочие процессы корреляции SAST/DAST, которые объединяют результаты обоих подходов, приоритетизируя уязвимости, подтвержденные как статическим, так и динамическим анализом как самый высокий риск.

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

Пример реализации

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

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

Подход к решению:

  • Автоматическое сканирование DAST: OWASP ZAP развернут в предшествующих производству средах для тестирования развернутых приложений с конфигурацией, похожей на производственную.
  • Защита среды выполнения контейнера: Реализован Microsoft Defender для контейнеров для мониторинга безопасности и оценки уязвимостей во время выполнения.
  • Тестирование безопасности API: Настроено специализированное тестирование API проверки подлинности, авторизации и проверки данных в развернутых конечных точках REST и GraphQL.
  • Корреляция SAST/DAST: Созданные рабочие процессы корреляции уязвимостей, объединяющие статические и динамические результаты для комплексной проверки безопасности.

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

Уровень критическости

Должно быть.

Сопоставление элементов управления

  • NIST SP 800-53 ред.5: SA-11, CA-8, RA-5
  • PCI-DSS версии 4: 6.4.2, 11.3.2
  • Элементы управления CIS версии 8.1: 16.7, 16.8
  • NIST CSF версии 2.0: DE.CM-4, PR.IP-12
  • ISO 27001:2022: A.8.29, A.8.30
  • SOC 2: CC7.1, CC7.3

DS-6. Защита жизненного цикла рабочей нагрузки

Политика Azure: См. встроенные определения политик Azure: DS-6.

Принцип безопасности

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

Риск для смягчения

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

  • Уязвимые образы рабочих виртуальных машин: Необновлённые базовые образы ОС или неправильно сконфигурированные золотые образы распространяют уязвимости на всех развернутых виртуальных машинах.
  • Непатченные уязвимые базовые образы: Контейнеры, созданные на базе, подверженной уязвимостям CVE (Log4Shell, Heartbleed, OpenSSL), подвергают рабочие нагрузки эксплуатации и уничтожению.
  • Устаревшие уязвимые артефакты: Изображения и пакеты остаются непросканированными, что приводит к накоплению CVEs, увеличивая поверхность атаки.
  • Недостаточная проверка изображений: Отсутствие криптографической подписи и проверки подлинности позволяет злоумышленникам заменять законные образы скомпрометированными версиями, содержащими бэкдоры или вредоносное ПО.
  • Чрезмерная поверхность атаки: Образы контейнеров, содержащие ненужные пакеты, средства разработки или отладочные утилиты, повышают уязвимость и предоставляют злоумышленникам дополнительные инструменты для эксплуатации.
  • Отсутствующие базовые показатели безопасности: Образы виртуальных машин и контейнеров, развернутые без соответствия требованиям CIS, укрепления безопасности или конфигурации минимальных привилегий, создают пробелы, которые могут быть использованы для атаки в защите в глубину.

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

MITRE ATT&CK

  • Первоначальный доступ (TA0001): эксплойт открытого приложения (T1190) с использованием неотпатшированных уязвимостей в контейнерах приложений или веб-службах.
  • Выполнение (TA0002): развертывание контейнера (T1610) для развертывания вредоносных контейнеров, которые отображаются законными из-за нехватки проверки образа.
  • Эскалация привилегий (TA0004): переход на хост (T1611) с использованием уязвимостей контейнера для выхода из изоляции контейнера и компрометации хост-системы.
  • Боковое перемещение (TA0008): эксплуатация удаленных служб (T1210) с перемещением через уязвимые виртуальные машины или контейнеры, развернутые из скомпрометированных образов.

DS-6.1. Внедрение безопасности образа контейнера

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

Защитите артефакты рабочей нагрузки, используя следующие практики:

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

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

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

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

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

  • Используйте интегрированные платформы безопасности: Решения, такие как Реестр контейнеров Azure с интеграцией Microsoft Defender для контейнеров , обеспечивают автоматическое сканирование, рабочие процессы карантина, доверие к содержимому и репликацию с несколькими регионами с согласованными политиками безопасности.

Пример реализации

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

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

Подход к решению:

  • Безопасность реестра контейнеров: Реализован реестр контейнеров Azure с проверкой уязвимостей, которая включает сканирование и карантин образов с высокими по серьезности CVEs перед развертыванием.
  • Защищенные образы виртуальных машин: Развернута Общая галерея изображений Azure с образами виртуальных машин, совместимыми с CIS, для регулируемых рабочих нагрузок.
  • Защита среды выполнения: Настроен Microsoft Defender для контейнеров для непрерывного обнаружения угроз и мониторинга смещения.
  • Целостность артефактов: Установлено криптографическое подписывание и проверка, обеспечивающие подлинность изображений на всем протяжении жизненного цикла.

Результат: Заблокированы уязвимые образы из рабочего развертывания. Резко сократилось количество уязвимостей контейнера (CVE) в каждом образе. Предотвращены атаки подмены изображений с помощью проверки подписи.

Уровень критическости

Должно быть.

Сопоставление элементов управления

  • NIST SP 800-53 ред.5: CM-2, CM-3, SI-2, SI-7, RA-5
  • PCI-DSS версии 4: 6.2.4, 6.3.3, 11.3.1
  • Элементы управления CIS версии 8.1: 4.1, 7.3, 7.4
  • NIST CSF редакция 2.0: PR.IP-1, PR.IP-3, DE.CM-8
  • ISO 27001:2022: A.8.9, A.8.31, A.8.32
  • SOC 2: CC7.2, CC8.1

DS-7. Реализация ведения журнала и мониторинга DevOps

Принцип безопасности

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

Риск для смягчения

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

  • Необнаруженные компрометации конвейера: Злоумышленники изменяют конвейеры CI/CD, чтобы внедрить вредоносный код, эксфильтровать секреты или установить бэкдоры, не вызывая срабатывания оповещений из-за отсутствия или недостаточности журналирования аудита.
  • Внутренние угрозы, изменяющие код или инфраструктуру: Злоумышленники или скомпрометированные учетные записи вносят несанкционированные изменения в исходный код, определения инфраструктуры или конфигурации развертывания без обнаружения.
  • Отсутствие комплексных следов аудита: Недостаток подробных журналов действий мешает проведению судебной экспертизы, оценке воздействия и анализу первопричин при возникновении инцидентов безопасности, что увеличивает время пребывания угроз и усиливает последствия нарушения.
  • Отложенный ответ на инциденты: Среднее время обнаружения (MTTD) расширяется от часов до недель, когда команды безопасности не имеют оповещений в режиме реального времени, обнаружения аномалий и автоматической корреляции событий безопасности DevOps.
  • Сбои аудита соответствия: Нормативные требования (SOX, PCI-DSS, HIPAA, ISO 27001) для комплексного аудита, отслеживания изменений и ведения журнала доступа не могут быть выполнены без централизованного мониторинга DevOps.
  • Слепота эскалации привилегий: Несанкционированное повышение прав доступа, создание учетных записей с черным ходом или изменение элементов управления доступом остается незамеченным без анализа поведения и мониторинга привилегий.

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

MITRE ATT&CK

  • Defense Evasion (TA0005): нарушение защиты (T1562) путем отключения ведения журналов аудита, проверок безопасности или агентов мониторинга для работы в слепых зонах и очистка индикаторов (T1070), в том числе очистка журналов аудита или истории выполнения конвейера для сокрытия вредоносной активности.
  • Сохраняемость (TA0003): обработка учетных записей (T1098) создает дополнительные субъекты-службы, личные маркеры доступа или ключи SSH без обнаружения.
  • Коллекция (TA0009): данные из репозиториев информации (T1213), эксфильтрующие исходный код, секреты или интеллектуальную собственность через доступ к конвейеру.
  • Доступ к учетным данным (TA0006): сбор незащищенных учетных данных (T1552) и извлечение открытых секретов из журналов конвейера или журнала выполнения.

DS-7.1. Реализация ведения журнала аудита для платформ DevOps

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

Создайте комплексный мониторинг безопасности DevOps с помощью следующих возможностей:

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

  • Переадресация журналов в централизованный SIEM в режиме реального времени: Перенаправляйте журналы аудита в режиме реального времени на централизованные платформы SIEM, а не на использование собственного хранения платформы DevOps (обычно 90 дней), что позволяет выполнять долгосрочный судебно-медицинский анализ, отчеты о соответствии требованиям и корреляцию с событиями безопасности из других систем. Потоковая передача журналов в центры управления безопасностью через стандартные протоколы (Event Hubs Azure, системный журнал) в структурированных форматах (JSON), которые позволяют автоматически делать разбор, анализ и оповещение без необходимости ручной проверки журналов.

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

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

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

  • Использование интегрированных платформ SIEM: Платформы, такие как потоковая передача аудита Azure DevOps с интеграцией Microsoft Sentinel, предоставляют перенаправление журналов в режиме реального времени, предварительно созданные правила обнаружения угроз DevOps, рабочие книги безопасности для расследования и автоматизацию оркестрации ответов.

Пример реализации

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

Проблема: Нет централизованного ведения журнала действий DevOps. Изменения в проводке и изменения в привилегированном доступе остались без контроля. Судебно-медицинское расследование оказалось затруднено из-за отсутствия журналов аудита. Сбой аудита соответствия требованиям из-за недостаточного отслеживания изменений.

Подход к решению:

  • Централизованное ведение журнала аудита: Включена передача событий аудита Azure DevOps в Microsoft Sentinel для анализа безопасности и долговременного хранения.
  • Аналитика поведения: Реализовано обнаружение аномалий, выявляющее необычные шаблоны доступа, изменения потока данных вне рабочего времени и эскалации привилегий, указывающие на внутренние угрозы.
  • Автоматическое оповещение: Настроенные оповещения для подозрительных действий, включая несанкционированные развертывания в рабочей среде и маршрутизацию создания учетных данных сервисного объекта в центры безопасности.
  • Отчеты о соответствии: Создано автоматическое создание тропы аудита, удовлетворяющее нормативным требованиям с комплексным отслеживанием изменений.

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

Уровень критическости

Следовало бы.

Сопоставление элементов управления

  • NIST SP 800-53 ред.5: AU-2, AU-3, AU-6, AU-12, SI-4
  • PCI-DSS версии 4: 10.2.1, 10.2.2, 10.3.4
  • Элементы управления CIS версии 8.1: 8.2 , 8.5, 8.11
  • NIST CSF версии 2.0: DE.CM-1, DE.CM-7, RS.AN-1
  • ISO 27001:2022: A.8.15, A.8.16
  • SOC 2: CC7.2, CC7.3
  • Last updated on