Статья "PodSecurityPolicy Deprecation: Past, Present, and Future".

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

Краткая выжимка:
- PodSecurityPolicy (PSP) перейдет в статус deprecated в версии 1.21
- Alpha релиз замены должен состояться в версии 1.22
-Старая версия будет удалена скорее всего в версии 1.25
- Разрабатывается замена для покрытия ключевых потребностей
- Изменения связанные с PSP никаким образом не повлияют на PodSecurityContext
- Основная причина отказа от текущей реализации – не удобство в использовании
- K-Rail, Kyverno и OPA/Gatekeeper это хорошо, но надо иметь простую, гибкую и встроенную реализацию
- За разработкой замены можно следить в Kubernetes Enhancement Proposal (KEP 2579)

Kubernetes Pentest: Methodology, Kubesploit and other resources.

Сегодня на очереди небольшая подборка статей и инструментов на тему пентеста Kuberentes для offensive-команд.

Серия статей от CyberARK о методологии тестирования Kubernetes от 2019 года:
- Kubernetes Pentest Methodology Part 1
- Kubernetes Pentest Methodology Part 2
- Kubernetes Pentest Methodology Part 3

А еще не так давно команда CyberARK выпустила инструмент Kubesploit для тестирования на проникновение среды Kubernetes. Поддерживает следующие возможности для тестирования:
- Выход за пределы контейнера с помощью маунтинга, docker.sock, эксплоита CVE-2019-5736;
- Поиск известных CVE кластера Kubernetes;
- Сканирование портов, относящихся к сервисам Kubernetes;
- Сканирование контейнеров на предмет RCE и доступных токенов сервис-аккаунтов за счет встроенного легковесного инструмента kubeletctl.

От этой же команды есть также инструмент KubiScan для аудита небезопасных ролей. В продолжении к этой же теме вот небольшая подборка инструментов, которая, правда, включает далеко не все (в частности здесь нет CDK). Больше про атаки можно найти по хэштегу #attack.

Для тех, кто пропустил, в конце марта Microsoft обновила свою Threat Matrix for Kubernetes. Обязательно советую к ознакомлению.

#ops #k8s

Security Chaos Engineering, Gaining Confidence in Resilience and Safety at Speed and Scale

Давно ждал эту книгу от Verica и рад, что она есть в открытом доступе. В книге описано подробно про Chaos Engineering в разрезе безопасности с примерами тестов. Прошлый пост с другими материалами по данной теме можно почитать здесь.

#ops #literature

Security Chaos Engineering: How to Security Differently

Интересно, что вместе с этой книгой Verica опубликовали статью "Security Chaos Engineering: How to Security Differently", где описали культуру, которая должна главенствовать в организации, чтобы эффективно внедрить соответствующие подходы. Основная идея заключается в концепции перехода от Safety I к Safety II, то есть от наказаний и пристального внимания за "негативными событиями" (баги, ошибки, события журналов) к совместному сотрудничеству с командами для развития способностей, которые помогают поддерживать системы в безопасном состоянии - "положительные события" (способности реагировать, отслеживать, изучать и предвидеть ошибки).

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

#dev #ops

Redefining Threat Modeling: Security team goes on vacation

Статья от компании Segment о том, что такое Threat Modeling и как они сделали так, чтобы разработчики сами его выполняли. Данную активность они назвали символично "Utopia". Сам по себе процесс участия безопасников в данном случае они сделали опциональным. Также команда Segment поделилась опытом обучения разработчиков моделированию угроз, включая презентации.

Данную идею я, кстати, встречаю не в первый раз. В качестве примера можно почитать "Appsec Development: Keeping it all together at scale" об опыте в Snowflake.

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

#threatmodeling

Uncomplicate Security for developers using Reference Architectures

Продолжение вчерашней темы о том, как сократить трудозатраты специалистов безопасности за счет самостоятельности разработчиков. В этот раз речь пойдет об "эталонной архитектуре" (reference architecture) - что это такое, какой она должна быть и какие существуют подводные камни. На картинке, в частности, пример такой "эталонной архитектуры".

Uncomplicate Security for developers using Reference Architectures

#dev #ops

Generating Kubernetes Network Policies By Sniffing Network Traffic

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

Идея, кстати, не новая. До этого, как правило, с задачей справлялся advisor вроде Inspektor Gadget.

#ops #k8s

CIS Red Hat OpenShift Container Platform 4 Benchamark (and RHCOS)

