State of Software Security

Со временем начинаю все меньше любить вендорские отчеты в виду большого колличетсва воды и минимальной ценности. Тем не менее заинтересовал последний отчет Veracode. Они проанализировали различные уязвимости с точки зрения их покрытия с помощью SAST и DAST - что из них эффективнее и при каких условиях, зависимость эффективности инструментов от частоты сканирования и способе их использования. Также рассматриваются уязвимости по степени их популярности и времени фикса.

Также в отчете отдельно рассматриваются "природные" (nature) и "приобретенные" (narture) факторы команды и то, как они влияют на безопасность приложений. К "природным" относятся масштабы организации и приложений, величины тех. долга безопасности. К "приобретенным" факторам относится все то, на что команда может повлиять, например, на частоту сканирования.

#sast #dast #sca #dev #report

How GitOps Improves the Security of Your Development Pipelines

Наткнулся на свежую статью, приводящую примеры того, как методология GitOps может улучшить безопасность вашей среды. К основным примерам относятся аудит и ограничение доступа CI/CD системы. Про проблемы классического подхода DevOps и решения GitOps также можно прочитать в статьях:

- How secure is your CICD pipeline?
- How GitOps Raises the Stakes for Application Security

Однако, как и везде, есть подводные камни. Хорошая статья на тему рисков, связанных с GitOps:

- Securing GitOps Pipeline

В основном здесь все сводится к угрозам системы контроля версий, но не стоит также забывать про RBAC. Ведь, несмотря на широкое ограничение доступа согласно методологии, оператор GitOps все еще может стать отправной точкой для злоумышленника. Еще одна проблема - сильная зависимость от кода и уход от подходов, связанных с контролем Run-time через тот же OPA. Как показывает практика, статические анализаторы далеко не всегда хороши в определении полной картины проблем, связанных с ИБ.

Пока комьюнити ищет золотую середину в подходах, предлагаю вам также прочитать следующий материал:

- GitOps Security with k8s-security-configwatch by Sysdig
- Access Control & Security (GitOps and Kubernetes Book)

Кстати, если вы не знакомы с методологией, то мне нравится перевод от Flant.

UPD. Книгу можно взять здесь. Спасибо подписчикам <3

#ops #k8s #literature

Lesser Known Techniques for Attacking AWS Environments

На сайте tldrsec появилась статья от известного в сообществе Scott Piper про малоизвестные методы атаки на AWS. К их числу относятся:

- Получение доступа через Amazon Machine Image (AMI)
- Отправка вредоносного CloudFormation Stack Set
- Сбор информации об IAM за счет политики доверия
- Использование злоумышленником предсказуемых названий так, чтобы организация по ошибке считала чужие ресурсы (вроде S3) за свои
- Переход между аккаунтами за счет неправильно построенных доверительных отношениях

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

Кстати на русском языке есть хороший доклад про базовые методики тестирования на проникновение AWS - Вадим Шелест, Digital Security – Облачный пентест: Методики тестирования Amazon AWS

Также кое-что можно найти по хэштегам и в @cloud_sec

#aws #attack

DevSecOps, A leader's guide to producing secure software without compromising flow, feedback and continuous improvement, Glenn Wilson

#literature #dev #ops

DevSecOps Practices And Open Source Managent in 2020

Отчет от Synopsys по результатам опроса 1500 специалистов касательно DevSecOps и проверки open-source компонентов.

Коротко:
- 66% опрошенных внедрили практики DevSecOps, но только половина из них считает, что они достаточно зрелы и распространены на всю организацию

- 42% считают, что за DevSecOps ответственна команда ИБ, 29% - разработка, 9% - эксплуатация, 18% - ответственность распределенная

- Самые популярные средства защиты - WAF, SCA, DAST

- 72% имеют политику использования open-source

- У 51% опрошенных фикс критической уязвимости с момента ее обнаружения занимает 2-3 недели, 24% - месяц

И некоторая другая статистика в pdf.

Ну и не обошлось конечно же без рекламы Synopsys и заезженной истории про Equifax. Хотя, если верить их опросу, то 33% опрошенных стали использовать коммерческий SCA после соответствующей публикации в СМИ.

За ссылку спасибо @Mr_R1p

#dev #ops #report

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 и будет итеративно перебирать эти сценарии, тем самым создавая много аномальной активности внутри ;)