Building an IaC security and governance program step-by-step

Небольшая статья от Bridgecrew о выстраивании политики безопасности IaC - разница в подходах CI/CD и VCS, что из этого выбрать и какими вопросами стоит задаться.

Bridgecrew являются авторами open source утилиты Checkov для проверки IaC на безопасность. Статью про инструмент можно прочитать здесь. Также есть удобная документация. Если вы еще не видели, то в более ранних постах можно найти сравнение инструментов сканирования IaC.

#iac #ops

Exploring Rootless Docker and User Namespaces

Небольшая статья еще от того года про тестирование rootless docker (экспериментальной фичи Docker 20.10), где автор пробует различные стандартные ситуации.

Возможность создавать rootless-контейнеры базируется на user namespaces. В конце того года вышли сразу две крутые статьи про это.

Improving Kubernetes and container security with user namespaces. Что такое user namespaces, как это спасает от известной CVE-2019-5736, какие на текущий момент есть сложности и как это в теории может работать в Kubernetes.

Evolving Container Security With Linux User Namespaces. О применение user namespaces в Netflix в их системе оркестрации Titus.

P.S. Про rootless-контейнеры я также писал здесь.

#ops #k8s #docker

The Power of Kubernetes RBAC

В конце того года я писал про опасность глаголов escalate и list при организации RBAC в Kubernetes. Тем не менее я не написал про bind, который имеет точно такой же эффект как и escalate. То есть, если пользователь или SA обладают правами на bind, то абсолютно неважно, какие глаголы еще выставлены у его роли в RBAC, ведь он может запросто изменить свою роль на cluster-admin. Про эффект bind можно прочитать в отдельной статье. Стоит это учитывать при написании RBAC, либо их аудите.

К теме RBAC хочется также упомянуть статью "The Power of Kubernetes RBAC LIST". Проблему с неявными полномочиями также можно встретить в GKE при выставлении прав container.secrets.list. Тут все еще страшнее, так как данные права есть в популярных IAM ролях Kubernetes Engine Developer и Kubernetes Engine Admin. Это в свою очередь позволяет пользователям получить доступ к секретам и завладеть ролью cluster-admin. Авторы в данном случае советуют руководствоваться правилом "один GKE на один проект" и использовать RBAC вместо IAM, чтобы распределять роли команды в рамках неймспейсов, а не назначать права на весь кластер. А еще в статье упоминается утилита, которая поможет выводить перечень конкретных прав для IAM в GCP.

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

#k8s #ops #gcp

Вчера в одном из чатов @ttffdd вбросил методичку по тестированию на проникновения k8s. Документ не новый, но напомнил мне тот, что я кидал по Docker, на основе которого я составлял репо Pentest-in-Docker. Информация хорошо структурирована, есть готовые скрипты и запросы к API, чтобы не тащить с собой kubectl.

Вообще для меня было когда-то приятной новостью увидеть страницу OWASP Kubernetes Security Testing Guide, на которой OWASP заявляли о своем желании выпустить подобную методологию. Однако релиз так и не произошел. Зато у них есть страница Kubernetes Security Cheat Sheet с хорошими реферансами в конце.

#attack #k8s #ops

OWASP Devsecops Maturity Model

Когда речь заходит о модели оценки зрелости (или в принципе некотором наборе лучших практик) почти всегда вспоминают BSIMM и OWASP SAMM, но оказывается у OWASP есть еще одна модель оценки зрелости - OWASP Devsecops Maturity Model (OWASP DSOMM). Более того, DSOMM и SAMM отлично сосуществуют вместе в рамках единого процесса. Это связано с тем, что цель DSOMM - определить конкретные активности для организации процесса безопасной разработки, а SAMM - задать некоторый roadmap без погружения в детали.

- Описание активностей, их статуса, связей с SAMM, ISO270001 и друг другом
- Подробное видео про OWASP DSOMM
- Ссылка на репозиторий с докладами, инструментами для оценки зрелости и ее визуализации

Еще очень много активностей находятся в стадии to-do, но репозиторий регулярно обновляется.

Кстати, если вы ищите другие альтернативные модели оценки зрелости, то предлагаю взглянуть на Secure development and deployment guidance от UK National Cyber Security Center.

#dev #ops

When the Levee Breaks: Protecting Vault Against Advanced Adversaries and Internal Threats

Я редко пишу про Vault в силу того, что мне не приходится с ним работать, но тут я наткнулся на любопытную статью про то, что происходит под капотом HashiCorp Vault.

В основе работы лежит так называемый "криптобарьер" (Cryptographic Barrier), который включает следующее:
- "Распечатка" ключа (или разделение) с помощью схемы Шамира и сторонних HSM или облачных KMS.
- Использование Go-реализации алгоритма AES-256 GCM
- Платные фичи Seal Wrap для дополнительного уровня шифрования с помощью внешнего криптомодуля и Entropy Augmentation для генерации аппаратных случайных чисел и увеличения энтропии

