Определение уязвимостей, для исправления которых следует отдать приоритет, и обеспечение того, чтобы эти исправления действительно сделали вашу систему более безопасной, — одна из самых сложных задач, с которыми может столкнуться команда безопасности.

И тут на помощь приходит Vulnerability Exploitability eXchange (VEX) и о нем идет речь в статье "How a Vulnerability Exploitability eXchange can help healthcare prioritize cybersecurity risk".

VEX это концепция и machine-readable формат, которая может использоваться со SBOM, так и без него. Его основная цель дать понятие к чему уязвим данный продукт и дать рекомендации по исправлению. При этом он учитывает, что наличие уязвимости не говорит о ее эксплотируемости в конкретном случае (non-exploitable vulnerabilities). И имеет статус:
- Not affected
- Affected
- Fixed
- Under Investigation

Данная информация призвана упростить определение приоритетов исправления уязвимостей. Пример VEX можно посмотреть тут.

В общем авторы статьи рисуют будущее в духе: SBOM+VEX+SLSA

P.S. Из статьи мне понравилась фраза: "Without the ability to see into what we must protect, it can be difficult to determine how to quickly reduce risk."

Мои слайды "Специфика расследования инцидентов в контейнерах" c KazHackStan 2022.

Буду рад ответить на любые вопросы в комментариях!

P.S. Обратите внимание, что некоторые спрашивают и ведут диалог в чате канала.

Хочу обратить отдельное внимание на Kubelet Checkpoint API из презентации "Специфика расследования инцидентов в контейнерах" (слайд 34) c KazHackStan 2022.

Это реально крутое будущее как для security, так и для IT, на пример, для реализации live migration. Пока что данное API в Kubernetes находится в ContainerCheckpoint feature gate, который по умолчанию отключен, и очень ограничен и упрощен:

POST /checkpoint/{namespace}/{pod}/{container}

Тоесть пока что можно просто сделать checkpoint/snapshot и потом в ручную с ним поработать. Но мы то знаем что под капотом у него CRIU (Checkpoint and Restore in Userspace), который может это и восстанавливать и запускать! Полностью с этим можно поиграться сейчас можно в Docker при активации Docker Checkpoint (экспериментальная фича).

А так представьте, что можно будет брать и контейнер с атакующим переносить (делать live migration) в sandbox cluster и там наблюдать и изучать его действия ;)

Слайды моего коллеги "Pentesting Kubernetes: From Zero to Hero" c VolgaCTF 2022.

Задавайте свои вопросы в комментариях!

Выложили видео и слайды с ArgoCon 2022. Это мероприятие от создателей таких проектов как: Argo CD, Argo Workflows, Argo Rollouts, Argo Events и соответственно о них.

Не обошлось и без докладов про связь данных проектов с security. Я для себя выделил:
- "Attacking Argo CD with Argo CD (and then Defending)" - говорящее название - любой продукт нужно готовить правильно!
- "Securing GitOps Supply Chain with Sigstore and Kyverno" - подпись образов и их проверка с помощью Policy Engine Kyverno и Sigstore (слайды, код).
- "Secure by Default with GitOps - A Guide to OPA with Argo CD" - подпись образов и их проверка с помощью Policy Engine OPA Gatekeeper и Sigstore (слайды, код).
- "Using Argo Project to Help Elastic infoSec Team in Securing Elastic" - очень рекомендую посмотреть тем командам что строят свой SOC на ELK стеке в Kubernetes - вы скорее всего и Argo проекты захотите себе взять после этого (слайды).

Запуск контейнера в ручную от Ивана Величко;)