Как показывает статистика поста с OpenShift Security Guide, очень много здесь тех, у кого есть OpenShift, и тех, кто интересуется вопросами его безопасности. Как многие, наверное, знают, классический CIS, как и инструменты контроля соответствия CIS, не применимы к OpenShift из коробки. В частности отличается набор мер по закрытию требований в силу специфики работы системы. С этой целью Red Hat разработали отдельно Compliance Operator, который осуществляет набор проверок на базе собственного чек-листа. Тем не менее сам чек-лист отдельно не публикуется.

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

Прикладываю:
- Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4

Здесь же есть профили со следующими проверками:
- Red Hat Enterprise Linux CoreOS 4
- Red Hat Enterprise Linux 8
- Red Hat Enterprise OpenStack Platform 13 / 10
- Ubuntu 18.04 / 16.04 / 20.04
- Suse Linux Enterprise 12 / 15
- Debian 9 / 10
- CentOS 7 / 8
и еще много разного полезного.

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

#ops #k8s

Authorizing Microservice APIs With OPA and Kuma

До этого я писал про OPA только в контексте контроля запросов на API кластера с целью их ограничения. В этот раз предлагаю ознакомиться с материалом по применению OPA как способ микросервисной авторизации для реализации Zero Trust Network.

Authorizing Microservice APIs With OPA and Kuma

В данном случае речь именно об интеграции с service mesh Kuma, но это также может быть и Istio. Каждый раз, когда поступает новый внешний запрос, Kuma отправляет запрос авторизации на OPA. В статье также упоминается Styra DAS как инструмент централизованного управления политиками OPA.

Если вам интересно узнать чуть больше про Kuma и Zero Trust, то вот небольшая статья. У разработчиков Kuma есть также демо интеграции enterpise версии service mesh Kong Mesh с OPA.

#opa #ops #k8s

Анонсы в мире безопасности разработки.

Последний год наполнен всевозможными онлайн и оффлайн мероприятиями на тему безопасности разработки / DevSecOps / SSDLC и безопасности контейнеров. По факту чаще всего ивент уходит в пресейл и поверхностную теорию. Однако сегодня мы взглянем на предстоящие мероприятия от проверенных организаторов.

- ZeroNight 2021, 30 июня, Севкабель Порт, Санкт-Петербург, Международная конференция по информационной безопасности. До 15 мая еще открыт CFP по докладам безопасности разработки. Программный комитет как всегда лучший.

- Positive Hack Days, 20-21 мая,
Центр Международной Торговли, Москва, Международная конференция по информационной безопасности. Еще можно зарегистрироваться на трек по безопасности разработки. С докладами уже можно познакомиться по ссылке.

- DevSecOps. Динамический анализ приложений. 25 мая, 15:00-17:00. Вебинар. Неоднократно упоминал на канале автора вебинара и своего наставника Юрия. Тема IAST,DAST,BAST мобилок и веба.

#events #talks

Rusty Hog - secret scanner in a Google doc, S3, Git, Confluence and Jira

Rusty Hog - простенький инструмент, написанный на Rust, для поиска секретов в Google документах, S3, Git, Confluence и Jira. Под капотом TruffleHog. Также поддерживает кастомные регулярные выражения.

#secret #dev

Argo's Threat Model

Trail of Bit выпустили отчет об аудите в связке с моделью угроз для ArgoCD.

Всего по итогу аудита было обнаружено 35 issues (3 medium,16 low, 16 info). Уязвимости с наибольшим уровнем критичности:

16. The zJWT auth tokens allow for denial of service in Argo CD (Severity: Medium, Difficulty: Low)
17. Non-cryptographically secure random function documented as CSPRNG (Severity: Medium, Difficulty: High)
35. Packages with security vulnerabilities in Argo-CD and Argo WorkflowsUI (Severity: Medium, Difficulty: Low)

По итогам проведения моделирования угроз было обнаружено 21 issues (10 medium, 1 info, 8 low, 1 Undetermined, 1 high ). Уязвимости с наибольшим уровнем критичности и наименьшей сложностью эксплуатации):

6. Lack of authentication rate limiting (Severity: Medium, Difficulty: Low)
10. Insufficient default network access controls between pods (Severity: High, Difficulty: High)
11. Lack of authentication rate limiting ( Severity: Medium, Difficulty: Low)
12. API does not require authentication by default (Severity: Medium, Difficulty: Low)
15. TLS is not enabled by default (Severity: Medium, Difficulty: Low)
20. Undocumented potential race condition in Event Bus (Severity: Medium, Difficulty: Low)

