DevSecOps Talks

NPM Provenance и его использование

Всем привет!

NPM Provenance – механизм, который позволяет «связать» опубликованный пакет с исходными кодами GitHub-Repository.

Казалось бы, это очень хороший функционал, который позволит усилить защиту против атак на цепочку поставки ПО.

Однако, насколько часто им пользуются? Размышления на эту тему можно найти в статье. Spoiler: хотелось бы больше 😊

Автор рассматривает:
🍭 Общие риски ИБ в модели ИБ NPM (отсутствие требований к наличию provenance, отсутствие требований к публикации пакетов и т.д.)
🍭 Возможные причины, почему Provenance не получил (ает) желаемого распространения
🍭 Как включить и как проверить тот самый Provenance
🍭 Общие рекомендации как для Package Maintainers, так и для Package Users

Все очень просто и кратко описано, что позволит лучше разобраться как и что работает.

Также статья затрагивает другую интересную тему, а именно: получение полной информации о ПО – от условного commit до того, что получает конечный пользователь. Но об этом как-нибудь в другой раз 😊

Helmper: анализ образов Helm Chart

Всем привет!

Допустим, что у вас есть Helm Chart, образы из которого надо поместить в локальный реестр для дальнейшего использования.

С простыми Chart сделать это относительно не сложно, а со сложноустроенными – все может быть далеко не так тривиально.

Именно эту задачу (и не только!) помогает решить утилита Helmper. Она объединяет в себе Helm, Oras, Trivy, Copaсetic и Cosign.

Да, уже из «состава» видно, что умеет она чуть больше, а именно:
🍭 «Извлечение» образов из всех Helm Chart и их Sub Chart
🍭 Гибкое управление «импортом» образов – все или только новые
🍭 Анализ образов на наличие уязвимостей с Trivy
🍭 Устранение уязвимостей с использованием Copaсetic (детальнее про него мы писали тут)
🍭 Возможность подписи образов контейнеров и не только

Больше информации можно найти в repo и в документации на утилиту.

Важно: утилита находится в beta-стадии.
И, если вдруг вы захотите «устранять уязвимости автоматически» с Copaсetic не забывайте, что он создает новый слой сверху, что может увеличить размер образа.

И еще немного про Kubernetes Operators

Всем привет!

Предлагаем вам еще одну статью, посвященную Kubernetes Operators. Если вы хотели побольше о них узнать, то она может быть полезна.

Сперва Автор раскрывает основные идеи – Current State, Target State, Reconcile Loop. Дальше, на примере Deployment, каждый из концептов и внутренняя «машинерия» раскрывается детальнее.

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

Далее – создание собственного контроллера с использованием Kubebuilder!

Автор приводит все шаги:
🍭 Подготовка шаблонов
🍭 Управление permissions при работе с (Sub) Resources
🍭 Настройка SetupWithManager и указание ресурса для reconcile
🍭 Описание той самой reconcile-логики (что надо сдедать в случае, если с ресурсом X произошло событие Y)
🍭 Работа с Finalizers и много всего еще

Очень-очень-очень-очень много пояснений, кода, различных схем и примеров из разных Kubernetes Operators.

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

«Вредные советы» по безопасной разработке

Всем привет!

Обычно рассказывают про хорошие / лучшие практики по чему-либо. Безопасная разработка – не исключение.

Однако, все мы помним Григория Остера и его замечательные «Вредные советы». Которые весело читались и сохранялись в памяти на долгие годы.

Поэтому сегодня хотим рассказать про статью от CISA, в которой собраны такие вот "советы" по вопросам безопасности разрабатываемого ПО.

Например:
🍭 Использование memory unsafe languages (спорно, но)
🍭 Возможность добавления пользовательского ввода в SQL-запросы
🍭 Возможность добавления пользовательского ввода в команды ОС
🍭 Использование «чего-либо», обладающего известными уязвимостями и т.д.

Для каждого «совета» приводится описание и как делать «правильно». Да, выглядит «избито и банально», но, возможно, в такой трактовке лучше запомнится 😊

P.S. А если вы не знаете, кто такой Григорий Остер и что за «Вредные советы» - очень настойчиво рекомендуем ознакомиться 😊

Основы сети и сетевая безопасность в Kubernetes

Всем привет!