Кроме криптографии к механизмам защиты Vault относятся:
- Контроль доступа через RBAC, ABAC
- Возможность аудита
- Использование кредов с коротким сроком службы
- Использование подхода Zero Trust, включая TLS и AuthN / AuthZ

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

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

#vault #ops

“Bad Pods: Kubernetes Pod Privilege Escalation”

Статья о 8 не безопасных конфигураций для Pod и соответствующие способы для повышения привилегий. Предполагается что у атакующего есть или возможность создать Pod с такой конфигурацией или он в него попал тем или иным образом. Рассматриваются такие свойства Pod и их сочетания как: hostNetwork, hostPID, hostIPC, hostPath, privileged (список на самом деле можно и расширить):

#1: Все разрешено
#2: Privileged и hostPid
#3: Только Privileged
#4: Только hostPath
#5: Только hostPid
#6: Только hostNetwork
#7: Только hostIPC
#8: Ничего не разрешено

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

Автор также выложил репозиторий со всеми манифестами, и вы можете повторить все описанное в статье. Материал полезен как пентестерам, так и людям, отвечающим за безопасность в Kubernetes.

Общий посыл не забываем про принцип наименьших привилегий (principal of least privilege).

P.S. Если атакующий попал в такой Pod через RCE, то он не знает о этих свойствах Pod и будет итеративно перебирать эти сценарии, тем самым создавая много аномальной активности внутри ;)

Using Jenkins, Vault, Terraform, Ansible, and Consul to Deliver an End-to-End CI/CD Pipeline

Серия статей и видео, посвященных выстраиванию инфраструктуры эффективного деплоймента, покрывая концепции IaC, CI/CD, управления секретами, динамических секретов, проблемы концепции secret zero, service mesh и так далее.

Тулстек:
- HashiCorp Packer
- HashiCorp Terraform
- HashiCorp Vault
- HashiCorp Consul
- Jenkins
- Ansible
- Microsoft Azure

Да, здесь нет статики, динамики и различных проверок образов, но практика показывает, что те, кто идут в DevSecOps, далеко не всегда люди из DevOps. Чаще всего это специалисты со стороны ИБ, которым еще предстоит разобраться во всем многообразии инструментов.

#ops #dev #vault

Безопасная разработка приложений, DevSecOps, Anti-malware

В один из чатов вбросили анонс онлайн-конференции по DevSecOps от Anti-Malware. Когда-то, помню, писал для них статью по сравнению решений Container Security.

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

Затрагиваемые вопросы на конференции по DevSecOps (помимо основ):
- Каковы требования к персоналу и каких специалистов придется нанять?
- Каковы метрики эффективности внедрения DevSecOps?
- С чего начать процесс внедрения DevSecOps?
- Какими средствами проводить фаззинг-тестирование?
- Когда лучше использовать статический (SAST) или динамический анализы (DAST)?
- Какова российская специфика рынка DevSecOps?

Из интересных гостей PT и BI.Zone.

https://live.anti-malware.ru/devsecops

#talks

Bringing Your A-Game: Availability for Security People

Любопытная статья-рассуждение на тему влияния безопасности на доступность важных для бизнеса сервисов. В статье приводится статистика о простоях в месяц для известных сервисов (Azure AD, AWS S3, Cloudflate и тд) и мысли на счет того, как с этим связана безопасность.

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

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

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

#ops

OpenShift Security Guide

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

Если знаете утилиты и другие гайды для аудита безопасности OpenShift - кидайте в комментарии.

#ops #k8s

Detecting zero days in software supply chain with static and dynamic analysis

Любопытная статья про поиск 0-day уязвимостей в сторонних компонентах. В качестве примера была собрана простая python-библиотека, считывающая переменные среды. Также в теории вредоносный пакет может устанавливать бэкдор, красть ресурсы для майнинга криптовалюты или использовать собранные данные для повышения привилегий. Решение максимально простое. Скачивать весь набор библиотек в пайплайне и применять статический анализ (например, Semgrep) или динамический анализ с помощью трассировщика системных вызовов.

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

Методы, описываемые в статье, применяют более современные практики вроде кастомных правил SAST или eBPF, однако есть и подводные камни. Semgrep не строит data flow, поэтому обойти данный набор проверок довольно просто, а писать правила на CodeQL мало кто потянет. Динамический анализ тоже не панацея. Не факт, что вредонос проявит себя на момент анализа работы компонента. Другой вариант - анализировать приложение, когда оно будет работать в Run-time на проде, блокируя активность на момент обнаружения аномалии, однако здесь все упирается в инструментальный стек, а с этим сейчас далеко не все хорошо в мире open-source и enterpise.

#dev

SAST and SCA correlation (?)

