DevSecOps Talks

Tracee — это runtime security утилита для контейнерных сред. Она использует технологию Linux eBPF для отслеживания событий в реальном времени и анализа шаблонов поведения.

Tracee позволяет увидеть развитие атаки и провести её расследование. К тому же, в отличие от многих freeware-продуктов, tracee имеет широкую поддержку вендора.

🍏 Например, в этом воркшопе (который является частью целого курса на гитхабе) показаны базовые функции Tracee и интеграция утилиты со Slack.

🍏 Эта статья в блоге Aquasec содержит руководство по установке Tracee в кластер Kubernetes и обнаружению атаки. Можно увидеть работу Tracee на примере эксплуатации уязвимого приложения.

🍏 А в этой статье описано создание кастомных правил, представляющих из себя сигнатуры тех или иных атак. В tracee есть неплохой набор правил "из коробки", но для обнаружения новейших атак его может оказаться недостаточно, поэтому важно уметь дописывать правила самому. К тому же, новые сигнатуры широко приветствуются вендором и помогают развивать продукт.

Привет!

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

Как правило, все они содержат упоминания нижеуказанных доменов:
🍭 Лучшие практики по архитектуре
🍭 Безопасность в CI/CD
🍭 Защита ресурсов
🍭 Защита runtime
🍭 Безопасность цепочки поставок (supply chain)
🍭 Сетевая безопасность
🍭 Управление уязвимостями и compliance-несоответствиями
🍭 Управление секретами

В статье приводится небольшой обзор таких framework как: CIS Kubernetes Benchmark, The MITRE ATT&CK® Framework for Kubernetes, PCI DSS Compliance for Kubernetes, NIST Application Container Security Framework, NSA-CISA Kubernetes Hardening Guide. Для каждого из них приводится общее описание, его сильные/слабые стороны и небольшие рекомендации по его использованию/автоматизации.

Существует еще один checklist, который не попал в список, но достоин упоминания – «Kubernetes Security Checklist and Requirements» от автора канала «DevSecOps Wine». Материал доступен как на русском, так и на английском языках.

Привет!

По ссылке доступна статья, детализирующая проблематику управления GitOps с использованием branches (об иных «тонких местах» работы с GitOps мы писали вот тут).

Автор ставит простой вопрос – «How do I promote a release to the next environment?» и описывает, почему ветвление в Git (branches) не является лучшей практикой:
🍭 В теории – promotion == git merge, на практике, как обычно, бывают нюансы
🍭 Сложности использования pull/merge request при большом количестве сред
🍭 Возможный configuration drift (особенно явно это видно при внесении hotfix)
🍭 Потребность поддержки и управления большим количеством branches и другие

Что же делать? И как правильно организовать работу с Git? Автор, в лучших традициях Адриано Челентано интригует и просит подождать следующей статьи, где ответит на этот вопрос! 😊

Пятница!

Debug – не самое простое занятие… Но его можно сделать немного более приятным, особенно, когда знаешь что искать и как сделать вывод наглядным!

В статье описываются 12 команд, которые, по мнению автора, помогут упростить debug нагрузок в кластере (workloads).

Команды сгруппированы для поиска проблем нескольких типов: «Workloads won’t run», «Cannot access workloads» и «Debug specific pods».

Примеры команд, которые приведены в статье:
🍭 kubectl get events –field-selector type=Warning –all-namespaces
🍭 kubectl resource-capacity –pods –util –sort cpu.util
🍭 kubectl lineage pod ${POD}
🍭 kubectl get endpointslices -o wide
🍭 kubectl debug pod –it –image=%image% $POD и другие

В статье приводится краткое описание причин использования команд и ссылки на open source утилиты, которые помогут еще больше упростить процесс поиска ошибок! Вместе с детальной debug-схемой (о которой мы писали тут) получается инструмент, которые отвечает на вопросы «Что искать? Как искать?». Если хочется чуть больше визуализации, можно посмотреть в сторону K9S (о которой мы писали тут).

P.S. Всем отличных выходных и вечера пятницы! До Нового Года осталась 1 неделя!!!

Привет!

Детальный материал (с примерами и screenshots), в котором описан kill chain по «захвату» nodes кластера K8S. От эксплуатации уязвимости в запущенном на нем web-приложении до получения root-доступа на node.
Статья хоть и не самая новая (2018 год), но все равно может оказаться полезной.