Если вы хотите познакомиться с основами сетевого устройства Kubernetes и подходами по защите, то эта обзорная статья может вам подойти.

Команда Otterize описывает следующее:
🍭 Ключевые концепты (Kube-proxy, Service и их типы)
🍭 Network Policies и как их можно использовать
🍭 «Путешествие» пакета и то, как можно анализировать трафик на примере простого приложения
🍭 Создание Network Policy для вышеуказанного приложения с использованием Open Source наработок Otterize (о которых мы писали тут и тут)

Очень много схем, комментариев и примеров. Отдельно хочется отметить часть, связанную с «путешествием» пакета – Авторы разобрали все весьма подробно.

Kubelab: интерактивные лабораторные по Kubernetes

Всем привет!

Самый простой способ что-то изучить – практика, практика и еще раз практика. Поэтому сегодня предлагаем вам познакомиться с проектом Kubelab.

Он позволяет реализовать «интерактивный Kubernetes-тренажер» локально и проходить различные задания.

Например:
🍭 Основы работы с Kubernetes (Networking, Storage, Jobs, RBAC и т.д.)
🍭 «Продвинутые» задания (выстраивание «цепочек» из того, что поясняется в «Основах»)

Для лабораторных есть подсказки или готовые решения, если не получилось сделать самостоятельно. Кроме этого, Kubelab обладает Web UI и редактором кода, чтобы упростить обучение.

Важно: проект еще достаточно «молодой», поэтому возможны различные нюансы, связанные с его работой

Форензика в Kubernetes

Всем привет!

Продолжение истории с DFIR в контейнерах от Sysdig! Предыдущая статья закончилась на том, что это важно, интересно и полезно. Но, как и что делать – озвучено не было.

Именно этому и посвящена вторая статья! А именно – использованию функционала Checkpoint. Если просто – сохранению состояния контейнера в определенный момент времени для дальнейшего расследования.

В качестве примера команда Sysdig собирает Falco, Falco Sidekick, ArgoCD вместе, чтобы автоматически создавать Checkpoint в случае, если Falco обнаруживает нечто подозрительное.

Далее на реальном примере разбирается как можно проводить расследования в контейнерах и на что можно и нужно обращать внимание.

В завершении – полный перечень используемых инструментов и много ссылок «на почитать».

P.S. А если хочется материалов по теме на русском языке, то рекомендуем обратиться вот к этому докладу Сергея Канибора из команды Luntry – все по полкам! Да, 2022, но концепты не слишком сильно изменились 😊

Gitlabcis: анализ GitLab на соответствие CIS

Всем привет!

Недавно GitLab представили собственную разработку – Gitlabcis.

Как нетрудно понять из названия он используется для того, чтобы проверять корректность конфигураций GitLab на соответствие одноименному CIS Benchmark.

Просто устанавливается, легко конфигурируется и быстро работает!

Из возможностей хотелось бы отметить:
🍭 Выдача результатов содержит Reason, в которой указано, почему настройка (не) соответствует требованиям
🍭 Есть возможность получения рекомендаций о том, как и что можно поправить (вплоть до «откройте XXX, выберите YYY и нажмите ZZZ)

Но не обошлось и без ограничений – реализовать автоматизированные проверки всего и вся не всегда просто/возможно. Все, что сейчас не реализовано, Авторы описали вот тут.

Больше подробностей, как обычно, в repo проекта и в официальной документации. А если вам хочется узнать roadmap развития утилиты, то он есть в статье из поста 😊

DFIR в контейнерах: основы

Всем привет!

Digital Forensics и Incident Response (DFIR) – тема очень интересная, особенно, если дело касается контейнеров, которые обитают «в своем мире».

В статье команда Sysdig описывает, как и что можно делать, согласно методологии NIST (Computes Security Incident Handling Guide).

Рассматриваются шаги:
🍭 Preparation
🍭 Detection and Analysis
🍭 Containment Eradication and Recovery
🍭 Post-Incident Activity

Для каждого шага описывается его назначение и возможные способы автоматизации.

P.S. А если хочется узнать про это больше, то можно ознакомиться с докладом по DFIR, представленным командой Sysdig на CloudNative SecurityCon в 2023. Ссылка на него есть в начале статьи

Observability в Kubernetes

