DevSecOps Wine

2021-02-17 09:43:04 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 Открыть/Комментировать

2021-02-17 09:42:59 Открыть/Комментировать

2021-02-16 10:16:28 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 Открыть/Комментировать

2021-02-15 09:56:01 OWASP ASVS 4.0 Testing Guide

Неофициальное руководство, в котором описывается, как автоматически тестировать веб по проверкам уровня Level 1 стандарта ASVS с помощью OWASP ZAP. К методике также недавно появилась обзорная статья. В руководстве достаточно подробно написано, как завести ZAP под ASVS с применением пассивного сканирования. Также в репо прилагаются все необходимые скрипты .

https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide

#dast #dev Открыть/Комментировать

2021-02-12 10:00:34 Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies

Недавно вышла интересная статья про то, как исследователь получил возможность исполнять код на серверах компаний и внедрять бэкдоры в их приложения. Уязвимыми оказались такие гиганты, как Microsoft, Apple, PayPal и Tesla. Атака стала возможной благодаря особенности пакетных менеджеров, которые пытаются загрузить внутренние зависимости компаний, в том числе и из публичных репозиториев. Это касается и хранилищ артефактов, если в одном виртуальном репозитории смешаны внутренние и внешние пакеты.

Реализовать атаку довольно просто: находим имена приватных пакетов, создаем собственные версии с аналогичным названием, выкладываем в публичный репозиторий. Далее ждем, когда кто-то установит наш пакет вместо приватного пакета компании. На HackerOne есть репорт, который раскрывает всю подноготную атаки, включая "вредоносный" пакет для тестирования.

Защита от подобного рода атак описывается в новеньком документе Microsoft. Для Nexus и JFrog выпущены соответствующие рекомендации. Но какой-то серебряной пули, которая поможет здесь и сейчас, нет. Особенно в случае с npm, когда ваши разработчики не используют scope.

Кстати, ситуация с Dependency Confusion еще один звоночек в пользу создания своей баг-баунти программы. Ведь владельцы оных были уведомлены об уязвимости аж 7 месяцев назад.

Новость и разбор от @Khorcus

#dev #sca #attack #news Открыть/Комментировать

2021-02-11 09:49:41 CodeQL: SAST своими руками (и головой). Часть 1

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

Конечно, здесь ещё много чего нет про построение data flow, подводные камни и сопутствующие страдания, но на то это и первая часть. Кое-что про основы я писал здесь.

Кстати, также Паша запустил чат по обсуждению CodeQL.

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

#sast #dev Открыть/Комментировать

2021-02-10 09:56:25 Cloud Security Newsletter #1

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

В этот раз я решил оформить это в виде подборки единым постом.

Cloud Controls Matrix (CCM) v4 - вышла новая версия матрицы безопасности облаков. Данный фреймворк объединяет требования ISO, NIST, PCI DSS и других нормативных документов, применяемых к облакам в едином файле.

Publishing Checkov Terraform Quality Checks to Azure DevOps Pipelines. - Встраивание Checkov для проверки Terraform в Azure Pipelines шаг за шагом.

How We Escaped Docker in Azure Functions. История про побег из Docker контейнера за счет уязвимости в Azure Functions.

Redefining Security in 2021. О том, что из себя представляют сервисы безопасности в Alibaba Cloud.

Cloud Security Table Top Exercises. Набор из возможных сценариев атак в AWS, которые стоит взять во внимание при аудитах.

New whitepaper: Designing and deploying a data security strategy with Google Cloud. Новый whitepaper от команды GCP по выстраиванию безопасности данных, покрывающий разделы Identity, Boundary, Access и Visibility.

#aws #gcp #azure #ops #dev Открыть/Комментировать

2021-02-09 10:07:06 HashiCorp Boundary

В 2020 году HashiCorp выпустили решение HashiCorp Boundary в open-source. Я долго тянул с тем, чтобы разобраться, что это, пока не наткнулся на статью Gating Access to Kubernetes API & Workloads with HashiCorp Boundary, в которой объясняется, каким образом HashiCorp Boundary обеспечивает безопасный доступ к API k8s и контейнерам. Выглядит довольно интересно. Даже прилагается пример в виде terraform.

HashiCorp Boundary представляет из себя CLI + Gateway, позволяющий администраторам получать доступ к ресурсам компании без прямого доступа к частной сети. Boundary интегрируется с существующими средствами аутентификаци, предлагает свою модель RBAC и подтягивает креды из HashiCorp Vault. Все это сопровождается возможностью аудита.

Первый вопрос, который возникает: Чем это отличается от современных Privileged Access Management (PAM) систем, кроме того, что это open-source?

- Boundary Connect (CLI) уже содержит в себе известные клиенты вроде RDP, SSH, kubectl, postgres, http. Таким образом, нет необходимости подключаться к некому бастиону по RDP/SSH, а оттуда перепрыгивать на целевую систему.

- Boundary не привязывается к IP-адресам целевых ресурсов. Это позволяет работать с объектами, которые динамически меняют свои адреса. Например, можно через boundary connect kube пройти аутентификацию, авторизацию и подключиться к желаемому контейнеру с временными кредами.

- Boundary имеет возможность развертываться через Terraform. Таким образом, можно реализовать привычный доступ в формате PAM не конфликтуя с DevOps-командами.

Вот, кстати, хорошее видео, где на пальцах объясняют как работает решение.

#ops #k8s Открыть/Комментировать

2021-02-08 10:06:40 SAST and SCA correlation (?)

На самом деле идея проверки SAST'ом open-source компонентов наталкивает меня на мысли об инструменте корреляции SCA и SAST (понимание как искать совпадения SAST и DAST уже есть). Здесь правда все упирается в то, чтобы находить функции уязвимой библиотеки в коде приложения. Предлагайте идеи, как вы это видите в чате :) Открыть/Комментировать

2021-02-08 10:06:40 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 Открыть/Комментировать