DevSecOps Talks

Примеры использования Network Policy Всем привет! В статье рассматривается создание Network Policy для защиты приложения, которое состоит из трех компонентов: Frontend (взаимодействие с Пользователями), Backend (логика) и Database (данные). Для приложения: 🍭 Создаются отдельные namespace для каждого компонента приложения. Для демонстрации работы Network Policy, если компоненты будут размещены в одном namespace, логика сохранится 🍭Описываются возможные Security Risks и способы их преодоления с использованием Network Policy 🍭Создаются Network Policy для сегментирования трафика приложения между его компонентами 🍭Осуществляется проверка того, что все работает как надо Схемы, описание, код – все на месте. Если хочется больше примеров использования Network Policy, то их можно найти на сайте networkpolicy.io, в котором собрана как теоретическая информация, так и разные примеры реализации сетевых политик.

Yet Another Kubernetes Dashboard Всем привет! Тема потребности наличия графического интерфейса Kubernetes достаточно спорная. С одной стороны все можно делать при помощи kubectl, с другой – такие проекты нет-нет, да и появляются, а значит они кому-то нужны (почти как звезды). В статье собрана общая информация о том, какие есть варианты – от весьма известных до недавно появившихся: 🍭 Lens 🍭 Octant 🍭 Kubevious 🍭 Kubenav и другие Для каждого рассматриваемого графического интерфейса кратко описываются его возможности, сильные и слабые стороны. А что думаете Вы? Нужна ли «графика» или одной лишь консоли вполне достаточно для полноценной работы? Пишите в комментариях 😊

Kubeshark: анализ сети k8s Всем привет! Да, Вам не показалось. Wireshark для Kubernetes – Kubeshark! Хотя, согласно документации, Kubeshark – некоторая «смесь» Wireshark и BPF Compiler Collection Tools. Kubeshark позволяет: 🍭 Выполнять sniffing TCP трафика в кластере и записывать их в PCAP-файлы 🍭 Анализировать трафик за счет enforce-policy 🍭 Создавать карту связности сервисов 🍭 Разбирать протоколы HTTP (1.0, 1.1, 2), AMPQ, Apache Kafka, Redis и не только Решение обладает web-интерфейсом, упрощающим работу по анализу трафика. Подробнее с Kubeshark можно познакомиться при помощи документации.

Пишем свой первый Admission Controller Всем привет! Один из самых простых способов понять что-либо – сделать это самому! Если вам интересна тема Validating и Mutating Webhooks и Вы хотите «копнуть глубже» в то, что происходит «под капотом», то эта статья может Вам подойти. В ней Автор предлагает вместе с ним написать свои собственные реализации Admission Controller, которые проверяют, что image взят с Dockerhub. Не самый лучший вариант с точки зрения ИБ, но в качестве базового примера – самое оно. Потребуется minikube (или «обычный» кластер k8s), golang, make и ko. Далее по шагам разобраны моменты: 🍭 Создание web-server (а Validating/Mutating Webhooks ничто иное как они) 🍭 Проработка логики проверок и/или изменений конфигурации создаваемого в кластере ресурса 🍭 Создание сертификатов с использованием cert-manager 🍭 Регистрация созданных webhooks и, конечно же, тестирование! В статье все подробно описано, доступны примеры кода (включая итоговый проект). Все по полочкам! Очень рекомендуем повторить этот Путь 😊

Общий взгляд на анализ безопасности 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, на которые обязательно стоит обратить внимание с точки зрения ИБ, сгруппированные по компонентам, которым они «принадлежат».

Приглашаем принять участие в серии вебинаров «Как крупному бизнесу развивать ИТ за счет публичного облака и делать это безопасно». Эксперты «Инфосистемы Джет» и Yandex Cloud раскроют тему с двух сторон: ИТ и ИБ, поэтому участие будет интересно как ИТ-менеджменту, так и ИБ-специалистам. 2 декабря, 11:00–12:30 «Как использовать облака в инфраструктуре предприятия»: 🔹Сценарии применения публичного облака для крупного бизнеса 🔹Локализация ИТ-инфраструктуры в России на базе облака 🔹Безопасность облачных сред Зарегистрироваться 9 декабря, 11:00–12:30, «Безопасность публичных облаков для крупных компаний»: 🔹5 вопросов, которые нужно решить перед началом миграции 🔹Подводные камни, встречающиеся при миграции в облако. Что нужно учесть? 🔹Экспертный подход к защите публичного облака Зарегистрироваться

