Telegram Web
OPA instead of PSP

Большинство, кажется, уже в курсе, что PSP в Kubernetes перейдет в статус deprecated в версии 1.21, а альфа-релиз замены появится только в 1.22, но тем не менее проблема будущего встроенного policy движка все еще стоит на повестке. Один из вариантов - Open Policy Agent (OPA) Gatekeeper.

Недавно в чат вкинули репо с правилами для OPA, которые можно взять за основу, чтобы полностью заменить PSP. Спасибо @Uburro!

#ops #k8s #ops
RESTler - first stateful REST API fuzzing tool

RESTler - инструмент от Microsoft, принимающий в качестве входных значений OpenAPI/Swagger спецификацию, а на выходе формирующий набор тестов, направленных на повышение безопасности. Сам же инструмент выполняет и фаззинг. Пока что среди багов находит утечку ресурсов, неавторизованный доступ, наличие ошибок (500), use-after-free, доступность дочерних ресурсов не из родительских.

#fuzzing #dev
Изучаем уязвимости в сервисах поставки кода

Увидел тут в Античате вырезку из журнала "Хакер" - "Опасная разработка. Изучаем уязвимости в сервисах поставки кода". Рассматриваются уязвимости и мисконфигурации таких продуктов как Jira, Confluence, Asana, GitLab, TeamCity и нескольких других.

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

#attack
Forwarded from CloudSec Wine
🔸Building an end-to-end Kubernetes-based DevSecOps software factory on AWS

"DevSecOps software factory implementation can significantly vary depending on the application, infrastructure, architecture, and the services and tools used. In a previous post, I provided an end-to-end DevSecOps pipeline for a three-tier web application deployed with AWS Elastic Beanstalk. The pipeline used cloud-native services along with a few open-source security tools. This solution is similar, but instead uses a containers-based approach with additional security analysis stages. It defines a software factory using Kubernetes along with necessary AWS Cloud-native services and open-source third-party tools. Code is provided in the GitHub repo to build this DevSecOps software factory, including the integration code for third-party scanning tools."

https://aws.amazon.com/ru/blogs/devops/building-an-end-to-end-kubernetes-based-devsecops-software-factory-on-aws/

#aws
Managing SSH Access at Scale with HashiCorp Vault

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

В результате интеграции Vault предоставляет механизм управления ключами совместно с политиками (порядок того, кто куда имеет доступ) и аудитом. Теперь вместо долгосрочных ключей используются кратковременные сертификаты с помощью SSH CA хранилища, которые можно создать в несколько экземпляров для различных сред (dev, stage, prod, infra).

Managing SSH Access at Scale with HashiCorp Vault

#vault #ops
Light-weighted API Firewall by Wallarm

Wallarm выложили на Github свой легковесный вариант API Firewall. Это реверс-прокси, написанный на Go, который валидирует запросы и ответы для OpenAPI v3. Поддерживается инсталляция через Helm.

Примеры:
- API Firewall demo with Docker Compose
- Protecting Kubernetes Application

Hot-to guide:
- Securing REST with free API Firewall.

#waf #ops
NCC_Group_Google_GOIST2005_Report_2020-08-06_v1.1 .pdf
849.7 KB
Announcing the results of Istio’s first security assessment

Команда Istio выпустила результаты аудита безопасности их продукта версии 1.6.5, который проводился NCC Group в прошлом году. К отчету идет сопутствующая статья, где поясняется, откуда взялись те или иные Security Best Practices.

#ops #attack #report #k8s
Forwarded from CloudSec Wine (Артем Марков)
🔶🔷🔴 Mapping of On-Premises Security Controls Versus Services Offered by Major Cloud Providers

By the link below you can find the fifth version of a diagram that started in March 2017, with just AWS and Azure versus On-Premises. The diagram began as an effort to make a translation between the typical on-premises security controls that everybody, more or less, knows what they do and the various services advertised by major public cloud providers. As the cloud providers tend to assign catchy names to products that quite often transcend the initial functionality of the on-prem control, it becomes harder and harder to stay up-to-date on what service does what.

https://www.managedsentinel.com/mapping-of-on-premises-security-controls-versus-services-offered-by-major-cloud-providers/

#aws #azure #gcp
Kubernetes Overview Diagrams

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

#k8s #ops
Threat Modelling & Supply-Chain (Part 1: Assets)

