Security Wine (бывший - DevSecOps Wine)

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

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

#secret #dev

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

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

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

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

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

#events #talks

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

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

Generating Kubernetes Network Policies By Sniffing Network Traffic

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

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

#ops #k8s

Uncomplicate Security for developers using Reference Architectures

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

Uncomplicate Security for developers using Reference Architectures

#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

Security Chaos Engineering: How to Security Differently

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

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

#dev #ops

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

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

#ops #literature

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

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

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

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

Awesome Kubernetes (K8s) Security

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

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

#ops #k8s

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

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

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

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

#ops #k8s

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

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

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

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

Со своей стороны дополнил бы паком 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