Open source threat modelling tools

Всем привет!

По ссылке доступен минималистичный обзор open source решений, которые могут быть использованы для автоматизации/упрощения/визуализации процесса моделирования угроз.

Рассматриваются такие инструменты, как:
🍭 Cairis
🍭 OWASP pytm
🍭 OWASP Threat Dragon
🍭 Threagile
🍭 ThreatSpec
🍭 Microsoft Threat Modeling Tool
🍭 Threats Manager Suite

Для каждого их них есть небольшой описание и ссылки на сайты/repo. В завершении статьи (раздел References) можно найти дополнительные материалы по теме.

Open-appsec: Web-protection и API Security

Всем привет!

Open-appsec – open source продукт, разрабатываемый командой Checkpoint. Представляет из себя add-on, который можно установить на Kubernetes Ingress Controller, Nginx и Kong API Gateway.

Обладает следующим функционалом:
🍭 API Security
🍭 Bot prevention
🍭 Intrusion Prevention (IPS Engine с поддержкой Snort 3.0 Signatures, аналитика от Checkpoint)
🍭 Защита от OWASP Top-10 и не только

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

Функционала и возможностей достаточно много, поэтому рекомендуем ознакомиться с документацией и роликами, которые демонстрируют работу open-appsec.

Service Mesh Comparison

Всем привет!

На сайте можно найти небольшое сравнение Service Mesh технологий. Рассматриваются все «основные» участники: Nginx, Istio, Kuma, Cilium, LinkerD и т.д.

В качестве критериев представлены:
🍭 Auto Proxy Injection
🍭 gRPC
🍭 Prometheus Integration
🍭 Tracing Integration
🍭 SPIFFE и не только

Кстати, на самом сайте можно найти интересную timeline-диаграмму, в которой отображены даты появления участников «на рынке».

DevSecOps в Chime

Всем привет!

По ссылке ребята из компании Chime делятся своим подходом к построению практик безопасной разработки и не только.

Соотношение разработчиков к ИБ было ~ 60/1, в результате чего надо было как-то оптимизировать затраты и выстроить рабочий процесс.

Если ничего не подходит – сделай свое! Так поступили ИБ-специалисты Chime и написали собственное приложение – Monocle.

При помощи него можно:
🍭 Получать сводную информацию о состоянии ИБ команды – что реализовано, степень соответствия требованиям
🍭 Оповещать команды в случае, если их «рейтинг» упал ниже порогового значения. При этом приложение позволяет указать, что именно надо поправить
🍭 «Сквозной рейтинг» всех команд – элемент геймификации
🍭 Получать сводную информацию о проекте команды и не только

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

Анализ PR на соответствие ИБ-требованиям

Всем привет!

Продолжение истории Chime! В статье они делятся опытом анализа pull request’ов при помощи их разработки – Monocle!

Команда определила следующие требования:
🍭 PR должен иметь хотя бы 1 review
🍭 PR не должен содержать dependency confusion
🍭 Repo должны содержать только те базовые образы, что были одобрены ИБ
🍭 «Новый код» не должен содержать уязвимостей уровня Critical и High

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

Если интересно, что внутри и как это работает (дада, там OPA) – в статье есть общая архитектура и описание ключевых принципов. Рекомендуем к прочтению!

Мини-лабораторные по анализу кода от GitHub

Всем привет!

По ссылке доступно 5 небольших лабораторных работ по анализу кода от команды GitHub.

Материал включает в себя:
🍭 Level-1: Black Friday
🍭 Level-2: Matrix
🍭 Level-3: Social Network
🍭 Level-4: Data Bank
🍭 Level-5: Locanda

Все лабораторные представляют из себя небольшие python-проекты. Чтобы «пройти» испытание, необходимо получить «passed» от hack.py (уязвимости больше нет) и test.py (при этом код все еще работает). Сложность возрастает от Level-1 до Level-5.

Можно попробовать как в Codespaces (при этом время использование будет тратиться) или установить локально.

Gartner Market Guide for Cloud Native Application Protection Platform

Всем привет!

В приложении можно скачать отчет Gartner, посвященный безопасности Cloud Native приложений. Пусть название Вас не смущает: помимо анализа рынка в отчете много полезной теоретической информации.

Например:
🍭 Общий взгляд на Risk Surface Area
🍭 «Дополнительные» задачи, которые появляются в Cloud Native для разработчиков
🍭 Описание функционала Cloud Native Application Protection Platform
🍭 Основные вызовы, с которыми можно столкнуться и не только

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