Всем привет!

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

Для того, чтобы решить эту задачу можно использовать различные observability-инструменты, которые позволят получить ту самую «видимость».

Автор статьи предлагает «разбить» observability на 3 уровня:
🍭 Внешняя. Информация, связанная с user experience – время отклика, производительность и т.д.
🍭 Внутренняя. Метрики и логи, генерируемые системой
🍭 Операционная система. Отслеживание System Calls

Для каждого уровня Автор приводит несколько инструментов, которые могут пригодиться.

Из интересного еще то, что каждый уровень рассматривается с точки зрения нескольких ролей: Клиент, Разработчик, Platform-инженер, SRE и т.д.

ℹ️Материалы по NIST CSF на русском

NIST CSF на мой взгляд один из лучших фреймворков по управлению рисками кибербезопасности. Изначально целевая группа NIST CSF – критически важные объекты, новая же (v 2.0) структура стала адаптируемой и полезной для более широкого круга организаций.

Все материалы NIST CSF на английском, но энтузиасты перевели их на русский и поделились с киберсферой:
1️⃣ Перевод NIST CSF от Вячеслава Аксенова (itsec.by). Получилось довольно качественно, переведены даже картинки (приложил к посту)
2️⃣ Перевод методики оценки по NIST CSF от Дмитрия Шапошникова. Структура документа подготовлена для ее загрузки в BI для визуализации прогресса

Забираем в закладки)
#framework

Наш друг ведет отличный канал по информационной безопасности в целом и по обновлениям различных стандартов в частности.

Не совсем по тематике DevSecOps, но вдруг кому-нибудь будет интересно :)

Zizmor: анализ GitHub Actions

Всем привет!

GitHub Actions - не самое популярное решение в enterprise-компаниях, но вдруг информация в посте кому-нибудь пригодится.

Zizmor – CLI утилита, которая позволяет его анализировать и  находить ИБ-недостатки.

Важно(!): на текущий момент она находится в beta-стадии.

Как и практически любая CLI-утилита, Zizmor устанавливается просто и сразу готова к использованию.

При помощи нее можно найти:
🍭 Dangerous triggers
🍭 Excessive permissions
🍭 Hardcoded container credentials
🍭 Template injection и не только

Из приятного – может предоставлять отчеты как plain-текстом, так и в JSON/SARIF-форматах.

Больше информации, включая примеры использования, можно найти в документации.

Эксплуатация software supply chain уязвимостей в Consul

Всем привет!

Сегодня предлагаем вам небольшую статью, в которой Авторы рассказывают о том, как им удалось найти dependency confusion в проекте Consul.

Началось все с того, что они обнаружили пакет, управление версиями для которого не осуществлялось. Да, был еще один конфигурационный файл, который это нивелировал. Однако, не все пакетные менеджеры смогли бы это «понять». Например, с pnpm могли возникнуть нюансы.

Продолжив исследование, команда нашла еще несколько подобных пакетов.  Оказалось, что они «свободны» и их можно «занять».

Именно это и сделали исследователи. Создали простой payload, который возвращает следующую информацию: hostname, whoami и path. После чего разместили пакет на общедоступном ресурсе.

И… это сработало! Спустя некоторое время команда получила pingback с информацией о «жертве». После успешного PoC пакет был удален, а команда HashiCorp («владельцы» Consul) внесли необходимые изменения.

Хорошо то, что хорошо заканчивается! Тем не менее это лишний раз подчеркивает важность и значимость обеспечения безопасности цепочки поставки ПО.

P.S. Информацию об уязвимых версиях и особенностях эксплуатации можно найти в статье.

Использование LLM для Application Security, опыт
DryRun Security

Всем привет!

Наверное, каждый пробовал поместить если уж не исходный код, то результаты срабатываний *AST-решений в LLM с вопросом – «Что тут false, а что – true positive?»

До сих пор нет однозначной позиции (кроме надежды на silver bullet, которая теплеет внутри) о том, насколько именно LLM могут быть полезны в этом вопросе.

Сегодня предлагаем вам ознакомиться со статьей от DryRun Security, которые в течение годаиспользовали разные LLM для того, чтобы оценить их «пригодность» для Application Security нужд.

