OSV: автоматическое устранение уязвимостей в зависимостях

Всем привет!

В апреле open source сканер от Google – OSV – получил интересный функционал: помощь в устранении уязвимостей в зависимостях.

На текущий момент функционал находится в стадии [Experimental], поддерживается только package.json и package-lock.json.

OSV предлагает следующее:
🍭 Анализ графа зависимостей с целью идентификации минимальных изменений, необходимых для устранения уязвимостей
🍭 Расстановка приоритетов в обновлении прямых зависимостей на основании количества устраненных уязвимостей в транзитивных
🍭 Расстановка приоритетов по устранению уязвимостей на основании «глубины/уровня» зависимости, уровня критичности и не только

OSV fix может не только помогать AppSec специалисту в анализе данных об уязвимостях, но и автоматически обновлять зависимости. Подробнее об использовании функционала можно прочесть в документации на решение.

P.S. Еще раз напоминаем, что эти возможности находятся в стадии [Experimental] и лучше не использовать это "в бою"

Iptables и Kubernetes

Всем привет!

Есть много курсов по тому, как научиться работать с Kubernetes и, в любом случае нет-нет, да и придется изучать Linux 😊

Анализ трафика – не исключение. Для того, чтобы лучше понять то, как можно его фильтровать нет ничего лучше, чем старые добрые Iptables!

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

Рассматривается:
🍭 Описание правил
🍭 Работа с chains
🍭 Добавление правил в custom chain
🍭 Управление логами Iptables
🍭 Использование Iptables для защиты Kubernetes и не только

В статье очень много примеров, screenshots, пояснений к происходящему. Самое «то», чтобы рабочая суббота «пролетела» чуточку быстрее ☺️

БЕКОН: когда много «мяса»!

Всем привет!

Все именно так! Для тех, кто не знает, БЕКОН – конференция, посвященная безопасности контейнеров и всего, что с ними связано, созданная командой Luntry. В этом году она пройдет во второй раз!

Никакой воды, маркетинга, рекламы, product placement и всего такого. Только «мясо». Много «мяса» и технических подробностей реализации нетривиальных задач!

С полным описанием программы конференции можно ознакомиться на сайте. Мы лишь подсветим компании, которые представляют спикеры:
🍭 Tinkoff
🍭 Luntry
🍭 Samokat Tech
🍭 Сбертех
🍭 Флант
🍭 Яндекс Финтех
🍭 Лаборатория Числитель

Конференция пройдет 5-ого июня, в Москве (Loft Hall). Приходите, будет «вкусно», интересно и чрезвычайно полезно! И будем очень рады, если вы придете поддержать Алису Кириченко, которая выступит с докладом, посвященным работе с Audit Logs в Kubernetes 😊

Vulnerability Management: ключевая проблематика и стоимость

Всем привет!

«Сколько, в среднем, стоит устранение уязвимостей в Компаниях?» - именно такой вопрос задала себе команда Chainguard (одним из направления деятельности, которых является создание минималистичных образов контейнеров, в которых уязвимостей значительно меньше, чем в «обычных»).

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

Если кратко, то:
🍭 Оценить время для tirage конкретной CVE затруднительно. Оно может варьироваться от 20 минут до нескольких недель
🍭 Большое количество действий при tirage. Обилие данных может привести к «открытию и чтению десятков вкладок» браузера, чтобы понять «что это есть на самом деле»
🍭 Shift Left не панацея. Уязвимости могут появляться ежедневно, поэтому управлять ими надо в «режиме реального времени»
🍭 Некоторые компании тратят тысячи часов на процесс управления уязвимостями. Грубо говоря, 1 и более сотрудников полноценно занимаются только этим в течение года

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

А что вы думаете по этому поводу? Имеет ли такой подход место быть и нужно ли стремиться к «zero tolerance»?

GitLab: CIS Benchmark

Всем привет!

В апреле этого года GitLab совместно с Center for Internet Security (CIS) выпустили CIS GitLab Benchmark (~ 301 страница), который можно найти в приложении.

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

Рекомендации делятся на 5 глобальных блоков:

🍡Source Code (исходный код)
🍡Build Pipelines (среда и конфигурационный файл сборки)
🍡Dependencies (зависимости)
🍡Artifacts (артефакты)
🍡Deployments (конфигурационные файлы для развертывания приложения)

