OWASP API Security Top 2019 на русском

Подписчик Eugene Rojavski скинул результат собственного перевода OWASP API Security Top 2019, выполненного совместно с его командой (act1on3, keni0k). Перевод уже стал частью официального репо OWASP.

"Несмотря на то, что более обширный Web Application Security Risks Top 10 по прежнему актуален, ввиду специфики API, необходим отдельный список рисков безопасности специфичных для API. Безопасность API фокусируется на стратегиях и решениях, направленных на понимание и предотвращение уникальных уязвимостей и рисков безопасности, связанных с использованием API."

#dev #web #attack

Shifting Engineering Right: What security engineers can learn from DevSecOps

Философская статья на тему того, как инженер безопасности может участвовать в разработке. Главная мысль заключается в том, что на текущий момент в направлении DevSecOps основной акцент делается на обучении разработчиков лучшим практикам безопасности, в то время как инженеры безопасности находятся в стороне.

Некоторые тезисы о том, как могут участвовать инженеры безопасности в разработке:
- Быть в курсе дорожной карты компании и продуктов
- Узнавать, может ли инженер безопасности повлиять на фичи продукта, направленные на повышение безопасности (2FA)
- Вносить самому PR
- Развивать навыки разработки и научиться погружаться в то, как собственные фичи влияют на впечатления конечного клиента
- Участвовать в мероприятиях разработчиков

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

#dev

"Враг не пройдёт, или как помочь командам соблюдать стандарты разработки"

Разбор доклада от Александра Токарева про Open Policy Agent на русском языке - что это, примеры проверок манифестов k8s и конфигурации сборок, способы интеграции OPA, use cases и немного про архитектуру OPA в Сбере.

https://habr.com/ru/company/oleg-bunin/blog/328262/

Для тех, кто заинтересовался инструментом, гораздо больше за хэштегом #opa

Сейчас, кстати, стало популярно относить все security практики к каким-то вехам DevSecOps. Open Policy Agent не исключение, поэтому часто можно услышать, что технология относится к Compliance as Code. Сюда же относится Chef InSpec, HashiCorp Santinel и, по сути, любой другой сканер. Подробнее про другие инструменты можно найти по ссылке.

#ops #dev

Kubestriker - Security Auditing tool for Kubernetes

Kubestriker - инструмент для тестирования безопасности Kubernetes. В отличие от большинства инструментов тестирования работает с read-only правами и поддерживает сканирования с anonymous доступом. Проверяет открытые порты, мисконфигурации контейнеров, IAM, PSP, Network Policies, возможность для повышения привилегий. Также поддерживаются все основные виды managed k8s.

#k8s #ops #attack

Attacking Kubernetes Clusters Through Your Network Plumbing: Part 1

CyberArk выпустили достаточно подробную статью о реализациях атак в кластере Kubernetes используя специфику работы сети. В частности речь пойдет о подмене DNS и обходе сетевых ограничений внутри кластера (удаление NET_RAW из пода, правила iptables), используя оверлейные сети. Вот, кстати, пример PoC для спуфинга DNS.

#k8s #ops #attack

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

Со своей стороны дополнил бы паком semgrep, куда входит небольшое число проверок на nginx (расширить рулы довольно просто). Semgrep также поможет переварить конфиги, которые, например, находятся в ConfigMap в случае, если вы столкнулись с таким при аудитах.

Вот оригиналы статей:
- Common Nginx misconfigurations that leave your web server open to attack
- Middleware, middleware everywhere - and lots of misconfigurations to fix

#dev #ops

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым
https://habr.com/ru/company/cloud4y/blog/547164/

У Яндекса есть анализатор конфигов Nginx
Nginx configuration static analyzer
https://github.com/yandex/gixy

Detecting MITRE ATT&CK by Sysdig Falco

Время от времени получаю различные запросы на проведение аудита Kubernetes и DevSecOps процессов. В рамках одного из них столкнулся с тем, что заказчик использует Falco совместно со встроенными правилами. Основными здесь являются falco_rules.yaml и k8s_audit_rules.yaml. На первый взгляд все очень красиво. Отдельным тэгом выделена классификация правил по MITRE ATT&CK. Каждое правило проставлено тэгом, который говорит о принадлежности правила к тому или иному этапу развития атаки.