Последовательность действий:
🍭 Анализ web-сайта, поиск уязвимостей (DirBuster)
🍭 «Проникновение» в контейнер через RCE-уязвимость. Установка необходимых «инструментов для дальнейшей работы» (Metasploit, Meterpreter)
🍭 Чтение Service Account (SA) Token. «Установка» kubectl. Изучение возможностей SA (list, create, exec и т.д.)
🍭 «Прыжок» в другой контейнер, SA которого обладает большими возможностями
🍭 Создание pod, с mount /root:/ - AttackerPod
🍭 Изменение пароля пользователя, входящего в sudo группу от имени root. SSH на node.
🍭 Но и этого оказалось мало для автора! Создание DaemonSet с AttackerPod и повтор аналогичных действий для компрометации всех nodes кластера

Статья - хорошо структурированный материал, который объединяет в себе несколько инструментов, тактик и техник, реализация которых привела к компрометации кластера. «Вишенкой» является интересный и простой слог автора ☺️

P.S. В конце статьи приводятся рекомендации – как можно было этого избежать? С одной стороны, достаточно простые меры и «все понятно». С другой – лишний повод задуматься о том, что даже встроенные возможности кластера K8S по ИБ могут дать многое и не стоит пренебрегать их настройками.

P.P.S. Preview к ссылке не работает, дублируем: https://www.inguardians.com/blog/attacking-and-defending-kubernetes-bust-a-kube-episode-1/

Привет!

Недавно обновился HashiCorp Vault Plugin для Jenkins. Есть Breaking Changes, а есть bug fix, который может быть в разы значительнее, чем добавление Secret File Credential Type (того самого breaking change).

Речь идет о «fixing the fallback to get the config to access Vault». В plugin была возможность использовать Credentials для доступа к Vault, задаваемых на разных уровнях: Folder, либо Global. Достаточно удобно, если вы используете Folder, реализована ролевая модель доступа и вы хотите, чтобы каждый проект в Folder использовал собственные учетные данные для аутентификации в Vault, а не единые для всех (Global).

Однако, даже при наличии соответствующих настроек, учетные данные уровня Folder не всегда использовались. Например, использование конструкции withCredentials все равно будет использовать параметры, заданные в Global.

Именно эту проблему и устраняет рассматриваемое обновление! Теперь все должно работать корректно: From pipeline => Possible parents (Folder Item) => Jenkins Global config. Таким образом, каждый проект в Folder будет использовать собственные учетные данные для аутентификации в Vault, а если они не указаны, то будет использована Global-конфигурация. Осталось только протестировать ☺️

Всем привет!

GitOps – очень интересный подход к управлению deployment. Однако, как и все, он не лишен недостатков.

В статье «The pains of GitOps 1.0» приводятся размышления на тему возможных проблем подхода. Автор выделяет такие как:
🍭 Частичное покрытие жизненного цикла разработки ПО при помощи GitOps
🍭 Не всегда тривиальное разделение CI и CD частей
🍭 Сложность одновременного управления средами (Dev, Test, Prod и т.д.)
🍭 Autoscaling и динамические окружения (как реализовать, когда GitOps вернет все «обратно»?)
🍭 Недостаточная Observability (в management смысле, а не в техническом)
🍭 Не самый простой аудит событий (да, в Git все есть, но это «все» надо еще найти и найти быстро)
🍭 Сложности, связанные с GitOps-управлением большого количества deployments
🍭 Управление секретами и многое другое!

Для каждого тезиса приводится несколько аргументов, его подкрепляющих. Самое интересное – Автор приводит примеры в стиле «В теории – классно, а на практике есть нюансы…». Многие вопросы, поднимаемые в статье, характерны и для «классического» управления deployment’ами. Целью Автора было развенчать миф: «внедрил GitOps и все работает, «как по маслу!», показать что и у него есть недостатки при всех его достоинствах!

Какой можно сделать вывод? GitOps – еще один «маркетинг»? Не думаем. Скорее – «серебряной пули не существует», у всего есть свои сильные и слабые стороны и за все приходится платить. Удобство иногда снижает «гибкость», «гибкость» иногда негативно отображается на управляемости и т.д. Главное при внедрении любой технологии/подхода – понять, нужна ли она вам? И если да, то как ее правильно реализовать и на какие «жертвы» вы готовы пойти.