Документ похож на CIS Benchmark for Supply Chain, который CIS выпускала ранее. Он может быть крайне полезен, если вы используете GitLab и хотите настроить его с учетом ИБ-практик

Linux Exploit Education

Всем привет!

Скоро будут вторые майские праздники, в которые можно поучиться чему-нибудь новому! Предлагаем вам обратить внимание на проект «Exploit Education», который позволит углубиться в тонкости работы с Linux.

Сами лабораторные работы представляют из себя набор виртуальных машин (увы, online не получится), в которых есть задания на различные тематики.

Например:
🍭 Nebula. Повышение привилегий в Linux, состояние гонок в файловой системе, проблемы в noscripting languages
🍭 Phoenix. Работа с дефектами, характерными для памяти
🍭 Fusion. Аналогично Phoenix, но предлагает более сложные сценарии

В среднем, в каждой виртуальной машине содержится примерно 15 заданий. Уровень сложности варьируется – от Nebula к Fusion он повышается.

Управление секретами: Vault и External Secrets Operator

Всем привет!

«Среда – это маленькая пятница!» Сегодня так уж точно ☺️ Поэтому предлагаем вашему вниманию небольшую статью.

В ней Автор рассматривает возможность динамического управления секретами в Kubernetes с использованием HashiCorp Vault и External Secrets Operator (ESO).

Предлагается следующий алгоритм:
🍭 Установка Vault и ESO
🍭 Создание Read Token в Vault для настройки взаимодействия с ESO
🍭 Создание Secret Engines и Secrets в Vault
🍭 Создание External Secret, обновление Secret на стороне Vault, синхронизация с Secret в Kubernetes

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

И, пользуясь случаем, поздравляем вас с наступающими праздниками! Желаем отлично провести время, набраться сил и до встречи на следующей неделе! ☺️

Как работает Kubectl?

Всем привет!

Если вам хоть раз доводилось «что-то» с Kubernetes, то вы точно использовали kubectl. Но задавались ли вы вопросом – а что именно она делает и как она устроена?

Если нет, то рекомендуем прочесть статью, в которой описаны основные принципы работы этой удобной утилиты.

Например:
🍭 Где и как она ищет kubeconfig
🍭 Почему и зачем в kubeconfig приведены именно эти параметры
🍭 Какие способы аутентификации она использует
🍭 Как можно воспроизвести (ну почти) ее действия с использованием обычного curl

В завершении статьи Автор предлагает пойти дальше – скачать себе ее repo, посмотреть на исходный код и добавить собственную функцию

CyberCamp: прием заявок до 1-ого июня!

Всем привет!

Ранее мы писали про открытие Call For Papers (CFP) на CyberCamp – мероприятия, в котором соединяется теория и практика!

CyberCamp проходит в online формате (как теория, так и практика) и собирает более 10 000 участников, объединенных любовью к информационной безопасности и тягой к знаниям.

Если у вас есть что рассказать (по тематике безопасной разработки, DevSecOps и не только), то приглашаем вас откликнуться и стать частью CyberCamp 2024! Крайний срок подачи заявок – 1-ое июня 2024 года.

Подробности можно найти по ссылке. Да, есть небольшая анкета, которую надо заполнить, но, обещаем, это не займет много времени! Спасибо и до встречи на мероприятии! ☺️

Cilium Network Policy: материал для погружения

Всем привет!

По ссылке можно найти весьма неплохую статью (~ 18 минут чтения) для погружения в Network Policy Kubernetes, которые можно реализовать при использовании Cilium.

Начинается все достаточно «безобидно» - общие концепты про взаимодействие pod, про основные «поля» Network Policy (selector, direction, types и т.д.).

Дальше становится интереснее Enforcement Mode, Application Discovery, Security Identity, использование Hubble для просмотра трафика между pods и, конечно же, возможные варианты troubleshooting.

Все указанные концепции рассматриваются на примере небольшого приложения, для которого Автор описывает необходимые политики контроля сетевого трафика.

Вакансия DevSecOps-инженера в Инфосистемы Джет.

Всем привет! А вот и наша непостоянная рубрика "вакансии" :)

Сейчас мы активно расширяем команду и ищем DevSecOps инженера.
Перечень задач весьма обширный и обсуждается индивидуально исходя из ваших возможностей и предпочтений, но если коротко, то вот он:
🔹внедрение инструментов DevSecOps (SAST, DAST, Container Security, Secret Management, OSA\SCA, ASOC)
🔹формирование процессов безопасной разработки (проведение аудитов по фреймворкам BSIMM, SAMM, DAF, разработка документации и консалтинг)
🔹создание новых и совершенствование существующих в компании сервисов в части безопасной разработки