Доброго пятничного утра! Хотите поиграть? Заходите на страничку, созданную по мотивам нашего участия в Highload и проходите квиз! Первые 100 участников, ответившие верно на 60% вопросов получат в качестве приза классные DevSecOps носки 🎁 Там же вы найдете вакансии и видео-ролик о нашей команде. Пройти квиз

Всем привет! А вы участвуете в Highload 24-25 ноября в Москве? Если да, то приходите к нам на стенд "Инфосистемы Джет", пообщаемся, ответим на ваши вопросы, поделимся опытом: 🕶 как делать DevSecOps в крупных компаниях, 🕶 как создать гибкую отказоустойчивую инфраструктуру, 🕶 как настроить интегрированный мониторинг, 🕶 как защищать контейнеры и обеспечить безопасность разработки 🔥 В треке «DevOps в Enterprise» наш эксперт Юрий Семенюков расскажет о том, как и на что можно заменить enterprise-решения и инструменты в части платформ управления контейнерами. 🎁 На нашем стенде можно сыграть в тематический квиз и получить призы) Увидимся на Highload!!!

Supply Chain: защита Build Всем привет! Продолжение вчерашнего поста, посвященному защите окружения разработки. На этот раз рассматривается Build-окружение. Как и в предыдущем материале Автор определяет 3 основные цели злоумышленника: 🍭 Compromise the Build artifact 🍭 Compromise the self-hosted runner 🍭 Pivot to other resources Далее рассматриваются Attack и Defense Trees. Материал содержит много ссылок на сведения по теме, конфигурацию окружения и лучшие практики, посвященные тематике. Итоговое «дерево» доступно по ссылке или на GitHub Автора.

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. Если верить Автору, то материал будет дорабатываться со временем.

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. У последнего есть даже перевод на русский язык.

GuardDog: идентификация вредоносных python-пакетов Всем привет! Команда Datadog подготовила отличную статью, посвященную анализу безопасности python-пакетов и инструменту, который был создан для их анализа. После исследования нескольких пакетов, команда пришла к выводу, что большинство вредоносных пакетов используются для Initial Access (например, typosquatting), Code Execution (eval/exec для получения нужного файла) и Exfiltration (передача данных различными способами). Для идентификации подобных пакетов ребята разработали GuardDog. Инструмент не анализирует пакеты на наличие CVE, как делает большинство SCA-решений, а использует SAST-практики. Примечательно, что анализу подлежит не только исходный код, но и метаданные пакета. В качестве основы GuardDog используется Semgrep, с правилами идентификации уязвимостей в коде можно ознакомиться тут. Для анализа метаданных ребята подготовили собственные проверки, которые доступны вот тут. В итоге получилась достаточно занятная утилита. Настоятельно рекомендуем ознакомиться со статьей – в ней есть примеры запуска, много сведений об анализе python-пакетов и о том, что они могут содержать. Читается легко и непринужденно. Как раз то, что нужно для пятницы!