State of Secrets in AppSec

Всем привет!

Команда GitGuardian опросила 507 представителей отрасли для того, чтобы собрать информацию о вопросах ИБ, связанных с управлением секретами. В результате получился прилагаемый отчет.

Внутри можно найти:
🍭 Статистику об управлении секретами (сколько % находили hardcode, кто озадачился вопросами управления секретами, используемые практики и т.д.)
🍭 Самооценка уровней зрелости Компаний по вопросам управления секретами
🍭 Подходы к идентификации секретов в репозиториях исходного кода и не только

Получился простой, наглядный и информативный отчет, рекомендуем!

Managed Kubernetes Auditing Toolkit

Всем привет!

Еще один отличный материал от DataDog – Managed Kubernetes Auditing Toolkit (MKAT). Он позволяет идентифицировать ИБ-дефекты в облачных инсталляциях Kubernetes. На текущий момент поддерживается только AWS. Поддержка GCP GKE есть в roadmap.

При помощи него можно:
🍭 Идентифицировать взаимосвязь между k8s SA и AWS IAM Roles
🍭 Искать hardcoded учетные данные AWS в ресурсах k8s (Pods, CM, Secrets)
🍭 Идентифицировать возможность доступа pod’ов к AWS Instance Metadata Service

Кроме этого, MKAT позволяет визуализировать взаимосвязь сущностей через --output dot. В repo есть ссылки на другие решения по анализу конфигураций и описание их отличия от MKAT.

Копирование Secrets в Kubernetes

Всем привет!

Казалось бы, зачем «изобретать еще один велосипед» при управлении секретами в k8s? Есть же HashiCorp Vault с его sidecar/operator, SealedSecrets, External Secrets и не только. Однако, бывают такие случаи 😊

В статье описывается «путь» Lonto. Началось все с того, что командам нужен был сертификат не только для домена вида *.dev.example.com, но и для его sub-domains. Самым очевидным решением стало копирование секретов. Очевидным, но трудно поддерживаемым на большом объеме, особенно в условиях динамического предоставления сервисов (namespace’ов k8s) разработчикам. Второй задачей стала синхронизация секретов во всех кластерха и namespace’ах.

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

В соответствии с потребностями определили следующие требования:
🍭 Поддержка регулярных выражений для указания namespaces, куда должны быть скопированы секреты
🍭 Наблюдение за создаваемыми namespaces для добавления в них секреты (если такое требуется)
🍭 При удалении CR все порожденные им Secrets должны так же удаляться
🍭 Controller должен быть расширяемым. Например, для интеграции с HashiCorp Vault

Результатом работы стал SecretMirror, который доступен на GitHub. И если у вас аналогичные задачи, то может быть именно он сможет вам помочь. Описание архитектуры, логики работы и примеры использования (в том числе работа с HashiCorp Vault) можно найти в статье.

Вебинар «Первичная настройка платформы "Штурвал". Конфигурация провайдеров»

24 мая компании «Лаборатория Числитель» и «Инфосистемы Джет» приглашают вас присоединиться к второму практическому вебинару, посвященному работе с платформой управления контейнерами «Штурвал».

В программе:
▪️Конфигурация провайдера oVirt
▪️Конфигурация провайдера vSphere
▪️Подготовка шаблонов узлов

Демонстрацию решения проведут:
▪️Александр Краснов, технический директор «Лаборатории Числитель»
▪️Дмитрий Горохов, директор департамента виртуализации и контейнеризации «Инфосистемы Джет»

Вебинар будет интересен DevOps-инженерам и DevOps-администраторам.

✅ Регистрация

Вредоносные расширения VSCode

Всем привет!

По ссылке можно ознакомиться с результатами исследования Checkpoint, посвященного анализу расширений (extensions) для VSCode.

Даже с учетом того, что Microsoft старается гарантировать защищенность того, что доступно на marketplace, все равно нашлись вредоносные расширения.

В статье приводятся примеры таких extensions:
🍭 Prettiest Java // попытка кражи чувствительных данных
🍭 Theme Darcula dark // передача данных об окружении на внешний ресурс
🍭 Python-vscode // установка shell injector

Некоторые из них скачивались более 45 000 раз. Из названий видно, что многие расширения «мимикрировали» под существующие безвредные аналоги. Получился такой вот аналог typo squatting.

А контролируете ли Вы устанавливаемые расширения в VSCode? И если да, то как?

Run containers as non-root: работает ли?

