DevSecOps Series: Shifting Security Left

"Running a DevSecOps program as well as what some of the (hard) lessons I learned through the years."

Давно в этом канале не было статей из разряда "классика" - как должен выглядеть процесс DevSecOps, из чего он состоит и кто в этом должен участвовать - "DevSecOps Series: Shifting Security Left".

#dev #ops

Kubernetes Overview Diagrams

Небольшой сборник диаграмм в помощь тем, кто начинает разбираться в Kubernetes. Диаграммы есть к архитектуре, workload's, network, storage, resource requests and limits и на картинке вы в частности видите RBAC.

#k8s #ops

Threat Modelling & Supply-Chain (Part 3: Security Controls)

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

Следующее, что нам нужно сделать - определить меры безопасности (security controls). Здесь два варианта - начать указывать их на каждом процессе или потоке данных в рамках схемы, либо выписать отдельной табличкой напротив каждой нашей угрозы (чтобы убедиться, что мы закрываемся от всего, что сами для себя определили). Говоря более предметно, давайте вернемся к supply chain атакам. В частности возьмем за основу упоминаемый ранее фреймворк SLSA и рассмотрим угрозу компрометации CI/CD системы.

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

Вот примеры реализации hardening'а для разных решений CI/CD систем:
- Security Practices in GitLab
- Managing Security of Jenkins
- Securing Jenkins CI Systems
- Security hardening for GitHub Actions
- TeamCity Security Notes (лучше всего на мой взгляд сделано здесь)
- CircleCI Security

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

Рассматривая компрометацию системы хранения кода (Gitlab/Bitbucket) и артефактов (Nexus Repo, Artifactory) формируем требования безопасности по аналогии из тех же доменов.

Если мы говорим про supply chain атаки, то помимо компрометации самих систем, участвующих в процессе разработки, отдельное внимание надо уделить угрозе нарушения целостности перемещаемых активов, а именно коду и артефактов. Здесь я советую снова обратиться к SLSA-фреймворку.

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

Обратите внимание, что при отсутствии проверки целостности и прохождения дополнительной аутентификации между системами сборки, хранения кода и артефактов нам необязательно получать полный доступ над системами. Например, достаточно указать неверные входные значения (сторонний git-репозиторий) в качестве параметров сборки, либо опубликовать артефакт в Artifactory вручную через CLI минуя security-проверки в рамках централизованного процесса сборки. Ещё один пример - изменить скрипт развёртывания так, чтобы установить вредоносный дистрибутив в прод вместо проверенного security-сканерами.

В помощь сюда приходят проекты вроде Notary или Sigstore. Кто-то реализует это посредством подписи SBOM на всех этапах разработки, кто-то ограничивается тэгированием артефактов без возможности перезаписи разработчиком. Неплохим требованием безопасности будет обязательный merge-approval для всех бизнесовых репозиториев, чтобы избежать нарушения целостности master/release ветки при компрометации УЗ разработчика.

#dev #ops #threatmodeling

ZeroNights 2021

Выложили записи и слайды с Zero Nights 2021. Самое интересное для этого канала находится в секции Defensive Track.

- О метриках с практической точки зрения - доклад про метрики (в частности про те, что были приведены в HP MagicNumbers), а также немного про OWASP SAMM и ASVS.
- Побег из контейнера: Kubernetes - доклад, где название говорит само за себя от автора @k8security. Доклад начинается с вводной части о работе k8s, после чего приводятся способы побега из контейнера через capabilities, маунты и CVE (есть очень много полезных ссылок).
- CVEhound: проверка исходников Linux на известные CVE - доклад про проблемы инструментов SCA и поиск CVE в Linux с помощью CVEhound.
- DevSecOps на Open Source: бурление в стакане - про построение классического процесса на базе gosec, trufflehog, defectdojo, semgrep и т.д. Автор также поделился пайплайнами gitlab в public.
- Атаки на микросервисные приложения: методы и и практические советы - доклад про то, на что надо обращать внимание с точки зрения безопасности, когда речь заходит о микросервисах (как проверять безопасность аутентификации, авторизации, какими инструментами, где брать чеклисты).
- Лезем невидимой рукой аппсека в релизные сборки - доклад про поиск уязвимостей в мобилках и написание своей тулы CheckKarlMarx.