Безопасность разработки стала весьма широким доменом в плане охватываемых проблемных зон и инструментов. За последние полгода в одну из решаемых задач попала митигация рисков, связанных с атаками на цепочку поставок (supply-chain attack). Для тех, кто следит за новостями, сразу вспоминаются атаки на SolarWinds (хотя в реальности примеров подобных атак значительно больше). Тем не менее, как связать примеры подобных атак с собственной инфраструктурой и цепочкой поставок не всегда очевидно (чем активно пользуются производители решений SCA).

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

Активами могут стать код, зависимости и итоговый артефакт, то есть те компоненты, которые участвуют в цепочке поставок. Также в качестве активов нередко рассматривают сами системы, которые участвуют в процессе сборки артефактов и их развертывания (CI и CD системы).

Раскидывая все процессы разработки на схеме (мне нравится обычный draw.io с плагином dfd) мы имеем архитектуру нашего сборочного конвейера совместно с этапом раскатки. Детализация схемы зависит от вашего погружения вместе с DevOps командами. Модель угроз можно декомпозировать вплоть до всех компонентов Kubernetes. Чтобы точно убедиться, что мы ничего не пропустили, мы можем расписать процессы отдельно:

CI Master:
- Вызов сборки
- Конфигурация сборки
- Получение секретов git из встроенного хранилища секретов
- ....

К каждому процессу подписываются защищаемыми нами активы:

A01: секреты git
A02: код бизнес-приложения
A03: итоговый артефакт
A04: зависимость
...

Совместно с определением процессов и активов рекомендуется определить так называемые доверенные зоны (trusted zones). Они помогают определить логические границы, за которых ответственны те или иные администраторы систем, а также поверхности атаки злоумышленника в случае, если он окажется внутри инфраструктуры.

#threatmodeling #dev #ops #talks
Threat Modelling & Supply-Chain (Part 2: Threats & Threat Actors)

Следующим этапом определим пользователей наших процессов. Эти же пользователи будут нашими потенциальными нарушителями (threat actors). Рассматривая атаки на цепочки поставок это могут быть внутренние нарушители (разработчики, администраторы CI и CD систем, администраторы кластера, сопровождение ОС и так далее) и внешние (пользователь, который может повилять на общедоступные репозитории).Также на этом этапе мы понимаем, где еще могут использоваться наши защищаемые активы (секреты и код на рабочих станциях).

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

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

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

В следующих постах мы поговорим про приоритизацию угроз и формирование требований ИБ по результатам модели угроз. Если вы уже хотите попрактиковаться, то можете почитать пример моделирования угроз для облачного приложения в AWS с использованием STRIDE. Хорошим материалом является также Threat Modeling Training от компании Segment, где есть простые и понятные слайды по всем этапам моделирования угроз.

#threatmodeling #dev #ops #talks
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
Jenkins secrets quiz

Сегодня мы сделаем небольшой квиз. У команды разработки есть Jenkins, используемый для сборки. Jenkins в свою очередь необходимы секреты для получения доступа к сторонним prod-системам (разработчики используют плагин сredentials-binding). Разработчики самостоятельно пишут groovy-скрипты в Jenkins с выданными правами на запись и запуск согласно матрице доступов. Безопасно ли это?

Ответ будет завтра.

#dev #ops #talks
Jenkins secrets extraction

Возвращаемся к нашему квизу, который вызвал бурные обсуждения в чате. 59% человек посчитало, что схема является безопасной с точки зрения управления секретами. Как итог они оказались неправы. Дело в том, что упомянутый плагин сredentials-binding может позволить разработчикам извлечь секреты даже если секреты используются во внешнем хранилище Vault. Но дело даже не в плагине, а в самой возможности разработчика влиять на конфигурацию сборки, ведь с тем же успехом можно извлечь секреты напрямую из $JENKINS_HOME/credentials.xml и $JENKINS_HOME/secrets воспользовавшись hudson.util.Secret.decrypt или сторонними инструментами.

Так как разработчик имеет доступ к конфигурации сборки и ее запуску в Jenkins, то помимо извлечения секретов может быть поднят reverse shell или вызван DoS всего сборочного конвейера. Все зависит от сетевых доступов и прав на агенте сборки.

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

#dev #ops #talks #attack
2025/07/09 19:13:11
Back to Top
HTML Embed Code: