ENISA Threat Landscape for Supply Chain Attacks.pdf
4.8 MB
И сам отчет в приложении ☺️
Всем привет!
В новой версии Kubernetes – 1.22 появилось много интересных изменений, в том числе по безопасности.
Ребята из Aqua Security сделали небольшой обзор нововведений:
🍭 PodSecurity Admission Controller
🍭 Default Seccomp Profile
🍭 NetworkPolicyEndPort (перенесен в статус Beta)
🍭 Поддержка Rootless Containers
Все указанные возможности пока что в Alpha Phase, но уже заметно в какую сторону движется community и что можно ожидать в следующих релизах.
Аналогичный разбор сделала команда Sysdig, заодно указав deprecations версии 1.22
В новой версии Kubernetes – 1.22 появилось много интересных изменений, в том числе по безопасности.
Ребята из Aqua Security сделали небольшой обзор нововведений:
🍭 PodSecurity Admission Controller
🍭 Default Seccomp Profile
🍭 NetworkPolicyEndPort (перенесен в статус Beta)
🍭 Поддержка Rootless Containers
Все указанные возможности пока что в Alpha Phase, но уже заметно в какую сторону движется community и что можно ожидать в следующих релизах.
Аналогичный разбор сделала команда Sysdig, заодно указав deprecations версии 1.22
Aqua
Kubernetes Version 1.22: Security Features You Need to Know
A review of the security features in Kubernetes version 1.22 incl. PodSecurity admission controller, new sysctl support, rootless containers support & more
12 августа коллеги делают интересный вебинар по хранению persistent данных и резервному копированию в кубере
Вендоры, традиционно поставляющие продукты backup & recovery, сравнительно недавно начали выпускать функционал работы с Kubernetes, он часто сырой и требует доработки напильником.
О чем пойдет речь:
📌 Persistent данные в Kubernetes: особенности, требования, pros & cons.
📌 Как обеспечить резервное копирование приложений и баз данных.
📌 Какие инструменты поддерживают резервное копирование в Kubernetes, в чем их особенности
📌⚡️ Live демо: Резервное копирование в Kubernetes с помощью Cоmmvault Backup and Recovery и Veeam Kasten.
Регистрируйтесь по ссылке
https://events.webinar.ru/jet/PersistentDevSecOps
Вендоры, традиционно поставляющие продукты backup & recovery, сравнительно недавно начали выпускать функционал работы с Kubernetes, он часто сырой и требует доработки напильником.
О чем пойдет речь:
📌 Persistent данные в Kubernetes: особенности, требования, pros & cons.
📌 Как обеспечить резервное копирование приложений и баз данных.
📌 Какие инструменты поддерживают резервное копирование в Kubernetes, в чем их особенности
📌⚡️ Live демо: Резервное копирование в Kubernetes с помощью Cоmmvault Backup and Recovery и Veeam Kasten.
Регистрируйтесь по ссылке
https://events.webinar.ru/jet/PersistentDevSecOps
Привет!
По ссылке собрана удобная коллекция решений по DevSecOps, разбитая по классам:
🍭 Application Security Testing: SAST, DAST, SCA, ASOC, MAST
🍭 Protection: WAF, WaaP, RASP, Bot Mitigation, CI/CD Security
🍭 Services: Penetration Testing, Bug Bounty, Training, EASM
Для каждого класса приводится перечень решений (Enterprise, Open Source) и краткое описание назначения класса. О похожей подборке мы уже писали в этом посте.
Такие агрегаторы могут быть удобны, например, если у кого-то возникает вопрос – «А что вообще есть?». Помимо многочисленных awesome можно кидать ссылку на рассматриваемую подборку для первичного ознакомления
P.S. При желании можно добавить инструмент через функционал "Submit Tool" ☺️
По ссылке собрана удобная коллекция решений по DevSecOps, разбитая по классам:
🍭 Application Security Testing: SAST, DAST, SCA, ASOC, MAST
🍭 Protection: WAF, WaaP, RASP, Bot Mitigation, CI/CD Security
🍭 Services: Penetration Testing, Bug Bounty, Training, EASM
Для каждого класса приводится перечень решений (Enterprise, Open Source) и краткое описание назначения класса. О похожей подборке мы уже писали в этом посте.
Такие агрегаторы могут быть удобны, например, если у кого-то возникает вопрос – «А что вообще есть?». Помимо многочисленных awesome можно кидать ссылку на рассматриваемую подборку для первичного ознакомления
P.S. При желании можно добавить инструмент через функционал "Submit Tool" ☺️
Appsecmap
AppSec Map
A map of AppSec service providers and solutions
Всем привет!
Ребята из Bridgecrew проделали колоссальную работу по анализу общедоступных Helm charts: «We scanned thousands of open-source Helm charts available for reuse on ArtifactHub against common Kubernetes security and compliance policies via Checkov»
Результаты своей работы Bridgecrew описали в цикле статей (раз, два, три)
Первая статья посвящена статистике и ключевым findings:
🍭 71% просканированных repo содержит misconfigurations (всего было просканировано 618)
🍭 В 60% манифестов не были корректно реализованы resource quotas
🍭 Множество манифестов, где были допустимы privelegeEscalation
🍭 Манифесты не содержат readiness/liveness probes (25%), некорректные настройки тэгов для образов (latest или отсутствие)
Можно сделать очень простой вывод – «Доверяй, но проверяй». Helm chart очень удобный инструмент для deploy приложений. Однако, не следует «слепо ему доверять», например, можно его доработать с точки зрения ИБ и использовать у себя!
Подробности (по второй и третьей статье) в следующих постах ☺️
P.S. Это еще не все, ребята также поделились инструментом по сканированию ArtifuctHub (для работы требуется artifacthub API token/secret token), под капотом все тот же Checkov
Ребята из Bridgecrew проделали колоссальную работу по анализу общедоступных Helm charts: «We scanned thousands of open-source Helm charts available for reuse on ArtifactHub against common Kubernetes security and compliance policies via Checkov»
Результаты своей работы Bridgecrew описали в цикле статей (раз, два, три)
Первая статья посвящена статистике и ключевым findings:
🍭 71% просканированных repo содержит misconfigurations (всего было просканировано 618)
🍭 В 60% манифестов не были корректно реализованы resource quotas
🍭 Множество манифестов, где были допустимы privelegeEscalation
🍭 Манифесты не содержат readiness/liveness probes (25%), некорректные настройки тэгов для образов (latest или отсутствие)
Можно сделать очень простой вывод – «Доверяй, но проверяй». Helm chart очень удобный инструмент для deploy приложений. Однако, не следует «слепо ему доверять», например, можно его доработать с точки зрения ИБ и использовать у себя!
Подробности (по второй и третьей статье) в следующих постах ☺️
P.S. Это еще не все, ребята также поделились инструментом по сканированию ArtifuctHub (для работы требуется artifacthub API token/secret token), под капотом все тот же Checkov
Bridgecrew
Part 1: Top trends from analyzing the security posture of open-source Helm charts
In this open-source Helm security research, we scanned thousands of Helm charts available on Artifact Hub and are sharing our findings and trends.
Привет!
Продолжение истории Bridgecrew! После сбора статистических данных команда решила проанализировать наиболее часто встречающиеся Helm-dependencies.
Задача отчасти похожа на создание Software Bill of Materials (SBOM), только для Helm-chart: необходимо понять какие именно компоненты являются «зависимыми» и насколько они корректны с точки зрения ИБ.
В статье продемонстрированы графы с легендой:
🍭 Зеленый: сканируемый chart
🍭 Синий: зависимость (URI) ссылается на тот же Helm repository, что и сам chart
🍭 Черный: «локальные» зависимости chart (отсутствует URI, только local file path)
🍭 Красный: Все остальные зависимости
В результате анализа получилось собрать статистику о наиболее часто используемых зависимостях (одной из которых стала bitnami/postgresql) и сделать вывод, что существует большая фрагментация зависимостей, их массовое дублирование, которые можно было бы переиспользовать. В конце статьи Bridgecrew привели несколько рекомендаций о том, как можно повысить уровень ИБ в такой ситуации: Embed static analysis into your CI/CD pipeline, Understand your runtime posture, Audit third-party Infrastructure code, Increase awareness of IaC security, Automate posture information at the point of consumption
Продолжение истории Bridgecrew! После сбора статистических данных команда решила проанализировать наиболее часто встречающиеся Helm-dependencies.
Задача отчасти похожа на создание Software Bill of Materials (SBOM), только для Helm-chart: необходимо понять какие именно компоненты являются «зависимыми» и насколько они корректны с точки зрения ИБ.
В статье продемонстрированы графы с легендой:
🍭 Зеленый: сканируемый chart
🍭 Синий: зависимость (URI) ссылается на тот же Helm repository, что и сам chart
🍭 Черный: «локальные» зависимости chart (отсутствует URI, только local file path)
🍭 Красный: Все остальные зависимости
В результате анализа получилось собрать статистику о наиболее часто используемых зависимостях (одной из которых стала bitnami/postgresql) и сделать вывод, что существует большая фрагментация зависимостей, их массовое дублирование, которые можно было бы переиспользовать. В конце статьи Bridgecrew привели несколько рекомендаций о том, как можно повысить уровень ИБ в такой ситуации: Embed static analysis into your CI/CD pipeline, Understand your runtime posture, Audit third-party Infrastructure code, Increase awareness of IaC security, Automate posture information at the point of consumption
Bridgecrew
Part 2: Top trends from analyzing the security posture of open-source Helm charts - Bridgecrew Blog
In part two of our open-source Helm security research, we analyze Helm chart dependencies and provide recommendations for security best practices.
Всех с пятницей!
Завершающая часть захватывающей трилогии анализа Helm chart от Bridgecrew! В прошлой серии ребята выяснили, что самая популярная зависимость - bitnami/postgresql.
Ее chart проанализировали при помощи Checkov, чтобы понять насколько он безопасен. Примеры того, что удалось узнать (с точки зрения failed-проверок, приведены не все результаты):
High
🍭 «Ensure Containers Do Not Run With AllowPrivilegeEscalation». Контроль возможности повышения привилегий, например, дочерним процессом
Medium
🍭 «Ensure that the seccomp profile is set to docker/default or runtime/default». Ограничение возможностей контейнера. В версии Kubernetes 1.22 «Default Seccomp» находится в стадии Alpha (можно почитать тут и тут)
🍭 «Use read-only filesystem for containers where possible». Сохранение immutable-подхода контейнеров
Low
🍭 «Memory and CPU limits should be set». Ограничение ресурсов, потребляемых контейнером, например, для предупреждения DoS-атак
🍭 «Minimize the admission of containers with capabilities assigned». Ограничение Linux-capabilities контейнеров
В статье также разобраны варианты remediation указанных недостатков с отсылками на идеи «как сделать лучше» и с указанием «точек» в Helm chart, где нужно реализовать изменение.
Получается, что самая популярная зависимость, которую использовали во многих Helm chart содержит целый перечень потенциальных улучшений по ИБ, что вновь подводит к выводу - "Доверяй, но проверяй!"
Завершающая часть захватывающей трилогии анализа Helm chart от Bridgecrew! В прошлой серии ребята выяснили, что самая популярная зависимость - bitnami/postgresql.
Ее chart проанализировали при помощи Checkov, чтобы понять насколько он безопасен. Примеры того, что удалось узнать (с точки зрения failed-проверок, приведены не все результаты):
High
🍭 «Ensure Containers Do Not Run With AllowPrivilegeEscalation». Контроль возможности повышения привилегий, например, дочерним процессом
Medium
🍭 «Ensure that the seccomp profile is set to docker/default or runtime/default». Ограничение возможностей контейнера. В версии Kubernetes 1.22 «Default Seccomp» находится в стадии Alpha (можно почитать тут и тут)
🍭 «Use read-only filesystem for containers where possible». Сохранение immutable-подхода контейнеров
Low
🍭 «Memory and CPU limits should be set». Ограничение ресурсов, потребляемых контейнером, например, для предупреждения DoS-атак
🍭 «Minimize the admission of containers with capabilities assigned». Ограничение Linux-capabilities контейнеров
В статье также разобраны варианты remediation указанных недостатков с отсылками на идеи «как сделать лучше» и с указанием «точек» в Helm chart, где нужно реализовать изменение.
Получается, что самая популярная зависимость, которую использовали во многих Helm chart содержит целый перечень потенциальных улучшений по ИБ, что вновь подводит к выводу - "Доверяй, но проверяй!"
Bridgecrew
Part 3: Top trends from analyzing the security posture of open-source Helm charts - Bridgecrew Blog
In part three of our open-source Helm security research, we analyze one of the most commonly used dependencies from a security standpoint.
Привет!
Lens – достаточно удобная “IDE для Kubernetes”, возможности которой можно расширять при помощи extensions.
Например:
🍭 Aqua Security Starboard: отображение информации по уязвимостям в образах контейнеров и ошибках в конфигурации кластера
🍭 Certificate Info: удобное отображение информации об используемых сертификатах
🍭 Resource Map: графическое представление информации о взаимосвязи сущностей в кластере
🍭 Debug pods: extension, предоставляющий возможность debug из интерфейса Lens
Больше информации доступно по ссылке ☺️
Lens – достаточно удобная “IDE для Kubernetes”, возможности которой можно расширять при помощи extensions.
Например:
🍭 Aqua Security Starboard: отображение информации по уязвимостям в образах контейнеров и ошибках в конфигурации кластера
🍭 Certificate Info: удобное отображение информации об используемых сертификатах
🍭 Resource Map: графическое представление информации о взаимосвязи сущностей в кластере
🍭 Debug pods: extension, предоставляющий возможность debug из интерфейса Lens
Больше информации доступно по ссылке ☺️
GitHub
GitHub - lensapp/lens-extensions: List of Lens Extensions
List of Lens Extensions. Contribute to lensapp/lens-extensions development by creating an account on GitHub.
Всем привет!
«Масштаб» может привносить затруднения, про которые не думаешь на малых объемах. Это применимо и к манифестам Kubernetes: чем больше становится приложение, растет его функционал и возможности, тем в большую «кашу» превращается папка с конфигурациями.
В статье автор предлагает интересный подход к структуре хранения манифестов. Все строится вокруг создания пространства папок, где каждая из них представляет отдельный Kind (Deployment, Service, ConfigMap и т.д.).
Приводится наглядный пример использования подобного подхода и рекомендации автора:
🍭 Сокращайте длинные аббревиатуры привычными аналогами при именовании файлов (например,
🍭 Используйте идентичные имена файлов между «Kind-директориями»
🍭 Не используйте тип сущности в ее названии (например nginx-service.yaml)
🍭 Именуйте ресурсы по аналогии с именами файлов, в которых они определяются
Такой подход упрощает восприятие конфигурации приложения и сокращает вероятность ошибки (например, из-за разных способов написания service/svc). Удобен ли Вам подобный подход к хранению манифестов приложений, стали бы вы его использовать?
«Масштаб» может привносить затруднения, про которые не думаешь на малых объемах. Это применимо и к манифестам Kubernetes: чем больше становится приложение, растет его функционал и возможности, тем в большую «кашу» превращается папка с конфигурациями.
В статье автор предлагает интересный подход к структуре хранения манифестов. Все строится вокруг создания пространства папок, где каждая из них представляет отдельный Kind (Deployment, Service, ConfigMap и т.д.).
Приводится наглядный пример использования подобного подхода и рекомендации автора:
🍭 Сокращайте длинные аббревиатуры привычными аналогами при именовании файлов (например,
hpas вместо horizontalpodautoscalers)🍭 Используйте идентичные имена файлов между «Kind-директориями»
🍭 Не используйте тип сущности в ее названии (например nginx
🍭 Именуйте ресурсы по аналогии с именами файлов, в которых они определяются
Такой подход упрощает восприятие конфигурации приложения и сокращает вероятность ошибки (например, из-за разных способов написания service/svc). Удобен ли Вам подобный подход к хранению манифестов приложений, стали бы вы его использовать?
Boxunix
A Better Way of Organizing Your Kubernetes Manifest Files | Boxunix
How to organize your kubernetes files with a consitent, modular and adaptable approach
Привет!
Интересный подход к динамическому тестированию безопасности приложений и анализу API представили ребята из StackHawk.
Интеграция осуществляется через… GitHub (который уже поддерживает возможность использования Dependabot, CodeQL и предоставляет возможность реализации интеграций со сторонними решениями)
Все очень просто:
🍭 Добавляем StackHawk (Security, Codescanning alerts), это создаст workflow для анализа приложения
🍭 Адаптируем конфигурацию, генерируемую «по умолчанию»
🍭 Производим настройки на стороне StackHawk, осуществляем onboarding приложения, формируется файл конфигурации
🍭 Помещаем полученную конфигурацию в корень проекта. Все!
Теперь можно просматривать результаты анализа в GitHub, есть удобные ссылки на StackHawk. Возможно, подобные решения будут реализованы и другими vendor’ами.
Революционного ничего нет, но реализовано очень просто и удобно для пользователей GitHub, что не может не радовать ☺️
P.S. Короткое видео по настройке и использованию можно найти по ссылке
Интересный подход к динамическому тестированию безопасности приложений и анализу API представили ребята из StackHawk.
Интеграция осуществляется через… GitHub (который уже поддерживает возможность использования Dependabot, CodeQL и предоставляет возможность реализации интеграций со сторонними решениями)
Все очень просто:
🍭 Добавляем StackHawk (Security, Codescanning alerts), это создаст workflow для анализа приложения
🍭 Адаптируем конфигурацию, генерируемую «по умолчанию»
🍭 Производим настройки на стороне StackHawk, осуществляем onboarding приложения, формируется файл конфигурации
🍭 Помещаем полученную конфигурацию в корень проекта. Все!
Теперь можно просматривать результаты анализа в GitHub, есть удобные ссылки на StackHawk. Возможно, подобные решения будут реализованы и другими vendor’ами.
Революционного ничего нет, но реализовано очень просто и удобно для пользователей GitHub, что не может не радовать ☺️
P.S. Короткое видео по настройке и использованию можно найти по ссылке
StackHawk
API and Application Security Testing in GitHub Code Scanning
The new StackHawk code scanning integration in GitHub enables developers to find API and application security vulnerabilities where they're already working.
Всем привет!
По ссылке доступна простая, но крайне наглядная статья про Admission Controllers, что это такое и зачем это нужно.
Сперва автор рассказывает базовые принципы работы:
🍭 MutatingAdmissionWebhook. Может подтверждать/изменять создание сущности. Например, может изменить конфигурацию
🍭 ValidatingAdmissionWebhook. Может подтверждать создание сущности. Например, проверять что образ взят из корректного registry и только после этого запустить pod
Описывает принципы их работы, в какой момент запроса (create, update, delete) они «проявляют» себя, приводит некоторые примеры использования – «Когда это может пригодится?»
В завершении статьи автор приводит пример использования собственного MutatingAdmissionWebhook, который позволяет запустить pod на node только при наличии необходимых ресурсов. В противном случае к pod будет применен toleration.
Материал, хоть и простой, но крайне важный. Например, OPA также является Admission Controller’ом
По ссылке доступна простая, но крайне наглядная статья про Admission Controllers, что это такое и зачем это нужно.
Сперва автор рассказывает базовые принципы работы:
🍭 MutatingAdmissionWebhook. Может подтверждать/изменять создание сущности. Например, может изменить конфигурацию
🍭 ValidatingAdmissionWebhook. Может подтверждать создание сущности. Например, проверять что образ взят из корректного registry и только после этого запустить pod
Описывает принципы их работы, в какой момент запроса (create, update, delete) они «проявляют» себя, приводит некоторые примеры использования – «Когда это может пригодится?»
В завершении статьи автор приводит пример использования собственного MutatingAdmissionWebhook, который позволяет запустить pod на node только при наличии необходимых ресурсов. В противном случае к pod будет применен toleration.
Материал, хоть и простой, но крайне важный. Например, OPA также является Admission Controller’ом
Nillsf
How to run your own admission controller on Kubernetes
I’ve done some work with a customer lately, where I helped them build a mutating admission controller on Kubernetes. The goal of this blog post is to explain what admission controllers are and how to deploy them on Kubernetes. To keep the content of the post…
Привет!
В 1.22 версии Kubernetes представили «наследника» PSP – Pod Security Admission (PSA). Инструмент пока что находится в стадии [Alpha], но уже можно к нему присматриваться.
В статье автор делает краткий разбор PSA и рассматривает вопросы:
🍭 Pod Security Standards //Privileged, Baseline, Restricted
🍭 Применение политик //Namespace, Cluster-wide
🍭 Policy Modes, управление политиками //Enforce, Audit, Warn. "Комбинации" режимов: например, Enforce для одной политики и Warn для другой
В завершении можно найти упоминание о рекомендациях по миграции с PSP на PSA.
PS. Напоминаем, что PSA находится в стадии [Alpha] и лучше пока что не использовать его «в бою», а просто изучать. Всем отличной пятницы и выходных!!!
В 1.22 версии Kubernetes представили «наследника» PSP – Pod Security Admission (PSA). Инструмент пока что находится в стадии [Alpha], но уже можно к нему присматриваться.
В статье автор делает краткий разбор PSA и рассматривает вопросы:
🍭 Pod Security Standards //Privileged, Baseline, Restricted
🍭 Применение политик //Namespace, Cluster-wide
🍭 Policy Modes, управление политиками //Enforce, Audit, Warn. "Комбинации" режимов: например, Enforce для одной политики и Warn для другой
В завершении можно найти упоминание о рекомендациях по миграции с PSP на PSA.
PS. Напоминаем, что PSA находится в стадии [Alpha] и лучше пока что не использовать его «в бою», а просто изучать. Всем отличной пятницы и выходных!!!
Medium
Hands on with Kubernetes Pod Security Admission
Kubernetes v1.22 pr alpha release for the successor of Pod Security Policy (PSP) (which is scheduled for deprecation in v1.25)…
Привет!
K8s-vault-webhook – Admission Controller, который позволяет подставлять секреты в Pod, Secrets, ConfigMaps.
На текущий момент поддерживаются следующие хранилища: HashiCorp Vault, AWS Secret Manager, Azure Key Vault и GCP Secret Manager.
Решение обладает следующим функционалом:
🍭 Аутентификация в хранилище
🍭 Извлечение секрета с последующей подстановкой в создаваемую/обновляемую сущность
🍭 «Инъекция» секрета происходит непосредственно в процесс
Подробнее про установку, настройку и примеры интеграции с хранилищами можно почитать в документации.
K8s-vault-webhook – Admission Controller, который позволяет подставлять секреты в Pod, Secrets, ConfigMaps.
На текущий момент поддерживаются следующие хранилища: HashiCorp Vault, AWS Secret Manager, Azure Key Vault и GCP Secret Manager.
Решение обладает следующим функционалом:
🍭 Аутентификация в хранилище
🍭 Извлечение секрета с последующей подстановкой в создаваемую/обновляемую сущность
🍭 «Инъекция» секрета происходит непосредственно в процесс
Подробнее про установку, настройку и примеры интеграции с хранилищами можно почитать в документации.
GitHub
GitHub - OT-CONTAINER-KIT/k8s-vault-webhook: A k8s vault webhook is a Kubernetes webhook that can inject secrets into Kubernetes…
A k8s vault webhook is a Kubernetes webhook that can inject secrets into Kubernetes resources by connecting to multiple secret managers - OT-CONTAINER-KIT/k8s-vault-webhook
Привет!
В tutorial разобран пример анализа событий, генерируемых Audit Policy k8s, по следующей схеме:
🍭 В качестве Backend выбираем Log Backend
🍭 Разворачиваем FluentBit, который будет выполнять функцию log forwarder: "забирать" из Log Backend и "направлять" в Falco
🍭 Разворачиваем Falco с Falcosidekick-UI, которые будут собирать логи, анализировать их (используемые проверки, более подробная информация) и отображать результаты в web-интерфейсе
В статье приведены все необходимые команды и ссылки для самостоятельного воспроизведения в demo-окружении.
В завершении представлен PoC на примере правила
В tutorial разобран пример анализа событий, генерируемых Audit Policy k8s, по следующей схеме:
🍭 В качестве Backend выбираем Log Backend
🍭 Разворачиваем FluentBit, который будет выполнять функцию log forwarder: "забирать" из Log Backend и "направлять" в Falco
🍭 Разворачиваем Falco с Falcosidekick-UI, которые будут собирать логи, анализировать их (используемые проверки, более подробная информация) и отображать результаты в web-интерфейсе
В статье приведены все необходимые команды и ссылки для самостоятельного воспроизведения в demo-окружении.
В завершении представлен PoC на примере правила
«Create/Modify Configmap With Private Credentials»: создаем ConfigMap, это порождает событие в Audit Log, которое забирает FluentBit и передает в Falco. Срабатывает правило, результат отображается в web-интерфейсеFalco
Detect Malicious Behaviour on Kubernetes API Server through gathering Audit Logs by using FluentBit - Part 2
Introduction In the previous blog post, we had talked about the Audit Logs in more detail, this post is a continuation of the previous blog post, so I suggest you take a look at the previous blog post before continuing reading. The only difference in this…
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
Опрос: что вы думаете о DevSecOps?
Коллеги из PT расшифровали доклад с PHDays о применении Security Gym в обучении разработчиков писать безопасный код: "Безопасность для айтишников: как научить разработчиков устранять уязвимости и создавать безопасные приложения". Помимо теории (описания уязвимости в коде), обучение также предполагает написание функциональных и security-тестов, участие в CTF.
Также PT запустили опрос: "Что вы думаете о DevSecOps?", в котором просят пользователей Habr рассказать о том, как обстоят дела с безопасной разработкой в компании. Предлагаю помочь им собрать как можно больше данных для исследования :)
#talks #dev
Коллеги из PT расшифровали доклад с PHDays о применении Security Gym в обучении разработчиков писать безопасный код: "Безопасность для айтишников: как научить разработчиков устранять уязвимости и создавать безопасные приложения". Помимо теории (описания уязвимости в коде), обучение также предполагает написание функциональных и security-тестов, участие в CTF.
Также PT запустили опрос: "Что вы думаете о DevSecOps?", в котором просят пользователей Habr рассказать о том, как обстоят дела с безопасной разработкой в компании. Предлагаю помочь им собрать как можно больше данных для исследования :)
#talks #dev
Привет!
Продолжая тематику визуализации и использования OPA для контроля состояния кластера по ИБ можно обратить внимание на Gatekeeper Policy Manager.
Он представляет из себя read-only web-интерфейс, в котором можно получить информацию об используемых политиках:
🍭 Статус политики
🍭 Код политики, написанный на REGO
🍭 Детальная информация о нарушениях политик (Violations)
🍭 Есть возможность отображения всех нарушений в табличной форме (Report View)
Недавно вышло обновление – v0.5.0, про которое можно почитать в обзорной статье и в changelog соответственно
Продолжая тематику визуализации и использования OPA для контроля состояния кластера по ИБ можно обратить внимание на Gatekeeper Policy Manager.
Он представляет из себя read-only web-интерфейс, в котором можно получить информацию об используемых политиках:
🍭 Статус политики
🍭 Код политики, написанный на REGO
🍭 Детальная информация о нарушениях политик (Violations)
🍭 Есть возможность отображения всех нарушений в табличной форме (Report View)
Недавно вышло обновление – v0.5.0, про которое можно почитать в обзорной статье и в changelog соответственно
GitHub
GitHub - sighupio/gatekeeper-policy-manager: A simple to use web-based OPA Gatekeeper policy manager
A simple to use web-based OPA Gatekeeper policy manager - sighupio/gatekeeper-policy-manager
Всем привет!
Во многих рекомендациях по ИБ (да и не только) рекомендуется указывать Resource Quotas. Одной из сложностей, с которой можно столкнуться – непонятно сколько именно требуется CPU и RAM для создаваемого ресурса.
В качестве «отправной» точки можно использовать Goldilocks: утилита, используя Vertical Pod Autoscaler (VPA), может подсказать:
🍭 Guaranteed QoS (Current/Guaranteed)
🍭 Burstable QoS (Current/Burstable)
🍭 Рекомендации по оптимизации (YAML-шаблоны с Requests и Limits)
Суть работы проста – утилита создает VPA для каждого deployment, после – "запрашивает" у него информацию и отображает ее пользователю.
Больше сведений о том, как задать Resource Quotas, можно найти в статье Ultimate Kubernetes Resource Planning Guide
Во многих рекомендациях по ИБ (да и не только) рекомендуется указывать Resource Quotas. Одной из сложностей, с которой можно столкнуться – непонятно сколько именно требуется CPU и RAM для создаваемого ресурса.
В качестве «отправной» точки можно использовать Goldilocks: утилита, используя Vertical Pod Autoscaler (VPA), может подсказать:
🍭 Guaranteed QoS (Current/Guaranteed)
🍭 Burstable QoS (Current/Burstable)
🍭 Рекомендации по оптимизации (YAML-шаблоны с Requests и Limits)
Суть работы проста – утилита создает VPA для каждого deployment, после – "запрашивает" у него информацию и отображает ее пользователю.
Больше сведений о том, как задать Resource Quotas, можно найти в статье Ultimate Kubernetes Resource Planning Guide
GitHub
GitHub - FairwindsOps/goldilocks: Get your resource requests "Just Right"
Get your resource requests "Just Right". Contribute to FairwindsOps/goldilocks development by creating an account on GitHub.
Привет!
Интересная статья от Aqua Security про «Advanced Persistent Threat Techniques Used in Container Attacks», подготовленная командой Nautilis (R’n’D команда Aqua).
В каждой атаке было идентифицировано следующее:
🍭 Running a vanilla container image. Использование Alpine-образа
🍭 Escaping to the host. Mount файловой системы host для последующего получения доступа
🍭 Downloading a malicious noscript. Загрузка и исполнение noscript cronb.sh
🍭 Loading and executing the malware. Выполнение атаки, например, установка cryptominer и сокрытие присутствия
В самой статье приведены анализ noscript и rootkits, использующихся злоумышленниками для совершения атаки и сокрытия собственного присутствия.
В конце – как обычно, некоторые рекомендации по противодействию
P.S. Всех с пятницей! ☺️☺️☺️
Интересная статья от Aqua Security про «Advanced Persistent Threat Techniques Used in Container Attacks», подготовленная командой Nautilis (R’n’D команда Aqua).
В каждой атаке было идентифицировано следующее:
🍭 Running a vanilla container image. Использование Alpine-образа
🍭 Escaping to the host. Mount файловой системы host для последующего получения доступа
🍭 Downloading a malicious noscript. Загрузка и исполнение noscript cronb.sh
🍭 Loading and executing the malware. Выполнение атаки, например, установка cryptominer и сокрытие присутствия
В самой статье приведены анализ noscript и rootkits, использующихся злоумышленниками для совершения атаки и сокрытия собственного присутствия.
В конце – как обычно, некоторые рекомендации по противодействию
P.S. Всех с пятницей! ☺️☺️☺️
Aquasec
Advanced Persistent Threat Techniques Used in Container Attacks
Team Nautilus provides a deep analysis of an intensive campaign targeting cloud native environments that use advanced persistent threat (APT) techniques
👍1
Привет!
Статья, посвященная контролю outbound traffic. Ребята начали с того, что ответили на вопрос – «А какие внешние соединения устанавливаются нашими приложениями?». После получения ответа команда задумалась о том, как лучше всего контролировать трафик в долгосрочной перспективе:
🍭 Нужна возможность написания политик, контролирующих трафик от specific source до specific destination
🍭 Требуется возможность использования DNS
🍭 Alerting, в случае если трафик отправляется на недоверенный источник
Ребята не смогли найти решение, которое соответствовало бы всем требованиям (статья от 2020 года) и решили начать с малого – контролировать трафик по портам с использованием Network Policy и Calico в качестве CNI.
Посмотрели в сторону Istio, но такое решение их не устроило. Дальше? DNS inspection! Однако и тут были сложности – доступные на тот момент enterprise-решения не могли быть «помещены» в K8S. К чему в итоге пришла команда после попыток и анализа различных подходов?
Ответом стали «эксклюзивные» proxy для всех внешних сервисов, с которыми устанавливаются соединения. Возможно, звучит немного страшно и overkill, но такой подход устроил команду, и она его реализовала. Как именно – рассказано в самом конце статьи ☺️
Статья, посвященная контролю outbound traffic. Ребята начали с того, что ответили на вопрос – «А какие внешние соединения устанавливаются нашими приложениями?». После получения ответа команда задумалась о том, как лучше всего контролировать трафик в долгосрочной перспективе:
🍭 Нужна возможность написания политик, контролирующих трафик от specific source до specific destination
🍭 Требуется возможность использования DNS
🍭 Alerting, в случае если трафик отправляется на недоверенный источник
Ребята не смогли найти решение, которое соответствовало бы всем требованиям (статья от 2020 года) и решили начать с малого – контролировать трафик по портам с использованием Network Policy и Calico в качестве CNI.
Посмотрели в сторону Istio, но такое решение их не устроило. Дальше? DNS inspection! Однако и тут были сложности – доступные на тот момент enterprise-решения не могли быть «помещены» в K8S. К чему в итоге пришла команда после попыток и анализа различных подходов?
Ответом стали «эксклюзивные» proxy для всех внешних сервисов, с которыми устанавливаются соединения. Возможно, звучит немного страшно и overkill, но такой подход устроил команду, и она его реализовала. Как именно – рассказано в самом конце статьи ☺️
Monzo
Controlling outbound traffic from Kubernetes
Всем привет!
Peirates – open source утилита, которую можно использовать для penetration test кластеров Kubernetes.
Основной фокус – privilege escalation и lateral movement.
На текущий момент поддерживаются такие возможности как:
🍭 Reverse shell на node, через pod с hostPath-mounting
🍭 Извлечение service account tokens из secret
🍭 Запуск token-dumping команды для всех pods
🍭 Получение IAM учетных данных из AWS или GCP
🍭 Распространение самого себя в другие pods, эмулируя lateral movement
Утилита обладает удобным интерфейсом - меню, из которого можно выбрать требуемое действие. Чуть больше информации можно прочитать по ссылке. Важно (!): Peirates attacks Kubernetes cluster. Talk to your lawyer and the cluster owners before using this tool.
Peirates – open source утилита, которую можно использовать для penetration test кластеров Kubernetes.
Основной фокус – privilege escalation и lateral movement.
На текущий момент поддерживаются такие возможности как:
🍭 Reverse shell на node, через pod с hostPath-mounting
🍭 Извлечение service account tokens из secret
🍭 Запуск token-dumping команды для всех pods
🍭 Получение IAM учетных данных из AWS или GCP
🍭 Распространение самого себя в другие pods, эмулируя lateral movement
Утилита обладает удобным интерфейсом - меню, из которого можно выбрать требуемое действие. Чуть больше информации можно прочитать по ссылке. Важно (!): Peirates attacks Kubernetes cluster. Talk to your lawyer and the cluster owners before using this tool.
GitHub
GitHub - inguardians/peirates: Peirates - Kubernetes Penetration Testing tool
Peirates - Kubernetes Penetration Testing tool. Contribute to inguardians/peirates development by creating an account on GitHub.