Fine grained personal access token в GitHub
Привет!
До недавнего времени personal access tokens (PAT) GitHub’a предоставляли достаточно широкие полномочия. Например, предоставлялся доступ ко всем repo, к которым был доступ у пользователя, генерирующего PAT. Это не всегда было удобно разработчикам и точно не соответствовало практикам ИБ. Например, такой подход не соответствует need-to-know и least privilege принципам.
18 октября GitHub открыл доступ к fine grained personal access tokens, которые находятся в стадии beta. Их задача – сделать предоставление доступа к repo максимально гибким и удобным.
Например:
🍭 Можно давать доступ ко всем repo или только к тем, которые выберет разработчик
🍭 Доступ только к Issues определенного repo
🍭 Возможность просмотра pull requests и многое другое
Всего добавлено более 50 granular permissions, которые можно устанавливать в значения «no access», «read», «read and write». Еще один приятный бонус – возможность просмотра использования токенов и их отзыв владельцами в случае необходимости.
Привет!
До недавнего времени personal access tokens (PAT) GitHub’a предоставляли достаточно широкие полномочия. Например, предоставлялся доступ ко всем repo, к которым был доступ у пользователя, генерирующего PAT. Это не всегда было удобно разработчикам и точно не соответствовало практикам ИБ. Например, такой подход не соответствует need-to-know и least privilege принципам.
18 октября GitHub открыл доступ к fine grained personal access tokens, которые находятся в стадии beta. Их задача – сделать предоставление доступа к repo максимально гибким и удобным.
Например:
🍭 Можно давать доступ ко всем repo или только к тем, которые выберет разработчик
🍭 Доступ только к Issues определенного repo
🍭 Возможность просмотра pull requests и многое другое
Всего добавлено более 50 granular permissions, которые можно устанавливать в значения «no access», «read», «read and write». Еще один приятный бонус – возможность просмотра использования токенов и их отзыв владельцами в случае необходимости.
The GitHub Blog
Introducing fine-grained personal access tokens for GitHub
Fine-grained personal access tokens offer enhanced security to developers and organization owners, to reduce the risk to your data of compromised tokens.
👍5
Подписи и аттестации
Всем привет!
Когда говорят про контроль supply chain зачастую вспоминают про подпись чего-бы-то-ни-было. Все как обычно – есть пара private/public key, используя которые можно гарантировать, что мы получили артефакт именно от его Автора.
Но есть небольшой нюанс. Может случиться так, что Автор подписывает сам артефакт без анализа того, что находится внутри. Например, анализа кода, который помещается в контейнер, анализа open source зависимостей, анализа образа контейнера и т.д.
Как быть в такой ситуации? Ответ отлично разобран в статье "Policy and Attestations", в которой рассматривается термин «Аттестация». Грубо говоря – набор некоторых утверждений, которые характерны для того или иного артефакта, подписанные электронной подписью. Например, те же результаты сканирования образа.
Именно так (анализируя аттестации) Kyverno может проверять когда последний раз образ был просканирован и принять решение – стоит ли его запускать. Об этом use case мы писали тут, там тоже есть немного про аттестацию и то, как она реализуется в Cosign.
Всем привет!
Когда говорят про контроль supply chain зачастую вспоминают про подпись чего-бы-то-ни-было. Все как обычно – есть пара private/public key, используя которые можно гарантировать, что мы получили артефакт именно от его Автора.
Но есть небольшой нюанс. Может случиться так, что Автор подписывает сам артефакт без анализа того, что находится внутри. Например, анализа кода, который помещается в контейнер, анализа open source зависимостей, анализа образа контейнера и т.д.
Как быть в такой ситуации? Ответ отлично разобран в статье "Policy and Attestations", в которой рассматривается термин «Аттестация». Грубо говоря – набор некоторых утверждений, которые характерны для того или иного артефакта, подписанные электронной подписью. Например, те же результаты сканирования образа.
Именно так (анализируя аттестации) Kyverno может проверять когда последний раз образ был просканирован и принять решение – стоит ли его запускать. Об этом use case мы писали тут, там тоже есть немного про аттестацию и то, как она реализуется в Cosign.
Medium
Policy and Attestations
Best Practices for Supply Chain Security
👍3
Проверка конфигурации GitHub
Всем привет!
Еще одно решение, похожее на Chain-bench – Legitify. Проверяет настройку параметров безопасности GitHub.
В отличие от Chain-bench, Legitify не использует CIS Software Supply Chain Security Guide, а руководствуется тем, что написано в OSSF Scorecards и в Policies.
Например, есть проверки того, что:
🍭 Включена защита веток (branch protection)
🍭 Применяется SAST и Fuzzing
🍭 (Не) допустимо использование force push
🍭 У repo большое количество администраторов и другие
Подробнее про проверки, реализованные при помощи Policies, а также про способы приведения в соответствие можно прочитать тут.
Всем привет!
Еще одно решение, похожее на Chain-bench – Legitify. Проверяет настройку параметров безопасности GitHub.
В отличие от Chain-bench, Legitify не использует CIS Software Supply Chain Security Guide, а руководствуется тем, что написано в OSSF Scorecards и в Policies.
Например, есть проверки того, что:
🍭 Включена защита веток (branch protection)
🍭 Применяется SAST и Fuzzing
🍭 (Не) допустимо использование force push
🍭 У repo большое количество администраторов и другие
Подробнее про проверки, реализованные при помощи Policies, а также про способы приведения в соответствие можно прочитать тут.
GitHub
GitHub - Legit-Labs/legitify: Detect and remediate misconfigurations and security risks across all your GitHub and GitLab assets
Detect and remediate misconfigurations and security risks across all your GitHub and GitLab assets - Legit-Labs/legitify
👍5
Ingress в Kubernetes
Всем привет!
Еще одна неплохая статья из темы «основы». Может быть полезна тем, кто только приступил к изучению k8s.
Одной из первых задач, с которой столкнется пользователя кластера – "как организовать доступ к моим ресурсам со стороны «внешних» ресурсов?". Есть несколько вариантов, но сегодня рассмотрим один – Ingress.
В статье рассматриваются такие вопросы как:
🍭 Что такое Ingress и зачем он нужен?
🍭 Как устроен Ingress, как он работает?
🍭 Что такое Nginx Ingress Controller и какими возможностями он обладает?
Минималистично-понятная статья, в которой нет ничего лишнего. А если Вас в большей степени интересует информационная безопасность, то можно ознакомиться с разделом Security и Hardening Guide из официальной документации на решение.
Всем привет!
Еще одна неплохая статья из темы «основы». Может быть полезна тем, кто только приступил к изучению k8s.
Одной из первых задач, с которой столкнется пользователя кластера – "как организовать доступ к моим ресурсам со стороны «внешних» ресурсов?". Есть несколько вариантов, но сегодня рассмотрим один – Ingress.
В статье рассматриваются такие вопросы как:
🍭 Что такое Ingress и зачем он нужен?
🍭 Как устроен Ingress, как он работает?
🍭 Что такое Nginx Ingress Controller и какими возможностями он обладает?
Минималистично-понятная статья, в которой нет ничего лишнего. А если Вас в большей степени интересует информационная безопасность, то можно ознакомиться с разделом Security и Hardening Guide из официальной документации на решение.
www.weave.works
NGINX Ingress Controller 101 - Load Balancing for Kubernetes
Learn how to use nginx ingress controllers: production-grade controllers that run alongside NGINX open source in a Kubernetes environment.
👍1
DevSecOps Playbook
Всем привет!
Еще один взгляд на систематизацию DevSecOps подходов и практик, которые можно реализовывать для повышения защищенности разрабатываемого ПО.
Материал включает в себя рекомендации по блокам:
🍭 Development environment
🍭 Source code management
🍭 CI/CD pipelines and automation
🍭 Deployment
🍭 Organizational techniques
Всего предложено порядка 60 активностей. Для каждой из них, помимо описания, приводится ее приоритет, сложность реализации и ссылки на стандарты для получения дополнительных сведений.
Всем привет!
Еще один взгляд на систематизацию DevSecOps подходов и практик, которые можно реализовывать для повышения защищенности разрабатываемого ПО.
Материал включает в себя рекомендации по блокам:
🍭 Development environment
🍭 Source code management
🍭 CI/CD pipelines and automation
🍭 Deployment
🍭 Organizational techniques
Всего предложено порядка 60 активностей. Для каждой из них, помимо описания, приводится ее приоритет, сложность реализации и ссылки на стандарты для получения дополнительных сведений.
GitHub
GitHub - 6mile/DevSecOps-Playbook: This is a step-by-step guide to implementing a DevSecOps program for any size organization
This is a step-by-step guide to implementing a DevSecOps program for any size organization - 6mile/DevSecOps-Playbook
🔥9❤1👍1
Управление GitOps Repos
Всем привет!
GitOps – подход, который позволяет управлять конфигурацией ИТ-инфраструктуры, используя подходы и практики разработки ПО. Например, есть централизованный repo, в котором хранятся интересующие нас конфигурации и инструмент, который применяет эти конфигурации. У такого подхода много преимуществ – начиная от «прозрачности» и заканчивая минимизацией вероятности возникновения configuration drift.
Но как правильно организовать тот самый repo с конфигурациями? Должен ли это быть 1 repo, в котором содержится все-все-все или это должно быть несколько repo? Например, отдельные для production и development-окружений?
Размышления на эту тему можно найти в статье. Автор рассматривает 4 варианта:
🍭 Один repo для приложения и поддерживающей его ИТ-инфраструктуры
🍭 Отдельный repo для ИТ-инфраструктуры с несколькими «долгоиграющими» ветками (main и development, например)
🍭 Несколько repo – по одному на каждое окружение
Для каждого варианта приведены его плюсы и минусы. Например, наличие (отсутствие) управления доступом на изменения, вероятность «расхождения» конфигураций различных окружений и т.д.
В конце статьи Автор дает ссылки на инструменты Harness (CI, CD, GitOps), в разработке которых участвует. По ссылкам можно больше узнать про решения и их open source версии.
Всем привет!
GitOps – подход, который позволяет управлять конфигурацией ИТ-инфраструктуры, используя подходы и практики разработки ПО. Например, есть централизованный repo, в котором хранятся интересующие нас конфигурации и инструмент, который применяет эти конфигурации. У такого подхода много преимуществ – начиная от «прозрачности» и заканчивая минимизацией вероятности возникновения configuration drift.
Но как правильно организовать тот самый repo с конфигурациями? Должен ли это быть 1 repo, в котором содержится все-все-все или это должно быть несколько repo? Например, отдельные для production и development-окружений?
Размышления на эту тему можно найти в статье. Автор рассматривает 4 варианта:
🍭 Один repo для приложения и поддерживающей его ИТ-инфраструктуры
🍭 Отдельный repo для ИТ-инфраструктуры с несколькими «долгоиграющими» ветками (main и development, например)
🍭 Несколько repo – по одному на каждое окружение
Для каждого варианта приведены его плюсы и минусы. Например, наличие (отсутствие) управления доступом на изменения, вероятность «расхождения» конфигураций различных окружений и т.д.
В конце статьи Автор дает ссылки на инструменты Harness (CI, CD, GitOps), в разработке которых участвует. По ссылкам можно больше узнать про решения и их open source версии.
DEV Community
Managing the ‘Git’ in ‘GitOps’: 4 Ways to Structure Code in Your GitOps Repos
Implementing GitOps practices will take your software delivery pipelines to the next level....
Обход eBPF
Всем привет!
Последнее время все чаще и чаще можно слышать про eBPF, которая привносит много нового и удобного не только для ИТ, но и для ИБ-специалистов.
Появляются средства защиты, которые могут анализировать kernel calls что может быть крайне полезно для идентификации подозрительных событий и инцидентов ИБ. Однако, как и у любой технологии у eBPF есть «ограничения», про которые важно помнить.
В статье Автор на примерах разбирает способы обхода средств защиты, использующих eBPF:
🍭 В качестве подопытного используется Tetragon от Cilium (будет работать и с другими аналогичными решениями)
🍭 Создается «подопытный» Ubuntu-контейнер, в котором запускается
🍭 Автор немного модифицирует
В статье много пояснений, примеров кода и рассуждений о возможных способах обхода. Это вовсе не означает, что eBPF – «плохой» инструмент, скорее наоборот. Главное помнить, что абсолютов не существует и не стоит «слепо» полагаться на автоматизацию.
Всем привет!
Последнее время все чаще и чаще можно слышать про eBPF, которая привносит много нового и удобного не только для ИТ, но и для ИБ-специалистов.
Появляются средства защиты, которые могут анализировать kernel calls что может быть крайне полезно для идентификации подозрительных событий и инцидентов ИБ. Однако, как и у любой технологии у eBPF есть «ограничения», про которые важно помнить.
В статье Автор на примерах разбирает способы обхода средств защиты, использующих eBPF:
🍭 В качестве подопытного используется Tetragon от Cilium (будет работать и с другими аналогичными решениями)
🍭 Создается «подопытный» Ubuntu-контейнер, в котором запускается
cat /etc/host. cat использует write system call, что видно при помощи Tetragon🍭 Автор немного модифицирует
write для того, чтобы Tetragon не смог увидеть произошедшее событиеВ статье много пояснений, примеров кода и рассуждений о возможных способах обхода. Это вовсе не означает, что eBPF – «плохой» инструмент, скорее наоборот. Главное помнить, что абсолютов не существует и не стоит «слепо» полагаться на автоматизацию.
www.form3.tech
Bypassing eBPF-based Security Enforcement Tools
During penetration tests and red team engagements, eBPF-based security observability and runtime enforcement tools can make it difficult to use public offensive security tools and techniques, as they are more often detected and blocked. However, eBPF-based…
👍5
Practical Guide to Secure Software Supply Chain with Sigstore
Всем привет!
По ссылке доступно очень-очень-очень-очень-очень много текста, посвященного защите supply chain с использованием механизма подписи и аттестации.
Материал включает в себя следующие разделы:
🍭 Sigstore: введение
🍭 Cosign: средство подписи и верификации
🍭 Fulcio: certification authority, выступающий в роли «доверенного» посредника
🍭 Rekor: хранение информации об мета-данных артефактов
🍭 Sigstore: как использовать рассмотренные выше материалы
Кстати, рассмотренный инструментарий поддерживают и другие проекты. Например, Trivy может генерировать отчет в формате Cosign Vulnerability Scan, а Kyverno может «читать» подписи и аттестации Cosign (функционал пока что в beta). И это не единственные примеры 😊
Всем привет!
По ссылке доступно очень-очень-очень-очень-очень много текста, посвященного защите supply chain с использованием механизма подписи и аттестации.
Материал включает в себя следующие разделы:
🍭 Sigstore: введение
🍭 Cosign: средство подписи и верификации
🍭 Fulcio: certification authority, выступающий в роли «доверенного» посредника
🍭 Rekor: хранение информации об мета-данных артефактов
🍭 Sigstore: как использовать рассмотренные выше материалы
Кстати, рассмотренный инструментарий поддерживают и другие проекты. Например, Trivy может генерировать отчет в формате Cosign Vulnerability Scan, а Kyverno может «читать» подписи и аттестации Cosign (функционал пока что в beta). И это не единственные примеры 😊
PUPUWEB
Practical Guide to Secure Software Supply Chain with Sigstore - PUPUWEB
Learn how to digitally sign software artifacts to ensure a safer chain of custody that can be traced back to the source. The article is for anyone new to
👍4
Snyk Learn: обновление учебных курсов
Snyk продолжает радовать отличными материалами и обучающими курсами в частности. На сайте Snyk Learn можно найти несколько интерактивных курсов, посвященных DevSecOps:
🍭 Insecure Design
🍭 Directory Traversal
🍭 SQL Injection
🍭 Container does not drop all capabilities
Мы уже писали про этот ресурс в 2021 году. На тот момент курсов было гораздо меньше. Приятно, что ребята не останавливаются и продолжают развивать данное направление.
Snyk продолжает радовать отличными материалами и обучающими курсами в частности. На сайте Snyk Learn можно найти несколько интерактивных курсов, посвященных DevSecOps:
Java, JS, Python, Golang, PHP, C#, Kubernetes.
Например:🍭 Insecure Design
🍭 Directory Traversal
🍭 SQL Injection
🍭 Container does not drop all capabilities
Мы уже писали про этот ресурс в 2021 году. На тот момент курсов было гораздо меньше. Приятно, что ребята не останавливаются и продолжают развивать данное направление.
Snyk Learn
Free Developer Security Education & Snyk Product Training | Snyk Learn
Free security education and Snyk product training designed for developers in .
🔥4
Удаление «старых» образов/контейнеров в Kubernetes
Всем привет!
Не всегда получается поддерживать актуальность используемых образов/контейнеров в кластерах Kubernetes. Альтернативный сценарий – unused images, которые могут храниться на узлах.
Хорошо, что у Kubernetes есть собственный механизм garbage collection, которому посвящена статья. Если просто – то многое зависит от размера образа и времени его последнего использования. Например, большой образ, который использовался неделю назад будет с большей вероятностью удален, чем небольшой и используемый «вчера».
Однако, это можно настроить через манифесты Kubelet:
🍭 Указать необходимый disk threshold
🍭 Задавать определенное количество dead containers (по умолчанию отсутствует)
🍭 Количество минут, через которое контейнер будет считаться «старым» и станет кандидатом на устранение (по умолчанию отсутствует) и не только
Статья 2021 года, но механизмы актуальны. Есть направления по переходу на механизм eviction, который может заменить garbage collection в будущем.
Всем привет!
Не всегда получается поддерживать актуальность используемых образов/контейнеров в кластерах Kubernetes. Альтернативный сценарий – unused images, которые могут храниться на узлах.
Хорошо, что у Kubernetes есть собственный механизм garbage collection, которому посвящена статья. Если просто – то многое зависит от размера образа и времени его последнего использования. Например, большой образ, который использовался неделю назад будет с большей вероятностью удален, чем небольшой и используемый «вчера».
Однако, это можно настроить через манифесты Kubelet:
🍭 Указать необходимый disk threshold
🍭 Задавать определенное количество dead containers (по умолчанию отсутствует)
🍭 Количество минут, через которое контейнер будет считаться «старым» и станет кандидатом на устранение (по умолчанию отсутствует) и не только
Статья 2021 года, но механизмы актуальны. Есть направления по переходу на механизм eviction, который может заменить garbage collection в будущем.
How-To Geek
How to Clean Up Old Containers and Images in Your Kubernetes Cluster
An active Kubernetes cluster can accumulate old containers and images. Ensuring discarded resources are removed when redundant helps to free up resources on your cluster’s nodes. Here’s how to approach garbage collection in Kubernetes.
👍2
AdminNetworkPolicy
Всем привет!
У сетевых политик Kubernetes есть известный недостаток – отсутствие cluster wide сущностей. По крайней мере у «Native Network Policy». Некоторые CNI, такие как Cilium и Calico, реализуют требуемый механизм. Именно по этой причине невозможно создать сетевую политику, которая, применится ко всему кластеру.
У Kubernetes есть разные SIG, одной из которых является Network. В рамках одного из enhancements Авторы предлагают нововведение – AdminNetworkPolicy, которая решает указанную проблему. При этом разработчики не смогут на нее влиять, а на «обычную» Network Policy – вполне.
Это достигается за счет нового ресурса – AdminNeworkPolicy, который работает в нескольких «режимах»:
🍭 Deny: запрет всего трафика
🍭 Allow: трафик разрешен
🍭 Pass: самое интересное – «решение» о том, разрешать трафик или нет, передается на уровень обычной NetworkPolicy
Увы, функционал пока не реализован, но сам подход достаточно интересный. Больше про user stories и примеры того, как это можно использовать можно найти в описании enhancement. А если хочется еще больше, то можно посмотреть короткое видео (~ 22 минуты), где Авторы рассказывают про этот механизм.
Всем привет!
У сетевых политик Kubernetes есть известный недостаток – отсутствие cluster wide сущностей. По крайней мере у «Native Network Policy». Некоторые CNI, такие как Cilium и Calico, реализуют требуемый механизм. Именно по этой причине невозможно создать сетевую политику, которая, применится ко всему кластеру.
У Kubernetes есть разные SIG, одной из которых является Network. В рамках одного из enhancements Авторы предлагают нововведение – AdminNetworkPolicy, которая решает указанную проблему. При этом разработчики не смогут на нее влиять, а на «обычную» Network Policy – вполне.
Это достигается за счет нового ресурса – AdminNeworkPolicy, который работает в нескольких «режимах»:
🍭 Deny: запрет всего трафика
🍭 Allow: трафик разрешен
🍭 Pass: самое интересное – «решение» о том, разрешать трафик или нет, передается на уровень обычной NetworkPolicy
Увы, функционал пока не реализован, но сам подход достаточно интересный. Больше про user stories и примеры того, как это можно использовать можно найти в описании enhancement. А если хочется еще больше, то можно посмотреть короткое видео (~ 22 минуты), где Авторы рассказывают про этот механизм.
GitHub
enhancements/keps/sig-network/2091-admin-network-policy at master · kubernetes/enhancements
Enhancements tracking repo for Kubernetes. Contribute to kubernetes/enhancements development by creating an account on GitHub.
👍1
YaraHunter: идентификация malware
Привет!
YaraHunter – небольшая утилита, которая позволяет идентифицировать вредоносное ПО. С правилами, на основании которых происходит идентификация можно ознакомиться тут.
При помощи утилиты можно:
🍭 Искать вредоносное ПО в образах контейнеров, контейнерах и на файловой системе
🍭 Встраивать в CI/CD pipeline
🍭 Получать результаты в машиночитаемом формате – JSON
Пока что YaraHunter находится на стадии разработки. Одной из интересных функций будет интеграция с ThreatMapper – решением по управлению уязвимостями от того же Deepfence, про который мы писали тут. Увы, roadmap, как и документация на решение, пока что возвращают 404.
Привет!
YaraHunter – небольшая утилита, которая позволяет идентифицировать вредоносное ПО. С правилами, на основании которых происходит идентификация можно ознакомиться тут.
При помощи утилиты можно:
🍭 Искать вредоносное ПО в образах контейнеров, контейнерах и на файловой системе
🍭 Встраивать в CI/CD pipeline
🍭 Получать результаты в машиночитаемом формате – JSON
Пока что YaraHunter находится на стадии разработки. Одной из интересных функций будет интеграция с ThreatMapper – решением по управлению уязвимостями от того же Deepfence, про который мы писали тут. Увы, roadmap, как и документация на решение, пока что возвращают 404.
GitHub
GitHub - deepfence/YaraHunter: 🔍🔍 Malware scanner for cloud-native, as part of CI/CD and at Runtime 🔍🔍
🔍🔍 Malware scanner for cloud-native, as part of CI/CD and at Runtime 🔍🔍 - deepfence/YaraHunter
👍2
GuardDog: идентификация вредоносных python-пакетов
Всем привет!
Команда Datadog подготовила отличную статью, посвященную анализу безопасности python-пакетов и инструменту, который был создан для их анализа.
После исследования нескольких пакетов, команда пришла к выводу, что большинство вредоносных пакетов используются для Initial Access (например, typosquatting), Code Execution (eval/exec для получения нужного файла) и Exfiltration (передача данных различными способами).
Для идентификации подобных пакетов ребята разработали GuardDog. Инструмент не анализирует пакеты на наличие CVE, как делает большинство SCA-решений, а использует SAST-практики. Примечательно, что анализу подлежит не только исходный код, но и метаданные пакета.
В качестве основы GuardDog используется Semgrep, с правилами идентификации уязвимостей в коде можно ознакомиться тут. Для анализа метаданных ребята подготовили собственные проверки, которые доступны вот тут.
В итоге получилась достаточно занятная утилита. Настоятельно рекомендуем ознакомиться со статьей – в ней есть примеры запуска, много сведений об анализе python-пакетов и о том, что они могут содержать. Читается легко и непринужденно. Как раз то, что нужно для пятницы!
Всем привет!
Команда Datadog подготовила отличную статью, посвященную анализу безопасности python-пакетов и инструменту, который был создан для их анализа.
После исследования нескольких пакетов, команда пришла к выводу, что большинство вредоносных пакетов используются для Initial Access (например, typosquatting), Code Execution (eval/exec для получения нужного файла) и Exfiltration (передача данных различными способами).
Для идентификации подобных пакетов ребята разработали GuardDog. Инструмент не анализирует пакеты на наличие CVE, как делает большинство SCA-решений, а использует SAST-практики. Примечательно, что анализу подлежит не только исходный код, но и метаданные пакета.
В качестве основы GuardDog используется Semgrep, с правилами идентификации уязвимостей в коде можно ознакомиться тут. Для анализа метаданных ребята подготовили собственные проверки, которые доступны вот тут.
В итоге получилась достаточно занятная утилита. Настоятельно рекомендуем ознакомиться со статьей – в ней есть примеры запуска, много сведений об анализе python-пакетов и о том, что они могут содержать. Читается легко и непринужденно. Как раз то, что нужно для пятницы!
Datadoghq
Finding malicious PyPI packages through static code analysis: Meet GuardDog
GuardDog is an open-source tool to identify malicious PyPI packages through source code and metadata analysis
👍5
API Hacking Tree & API Security Checklist
Всем привет!
По ссылке доступен mind map, посвященный API Hacking. Материал структурирован по двум основным направлениям: Reconnaissance и Security Testing.
Указанные направления детализируются далее, например:
🍭 Search for APIs
🍭 Enumerate endpoints/methods
🍭 Excessive data exposure
🍭 Improper asset management и другие
Для каждого «листа» дерева приводится дополнительная информация: способы реализации, ссылки на полезные материалы/статьи.
Может быть удобно использовать еще с одним проектом – API Security Checklist. У последнего есть даже перевод на русский язык.
Всем привет!
По ссылке доступен mind map, посвященный API Hacking. Материал структурирован по двум основным направлениям: Reconnaissance и Security Testing.
Указанные направления детализируются далее, например:
🍭 Search for APIs
🍭 Enumerate endpoints/methods
🍭 Excessive data exposure
🍭 Improper asset management и другие
Для каждого «листа» дерева приводится дополнительная информация: способы реализации, ссылки на полезные материалы/статьи.
Может быть удобно использовать еще с одним проектом – API Security Checklist. У последнего есть даже перевод на русский язык.
Whimsical
KARTIK GUPTA
Whimsical combines whiteboards and docs in an all-in-one collaboration hub.
👍5
Supply Chain: защита SCM
Всем привет!
Статья, посвященная анализу ИБ систем управления исходным кодом (Source Code Management, SCM) на примере GitHub. В статье Автор определяет 3 основные цели злоумышленника, вокруг которых в дальнейшем будет построена статья. Этими целями являются: Submit malicious source code, Delete source code, Push a release tag pointing to vulnerable commit.
Далее Автор рассматривает каждую цель с двух сторон:
🍭 Read Team: что надо сделать, чтобы достичь целей?
🍭 Blue Team: что надо сделать, чтобы помешать злоумышленнику?
Отличительной особенностью статьи является наличие Attack Trees и Defense Trees, которые визуализирую действия злоумышленника или защитников. Для каждой цели описывается как ее можно достичь или рекомендации, как этому можно противодействовать.
В заключение статьи можно найти перечень возможностей GitHub, которые упоминались в статье. В целом рассмотренный подход можно применять и к другим SCM (GitLab, Bitbucket и т.д.).
«Деревья» доступны на GitHub. Если верить Автору, то материал будет дорабатываться со временем.
Всем привет!
Статья, посвященная анализу ИБ систем управления исходным кодом (Source Code Management, SCM) на примере GitHub. В статье Автор определяет 3 основные цели злоумышленника, вокруг которых в дальнейшем будет построена статья. Этими целями являются: Submit malicious source code, Delete source code, Push a release tag pointing to vulnerable commit.
Далее Автор рассматривает каждую цель с двух сторон:
🍭 Read Team: что надо сделать, чтобы достичь целей?
🍭 Blue Team: что надо сделать, чтобы помешать злоумышленнику?
Отличительной особенностью статьи является наличие Attack Trees и Defense Trees, которые визуализирую действия злоумышленника или защитников. Для каждой цели описывается как ее можно достичь или рекомендации, как этому можно противодействовать.
В заключение статьи можно найти перечень возможностей GitHub, которые упоминались в статье. В целом рассмотренный подход можно применять и к другим SCM (GitLab, Bitbucket и т.д.).
«Деревья» доступны на GitHub. Если верить Автору, то материал будет дорабатываться со временем.
Medium
SLSA dip — At the Source of the problem!
This article is part of a multi-part series about the security of the software supply chain. We will be analyzing in depth each component…
👍3
Supply Chain: защита Build
Всем привет!
Продолжение вчерашнего поста, посвященного защите окружения разработки. На этот раз рассматривается Build-окружение.
Как и в предыдущем материале Автор определяет 3 основные цели злоумышленника:
🍭 Compromise the Build artifact
🍭 Compromise the self-hosted runner
🍭 Pivot to other resources
Далее рассматриваются Attack и Defense Trees. Материал содержит много ссылок на сведения по теме, конфигурацию окружения и лучшие практики, посвященные тематике. Итоговое «дерево» доступно по ссылке или на GitHub Автора.
Всем привет!
Продолжение вчерашнего поста, посвященного защите окружения разработки. На этот раз рассматривается Build-окружение.
Как и в предыдущем материале Автор определяет 3 основные цели злоумышленника:
🍭 Compromise the Build artifact
🍭 Compromise the self-hosted runner
🍭 Pivot to other resources
Далее рассматриваются Attack и Defense Trees. Материал содержит много ссылок на сведения по теме, конфигурацию окружения и лучшие практики, посвященные тематике. Итоговое «дерево» доступно по ссылке или на GitHub Автора.
Medium
SLSA dip — It’s Build Time!
This article is part of a multi-part series about the security of the software supply chain. We will be analyzing in depth each component…
👍3
Всем привет!
А вы участвуете в Highload 24-25 ноября в Москве?
Если да, то приходите к нам на стенд "Инфосистемы Джет", пообщаемся, ответим на ваши вопросы, поделимся опытом:
🕶 как делать DevSecOps в крупных компаниях,
🕶 как создать гибкую отказоустойчивую инфраструктуру,
🕶 как настроить интегрированный мониторинг,
🕶 как защищать контейнеры и обеспечить безопасность разработки
🔥 В треке «DevOps в Enterprise» наш эксперт Юрий Семенюков расскажет о том, как и на что можно заменить enterprise-решения и инструменты в части платформ управления контейнерами.
🎁 На нашем стенде можно сыграть в тематический квиз и получить призы)
Увидимся на Highload!!!
А вы участвуете в Highload 24-25 ноября в Москве?
Если да, то приходите к нам на стенд "Инфосистемы Джет", пообщаемся, ответим на ваши вопросы, поделимся опытом:
🕶 как делать DevSecOps в крупных компаниях,
🕶 как создать гибкую отказоустойчивую инфраструктуру,
🕶 как настроить интегрированный мониторинг,
🕶 как защищать контейнеры и обеспечить безопасность разработки
🔥 В треке «DevOps в Enterprise» наш эксперт Юрий Семенюков расскажет о том, как и на что можно заменить enterprise-решения и инструменты в части платформ управления контейнерами.
🎁 На нашем стенде можно сыграть в тематический квиз и получить призы)
Увидимся на Highload!!!
🔥8👏2🌭2👻2
Доброго пятничного утра!
Хотите поиграть?
Заходите на страничку, созданную по мотивам нашего участия в Highload и проходите квиз!
Первые 100 участников, ответившие верно на 60% вопросов получат в качестве приза классные DevSecOps носки 🎁
Там же вы найдете вакансии и видео-ролик о нашей команде.
Пройти квиз
Хотите поиграть?
Заходите на страничку, созданную по мотивам нашего участия в Highload и проходите квиз!
Первые 100 участников, ответившие верно на 60% вопросов получат в качестве приза классные DevSecOps носки 🎁
Там же вы найдете вакансии и видео-ролик о нашей команде.
Пройти квиз
👍6🎉5🔥2
The State of Kubernetes Open Source Security.pdf
737.1 KB
The State of Kubernetes Open Source Security
Привет!
В приложении доступен отчет от Armo, посвященный использованию open source решений для защиты Kubernetes. Были опрошены 200 специалистов различных ролей из Америки, Европы и APAC.
Результаты оказались достаточно интересными:
🍭 Больше половины компаний использует open source. И не один (в среднем – около 3-4 решений). Тут все просто: как правило OSS решает одну задачу, чего бывает недостаточно
🍭 Больше всего commercial решений там, где требуется runtime. ServiceMesh, анализ конфигураций – как правило open source
🍭 Самое большое опасение в commercial-решениях – это… blackbox! Недостаточно видимости того, что «внутри»
🍭 Самая большая сложность по мнению опрошенных – интеграция таких решений в существующее окружение. Отчасти это может быть обусловлено их «количеством»
🍭 И, конечно же, K8S Security не «самостоятельная дисциплина», а часть программы Cloud Security. Надеемся, что и у нас будет также
В отчете есть еще много чего интересного: challenges, частота сканирования, time-to-fix и т.д. Большое количество графики, текст по сути. Рекомендуем!
Привет!
В приложении доступен отчет от Armo, посвященный использованию open source решений для защиты Kubernetes. Были опрошены 200 специалистов различных ролей из Америки, Европы и APAC.
Результаты оказались достаточно интересными:
🍭 Больше половины компаний использует open source. И не один (в среднем – около 3-4 решений). Тут все просто: как правило OSS решает одну задачу, чего бывает недостаточно
🍭 Больше всего commercial решений там, где требуется runtime. ServiceMesh, анализ конфигураций – как правило open source
🍭 Самое большое опасение в commercial-решениях – это… blackbox! Недостаточно видимости того, что «внутри»
🍭 Самая большая сложность по мнению опрошенных – интеграция таких решений в существующее окружение. Отчасти это может быть обусловлено их «количеством»
🍭 И, конечно же, K8S Security не «самостоятельная дисциплина», а часть программы Cloud Security. Надеемся, что и у нас будет также
В отчете есть еще много чего интересного: challenges, частота сканирования, time-to-fix и т.д. Большое количество графики, текст по сути. Рекомендуем!
👍5
Приглашаем принять участие в серии вебинаров «Как крупному бизнесу развивать ИТ за счет публичного облака и делать это безопасно».
Эксперты «Инфосистемы Джет» и Yandex Cloud раскроют тему с двух сторон: ИТ и ИБ, поэтому участие будет интересно как ИТ-менеджменту, так и ИБ-специалистам.
2 декабря, 11:00–12:30
«Как использовать облака в инфраструктуре предприятия»:
🔹Сценарии применения публичного облака для крупного бизнеса
🔹Локализация ИТ-инфраструктуры в России на базе облака
🔹Безопасность облачных сред
Зарегистрироваться
9 декабря, 11:00–12:30
«Безопасность публичных облаков для крупных компаний»:
🔹5 вопросов, которые нужно решить перед началом миграции
🔹Подводные камни, встречающиеся при миграции в облако. Что нужно учесть?
🔹Экспертный подход к защите публичного облака
Зарегистрироваться
Эксперты «Инфосистемы Джет» и Yandex Cloud раскроют тему с двух сторон: ИТ и ИБ, поэтому участие будет интересно как ИТ-менеджменту, так и ИБ-специалистам.
2 декабря, 11:00–12:30
«Как использовать облака в инфраструктуре предприятия»:
🔹Сценарии применения публичного облака для крупного бизнеса
🔹Локализация ИТ-инфраструктуры в России на базе облака
🔹Безопасность облачных сред
Зарегистрироваться
9 декабря, 11:00–12:30
«Безопасность публичных облаков для крупных компаний»:
🔹5 вопросов, которые нужно решить перед началом миграции
🔹Подводные камни, встречающиеся при миграции в облако. Что нужно учесть?
🔹Экспертный подход к защите публичного облака
Зарегистрироваться
🔥6
Общий взгляд на анализ безопасности K8S
Всем привет!
В первой статье собрана информация о возможных ИБ-недостатках Kubernetes, агрегированная по таким вектором атак, как:
🍭 Attack K8S Components (api-server, etcd, kubelet, kube-proxy)
🍭 Attack the external services
🍭 Attack the business pod
🍭 Container escape
Вторая статья посвящена иным векторам атак:
🍭 Lateral movement
🍭 Attack on third-party components
Обе статьи неплохо описывает концепты и возможные действия злоумышленника. Например, на что обращать внимание на стадии reconnaissance и на что в первую очередь обратят внимание. Материал не содержит что-либо «космическое». Однако, даже такие дефекты можно найти во многих инсталляциях K8S. Радует то, что поправить это не сложно и есть много информации о том, как это сделать.
Завершает статьи перечень недостатков в конфигурации pod’ов и перечень CVE, на которые обязательно стоит обратить внимание с точки зрения ИБ, сгруппированные по компонентам, которым они «принадлежат».
Всем привет!
В первой статье собрана информация о возможных ИБ-недостатках Kubernetes, агрегированная по таким вектором атак, как:
🍭 Attack K8S Components (api-server, etcd, kubelet, kube-proxy)
🍭 Attack the external services
🍭 Attack the business pod
🍭 Container escape
Вторая статья посвящена иным векторам атак:
🍭 Lateral movement
🍭 Attack on third-party components
Обе статьи неплохо описывает концепты и возможные действия злоумышленника. Например, на что обращать внимание на стадии reconnaissance и на что в первую очередь обратят внимание. Материал не содержит что-либо «космическое». Однако, даже такие дефекты можно найти во многих инсталляциях K8S. Радует то, что поправить это не сложно и есть много информации о том, как это сделать.
Завершает статьи перечень недостатков в конфигурации pod’ов и перечень CVE, на которые обязательно стоит обратить внимание с точки зрения ИБ, сгруппированные по компонентам, которым они «принадлежат».
Tutorial Boy
A Detailed Talk about K8S Cluster Security from the Perspective of Attackers (Part 1)
👍3