Последнее время я много пишу про безопасность образов. И возникает вопрос, а как дела обстоят у нашего Luntry и как мы смотрим на данный аспект. Ведь в нашем составе также есть сторонние компоненты и в них появляются известные уязвимости. И так по порядку, что мы делаем и что предоставляем:
1) Стараемся своевременно все патчить. Но это не всегда просто и все равно есть окно между моментом, когда это находит наш же сканер (да у нас есть сканер на известные CVE) и моментом когда обновленная версия раскатывается клиентом.
2) Переходим на distroless образы. Снижаем false positive срабатывания сканера на известные CVE, уменьшаем attack surface и возможности для атакующего.
3) Предоставляем модели поведения (behaviour models) для Luntry на наши микросервисы. В случае попыток эксплуатации известных CVE или не известных уязвимостей (0-days) наш движок обнаружит аномалию и проинформирует клиента.
4) Предоставляем AppArmor для наших микросервисов. В случае попыток эксплуатации известных CVE или не известных (0-days) подсистема ядра Linux просто не даст запуститься тому, что не прописано в AppArmor профиле.
5) Предоставляем NetworkPolicy для наших микросервисов. Если атакующий каким-то образом все-таки смог запустить вредоносную логику, то по сети он не сможет общаться с сервисами клиента, да и вообще не со всеми компонентами нашей системы.

На мой взгляд это супер набор, который сторонний вендор может сделать и предоставить клиенту, для обоснование безопасности своего продукта на ряду со SBOM. И в моем идеальном мире будущего - сторонний вендор, аутсорсер должен предоставлять это на свою разработку, а клиент только использовать и контролировать, реализую концепцию ZeroTrust.

Сегодня поговорим об одном тонком моменте связанным с автоматической генерацией NetworkPolicy. Реализуя данную фичу в нашем Luntry, мы предварительно проанализировали подобную функциональность в других решениях и с удивлением обнаружили, что никто не учитывал специфику labels, которые есть у Pods ...

Если сказать проще, то при генерации NetworkPolicy в этих решениях в podSelector попадали абсолютно ВСЕ labels - типа pod-template-hash, minor-version и подобные легко/часто меняющиеся labels. Это автоматом означало, что при их изменении, применение NetworkPolicy просто отваливалась. В итоге, с такими политиками приходится еще и возится вручную или часто их пере генерировать и пере применять.

Так что важно при работе с NetworkPolicy выделить/определить labels по которым будет применяться сетевая политика ;)

Сегодня и завтра пройдет ежегодный eBPF Summit . Старт в 18:30 по Мск. Трансляцию всех докладов всех двух дней можно посмотреть здесь:
- День 1
- День 2

Там море интересных докладов! Я же для себя отметил:
- Signed eBPF Programs: A Cross-Platform Analysis
- When you need to overcome your fear and build your own data-driven eBPF firewall
- Securing systems with eBPF Linux Security Module
- Using eBPF in system security
- Applied eBPF for cross platform security research
- Analysis of offensive capabilities of eBPF and implementation of a rootkit

P.S. Для ряда презентаций первого дня в описании доклада уже доступны слайды!

Сегодня хочу рассказать про один интересный/забавный момент, что недавно со мной поделились SOC команды из наших клиентов.

Но сначала поясню что у нас в Luntry есть функциональность Runtime Security, которая позволяет строить поведенческие модели для микросервисов (выглядят они в виде графа взаимоотношений между процессами). Отхождения от модели поведения создаёт аномалию и на неё уже реагирует SOC. Это как бы их классический сценарий работы.

Но порой они лезут глубже и изучают что вообще микросервисы делают и из чего состоят. И находят просто ужас/кошмар разработки. На пример, цепочку вызовов: java -> python -> bash -> perl …ну и это уже эскалируют на Лидов разработки, которых такое тоже повергает в шок =)

PS Для SOC такие цепочки вызовов также выглядят очень подозрительно и напоминают закрепление ;)

На просторах сети попалась очень добротная статья "Kubernetes Security Best Practices Part 2: Network Policies" - про нативные NetworkPolicy (не забываем что есть и кастомные от Calico и Cilium).

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

