Using Jenkins, Vault, Terraform, Ansible, and Consul to Deliver an End-to-End CI/CD Pipeline
Серия статей и видео, посвященных выстраиванию инфраструктуры эффективного деплоймента, покрывая концепции IaC, CI/CD, управления секретами, динамических секретов, проблемы концепции secret zero, service mesh и так далее.
Тулстек:
- HashiCorp Packer
- HashiCorp Terraform
- HashiCorp Vault
- HashiCorp Consul
- Jenkins
- Ansible
- Microsoft Azure
Да, здесь нет статики, динамики и различных проверок образов, но практика показывает, что те, кто идут в DevSecOps, далеко не всегда люди из DevOps. Чаще всего это специалисты со стороны ИБ, которым еще предстоит разобраться во всем многообразии инструментов.
#ops #dev #vault
Серия статей и видео, посвященных выстраиванию инфраструктуры эффективного деплоймента, покрывая концепции IaC, CI/CD, управления секретами, динамических секретов, проблемы концепции secret zero, service mesh и так далее.
Тулстек:
- HashiCorp Packer
- HashiCorp Terraform
- HashiCorp Vault
- HashiCorp Consul
- Jenkins
- Ansible
- Microsoft Azure
Да, здесь нет статики, динамики и различных проверок образов, но практика показывает, что те, кто идут в DevSecOps, далеко не всегда люди из DevOps. Чаще всего это специалисты со стороны ИБ, которым еще предстоит разобраться во всем многообразии инструментов.
#ops #dev #vault
Безопасная разработка приложений, DevSecOps, Anti-malware
В один из чатов вбросили анонс онлайн-конференции по DevSecOps от Anti-Malware. Когда-то, помню, писал для них статью по сравнению решений Container Security.
Вообще, это логично, что тема дошла и до безопасности разработки в силу роста ее популярности. Я положительно отношусь к подобному продакшену - с качественной съемкой и разными приглашенными гостями. Местами у меня возникают вопросы к поднимаемым темам и причастности гостей к ним, но в этот раз, кажется, должно быть интересно. Другую их онлайн-конференцию по облачной безопасности, например, можно посмотреть здесь.
Затрагиваемые вопросы на конференции по DevSecOps (помимо основ):
- Каковы требования к персоналу и каких специалистов придется нанять?
- Каковы метрики эффективности внедрения DevSecOps?
- С чего начать процесс внедрения DevSecOps?
- Какими средствами проводить фаззинг-тестирование?
- Когда лучше использовать статический (SAST) или динамический анализы (DAST)?
- Какова российская специфика рынка DevSecOps?
Из интересных гостей PT и BI.Zone.
https://live.anti-malware.ru/devsecops
#talks
В один из чатов вбросили анонс онлайн-конференции по DevSecOps от Anti-Malware. Когда-то, помню, писал для них статью по сравнению решений Container Security.
Вообще, это логично, что тема дошла и до безопасности разработки в силу роста ее популярности. Я положительно отношусь к подобному продакшену - с качественной съемкой и разными приглашенными гостями. Местами у меня возникают вопросы к поднимаемым темам и причастности гостей к ним, но в этот раз, кажется, должно быть интересно. Другую их онлайн-конференцию по облачной безопасности, например, можно посмотреть здесь.
Затрагиваемые вопросы на конференции по DevSecOps (помимо основ):
- Каковы требования к персоналу и каких специалистов придется нанять?
- Каковы метрики эффективности внедрения DevSecOps?
- С чего начать процесс внедрения DevSecOps?
- Какими средствами проводить фаззинг-тестирование?
- Когда лучше использовать статический (SAST) или динамический анализы (DAST)?
- Какова российская специфика рынка DevSecOps?
Из интересных гостей PT и BI.Zone.
https://live.anti-malware.ru/devsecops
#talks
Bringing Your A-Game: Availability for Security People
Любопытная статья-рассуждение на тему влияния безопасности на доступность важных для бизнеса сервисов. В статье приводится статистика о простоях в месяц для известных сервисов (Azure AD, AWS S3, Cloudflate и тд) и мысли на счет того, как с этим связана безопасность.
Посыл заключается в том, что команда безопасности зачастую пренебрегает вопросами доступности, а в модели угроз и оценке рисков они часто вовсе не учитываются.
Например, повышение привилегий через последнюю уязвимость в sudo, криптомайнеры или утечка данных - все это, как итог, влияет на доступность сервисов. Тем не менее почему-то во многих командах пытаются считать репутационные потери "количественной оценкой рисков", что больше похоже на "юморизм", а не статистический анализ.
В то же время команды Ops наоборот стараются оптимизировать доступность. Соответственно, если одна из ваших целей состоит в том, чтобы улучшить отношения Sec и Ops, то доступность может стать отличной для этого отправной точкой.
#ops
Любопытная статья-рассуждение на тему влияния безопасности на доступность важных для бизнеса сервисов. В статье приводится статистика о простоях в месяц для известных сервисов (Azure AD, AWS S3, Cloudflate и тд) и мысли на счет того, как с этим связана безопасность.
Посыл заключается в том, что команда безопасности зачастую пренебрегает вопросами доступности, а в модели угроз и оценке рисков они часто вовсе не учитываются.
Например, повышение привилегий через последнюю уязвимость в sudo, криптомайнеры или утечка данных - все это, как итог, влияет на доступность сервисов. Тем не менее почему-то во многих командах пытаются считать репутационные потери "количественной оценкой рисков", что больше похоже на "юморизм", а не статистический анализ.
В то же время команды Ops наоборот стараются оптимизировать доступность. Соответственно, если одна из ваших целей состоит в том, чтобы улучшить отношения Sec и Ops, то доступность может стать отличной для этого отправной точкой.
#ops
Capsule8
Bringing Your A-Game: Availability for Security People | Capsule8
Modernize without Compromise
RedHatOpenShiftSecurityGuide.epub
14.5 MB
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
Любопытная статья про поиск 0-day уязвимостей в сторонних компонентах. В качестве примера была собрана простая python-библиотека, считывающая переменные среды. Также в теории вредоносный пакет может устанавливать бэкдор, красть ресурсы для майнинга криптовалюты или использовать собранные данные для повышения привилегий. Решение максимально простое. Скачивать весь набор библиотек в пайплайне и применять статический анализ (например, Semgrep) или динамический анализ с помощью трассировщика системных вызовов.
На самом деле идея не новая. До этого проблема с 0-day в пакетах, как правило, решалась с помощью песочниц. На моей практике заказчики заворачивали пайплайны так, чтобы тестируемое приложение деплоилось в песочнице вроде FortiSandbox.
Методы, описываемые в статье, применяют более современные практики вроде кастомных правил SAST или eBPF, однако есть и подводные камни. Semgrep не строит data flow, поэтому обойти данный набор проверок довольно просто, а писать правила на CodeQL мало кто потянет. Динамический анализ тоже не панацея. Не факт, что вредонос проявит себя на момент анализа работы компонента. Другой вариант - анализировать приложение, когда оно будет работать в Run-time на проде, блокируя активность на момент обнаружения аномалии, однако здесь все упирается в инструментальный стек, а с этим сейчас далеко не все хорошо в мире open-source и enterpise.
#dev
Ajin Abraham
Detecting zero days in software supply chain with static and dynamic analysis
This blog shares some ideas about detecting zero-days in the software supply chain even before they get flagged by your typical Software Composition Analysis (SCA) or Dependency checking tools. Also shares the proof of concept code to detect malicious behavior…
SAST and SCA correlation (?)
На самом деле идея проверки SAST'ом open-source компонентов наталкивает меня на мысли об инструменте корреляции SCA и SAST (понимание как искать совпадения SAST и DAST уже есть). Здесь правда все упирается в то, чтобы находить функции уязвимой библиотеки в коде приложения. Предлагайте идеи, как вы это видите в чате :)
На самом деле идея проверки SAST'ом open-source компонентов наталкивает меня на мысли об инструменте корреляции SCA и SAST (понимание как искать совпадения SAST и DAST уже есть). Здесь правда все упирается в то, чтобы находить функции уязвимой библиотеки в коде приложения. Предлагайте идеи, как вы это видите в чате :)
Telegram
Security Wine Chat (бывший DevSecOps Chat)
Чат для обсуждения DevSecOps и постов канала @sec_devops
Вакансии и помощь в подборе сотрудников: https://radcop.online/informacionnaya-bezopasnost/virtual-ciso/rekruting-i-podbor-personala/
Услуги: https://radcop.online/
Председатель: @SurmatMG
Вакансии и помощь в подборе сотрудников: https://radcop.online/informacionnaya-bezopasnost/virtual-ciso/rekruting-i-podbor-personala/
Услуги: https://radcop.online/
Председатель: @SurmatMG
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 имеет возможность развертываться через Terraform. Таким образом, можно реализовать привычный доступ в формате PAM не конфликтуя с DevOps-командами.
Вот, кстати, хорошее видео, где на пальцах объясняют как работает решение.
#ops #k8s
В 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
Hashicorp
Announcing HashiCorp Boundary
Simple and secure remote access — to any system anywhere based on trusted identity.
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
Когда я ищу новый материал для канала, то часто сталкиваюсь со статьями и докладами, которые относятся к облачной безопасности. Как правило весь материал я отправляю сюда.
В этот раз я решил оформить это в виде подборки единым постом.
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
Telegram
CloudSec Wine
All about cloud security
Contacts:
@AMark0f
@dvyakimov
About DevSecOps:
@sec_devops
Contacts:
@AMark0f
@dvyakimov
About DevSecOps:
@sec_devops
CodeQL: SAST своими руками (и головой). Часть 1
Вводная статья от Паши Канна про CodeQL. Что это такое, как начать с этим работать и чем это может быть полезно. Ссылки в дополнительных материалах помогут разобрать вопрос чуть глубже.
Конечно, здесь ещё много чего нет про построение data flow, подводные камни и сопутствующие страдания, но на то это и первая часть. Кое-что про основы я писал здесь.
Кстати, также Паша запустил чат по обсуждению CodeQL.
https://habr.com/ru/company/swordfish_security/blog/541554/
#sast #dev
Вводная статья от Паши Канна про CodeQL. Что это такое, как начать с этим работать и чем это может быть полезно. Ссылки в дополнительных материалах помогут разобрать вопрос чуть глубже.
Конечно, здесь ещё много чего нет про построение data flow, подводные камни и сопутствующие страдания, но на то это и первая часть. Кое-что про основы я писал здесь.
Кстати, также Паша запустил чат по обсуждению CodeQL.
https://habr.com/ru/company/swordfish_security/blog/541554/
#sast #dev
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
Недавно вышла интересная статья про то, как исследователь получил возможность исполнять код на серверах компаний и внедрять бэкдоры в их приложения. Уязвимыми оказались такие гиганты, как Microsoft, Apple, PayPal и Tesla. Атака стала возможной благодаря особенности пакетных менеджеров, которые пытаются загрузить внутренние зависимости компаний, в том числе и из публичных репозиториев. Это касается и хранилищ артефактов, если в одном виртуальном репозитории смешаны внутренние и внешние пакеты.
Реализовать атаку довольно просто: находим имена приватных пакетов, создаем собственные версии с аналогичным названием, выкладываем в публичный репозиторий. Далее ждем, когда кто-то установит наш пакет вместо приватного пакета компании. На HackerOne есть репорт, который раскрывает всю подноготную атаки, включая "вредоносный" пакет для тестирования.
Защита от подобного рода атак описывается в новеньком документе Microsoft. Для Nexus и JFrog выпущены соответствующие рекомендации. Но какой-то серебряной пули, которая поможет здесь и сейчас, нет. Особенно в случае с npm, когда ваши разработчики не используют scope.
Кстати, ситуация с Dependency Confusion еще один звоночек в пользу создания своей баг-баунти программы. Ведь владельцы оных были уведомлены об уязвимости аж 7 месяцев назад.
Новость и разбор от @Khorcus
#dev #sca #attack #news
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
Неофициальное руководство, в котором описывается, как автоматически тестировать веб по проверкам уровня Level 1 стандарта ASVS с помощью OWASP ZAP. К методике также недавно появилась обзорная статья. В руководстве достаточно подробно написано, как завести ZAP под ASVS с применением пассивного сканирования. Также в репо прилагаются все необходимые скрипты .
https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide
#dast #dev
GitHub
GitHub - BlazingWind/OWASP-ASVS-4.0-testing-guide
Contribute to BlazingWind/OWASP-ASVS-4.0-testing-guide development by creating an account on GitHub.
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
В вопросах, касающихся уязвимостей в сторонних компонентах (цепочке поставок), одна из главных проблем - полнота сведений в базе данных. В частности речь идет о 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
GitHub
GitHub - google/oss-fuzz: OSS-Fuzz - continuous fuzzing for open source software.
OSS-Fuzz - continuous fuzzing for open source software. - google/oss-fuzz
Red_Hat_and_IT_Security.pdf
2.8 MB
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
Обзорная книга по безопасности в 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
Была немного тяжелая неделя, накопилось много идей, о чем написать, но это потом.
Сейчас мы тестируем Clubhouse и знакомимся с комьюнити DevSecOps
Присоединяйтесь. Будем говорить про метрики, азы, что надо знать при трудоустройстве и любые предложенные темы.
https://www.joinclubhouse.com/room/xn76O70a
#talks
Clubhouse
Join Clubhouse to find more great rooms.
Возвращаясь к теме 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
Первая утилита анализирует файл с определением зависимостей и проверяет, заняты ли имена приватных пакетов в публичных репозиториях. Работает для 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?
Что же будет, если эту политику выключить?
Спустя 6 минут после утечки происходит волна активности с IP-адресов в Нидерландах. Эти же IP-адреса связаны со спамом и узлами TOR. Почти сразу создаются экземпляры EC2. Очевидно, что это майнинг криптовалюты, а именно XMR (Monero).
Спустя 36 минут IP-адреса из Израиля используют секреты для доступа к S3. В это же время злоумышленник связывается с администратором требуя выкуп.
Итого 13 разных обращений к AWS в течение 24 часов и 4 злоумышленника выполнили действия, аналогичные описанным выше.
#secret
"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. То есть вы можете настраивать более жесткие политики контроля, если пользователь, скажем, входит в
#ops
До этого я немного касался нового решения 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
Каждый, кто когда-нибудь подходил к оценке рисков, связанных с Kubernetes, сталкивался со статьей от Microsoft "Threat matrix for Kubernetes". Она построена на базе ATT&CK матрицы, созданной организацией MITRE, которая до этого не подходила к безопасности контейнеров.
Вышла драфтовая версия MITRE ATT&CK матрицы для безопасности контейнеров. Она включает как риски обозначенные Microsoft, так и новые, например, выход за пределы контейнера, сборка образа злоумышленника на хосте, получение доступа к API и так далее.
#ops #k8s #attack