На самом деле идея проверки SAST'ом open-source компонентов наталкивает меня на мысли об инструменте корреляции SCA и SAST (понимание как искать совпадения SAST и DAST уже есть). Здесь правда все упирается в то, чтобы находить функции уязвимой библиотеки в коде приложения. Предлагайте идеи, как вы это видите в чате :)

HashiCorp Boundary

В 2020 году HashiCorp выпустили решение HashiCorp Boundary в open-source. Я долго тянул с тем, чтобы разобраться, что это, пока не наткнулся на статью Gating Access to Kubernetes API & Workloads with HashiCorp Boundary, в которой объясняется, каким образом HashiCorp Boundary обеспечивает безопасный доступ к API k8s и контейнерам. Выглядит довольно интересно. Даже прилагается пример в виде terraform.

HashiCorp Boundary представляет из себя CLI + Gateway, позволяющий администраторам получать доступ к ресурсам компании без прямого доступа к частной сети. Boundary интегрируется с существующими средствами аутентификаци, предлагает свою модель RBAC и подтягивает креды из HashiCorp Vault. Все это сопровождается возможностью аудита.

Первый вопрос, который возникает: Чем это отличается от современных Privileged Access Management (PAM) систем, кроме того, что это open-source?

- Boundary Connect (CLI) уже содержит в себе известные клиенты вроде RDP, SSH, kubectl, postgres, http. Таким образом, нет необходимости подключаться к некому бастиону по RDP/SSH, а оттуда перепрыгивать на целевую систему.

- Boundary не привязывается к IP-адресам целевых ресурсов. Это позволяет работать с объектами, которые динамически меняют свои адреса. Например, можно через boundary connect kube пройти аутентификацию, авторизацию и подключиться к желаемому контейнеру с временными кредами.

- Boundary имеет возможность развертываться через Terraform. Таким образом, можно реализовать привычный доступ в формате PAM не конфликтуя с DevOps-командами.

Вот, кстати, хорошее видео, где на пальцах объясняют как работает решение.

#ops #k8s

Cloud Security Newsletter #1

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

В этот раз я решил оформить это в виде подборки единым постом.

Cloud Controls Matrix (CCM) v4 - вышла новая версия матрицы безопасности облаков. Данный фреймворк объединяет требования ISO, NIST, PCI DSS и других нормативных документов, применяемых к облакам в едином файле.

Publishing Checkov Terraform Quality Checks to Azure DevOps Pipelines. - Встраивание Checkov для проверки Terraform в Azure Pipelines шаг за шагом.

How We Escaped Docker in Azure Functions. История про побег из Docker контейнера за счет уязвимости в Azure Functions.

Redefining Security in 2021. О том, что из себя представляют сервисы безопасности в Alibaba Cloud.

Cloud Security Table Top Exercises. Набор из возможных сценариев атак в AWS, которые стоит взять во внимание при аудитах.

New whitepaper: Designing and deploying a data security strategy with Google Cloud. Новый whitepaper от команды GCP по выстраиванию безопасности данных, покрывающий разделы Identity, Boundary, Access и Visibility.

#aws #gcp #azure #ops #dev

CodeQL: SAST своими руками (и головой). Часть 1

Вводная статья от Паши Канна про CodeQL. Что это такое, как начать с этим работать и чем это может быть полезно. Ссылки в дополнительных материалах помогут разобрать вопрос чуть глубже.

Конечно, здесь ещё много чего нет про построение data flow, подводные камни и сопутствующие страдания, но на то это и первая часть. Кое-что про основы я писал здесь.

Кстати, также Паша запустил чат по обсуждению CodeQL.

https://habr.com/ru/company/swordfish_security/blog/541554/

#sast #dev

Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies

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

Реализовать атаку довольно просто: находим имена приватных пакетов, создаем собственные версии с аналогичным названием, выкладываем в публичный репозиторий. Далее ждем, когда кто-то установит наш пакет вместо приватного пакета компании. На HackerOne есть репорт, который раскрывает всю подноготную атаки, включая "вредоносный" пакет для тестирования.

Защита от подобного рода атак описывается в новеньком документе Microsoft. Для Nexus и JFrog выпущены соответствующие рекомендации. Но какой-то серебряной пули, которая поможет здесь и сейчас, нет. Особенно в случае с npm, когда ваши разработчики не используют scope.

Кстати, ситуация с Dependency Confusion еще один звоночек в пользу создания своей баг-баунти программы. Ведь владельцы оных были уведомлены об уязвимости аж 7 месяцев назад.

Новость и разбор от @Khorcus

#dev #sca #attack #news

OWASP ASVS 4.0 Testing Guide

Неофициальное руководство, в котором описывается, как автоматически тестировать веб по проверкам уровня Level 1 стандарта ASVS с помощью OWASP ZAP. К методике также недавно появилась обзорная статья. В руководстве достаточно подробно написано, как завести ZAP под ASVS с применением пассивного сканирования. Также в репо прилагаются все необходимые скрипты .

https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide

#dast #dev