YaraHunter: идентификация malware Привет! YaraHunter – небольшая утилита, которая позволяет идентифицировать вредоносное ПО. С правилами, на основании которых происходит идентификация можно ознакомиться тут. При помощи утилиты можно: 🍭 Искать вредоносное ПО в образах контейнеров, контейнерах и на файловой системе 🍭 Встраивать в CI/CD pipeline 🍭 Получать результаты в машиночитаемом формате – JSON Пока что YaraHunter находится на стадии разработки. Одной из интересных функций будет интеграция с ThreatMapper – решением по управлению уязвимостями от того же Deepfence, про который мы писали тут. Увы, roadmap, как и документация на решение, пока что возвращают 404.

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 Всем привет! Не всегда получается поддерживать актуальность используемых образов/контейнеров в кластерах Kubernetes. Альтернативный сценарий – unused images, которые могут храниться на узлах. Хорошо, что у Kubernetes есть собственный механизм garbage collection, которому посвящена статья. Если просто – то многое зависит от размера образа и времени его последнего использования. Например, большой образ, который использовался неделю назад будет с большей вероятностью удален, чем небольшой и используемый «вчера». Однако, это можно настроить через манифесты Kubelet: 🍭 Указать необходимый disk threshold 🍭 Задавать определенное количество dead containers (по умолчанию отсутствует) 🍭 Количество минут, через которое контейнер будет считаться «старым» и станет кандидатом на устранение (по умолчанию отсутствует) и не только Статья 2021 года, но механизмы актуальны. Есть направления по переходу на механизм eviction, который может заменить garbage collection в будущем.

Snyk Learn: обновление учебных курсов Snyk продолжает радовать отличными материалами и обучающими курсами в частности. На сайте Snyk Learn можно найти несколько интерактивных курсов, посвященных DevSecOps: Java, JS, Python, Golang, PHP, C#, Kubernetes. Например: 🍭 Insecure Design 🍭 Directory Traversal 🍭 SQL Injection 🍭 Container does not drop all capabilities Мы уже писали про этот ресурс в 2021 году. На тот момент курсов было гораздо меньше. Приятно, что ребята не останавливаются и продолжают развивать данное направление.

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). И это не единственные примеры 😊

Обход eBPF Всем привет! Последнее время все чаще и чаще можно слышать про eBPF, которая привносит много нового и удобного не только для ИТ, но и для ИБ-специалистов. Появляются средства защиты, которые могут анализировать kernel calls что может быть крайне полезно для идентификации подозрительных событий и инцидентов ИБ. Однако, как и у любой технологии у eBPF есть «ограничения», про которые важно помнить. В статье Автор на примерах разбирает способы обхода средств защиты, использующих eBPF: 🍭 В качестве подопытного используется Tetragon от Cilium (будет работать и с другими аналогичными решениями) 🍭 Создается «подопытный» Ubuntu-контейнер, в котором запускается cat /etc/host. cat использует write system call, что видно при помощи Tetragon 🍭 Автор немного модифицирует write для того, чтобы Tetragon не смог увидеть произошедшее событие В статье много пояснений, примеров кода и рассуждений о возможных способах обхода. Это вовсе не означает, что eBPF – «плохой» инструмент, скорее наоборот. Главное помнить, что абсолютов не существует и не стоит «слепо» полагаться на автоматизацию.

Управление GitOps Repos Всем привет! GitOps – подход, который позволяет управлять конфигурацией ИТ-инфраструктуры, используя подходы и практики разработки ПО. Например, есть централизованный repo, в котором хранятся интересующие нас конфигурации и инструмент, который применяет эти конфигурации. У такого подхода много преимуществ – начиная от «прозрачности» и заканчивая минимизацией вероятности возникновения configuration drift. Но как правильно организовать тот самый repo с конфигурациями? Должен ли это быть 1 repo, в котором содержится все-все-все или это должно быть несколько repo? Например, отдельные для production и development-окружений? Размышления на эту тему можно найти в статье. Автор рассматривает 4 варианта: 🍭 Один repo для приложения и поддерживающей его ИТ-инфраструктуры 🍭 Отдельный repo для ИТ-инфраструктуры с несколькими «долгоиграющими» ветками (main и development, например) 🍭 Несколько repo – по одному на каждое окружение Для каждого варианта приведены его плюсы и минусы. Например, наличие (отсутствие) управления доступом на изменения, вероятность «расхождения» конфигураций различных окружений и т.д. В конце статьи Автор дает ссылки на инструменты Harness (CI, CD, GitOps), в разработке которых участвует. По ссылкам можно больше узнать про решения и их open source версии.