Red Hat to Acquire Kubernetes-Native Security Leader StackRox

Интересная новость, которая как-то прошла мимо. На той неделе Red Hat объявили о намерении покупки компании StackRox, которая специализируется на разработке средств защиты для контейнерной среды. Закрытие сделки ожидается на первый квартал 2021 года.

https://www.redhat.com/en/about/press-releases/red-hat-acquire-kubernetes-native-security-leader-stackrox?sc_cid=701f2000000tyBtAAI

#news #ops #k8s

Лучшие практики при написании безопасного Dockerfile

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

- Почему COPY, лучше чем ADD
- Полезные лейблы (securitytxt)
- Как скачивать компоненты из Интернета при сборке образа, избегая MiTM атаки
- Почему нужно задавать USER в конце и как может помочь gosu
- Затронута тема минимальных и Distroless образов
- Безопасная работа с секретами (multi-stage сборка, фича BuildKit, проблемы рекурсивного копирования)
- Существующие анализаторы Dockerfile
- Разные полезные доп. материалы

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

#dev #docker

Linux Hardening Guide

Выстраивая безопасность Kubernetes/Docker нельзя забывать, что львиная доля безопасности систем зависит от ОС. Это касается как харденинга, так и поддержания актуальной версии ядра (небезызвестная CVE-2016-5195). Сегодня предлагаю вам взять на вооружение большой гайд по харденингу Linux, который не зависит от конкретной ОС.

Не забываем прочитать важный дисклеймер: "Do not attempt to apply anything in this article if you do not know exactly what you are doing. "

https://madaidans-insecurities.github.io/guides/linux-hardening.html

#ops

HuskyCI - open source tool that orchestrates security tests

huskyCI - open-source утилита для упрощения встраивания статических анализаторов в процессы CI. Из поддерживаемых Bandit, Safety, Brakeman, Npm Audit, Yarn Audit, Gosec, SpotBugs с Find Sec Bugs, TFSec, GitLeaks. Есть клиентская и серверная части. Веб-морда для управления уязвимостями отсутствует, но можно отправить запрос на API для извлечения результатов из БД. Подробнее можно прочитать в документации.

https://github.com/globocom/huskyci

#dev #ops #sast #secret

Sysdig 2021 container security and usage report

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

Статью со сводной информацией можно прочитать здесь.

Коротко:
- 49% контейнеров живут меньше 5 минут, 21% менее 10 секунд

- 74% клиентов сканируют образы в CI/CD, при этом 58% контейнеров запускаются от рута

- Рост использования containerd и CRI-O в 2 раза за 2020 год

- 53% уязвимостей программных компонентов (библиотеки PIP, Ruby и тд) обладают высоким уровнем критичности. Для ОС-компонентов только 4% из всех уязвимостей обладают высоким уровнем критичности.

- Рост использования Falco в 3 раза за 2020 год. Рост использования Prometheus на 16% за 2020 год. И то и то очень удачно вписывается в продажи Sysdig ;)

В отчете очень много информации, которая не относится к security вроде числа нод, подов на хост, статистики алертов и тд.

#ops #k8s #docker #report

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