А что вы думаете о GitOps? Пишите в комментариях!

Всем привет!

Есть 2 команды, которые, на первый взгляд очень похожи, делают аналогичные вещи и не очень понятно, чем именно они отличаются. Речь идет об attach и exec.

В своей новой статье Ivan Velichko приводит наглядное описание разницы. Как и везде, дьявол кроется в деталях – а именно в реализации attach и exec.

Если коротко, то:
🍭 Attach – как бы «присоединяется» (attached) к stdio запущенного контейнера
🍭 Exec – вообще не подключается к запущенному контейнеру... тут лучше прочитать самим, не хотим делать спойлеры ☺️ Если не знаете, как именно это работает, то очень сильно удивитесь!

Ранее мы уже писали про блог Ivan, его Телеграм-канал и Learning Path по контейнерам. Очень рекомендуем материалы автора и согласны с его мыслью – «Зачем запоминать, если можно понять?»

P.S. Всем отличной рабочей недели! Да, до Нового Года осталось 2 недели!

Всем привет!

Вот и настал конец года. Самое время заняться ретроспективой, подведением итогов года и планированием следующих шагов своего карьерного развития или развития вашей команды!

По ссылке ниже доступна интерактивная карта сертификаций по направлению ИБ. Сама карта разбита на домены (например, IAM, Software Security...), в каждом из которых указаны названия сертификаций (например, CISSP, CSSLP...). Вендорских тут нет. При нажатии на название выполняется переход на официальный источник, где уже представлено детальное описание.

P.S. Цены карта тоже отображает, но лучше проверять их на официальных сайтах.

Ссылка: https://pauljerimy.com/security-certification-roadmap/

Поздравляем, друзья, нас уже больше 1000! Ура! 🥳

Спасибо, что вы были и остаетесь с нами, впереди вас ждет еще больше полезностей из мира DevSecOps.

С вами на связи
Jet DevSecOps Team

Stay tuned!

Всем привет!

Еще один интересный обучающий проект, достойный внимания – Styra Academy! Отличный курс, который рассказывает про OPA, как и зачем использовать этот инструмент.

Курс состоит из нескольких частей:
🍭 Overview of OPA. Какие задачи решает, какими возможностями обладает
🍭 Rego Expressions. Основа языка Rego, используемого для написания OPA-политик
🍭 Basic Rego Rules. Описание концепции вычисления правил, создание «цепочки» правил
🍭 Partial Rego Rules. Использование Partial Object и Functional Rules
🍭 Rego Iteration. Взаимодействие с Arrays, Objects и Sets
🍭 Rego Packages. «Упаковка» политик в предопределенные packages

Курс содержит теорию, практические задания и предоставляется бесплатно! ☺️

Всем привет!

Продолжаем тему с интересными обучениями, которые доступны бесплатно и могут дать представление о чем-то новом!

Сегодня – GitOps! Точнее – курс от CodeFresh, посвященный этому подходу и его реализации при помощи ArgoCD.

Курс состоит из 5 основных блоков:
🍭 About GitOps. Декларативное описание инфраструктуры, использование Git в качестве «источника истины», обзор плюсов и минусов подхода
🍭 ArgoCD basics. Обзор возможностей ArgoCD для управления нагрузками на кластере
🍭 Using ArgoCD. Реализация операций «второго дня» с использованием Argo
🍭 Progressive Delivery. Использование Argo Rollouts для Blue/Green и Canary Deployment
🍭 Summary and examination. Обзор пройденного материала, небольшой тест для закрепления

Если курс понравится, можно ознакомиться еще с двумя – GitOps at Edge и GitOps at Scale (по мере их появления) ☺️

​​Сотни продуктов пострадали от уязвимости в Log4J и это, в основном, известные и часто используемые.

А сколько внутренних проектов уязвимо? Еще предстоит узнать.

Как оперативно находить подобные уязвимости в своих проектах, исправлять опасные настройки Kubernetes с помощью KSPM (близкий родственник CSPM) и контролировать контейнеры на уровне Runtime ?