Как обычно, началось все с недовольства работой *AST решений: много «шума», отсутствие понимания контекста, не самая высокая производительность, труднопонимаемые результаты для разработчиков и т.д.

Казалось бы, все это можно решить с использованием LLM. При этом получится отличный «переводчик» между AppSec и разработчиками.

Однако, команда все-таки столкнулась с нюансами
🍭 Не все LLM хорошо понимают «в код»
🍭 Результаты не всегда содержат информацию, позволяющую принять решение
🍭 Нюансы, связанные с конфиденциальностью (если используется внешняя LLM)
🍭 «Тренировка» модели процесс не конечный, его надо поддерживать, что не всегда просто

Поэтому реализовать концепт «отдали код – получили перечень уязвимостей» не будет работать. Но расстраиваться не стоит 😊

Если кратко, то использованием LLM может неплохо помочь Application Security, но с нюансами. Какими? Ответ вы найдете в статье 😊

P.S. А что вы думаете про использование LLM для описанных в посте целей? Можно ли на них полагаться или лучше не стоит?

И тот самый Whitepaper (~ 40 страниц) ☺️

Client-Side Path Traversal Playground

Всем привет!

По ссылке доступен GitHub-репозиторий, в котором можно найти Client-Side Path Traversal (CSPT) Playground, подготовленную ребятами из Doyensec.

CSPT – тип уязвимости, который позволяет злоумышленнику манипулировать файлами, используемыми клиентскими приложениями.

Да, они не так распространены, как их «старший брат» (Server-Side Path Traversal), но, тем не менее, результаты могут быть не самые приятные: от XSS до разглашения чувствительной информации.

С примерами можно ознакомиться в статье от Doyensec или в Whitepaper (отправим в следующем посте).

Сам же repo содержит 2 основных сценария:
🍭 CSPT to CSRF
🍭 CSPT to XSS

Для запуска необходимо лишь выполнить docker compose up, после чего перейти на http://localhost:3000 и начать исследование.

Stateful Apps в Kubernetes: возможные способы реализации

Всем привет!

Интересная обзорная статья о том, как работать с Stateful Apps в Kubernetes. Начинается все с истории их возникновения, определенной потребностью нет-нет, да и сохранять состояние, вопреки stateless-идеологии.

Далее – интересней! Статья разбирает такие аспекты, как:
🍭 Принципы работы StatefulSets, их недостатки и подводные камни
🍭 Работа с PV и PVC – что может пойти не так и почему этим может быть сложно управлять
🍭 Использование Operators (на примере ClickHouse)

В статье крайне много наглядных примеров относительно того, почему реализация хранения чего-либо в Kubernetes – не самая очевидная задача.

Завершает статью небольшой переченьOperators, которые можно использовать в случае, если необходимо реализовать Stateful App

P.S. А как вы считаете? Надо ли это делать или все же Kubernetes – это про Stateless подход?

Защита ArgoCD в multi-tenant окружениях

Всем привет!

Еще одна статья, посвященная безопасности ArgoCD. Можно выделить два наиболее значимых аспекта – контроль того, куда можно устанавливать что-либо и контроль тех, кто может взаимодействовать с системой.

Далее Авторы описывают:
🍭 Контроль доступа к ресурсам ArgoCD с использованием policies
🍭 Контроль доступа к ресурсам Kubernetes c использованием Application Project

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

Первая команда может только просматривать собственные Applications, вторая – просматривать/редактировать свои Applications и видеть Applications первой команды.

Дальше – детальные примеры того, как это можно настроить: screenshots, комментарии, конфигурационные файлы – все на месте😊

Сколько времени проходит между ударом по рукам и началом работы продукта на примере ZIIoT

Наши коллеги по цеху, ребята из «Лаборатории Числитель», выпустили пятый выпуск собственного видеоподкаста. Приглашенным гостем стал Максим Шалаев, главный архитектор платформы ZIIoT в ГК «Цифра».

✔️ Как разрабатывалась платформа ZIIoT и развивалась за последние три года
✔️ Кто целевая аудитория решения
✔️ С кем уже были реализованы проекты
✔️ Как устроена продуктовая команда и в чем особенности работы в промтехе

Ответы на эти и другие вопросы вы найдёте в записи подкаста.
Cмотрите на удобной для вас платформе:

📺Rutube
📺YouTube