Всем привет!

Одна из самых базовых рекомендаций, что можно встретить при знакомстве с безопасностью контейнеров и Kubernetes – «не запускайте контейнеры из-под root».

Логично. Но много ли кто реализовал это на самом деле? Именно таким вопросом задаются Greg Castle и Vinayak Goyal в своем докладе. Согласно статистике – нет. Но как быть? Да, можно понять как работает образ, сделать необходимые chown, chmod, настроить права, вписать USER и т.д. Но это затратно по ресурсам, особенно на большом объеме контейнеров.

Как быть в такой ситуации? Команда определила следующий подход:
🍭 Все попытки запуска новых root контейнеров блокируются
🍭 У существующих контейнеров «отнимали» права root
🍭 Те, что остались работать – не требовали вмешательства
🍭 Если контейнер «сломался» - команда обращалась к владельцу для решения проблем

С точки зрения контроля было принято решение анализировать как Dockerfile (при наличии), так и модифицировать манифесты (добавлять runAsUser, runAsGroup, privileged: false и т.д.).

Особенно интересно, что в своем докладе ребята рассказали про сложности, с которыми им пришлось столкнуться. Например, особенности работы fsMount и hostPath, интересное использование supplementalGroups или нюансы, связанные с управлением capabilities.

Завершает рассказ упоминание Linux User Namespaces, которые недавно появились в Kubernetes (1.25, но пока Alpha) и как их (потенциально) можно будет использовать для решения задачи с root. Получился отличный, простой и очень полезный доклад, рекомендуем к просмотру!

Kubernetes Scheduler «на пальцах»

Всем привет!

Статья от learnk8s, посвященная принципам работы Kubernetes Scheduler. Как и все материалы от этих ребят – просто, понятно и крайне информативно.

Допустим мы сделали kubectl apply -f smth, будущий ресурс сохранился в etcd и теперь надо его создать. Кто это делает? Нет, не Scheduler, ControllerManager 😊 То самое состояние pending.

Далее уже Scheduler берется за дело. Определяет на каком узле кластера надо разместить ресурс и записывает эту информацию в etcd.

Самое интересное в том, что происходит при выборе узла:
🍭 Фильтрация узлов. Есть целых 13 predicates, которые использует Kubernetes (например, CheckNodeCondition, PodMatchNodeSelector, CheckNodeDiskPressure и т.д.)
🍭 Scoring. Расстановка приоритетов размещения ресурса среди узлов, прошедших фильтрацию. И тут есть собственные predicates (например, NodeAffinityPriority, TaintTolerationPriority, LeastRequestedPriority)

Помимо этого, в статье приводятся способы влияния на решение Scheduler - те самые Affinity, Taints & Tolerations, NodeSelectors и другие! Весь материал подается с примерами и иллюстрациями для лучшего понимания ☺️ Самое «то» для пятницы!

Определение Request и Limits с Kube-Reqsizer

Всем привет!

Установка параметров Requests и Limits является не только хорошей практикой, но и содержится практически во всех рекомендациях по ИБ. Однако, не всегда может быть понятно какие значения поставить.

Может помочь герой сегодняшнего поста – Kube-Reqsizer. С его помощью можно автоматически управлять параметрами Requests и Limits для нагрузок кластера. Не путать с VPA (Vertical Pod Autoscaler), т.к. есть различия в работе 😊

Kube-Reqsizer представляет из себя controller, обладающий функционалом:
🍭 Определяет количество CPU/RAM, потребляемых pod. Для этого используется metrics-server и API-группа apis/metrics.k8s.io/v1beta1
🍭 Анализирует pod, идентифицирует его «прародителей»
🍭 После этого изменяет параметры Requests и Limits в «прародителе»

Kube-Reqsizer можно минималистично настраивать. Например, (не) разрешить ему увеличивать или уменьшать показатели, ограничивать CPU и RAM, которые он может поставить для pod и не только.

Ранее мы уже писали про управление Requests и Limits и возможные способы автоматизации тут и тут. Все они построены «поверх» VPA 😊

Kubernetes Purple Teaming Lab

Всем привет!

В статье описывается опыт Sumo Logic по созданию лаборатории для тестирования различных практик эксплуатации уязвимостей в средах контейнерной оркестрации и способов их идентификации.

Команда собрала следующий инструментарий:
🍭 Рабочая станция под управлением Linux. Настроенный Auditd и Laurel для сбора телеметрии. В качестве настроек Auditd использовался готовый набор правил
🍭 Minikube – в качестве «подопытного»
🍭 Vectr – для отслеживания Red и Blue активностей