Отдельно обращу ваше внимание на раздел про "Deny-all NetworkPolicy", так как далеко не все понимают истинный смысл данной политики (и скорее используют на автомате, бездумно).

А так же в статье отдельно четко прописан момент про "NetworkPolicies have to be defined on both sides" - не забывайте ;)

После релиза PCI Security Standards Council документа "Guidance for Containers and Container Orchestration Tools" исследователи продолжают его анализировать и оценивать его применимость к Kubernetes. Так в новой статье "The Challenges of Assessing Kubernetes clusters for PCI Compliance" автор рассматривает проблемы/вызовы с которыми может столкнуться аудитор при рассмотрении сред Kubernetes в виду их разнообразия (не забываем, что Kubernetes это фреймворк и каждый его готовит и использует по своему). Фундаментально автор рассматривает 2 важных аспекта:
1) Managed against Unmanaged - тут и возможность проверить настройки Control Plane и точное расположение файлов и имен или вообще как отдельный кейс OpenShift.
2) Kubernetes Versions - достаточно сказать об очень динамичном развитии Kubernetes с появлением новых возможностей (в стадиях “alpha” , “beta”, “GA”), так и с исчезновением старых (“deprecated”).

Так что некорректное соотношение гайдов к окружению может дать абсолютно непрогнозируемые результаты (false positive или false negative).

В официальном блоге появилась емкая и короткая заметка c очень говорящим названием "Kubernetes 1.25: alpha support for running Pods with user namespaces".

Если кратко, то она о фичи которая позволяет контейнерным процессам работать в отдельном пространстве (user namespace), отличном от хостового. И root в одном не является root в другом. Что также позволяет уменьшить возможный ущерб в случае эксплотации ряда уязвимостей в контейнере.

Для работы с этой фичей необходимо:
1) Включенный UserNamespacesStatelessPodsSupport feature gate
2) Настройка "hostUsers: false" в спецификации Pod
3) Container Runtime с соответствующей поддержкой: CRI-O >= v1.25 или containerd >= 1.7 (еще не вышла)

Также в документации есть более детальный пример использования данной фичи в разделе "Use a User Namespace With a Pod".

P.S. Кстати, не путайте эту фичу с KubeletInUserNamespace, появившейся в 1.22.

P.S.S. Для полного погружения в тему изучите 1 и 2.

На днях прошла конференция KubeHuddle 2022 в расписании которой есть много всего интересного, а видео уже доступно [1,2,3,4]. На пример:

- eBPF or sidecars?
- Securing Kubernetes with Open Policy Agent
- Hacking Kubernetes Like a Beginner with kdigger 🔥
- Secret Management: The Soft Way

- Hacking Kubernetes: Live Demo Marathon 🔥
- Who Can You Really Trust?
- Step by step Kubernetes observability with eBPF
- How to protect your Kubernetes cluster using Crowdsec
- Policy + Cloud Controllers = Secure Scalable Dev-Centric Infrastructure.

- EBPF and Kubernetes - Next level observability
- BumbleBee: Or How I Learned To Stop Worrying And Love eBPF

P.S. Видео с eBPF Summit 2022 также уже доступно ;)

Статья "Exploiting Distroless Images" с прикольной техникой эксплотации в контейнерах на базе gcr.io/distroless/base, которая позволяет читать, писать произвольные файлы и выполнять команды в этом distroless image!

А все это базируется на присутствующей внутри этого образа OpenSSL! Да, shell внутри такого образа нет, но зато можно использовать interactive command prompt от OpenSSL ;)

Таким образом, атакующий, получивший доступ к Kubernetes кластеру, может, через установленный OpenSSL в distroless base образе, прочитать service account tokens (SA), прокинутые secrets и даже получить интерактивное выполнение команд через загрузку custom shell.

Помните в одном из прошлых постов писал, что не все Distroless Images одинаковые (static/base/cc/interpreted)?!

Так что distroless images это не панацея, а лишь одна из техник усиления (hardening) - и никто behavior monitoring, AppArmor не отменял.