На этот счет в 2019 году Sysdig выпустили даже отдельную статью "MITRE ATT&CK framework for container runtime security with Falco", а в 2021 году вышло две статьи о том, как Falco может определить реализацию атак на практике:
- MITRE ATT&CK framework for container runtime security with Falco.
- Detecting MITRE ATT&CK: Defense evasion techniques with Falco

Можно ли применить сразу данные правила и почему подобного пака нет в OPA? Все дело в том, что встроенный пак от Falco никак не учитывает специфику вашей организации и используемые инструменты. Если мы посмотрим на правило "Write below etc", то увидим более 30 различных исключений, которые потенциально могут использоваться злоумышленником. По этой причине весь встроенный пак нуждается в серьезной кастомизации, чтобы не повторить кейса, похожего на Falco Bypass. Даже если вы не готовы выделять деньги на коммерческие решения с встроенным механизмом профилирования, всегда придерживайтесь концепции Least Privilege и Zero Trust.

#ops #attack

Безопасность Kubernetes, Яндекс Облако

Сегодня я хочу поделиться небольшим набором вебинаров от команды Яндекс.Облако на тему безопасности Kubernetes.

- Безопасность в инфраструктуре, основанной на Kubernetes
- Настройки ролевых моделей и политик для Managed Service for Kubernetes
- Практический вебинар по сетевой безопасности

Также у них можно найти репо с тестовым стендом. Весь стенд предполагается развертывать в облаке Яндекса. Здесь есть и примеры "плохих" подов и примеры политик Kyverno.

#ops #k8s

Awesome Kubernetes (K8s) Security

Свеженький Awesome по безопасности Kubernetes. Безусловно, есть чем дополнить, но на текущий момент это самая широкая сборка по данной теме. Отдельным открытием для меня стали материалы из раздела Trainings. Здесь и KubeCon NA 2019 CTF со сценариями атаки и защиты, и бесплатные тренинги от ControlPlane.

Отдельно хотелось бы добавить ссылку на ресурс CloudSecDocs по инструментам для проведения аудита Kubernetes.

#ops #k8s

Introducing sigstore: Easy Code Signing & Verification for Supply Chain Integrity

Сегодня у нас новый проект от Linux Foundation - Sigstore, основная цель которого предоставить возможность подписывать и проверять релизы. Из слов разработчиков, "Так же, как Let's Encrypt предоставляет бесплатные сертификаты и инструменты автоматизации для HTTPS, sigstore предоставляет бесплатные сертификаты и инструменты для автоматизации и проверки подписей исходного кода."

На текущий момент проект нацелен на артефакты вроде tar, бинарных файлов и образов контейнеров. Позже будут рассмотрены jar-файлы, манифесты (например, SBOM).

Важно отметить, что речь идет именно о проекте. Реализация зависит от конкретного инструмента. На текущий момент это Cosign от инженера Google (пример работы), Rekore и Fulcio.

Среди примеров угроз, от которых потенциально спасает инструмент - dependency confusion attack и импорт уязвимых пакетов RubyGems.

#sca

Kics - Secure IaC by Checkmarx (with OPA engine)

Checkmarx выпустили open-source инструмент Kics - сканер IaC (Terraform, Kubernetes, Dockerfile, Ansible, CloudFormation, Helm) на предмет мисконфигураций. Работает на базе правил Rego и умеет выдавать результат в JSON и красивых HTML. Правила все находятся в репо и дописываются, пока я пишу текст к этому посту. В общем выглядит очень интересно.

Если кто хочет послушать про это вебинар 15 апреля от самих Checkmarx, то ссылка вот. Спасибо подписчикам!

Если вам интересны еще подобные проекты, то оказывается, существует отдельный Awesome под OPA - интеграции, статьи, тренинги, коммерческие обвязки.

#opa #dev #ops

Статья "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