Расскажет Aqua Security в серии коротких вебинаров:

Aqua: Начинаем погружение!
Серия 30 минутных вебинаров по безопасности Cloud Native:
1. Сканирование образов контейнеров
2. Безопасность Kubernetes (KSPM)
3. Новый термин - CNAPP
4. Compliance for Cloud Native
5. Runtime Security и многое другое.

Ближайший вебинар уже завтра, регистрация -
https://info.aquasec.com/jump-start-russia

Привет!

Чем заняться на новогодних праздниках? Конечно же – учиться! Тем более, что интересных курсов очень много. Одним из таких порадовали ребята из Sysdig!

Они выпустили курс «Falco 101», который очень лаконично описали: «All you need to learn to get started with Falco».

Суммарно курс состоит из ~ 5,5 часов видеоматериалов и включает в себя такие разделы, как:
🍭 What is runtime security
🍭 Falco installation and basic settings
🍭 Falco event sources
🍭 Falco rules: basics and deep dives

И другие! Кстати, недавно мы писали про лабораторные работы от Sysdig, посвященные Falco. Их можно использовать вместе с курсом для совмещения теории и практики 😊

Привет

Графическое представление может быть удобно для восприятия информации, особенно, когда много действий и/или участников.

В статье приводится наглядная схема, описывающая то, что происходит при запуске команды "kubectl create pod nginx":
🍭 Аутентификация запроса
🍭 Kube-apiserver создает объект Pod, обновляет данные в ETCD
🍭 Kube-scheduler получает информацию о том, что Pod был создан, без Node
🍭 Kube-scheduler "подбирает" оптимальную Node, сообщает Kube-apiserver, информация в ETCD обновляется
🍭 Новая информация передается Kube-apiserver'ом Kubelet'у той Node, что была выбрана Kube-scheduler
🍭 Kubelet создает Pod на Node, взаимодействуя с Container Runtime Engine
🍭 После завершения работы Kubelet оповещает Kube-apiserver, обновляется информация в ETCD

Важно (!) схема очень-очень-очень упрощенная, просто для общего понимания.

Если хочется больше и детальнее - рекомендуем посмотреть невероятную статью "What happens when I type kubectl run", в которой подробно описывается, что происходит "под капотом", пусть даже и на базовых операциях ☺️

Всем пятница!

Регулярные выражения (regular expressions, regexp) – популярный и важный инструмент, который может быть использован для поиска подстроки в строке или при parsing результатов для последующей обработки.

Некоторые ИБ-решения, в том числе основаны на их использовании, например, поиск секретов в Trufflehog использует этот функционал.

Есть один нюанс – поначалу они могут показаться чем-то очень сложным и неудобным, но стоит лишь привыкнуть… Для более быстрого погружения есть интересный интерактивный курс от RegexLearn! Курс комбинирует в себе теорию и практику, продолжает развиваться. Например, модули Practice и Playground обещают скоро добавить.

Если вы никогда не сталкивались с regexp, но вам интересно – неплохое место для старта, а если вы профессионал написания «регулярок», то попробуйте разгадать кроссворд! Неплохое развлечение для вечера пятницы! 😊

P.S. Всем отличной пятницы и выходных! И да, до Нового Года осталось совсем чуть-чуть, 3 недели!

Всем привет!

В ноябре 2021 года вышла новая версия GitLab - 14.5, в которой много интересных нововведений не только для Dev, но и для Ops и Security-команд!

Сводную информацию можно почитать на официальном ресурсе, отдельно хотелось бы выделить следующее:
🍭 Добавлена возможность сканирования IaC при помощи KICS от Checkmarx (не путать с защитой АСУ ТП от Kaspersky ☺️)
🍭 Добавлены Secret Detection Patterns
🍭 GitLab Kubernetes Agent! Да, они были, но… теперь они доступны в Community-версии продукта!
🍭 Гранулированный контроль доступа Kubernetes-агентов с использованием Impersonate (не доступно в Community)
🍭 Добавление параметра exist в include – теперь можно еще более гибко настраивать вызовы pipeline’ов и job из внешних repo

И еще много-много-много всего, как для Community-версии, так и для ее «старших» братьев! Крайне рекомендуем к прочтению и ознакомлению! ☺️

Всем привет!