P.S. О данной проблеме/особенности было сообщено Google в августе 2021 и они решили не фиксить это.

Обновляя свой тренинг по безопасности Kubernetes до соответствующей последней доступной версии 1.25, поймал себя на мысли, что она для меня стала в один ряд с версией 1.22 по вкладу в аспекты безопасности. То есть стала одной из любимых, если так можно по этому вопросу выразиться) Понятное дело, что много классных нововведений и изменений там еще находиться в стадии alpha, но это не принижает их вклада.

Также сегодня хочу сказать, что наша небольшая команда Luntry продолжает медленно, но верно расти и искать новых единомышленников! Сейчас мы ищем:
- Middle/Senior Go Developer - работа с Kubernetes operators и высокой нагрузкой.
- Frontend/Full-stack-разработчик (Middle/Senior) - работа с незаурядными интерфейсами, графиками, графами и API.

Можно откликаться как там, так и писать на прямую мне - репост приветствуется =)

Из статьи "Introducing Wolfi – the first Linux (Un)distro designed for securing the software supply chain" вы узнаете о дистрибутиве Wolfi (хотя авторы для него придумали название undistro) для supply chain security и он сфокусирован на container/cloud-native окружениях с рядом специализированных особенностей/возможностей:
- Наличие SBOM во время сборки для всех пакетов
- Минималистичный образ
- Поддержка apk package формата
- Полностью declarative и reproducible билд система
- Поддeржка glibc и musl

С помощью данного проекта как раз и создают Chainguard Images, а это у нас реализация distroless образов! Подробнее о таких образах можно узнать из статьи "Minimal Container Images: Towards a More Secure Future" и понять что вам самим может проект Wolfi.

В первую очередь проект будет интересен тем кто хочет делать свои собственные distroless образы и тщательно следить за supply chain security.

Достаточно хорошее сравнение Policy Engine: Gatekeeper и Kyverno в статье "Kubernetes Policy Comparison: OPA/Gatekeeper vs. Kyverno".

А вот тут можно посмотреть наше с коллегой сравнение - оно сделано немного на другом уровне.

О сравнение этих движков с PSP и PSA я писал ранее тут.

А так я лично отношусь к ним обоим нормально (поэтому в Luntry есть поддержка одного и второго), но предпочтение отдаю Kyverno ;)

Сегодня я хочу поделится с вами записью и слайдами своего keynote-доклада "Заметки путешественника между мирами: ИБ, ИТ" с конференции OFFZONE 2022.

Большое спасибо организаторам за возможность открыть конференцию, поделиться своим опытом, знанием и идеями/взглядами с сообществом!

Если вам хочется понимать как в современных реалиях нужно подходить к ИБ и просто хочется лучше понимать мои взгляды на ИБ, то доклад определенно стоит посмотреть - я в него вложил много своего опыта и знаний.

Некоторое продолжение/развитие данная тема получит у меня в докладе "Сочетание несочетаемого в Kubernetes: удобство, производительность, безопасность" на HighLoad++ в Москве 24-25 ноября.

Недавно в комментариях к посту спрашивали, что такое Image Registry lookups и Image Verification в контексте Policy Engine. Сегодня я подготовил подборку по этой теме того, что уже писал и не писал на канале. Основные герои это Sigstore Cosign и Kyverno, которые хорошо дружат между собой. И так поехали:

- "Signing And Verifying Container Images With Sigstore Cosign And Kyverno" - краткий видео экскурс в тему
- "Securing GitOps Supply Chain with Sigstore and Kyverno" - выступление с примером кода для реализации с учетом ArgoCD
- "Protect the Pipe! A Policy-based Approach for Securing CI/CD Pipelines" - выступление с примером кода для реализации с учетом Tekton
- Пошаговая инструкция по использованию Cosign и Kyverno
- Пост про политики, ограничивающие/контролирующие Image Registry