Требования к кандидату, условия работы и наши ожидания: https://jet.su/career/vacancies/inzhener-devsecops/

Формат работы: гибрид с офисом в центре Москвы

Резюме и вопросы присылайте в телеграм нашему HR @BigmanVictoria или в отклике на вакансию

Если вы прочитали и подумали, что по каким-то параметрам не дотягиваете, то посмотрите на еще одну нашу интересную вакансию https://hh.ru/vacancy/96999601 ☺️

Network Policy Templating с использованием Helm

Всем привет!

Продолжаем тему работы с сетевыми политиками. Сегодня хочется поделиться интересным и удобным подходом к их управлению. А именно – использованием Helm Template.

В статье Автор предлагает следующее:
🍭 Создание сетевой политики, например, с использованием Cilium Network Policy Editor
🍭 Создание Helm Template на базе ранее созданной политики
🍭 Подготовка Helpers (podSelector, ingress, egress, cidr block и т.д.)
🍭 Тестирование! 😊

Все примеры и пояснения можно найти в статье. Но зачем использовать Helm? Все просто – политики могут отличаться в зависимости от ситуации, но «ядро политики» может быть одним.

Поэтому может быть проще не создавать отдельные NetworkPolicy файлы, а осуществлять управление через разные Helm Values и Helpers.

Обогащение информации по уязвимостям

Всем привет!

По ссылке можно найти repository, в котором содержится обогащенная информация по CVE. Проект и работа по нему курируется CISA.

Если совсем просто, то CVE обогащаются информацией на основании SSVC scoring (наработки CISA, о которых можно прочесть тут).

В «расширении» информации об уязвимости могут быть добавлены поля
🍭 Exploitation status
🍭 Technical impact
🍭 Automatable

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

Semgrep Academy: новые курсы!

Всем привет!

Недавно мы писали про Semgrep Academy (вот тут). На тот момент, курсов было немного, но! Недавно их стало больше!

Были добавлены:
🍭 API Security Mini Course (16 уроков, 30 минут видео)
🍭 Secure Coding (70 уроков, 2 часа виде)
🍭 Semgrep 101 (27 уроков, 1 час видео)

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

Надеемся, что проект будет развиваться, появятся лабораторные работы и, возможно, экзамены ☺️

Admission Controller с использованием OPA (но не Gatekeeper)

Всем привет!

Про Admission Webhook есть очень много разных статей, а полезность самой технологии велика! И сегодня мы предлагаем вам ознакомиться с еще одной статьей по теме 😊

Автор предлагает использовать OPA в качестве «точки принятия решения» о соответствии Admission Review Request требованиям. Нюанс в том, что это не Gatekeeper, а самостоятельный сервис, реализованный на "чистой" OPA.

В первой части материала предлагается установить OPA:
🍭 Создание сертификатов, создание и подтверждение CSR
🍭 Разворачивание и конфигурация OPA и kube-mgmt
🍭 Создание Service
🍭 Настройка прав доступа

Все готово! Теперь в кластере есть полноценный Policy Engine, готовый обрабатывать запросы на соответствие политикам.

А продолжение… (написание политик, контроль создаваемых ресурсов и т.д.) будет во второй части статьи!

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

Pipeline Integrity and Security

Всем привет!

Еще одна интересная статья из блога GitGuardian. В этот раз ребята рассматривают вопросы обеспечения информационной безопасности конвейеров сборки.

Начинается все с небольшого моделирования угроз (если вы изучали SLSA, то схема будет вам очень знакома 😊), а далее Автор переходит к описанию мер защиты.

Рассматривается:
🍭 Branch protection
🍭 Reproducible builds
🍭 Artifact signing
🍭 Workstation security
🍭 Build platform hardening и не только

В статье приведен очень неплохой обзор того, что можно делать для защиты конвейера сборки, получаемых в процессе артефактов и build workers.

Единственное, чего бы хотелось – больше детализации.

K8S Cleaner: удаление неиспользуемых ресурсов k8s

Всем привет!

