Launching OSV - Better vulnerability triage for open source

В вопросах, касающихся уязвимостей в сторонних компонентах (цепочке поставок), одна из главных проблем - полнота сведений в базе данных. В частности речь идет о NIST. Информации о CVE, CVSS и CPE чаще всего недостаточно, чтобы точно идентифицировать, какие компоненты подверглись уязвимости в цепочке поставок. Это же проблема является ключевой в вопросах корреляции SAST/SCA. Более того, мы не обладаем информацией о том, в каких версиях происходит исправления уязвимости. Чтобы решить данную проблему, крупные вендоры (например, Sonatype) ведут собственные фиды.

По этой причине команда Google на базе информации, полученной по итогам работы над OSS-Fuzz, запустила проект Open Source Vulnerabilities (OSV). Это сервис, который использует собственные фиды, чтобы предоставить расширенную информацию об уязвимостях в версии ПО. Про подход "Know, Prevent, Fix", взятый за основу, они также писали в отдельной статье.

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

Вот, например, OSV-2020-2291. Здесь содержится информация о том, что за уязвимость, какие компоненты также подвержены, ссылка на репо, коммит, в котором уязвимость была найдена и устранена. Здесь же есть данные о результатах тестирования с помощью OSS-Fuzz.

#dev #sca

Red Hat and IT Security

Обзорная книга по безопасности в DevOps в связке с продуктами Red Hat от 2021 года.

Из интересного и не заезженного - обзор в связке с безопасностью:
- Red Hat Hyperconverged Infrastructure (HCI)
- Red Hat OpenStack Platform (RHOSP)
- Red Hat Smart Management
- Red Hat Insights.

#literature #ops

Всем привет!

Была немного тяжелая неделя, накопилось много идей, о чем написать, но это потом.

Сейчас мы тестируем Clubhouse и знакомимся с комьюнити DevSecOps

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

https://www.joinclubhouse.com/room/xn76O70a

#talks

Возвращаясь к теме Dependency Confusion, хочется упомянуть несколько простых скриптов, которые могут помочь в обнаружении проблемных артефактов: confused и repo-diff.

Первая утилита анализирует файл с определением зависимостей и проверяет, заняты ли имена приватных пакетов в публичных репозиториях. Работает для Python (pypi), JavaScript (npm) и PHP (composer). Подойдет для сканирования небольшого количества проектов.

Если репозиториев больше нескольких десятков, то гораздо проще взаимодействовать с хранилищем артефактов. Неплохим примером, иллюстрирующим работу с API Nexus, служит repo-diff. Он проверяет, нет ли в проксируемых репозиториях Nexus пакетов с такими же именами, что и в приватных. На его основе можно написать кастомный скрипт. Например, чтобы вытащить все приватные зависимости. Такую задачу можно решить также с помощью кастомных groovy скриптов.

P.S. В предыдущем посте никак не затрагивался PHP с его composer. Хотя про эту парочку есть хорошая статья. Исправляюсь.

От @Khorcus

#attack #sca #dev

Keep it secret. Keep it ... safe?

"It look just 6 minutes for the malicious actor to find the leaked credentials on GitHub and compromise our AWS account."

Любопытный эксперимент. Команда вендора Shhgit умышленно разместила ключи AWS в публичном репо GitHub. Первое, что происходит спустя 4 минуты - срабатывание политики AWSCompromisedKeyQuarantine, согласно которой скомпрометированные ключи отзываются с автоматическим уведомлением администратора.

Что же будет, если эту политику выключить?

Спустя 6 минут после утечки происходит волна активности с IP-адресов в Нидерландах. Эти же IP-адреса связаны со спамом и узлами TOR. Почти сразу создаются экземпляры EC2. Очевидно, что это майнинг криптовалюты, а именно XMR (Monero).

Спустя 36 минут IP-адреса из Израиля используют секреты для доступа к S3. В это же время злоумышленник связывается с администратором требуя выкуп.

Итого 13 разных обращений к AWS в течение 24 часов и 4 злоумышленника выполнили действия, аналогичные описанным выше.

#secret

Achieving Cloud Native Security and Compliance with Teleport

До этого я немного касался нового решения HashiCorp Boundary для контроля привилегированного доступа администраторов взамен старым легаси решениям. Сегодня на очереди статья про его аналог - Teleport.

В статье вы узнаете об архитектуре решения, его преимуществах по сравнению с классическими бастион хостами и порядке инсталляции. В Teleport также есть интеграция с Kubernetes, запись сессии, выбор ресурсов через веб-интерфейс. В платную подписку входит SSO, RBAC, возможность запрашивать доступ через Jira, Slack. RBAC кстати также интегрирован с RBAC Kubernetes. То есть вы можете настраивать более жесткие политики контроля, если пользователь, скажем, входит в system:masters.

#ops

Help Shape ATT&CK for Containers

Каждый, кто когда-нибудь подходил к оценке рисков, связанных с Kubernetes, сталкивался со статьей от Microsoft "Threat matrix for Kubernetes". Она построена на базе ATT&CK матрицы, созданной организацией MITRE, которая до этого не подходила к безопасности контейнеров.

Вышла драфтовая версия MITRE ATT&CK матрицы для безопасности контейнеров. Она включает как риски обозначенные Microsoft, так и новые, например, выход за пределы контейнера, сборка образа злоумышленника на хосте, получение доступа к API и так далее.

#ops #k8s #attack

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