В отчете также прилагается описание мер по повышению безопасности инфраструктуры по итогам проведения аудита. Меры делятся на краткосрочные и долгосрочные. Также описана методология тестирования и используемые инструменты (Semgrep, gosec, CodeQL, errcheck).

#ops #k8s #attack

Still Dependency Confusion. Defending Against Software Supply Chain Attacks

На тему атаки Dependency Confusion продолжают выходить статьи и инструменты.

В частности ребята из Salesforce выпустили инструмент DazedAndConfused для проверки Cocoapods, composer, gems, gradle и не только.

Вышла даже статья по реализации атаки в Game Development на Unity (потому что NPM). На тему устранения уязвимости в NPM вот. Если вы используете Bundler для работы с зависимостями в Ruby, то для вас также есть статья.

На тему Supply Chain последнее время пишут достаточно часто. В частности CISA выпустила методичку "Defending Against Software Supply Chain Attacks" по защите от атак на цепочку поставок. В ней есть упоминание множества полезных практик NIST - NIST SP 800-161 (April 2015), NISTIR 8276 (February 2021), SSDF (April, 2020)

#dev #sca #attack

Nuclei and DevSecOps

Если вы сидите в чатиках, посвященных пентестам / уязвимостям веба, то наверняка могли слышать про инструмент Nuclei. Nuclei позиционируется как быстрый сканер уязвимостей в вебе, в котором можно определять шаблоны отправки запросов на базе yaml. Похожий подход используется, как мы знаем, современными SAST (Checkmarx, CodeQL, semgrep). Также, как и в CodeQL, предполагается, что эти же заполненные шаблоны могут быть переданы исследователями безопасности в рамках Bug Bounty. В дальнейшем Nuclei вместе со всеми шаблонами встраивается в CI/CD. У инструмента также есть отдельное репо с готовыми шаблонами на разные случаи жизни (от фаззинга до IoT).

Прилагаю также дополнительный полезный материал на тему Nuclei:

- Exploiting Race conditions with Nuclei

- How to Scan Continuously with Nuclei?

- Nuclei - Fuzz all the things

#dev #ops #attack #dast

Jenkins attack framework

Инструмент для тестирования безопасности Jenkins от Accenture - jenkins-attack-framework. Инструмент работет как white box и требует URL сервера и агента, username, password или API-токен. Среди атак попытка просмотра и запуска джоб и скриптов, дамп кредов, загрузка файлов.

Есть также сопровождающая статья:
- Red teaming Jenkins with the Jenkins Attack Framework

#dev #ops #attack

Infrastructure-as-code security tool compare

Сравнение инструментов для анализа конфигурационных файлов IaC: Checkov, Indeni Cloudrail, Kics, Snyk, Terrascan, Tfsec. В качестве тестовой выборки был взят Terraform для AWS. Каждый test-case можно увидеть в репо. Полезно также будет для понимания типовых ошибок.

#terraform #iac #sast #dev #ops

Detecting Malicious Activity in CI/CD Pipeline with Tracee and Codecov story.

Aqua Security показали один из примеров, как можно использовать относительно новый инструмент Tracee. Напоминаю, что Tracee - это утилита, которая помогает собирать информацию об активности приложения, которое развернуто на сервере с Tracee, в режиме runtime на основе технологии eBPF (по аналогии с тем, как работают движки Container Runtime в современных средствах защиты класса CSP).

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

Сам автор поста заявляет, что данный механизм защиты может помочь предотвратить индицент аналогичный тому, что произошел с Codecov в апреле 2021 года, когда злоумышленники подменили скрипт Bash Uploader, используемый в Codecov-actions для Github, Codecov CircleCl Orb и Codecov Bitrise Step. Злоумышленнику удалось воспользоваться ошибкой в используемом Codecov процессе создания образа Docker, позволившей ему извлечь учетные данные, необходимые для внесения изменений в скрипт Bash Uploader (наглядный пример supply chain атаки).

Ненавистники сигнатур занегодуют, но стоит признать, что сам по себе подход имеет право на существование.

Помимо анализа работы ПО, используемого в CI/CD на наличие аномалий, важно не забывать про механизмы защиты самого процесса CI/CD: MFA, хранение секретов, изоляция окружений, сетевая безопасность и многое другое. Этой теме в будущем будут посвящены отдельные посты.

#attack #dev #ops

Terraform Plan “RCE”

Небольшая статья о реализации "Remote Code Execution" (RCE) злоумышленником при работе с terraform plan. Это особенно актуально, если вы проверяет таким образом PR перед merge в прод бранч.

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

В статье есть раздел по митигации риска.

#terraform #attack #dev #ops