После создания инфраструктуры ребята приступили к тестированию тактик, описанных в MITRE: T1610 – deploy container, T1609 – Container administration command, T1613 - Container and resource discovery, T1496 - Resource hijacking.

Все проведенные активности записывались в Vectr для отслеживания и визуализации. Такой подход еще раз наглядно демонстрирует важность сбора и анализа логов на всех уровнях – инфраструктура, Kubernetes и логи ПО, запущенного на кластере.

P.S. Да, многое вращается «вокруг» Sumo Logic, но вместо него может выступать любая другая система анализа событий.

Nauticus: управление Spaces в Kubernetes

Всем привет!

Все так, ошибки нет 😊 Именно Spaces, а не Namespaces И ими можно управлять при помощи open source утилиты – Nauticus.

Он представляет из себя controller (да-да, в любой непонятной ситуации пишите свой operator 😊), управляющий CR – Space.

Space включает в себя:
🍭 Уникальный namespace
🍭 ResourceQuotas и LimitRanges
🍭 RoleBinding
🍭 NetworkPolicy и не только

Таким образом задача управления разными namespaces значительно упрощается за счет «преднастройки». Например, при создании Space можно указать enableDefaultStrictMode, что ограничит внешний трафик из других namespaces.

Если интересно прочитать про примеры использования Nauticus, то можно обратиться к этой статье.

Software Licenses in Plain English

Всем привет!

Мы все очень тесно связаны с миром Opensource и Свободного ПО, но большинство не сильно вникает в суть лицензирования.

tl;drLegal - Неплохой способ разобраться в сути лицензий, не имея юридического образования 👨🏻‍🎓.

📄 Более 140 лицензий, с описанием и полными текстами, для изучения.

🇬🇧 Понятный язык, без специфичных для Английского права понятий.

🔍 Поиск по названию и тегам, описывающих суть лицензии.

А если хотите выбрать лицензию для своего проекта - это один из понятных способов разобраться!🧑🏼‍💻

Vim для DevOps

Всем привет!
Многие инженеры пользуюся VSCode для работы. А если сервер доступен только по ssh и файлы хочется редактировать прямо на нем? Или же рабочая станция не самая новая?
Использовать редактор Vim конечно же! Ведь он есть под все современный платформы, даже для Winodws Такое мы не одобряем 😊, а конфиг - везде одинковый, что повышает портируемость. И да, в большинстве случаев он уже установлен в вашей системе.

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

Вот минимальный набор, который будет полезно иметь:

🍭 NERDTree - Позволяет удобно выбирать файлы для редактирования в боковом меню

🍭 nerdtree-git-plugin - Позволяет просматривать статус файлов и строк с системах контроля версий на основе git.

🍭 coc.vim - Conquer of Completion. Плагин для расширений, на базе Nodejs. Поддерживаются языковые сервера для большинства языков программирования и разметки, но нас интересует Bash, Python, Golang, JSON, YAML, Markdown, ASCIIDoc и даже для Dockerfile!
В случае YAML, так же можно включить поддержку синтаксиса ресурсов kubernetes. В итоге вы получите автодополнение!

🍭 vim-terraform - Позволит управлять Terraform не выходя из редактора

🍭 markdown-preview - Дает возможность предпросмотра для Markdown файлов, что очень удобно для написания документации. Мы же все любим это делать, да?😊

А если вам нужно что-то, что не указано здесь - на сайте VimAwesome собран огромный список плагинов с их описанием и возможностью поиска и сортировки. Ведь Vim - конструктор, который каждый собирает под себя👨‍🏭

Infrastructure as Code: риски и способы защиты

Привет!

По ссылке доступна обзорная статья, посвященная вопросам защиты при использовании Infrastructure as Code подхода к управлению ИТ-инфраструктурой.

Сперва Автор рассматривает наиболее «популярные» риски: Misconfiguration, Unauthorized access, Outdated dependencies, Malicious code injections, Inadequate audit and monitoring, Cloud resources we forgot to turn off.

Далее для каждого из рисков приводится верхнеуровневое описание того, как его можно идентифицировать. В том числе с использованием различных утилит. Например, checkov, tfsec, OPA и т.д.

Статья минималистичная, но дающая общий взгляд на вопросы ИБ Infrastructure as Code и подойдет «для начала».

P.S. В самой статье есть много отсылок на другие интересные материалы по теме.