Все слайды можно найти здесь.

#talks #dev #ops

Kubernetes Security Checklist and Requirements

В канале было много того, что касается безопасности ванильного Kubernetes, но, когда дело доходит до составления перечня требований или чеклиста для аудита, так или иначе приходится тратить время для сведения всего этого воедино. Чтобы упростить эту задачу мы зарелизили собственный чек-лист безопасности k8s: Kubernetes Security Checklist and Requirements 🎉

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

Кстати, есть также версия на русском.

#k8s #ops

Common Threat Matrix for CI/CD Pipeline

В рамках доклада “Attacking and Securing CI/CD Pipeline” на конференции CODE BLUE 2021 Opentalks вышла матрица угроз MITRE ATT&CK для CI/CD: Threat Matrix for CI/CD Pipeline. Частично она переиспользует идеи, предложенные SLSA, расширяя перечень потенциальных угроз и мер безопасности. Про многое я писал в серии постов по моделированию угроз CI/CD [1,2,3] и возможности извлечения секретов из CI.

Очень понравился перечень мер безопасности, который сильно пересекается с тем, что прорабатывал я в рамках аналогичной активности (но не успел пока выложить в открытый доступ). Не стоит забывать, что создание модели угроз и требований ИБ для таких широких процессов, как сборка и деплой - это всегда про кастомизацию. Кому-то будет важно ограничить прямой доступ к CD, отделив процесс отдельной системой (например, AWX, для которого есть свой набор security практик) и закрыв PAM'ом. Для кого-то верификация сигнатур в CI/CD может быть очень дорогим процессом и они ограничиваются проставлением метатэгов на уровне централизованного репозитория артефактов. Сама по себе мера "Hardening CI/CD pipeline servers" может завезти вереницу проверок и возможных "переключателей" (пример вариации настроек).

#ops

Практика управления безопасностью ПО в масштабных продуктах

Доклад от CISO Тинькофф об угрозах, присущих платформам разработки (куда также относятся CI/CD системы). В число угроз попали:
- Уже многим известный Dependency Confussion
- Использование одних и тех же ключей для всех сборок и деплоев
- Повышение привилегий через shared раннеры (в т.ч. привилегированный DinD)
- Внесение изменений в код за счет отсутствия правил approve/review
- Использование небезопасных сторонних библиотек
- Публикация внутренних API во внешнюю среду через единый ingress
- Открытие полного доступа в Интернет для закрытых ресурсов

#dev #ops #attack

Vulnerability subsprition

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

Вариант #1 - подписаться на CVE

Есть множество сервисов, где это можно сделать. Один из них - opencve.io. Сервис абсолютно бесплатный, можно подписаться на определенного вендора или продукт с отбивками на почту. Достаточно удобно, но наблюдаются задержки в 1-2 дня.

Вариант #2 - узнавать о новых уязвимостях от первоисточника.

Информация о важных обновлениях, решающих вопросы безопасности, может содержаться в еженедельных отчетах вендоров через их официальные страницы (как, например, страница релизов на примере Gitlab). Здесь мы имеем очевидную проблему c отсутствием унификации поступающей информации. В случае, если продукт open source и он находится на Github или Gitlab, то здесь у нас есть возможность отслеживать уязвимости через страницу Issues. Так, например, чтобы узнавать раньше всех о найденных уязвимостей Kubernetes, надежнее всего подписаться на label kind/bug (в сочетании с triage/accepted) через desktop client (как описано в этом топике).

Вариант #3 - воспользоваться агрегатором

Другой вариант - воспользоваться сервисами вроде Vulners. Vulners, помимо возможности отслеживания CVE, предоставляет язык запросов, на результаты которого можно подписываться. Например, запрос affectedSoftware.name:"nginx" OR affectedPackage.packageName:"nginx" OR cpe:nginx order:published выдаст агрегированную информацию обо всех уязвимостях, связанных с nginx.

В заключение хочу поделиться также интересным ресурсом - cvetrends.com, который собирает информацию о "хайповых" CVE из twitter.

#dev #ops

CIS Software Supply Chain Security Guide

Вот это пушка, конечно, вышла. Набор требований безопасности CIS с разбивкой на код, сборку, зависимости, артефакты и деплоймент.

#dev #ops #cicd