Иногда случается так, что в кластере k8s остаются неиспользуемые ресурсы или ресурсы, которые находятся в постоянном перезапуске. Причин может быть множество – от некорректно отработавших finalizers до нарушения в логике работы приложения.

Такие ресурсы не очень хочется хранить: они могут потреблять вычислительные мощности или быть использованы для совершения атак.

Удалять их можно по-разному: следить «руками» (но кто так делает в 2024?) или автоматизировать! Реализацией второго варианта может служить K8S Cleaner!

На текущий момент он работает с:
🍭 ConfigMaps/Secrets
🍭 ClusterRoles/Roles
🍭 ServiceAccounts
🍭 Deployments/StatefulSets и не только

А чтобы вы были в курсе происходящего можно настроить оповещения через различные каналы о том, какие ресурсы были удалены. Но это не все 😊 Со всеми возможностями и параметрами конфигурации K8S Cleaner можно ознакомиться в repo проекта

CodeQL: From zero to hero, Part 3

Всем привет!

Еще одна потрясающая статья, посвященная CodeQL, принципам его работы и возможностям (про первую и вторую части мы писали тут и тут соответственно).

Третья часть посвящена использованию CodeQL для проведения Security Research. Автор описывает:
🍭 Поиск определенных методов используемых библиотек
🍭 Отслеживание taint-данных (с разбором data flow – local/global и их отличия от taint)
🍭 Идентификация аналогичных/идентичных уязвимостей в кодовой базе
🍭 Общую методологию анализа исходных кодов с использованием CodeQL

Материала много, деталей много, пользы (надеемся) тоже много! Каждый пример описывается максимально подробно, чтобы точно понять, что происходит. Отличное чтиво для пятницы или приближающихся выходных, рекомендуем 😊

P.S. Для укрепления теоретических навыков можно пройти ряд практических заданий 😊

Distroless Containers: (не) самые защищенные?

Всем привет!

Можно до бесконечности пытаться устранить уязвимости в образах контейнеров, а можно использовать минималистичные образы, в которых «начинка» сведена к минимуму – distroless.

Варианты реализации есть от Google и Chainguard. И кажется, что все отлично – ничего лишнего внутри нет, sh, bash отсутствуют и эксплуатация уязвимостей становится (не) возможной.

Однако, нет ничего абсолютного. В статье Автор предлагает рассмотреть обычный Debian образ из реестра Google и посмотреть можно ли что-то сделать.

Автор пробует:
🍭 Запустить sh, bash внутри контейера. Логично, что ничего не получается
🍭 Далее он меняет entrypoint на /usr/bin/openssl
🍭 Используя enc он может читать информацию, в том числе в Kubernetes, получая ServiceAccountToken

Да, это лишь чтение и изучение, но идею можно развить и дальше. Какой вывод можно сделать? Да, distroless – отличный вариант для сокращения поверхности атаки, но это не панацея и потому лучше не полагаться только на них, а подходить к вопросу обеспечения защиты контейнеров комплексно

Kubernetes Pentesting Checklist

Всем привет!

По ссылке можно ознакомиться с checklist’ом, в котором описаны подходы к тестированию на проникновение кластеров Kubernetes.

Материал «разбит» на следующие части:
🍭 Control Plane (etcd, kubelet, static pods и т.д.)
🍭 RBAC Abuse (кража token, горизонтальное перемещение, глаголы (verbs) с повышенными привилегиями и т.д.)
🍭 Иное (то, что не попало в перечень выше)

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

Например, в статье можно найти информацию о том, как записывать данные в etcd, взаимодействовать с kubelet напрямую для получения информации о кластере или запускать команды внутри pod и многое другое

Анализ PyPi пакетов от DataDog

Всем привет!

В том году команда DataDog выпустила в open source свет проект GuardDog, который совмещает возможности композиционного и статического анализа для более точной идентификации уязвимых open source компонент.

Согласно статье команда и сама его использует. В том числе для анализа PyPi пакетов на постоянной основе. Всего у них получилось идентифицировать ~ 1500 вредоносных open source пакетов.

Однажды им попалось вот такое срабатывание:
🍭 Empty Information. У пакета отсутствует описание
🍭 Single Python File. Пакет состоит лишь из одного Py-файла
🍭 Command Overwrite. Команда install видоизменена
🍭 Code Execution, Пакет выполняет команды на уровне ОС

Этого оказалось достаточно для того, чтобы заинтересоваться пакетом и провести его исследование.

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