Сегодня в рубрике «Срочно в закладки» шикарное пополнение! Несмотря на то что предмет сегодняшнего поста не новый, он от этого не становится менее полезным! Кто то с ним прекрасно знаком, для кого-то, возможно, он станет открытием, но несомненно, для всех он будет прекрасным помощником в неблагодарном деле обеспечения безопасности!
Встречайте, матрица безопасности MITRE ATT&CK® (Adversarial Tactics, Techniques & Common Knowledge)

Кто такой? Чем знаменит?

Когда то давным давно, специалисты по безопасности одной крупной заграничной организации задумались, а можно ли описать типовые паттерны поведения нарушителя информационной безопасности? Можно ли собрать все возможные потенциальные действия злоумышленника и сгруппировать из по стадиям начиная с разведки и заканчивая успешной эксплуатацией каких-либо уязвимостей и получением контроля над критичными системами?
Благодаря огромному количеству проведённой ими аналитической работы выяснилось что в большинстве случаев, злоумышленники используют примерно одинаковую тактику и методы на каждом этапе атаки на любую систему!
Например:

🍩 Reconnaissance. Злоумышленник сканирует внешние адреса организации в поиске открытых портов
🍩 Resource Development. Далее он пытается разведать состав и конфигурацию инфраструктуры
🍩 Initial Access. Затем он пытается получить контроль через публичные endpoint’ы приложений
🍩 Execution. Получив контроль он старается выполнить свой вредоносный код

Таким образом злоумышленник постепенно получает полный контроль над критическими системами, не забывая при этом замести следы.
И вот спустя долгие годы дотачивания и актуализации у нас появилась матрица MITRE ATT&CK®, которая структурирует и подробно описывает каждый этап деятельности злоумышленника с подробным описанием техник, используемых на каждом шаге!
Благодаря этому сакральному знанию, проверенным годами в реальных условиях защиты business critical систем и приложений, мы теперь имеем наглядное руководство о том как могут быть взломаны практически любые системы! А имея подобную mind карту, нас теперь не нужно ставить себя на место атакующего и придумывать как взламывать собственную систему. Мы знаем пошагово что будет делать злоумышленник и можем точно знать что и где на нам защищать!

Данный дидактический материал очень рекомендуется к ознакомлению! По ссылке доступны матрицы для Windows, macOS, Linux, PRE, Azure AD, Office 365, Google Workspace, SaaS, IaaS платформ, сети и контейнеров!

Ссылка на официальный сайт, как всегда, внизу! Приятного погружения! 👇

https://attack.mitre.org

Всем привет! Если вы ещё не погрузились в тематику защиты контейнеров или только начинаете это делать, мы подготовили небольшое обзорное видео в рамках нашей рубрики Security Small Talk.

Итак, о чем вы узнаете из ролика?
🍬 Что именно нужно защищать и почему обычных СЗИ для этого мало.
🍬Как хакеры атакуют Kubernetes, чем опасны подделки запросов к kube-apiserver или kubelet и что будет, если киберпреступник заберётся внутрь контейнера.
🍬 Готовый фреймворк для защиты кластера на всех уровнях — от узла до контейнера.
🍬Верхнеуровневое знакомство с Open Source и коммерческими решениями.

Ролик доступ по ссылке.

Привет!

Observeability - важный аспект, который помогает нам понимать что происходит в кластере и может быть полезен при поиске ошибок.

У Kubernetes есть сущность - Event - которая помогает более точно понять, что (не)произошло и почему.

В статье автор описывает что это такое и чем это может быть полезно на примере:
🍭 Failed Events. Например, pod не был создан или проблемы в работе node
🍭 Evicted Events. "Переселение" нагрузок не всегда является проблемой, но лучше понимать, что стало причиной
🍭 Storage-Specific Events. Все, что связано с использованием Storage
🍭 Scheduling Events. Почему не получилось выбрать node для нагрузки
🍭 Node-Specific Events. Проблемы с nodes: недоступность, перезапуски и т.д.

Важно помнить, что Events бывают разные: Normal, Information и Warning. Не все из них одинаково полезны и рекомендуются к анализу.

В завершении статьи автор показывает, как можно получить доступ к рассматриваемому объекту и как можно фильтровать запросы.