И, как обещали, тот самый «Controlling the Source: Abusing Source Code Management Systems».

Документ состоит из следующих разделов:
🍭 Source code management systems
🍭 GitHub enterprise (Background / Attack Scenarios)
🍭 GitLab enterprise (Background / Attack Scenarios)
🍭 Bitbucket (Background / Attack Scenarios)
🍭 SCMKit (использование на различных этапах kill-chain)
🍭 Defensive considerations

Всего ~ 111 страниц текста.

X-AST: разновидности

Всем привет!

По ссылке доступна очень лаконичная статья от PVS-Studio, посвященная разновидностям Application Security Testing (AST).

Рассматриваются такие подходы и практики, как:
🍭 SAST: Static Application Security Testing
🍭 DAST: Dynamic Application Security Testing
🍭 IAST: Interactive Application Security Testing
🍭 MAST: Mobile Application Security Testing. В статье не рассматривается, но если Вам интересно узнать, что это такое, то рекомендуем прочитать про Stingray. Ссылка на документацию.

Если Вы уже все про это знаете, то ничего нового точно не найдете. С другой стороны, если Вы немного «путаетесь» в аббревиатурах – самое то! Автор отлично все описал, просто и понятно, указал на плюсы и минусы тех или иных подходов, а в заключении собрал все в единую и наглядную таблицу.

Использование Alpine в качестве base image

Всем привет!

Ivan Velichko поделился своими размышлениями об использовании Alpine в качестве базового образа.

Началось с того, что он задал вопрос в Twitter о том, используют ли компании Alpine. Большинство ответили, что «Да!». Следующий вопрос был более общий – что важнее при выборе «основы»: быстрая сборка, общее количество CVE, иное. Варианты «Сборка» и «Количество CVE» были практически идентичны! И, напоследок, Ivan подготовил еще один вопрос: «Я использую Alpine, потому что…». И вот тут вариант ответа «5 Mb!» выбился в лидеры со значительным отрывом.

На основе такого опроса можно попробовать сделать несколько выводов:
🍭 Размеры образа важны, т.к. это ускоряет процесс, сокращает количество CVE (спорно, но скорее всего в более минималистичных образах количество CVE меньше)
🍭 Alpine – не единственный, хоть и очень удобный, выбор в качестве base image. Есть и альтернативы – тот же distroless (про который мы писали тут) или использование DockerSlim (которые еще генерирует AppArmor и Seccomp профили по резлуьтатам работы)

Подробности – в статье от Ivan, крайне рекомендуем к прочтению, как и весть его блог. Множество ценной и полезной информации, подаваемой в простом и удобном для восприятия формате.

Обзор Kubernetes Services, LoadBalancers и Ingress

Привет!

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

Как организовать сетевое взаимодействие между pod внутри кластера? А как с «внешним миром»? Почему IP-адреса вроде, как и есть, а вроде как их нет? Ответы на эти вопросы и не только можно найти в статье.

Авторы рассматривают такие сущности как:
🍭 Services (ClusterIP, NodePort, LoadBalancer)
🍭 Ingress

Отдельно в статье упоминаются FAQ. Например: можно ли создать несколько Services с одинаковым именем? Можно ли «пинговать» Services? Можно ли взаимодействовать с pods из другого namespace? Что такое Headless Service и т.д.

Есть примеры, ссылки на материалы по теме. А в конце статьи приведена общая табличка с типами сетевых сущностей и разницей между ними, включая уровни модели ISO/OSI, на которых они работают.

Импорт результатов Trivy в PolicyReporter

Всем привет!

Frank Jogeleit подготовил интересный проект. Он взял результаты работы Trivy (Vulnerability Assessment, RBAC Analysis и не только) и «переложил» их в структуру v1alpha2.PolicyReportResult и v1alpha2.ClusterPolicyReportResult.

Указанные структуры представляют из себя CRD, прорабатываются Kubernetes Policy Working Group и набирают все большую популярность.

Именно в таком формате, например, предоставляет результаты и другой инструмент – Kyverno! А для визуализации подобных отчетов есть отдельное решение – PolicyReporter. Суть простая: данные из polr (PolicyReports) и cpolr (ClusterPolicyReports) отображаются в виде графиков, что упрощает дальнейший анализ.

Если объединить первое со вторым, то получится «единое» окно, в котором содержится графическое представление результатов работы сразу нескольких инструментов: Kyverno, KubeBench, Trivy. При желании можно дописать свой mapper или доработать существующие. Например, если вы не согласны с той логикой, что определил Автор.

Дополнительно настраивать ничего не надо. Данные по отчетам Trivy появятся в блоках PolicyReports и ClusterPolicyReports за счет того, что PolicyReporter «подписан» на соответствующие изменения.

Устройство сети Kubernetes

Всем привет!

По ссылкам можно ознакомиться с циклом статей, посвященному устройству сети Kubernetes. Цикл разбит на три части, в каждой из которых уровень «погружения» увеличивается.

🍭 Первая статья рассказывает про namespaces (pid, mnt, utc, ipc, user, net). Что это такое, зачем оно нужно и какое отношение имеет к контейнерной сети.
🍭 Вторая раскрывает тему Pause Container. Если вы не знаете, что это такое и в чем суть его существования – очень рекомендуем прочесть, ответ достаточно интересный. Простой контейнер с одним бинарным файлом.
🍭 Третья уже вплотную подбирается к Kubernetes. Описывается как взаимодействуют компоненты между собой (на одной node, на разных node), что такое cbr0, примеры маршрутизации трафика.

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

CyberCamp 2022!!!

Всем привет!

Материал не совсем по тематике канала (хотя, spoiler: в программе есть отличный доклад Сергея Канибора из Luntry!), но не поделиться им мы не можем!!!

Встречайте, CyberCamp 2022 !!!

Присоединяйтесь 14-16 сентября к онлайн-конференции! Практики по кибербезопасности расскажут, как обнаруживать, расследовать и отражать кибератаки.

Что будет?
🔹20 докладов и мастер-классов от пентестеров, специалистов по мониторингу и расследованию инцидентов из Group-IB, «Лаборатории Касперского», «Инфосистемы Джет», Positive Technologies, Luntry, Синклит и Yandex Cloud
🔹Задания для отработки практических навыков в формате игрового обучения

Забронируйте три дня на полезный контент:
🔹Поиск низко висящих фруктов в ИТ-инфраструктуре
🔹Раскладываем атаки по MITRE
🔹Эффективный харденинг ИТ-инфраструктуры
🔹Типовые сценарии Windows Persistence и их обнаружение
🔹Инструменты пентестеров для BlueTeam
🔹Автоматизация работы с инцидентами
🔹Форензика и криминалистические артефакты
🔹Безопасность АСУ ТП: угрозы, подходы, практики
🔹Обогащение в SIEM: как забирать данные из AD, GeoIP, TI

Регистрация на сайте CyberCamp 2022!

Kubernetes OWASP Top-10: примеры

Привет!

Проект Kubernetes OWASP Top 10 продолжает развиваться. Ранее пустые разделы постепенно наполняются описанием и примерами! Появляются статьи, которые разбирают описанные в нем риски.

Одна из таких статей разбирает первый и самый «популярный» - Insecure Workload Configurations. Автор описывает Security Context и что они могут/для чего они нужны.

Он разбирает не все, лишь самые интересные на его взгляд:
🍭 Privileged
🍭 Действия с Capabilities
🍭 runAsUser/Group
🍭 runAsNonRoot
🍭 readOnlyFileSystem

Приведены примеры, что это и зачем, почему это (не) стоит применять. А если Вы не успели ознакомиться с полной версией Kubernetes OWASP Top 10, то он доступен по ссылке.

Контроль доступа к REST-endpoints в k8s

Всем привет!

Допустим, что есть приложение с опубликованным REST-endpoint в Kubernetes. Как предотвратить несанкционированный доступ к такому Endpoint?
У приложения могут быть собственные механизмы аутентификации. А что, если их нет? Или они по какой-то причине недоступны?

В статье Автор разбирает возможные сценарии решения задачи:
🍭 Ingress, поддерживающий аутентификацию. Один из наиболее частых способов, реализуемый, например, с Nginx Ingress Controller
🍭 Reverse-proxy. Использование sidecar-контейнера, например, с Nginx
🍭 Использование RBAC k8s. Да, можно и так!

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

Security Small Talk

Всем привет!

Вышел новый выпуск Security Small Talk об управлении секретами.
В нём детально объясняется следующее:
• Что такое секреты и в чем отличие «human-to-machine» и «machine-to-machine» секретов
• Управление секретами на всех этапах жизненного цикла
• Как можно защищать секреты, какие практики и средства автоматизации можно использовать

Trivy, Cosign и Kyverno: анализ даты последнего сканирования образа контейнера

Всем привет!

Если соединить Trivy, Cosign и Kyverno, то можно реализовать достаточно интересный сценарий. Его демонстрация с примерами всех настроек приведена в статье. Да, там используется GitHub Actions, но сам подход можно реализовать на любой удобной Вам платформе.

Происходит следующее:
🍭 Образ сканируется при помощи Trivy, в результате получаем отчет по уязвимостям
🍭 Результат сканирования проходит аттестацию при помощи Cosign. Про аттестацию (in-toto attestation) можно прочитать тут и тут. «Спецификация» аттестации, генерируемая Cosign описана тут.
🍭 Создается политика Kyverno, которая может «читать» аттестацию и анализировать ее поля. Например, можно проверить, что со времени последнего сканирования прошло не более X дней.

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

Это только небольшой пример возможностей Kyverno по взаимодействию с Cosign, рекомендуем ознакомиться с документацией, чтобы узнать больше!

Elixir Secure Coding Training

Всем привет!

В repo представлен набор Secure Coding Training, включающий в себя такие разделы как:
🍭 OWASP
🍭 Secure SDLC
🍭 GraphQL, Elixir Security
🍭 Cookie Security
🍭 Security Anti-patterns
🍭 CI/CD Tooling

С описанием того, что внутри можно ознакомиться в соответствующих файлах. А если хочется большей красоты и интерактивности – можно установить Livebook и использовать его в качестве «интерпретатора».

Ephemeral Containers

Всем привет!

По ссылке доступна ознакомительная статья, которая позволит понять, что такое ephemeral containers и зачем они нужны.

Вкратце, ephemeral container – «рыба-прилипала», которая «присоединяется» к целевому контейнеру и позволяет с ним взаимодействовать. Это может быть нужно, например, для debug.

Представим, что у вас есть distroless образ и вы думаете, что есть проблемы с сетевой связностью. Но как проверить? wget, curl – их не будет в таком образе. Как раз вот тут и пригодятся ephemeral containers и это далеко не единственный случай.

Такое возможно благодаря тому, что ephemeral container «разделяет» namespaces (mnt, utc, ipc, user, net и т.д.) с «целевым». Кстати, с pid все несколько иначе.

Детали, команды и их результаты представлены в статье. А в конце – пример использования mirrord с Job или через ephemeral containers.

Securing the Software Supply Chain: Recommended Practices for Developers

Всем привет!

Недавно вышли новые рекомендации от NSA, посвященные безопасности Software Supply Chain.

В 64-х страничном документе разобраны такие темы, как:
🍭 Develop Secure Code
🍭 Verify Third-Party Components
🍭 Harden the Build Environment
🍭 Deliver Code

Документ описывает проблематику для каждого «блока» и рекомендации о том, как сделать лучше и безопаснее. Каждая рекомендация описывается достаточно подробно, но без детальных how-to (все-таки это документ, содержащий общие практики). В целом получилось достаточно интересно, на наш взгляд.

Risk8s Business: Risk Analysis of Kubernetes Clusters

Всем привет!

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

Guide состоит из нескольких разделов:
🍭 Introduction. Обзор Kubernetes, рассуждения на тему «что такое безопасный кластер»
🍭 Understanding Your Environment. Как получить необходимую информацию о кластере для последующей «работы» с ним по ИБ
🍭 Understanding Your Risk. Простенький анализ рисков с учетом всей информации, полученной на предыдущих этапах
🍭 Wrapping Up. Заключение, в котором делается обзор всего пути и ключевые выводы

Есть примеры, инструменты, их использование и много всего интересного. Рекомендуем открывать на PC, потому что с телефона отображение информации или навигация могут быть искажены.

Kubernetes resources under the hood — Part 1

Привет!

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

Автор рассматривает такие вопросы, как:
🍭 Linux namespaces, их назначение и как (для чего) они используются контейнерами
🍭 Можно узнать, сколько pod по умолчанию Kubernetes может разместить на одной node. Да, есть и такое
🍭 Что такое Requests и Limits, как они связаны с cgroups, при чем тут «сompressible» и «incompressible», что такое throttling и от чего он возникает
🍭 Какие есть QoS у Kubernetes и от чего они зависят. И тут есть много своих нюансов. Если кому хочется узнать особенности поведения Guaranteed с использованием целого количества ядер, а не millicores, как обычно, то можно прочитать про Topology Manager

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

Kubernetes resources under the hood — Part 2

Всем привет!

Вторая часть серии посвящена Requests и их роли в жизненном цикле pod, которая заключается не только в scheduling.

Прочитав ее, можно узнать:
🍭 Сколько CPU Shares запрашивает Kubernetes, основываясь на данных, указанных пользователем в Requests
🍭 Completely Fair Scheduler (CFS) Linux – распределение CPU requests между процессами, как он работает и зачем нужен
🍭 Влияние threads и QoS на предоставление ресурсов CPU

Просто, наглядно и с примерами!

Kubernetes resources under the hood — Part 3

Всем привет!

Третья часть серии начинается достаточно провокационно – Don’t set your CPU limits! Это сильно противоречит большинству рекомендаций по ИБ (и не только) по корректному написанию манифестов (наличие CPU/RAM requests и limits).

Далее начинается нечто! Автор обосновывает свою точку зрения с учетом:
🍭 Информации из предыдущих статей, особенно с использованием CPU Shares
🍭 Чуть больше раскрывается тема throttling, разница поведений контейнеров при использовании single/multi threading
🍭 Математики (да, ее много для статьи не про нее)
🍭 Рассуждений о том, что будет если 1 контейнер будет сильно потреблять ресурсы – пострадает только он или все его «соседи» по node?
🍭 Эксперимент с последовательным запуском двух pods, значения CPU requests/limits которых (не)устанавливаются в разные «положения» и что при этом происходит с учетом тех QoS, которые они получают от Kubernetes.

И все-таки? Нужны ли CPU Limits? Мнение Автора и примеры их (не)использования в реальном мире можно узнать в разделе «When to use CPU Limits» в конце статьи.

False positive/negative при сканировании образов контейнеров

Всем привет!

Одна из самых частых практик, про которую точно слышали все – сканирование образов контейнеров на наличие уязвимостей. Есть большое количество инструментов (как open source, так и enterprise), которые решают эту задачу. Они развиваются, функционал расширяется, например, создание Software Bill of Materials (SBOM) для образа контейнера. Но все ли они видят? И как обстоят дела с наличием ошибок первого и второго рода?

В статье приводятся примеры как первых, так и вторых – можно либо найти лишнее, либо не найти то, что на самом деле важно.

Почему это так?
🍭 Большинство сканеров работают с базой данных пакетных менеджеров (apt, yum, apk и т.д.) и видят только то, что установлено с их использованием
🍭 У некоторых сканеров (например, Snyk) есть «собственные проприетарные практики» обнаружения, например, Node.js, который обычно ставится «напрямую», а не через пакетный менеджер

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

Что делать? Авторы статьи предлагают перенести созданием SBOM на момент сборки и, по возможности, использовать distroless подход с использованием melange и apko (о которых мы писали тут).

Sidecar(less) mTLS от Cilium

Всем привет!

Многие ИБ-специалисты хотят, думают использовать, используют (?) mTLS для повышения безопасности сред контейнерной оркестрации.

Одним из самых популярных подходов является использование sidecar-паттерна, который реализует необходимый функционал. Однако, такой подход может быть избыточным и ребята из Cilium представили свой подход к mTLS, в котором не требуется дополнительных контейнеров.

В статье этот вопрос рассматривается более детально:
🍭 Общее описание того, что такое mTLS и зачем он нужен
🍭 Разница между session based и network based mutual authentication
🍭 Плюсы и минусы описанных выше подходов

Далее поднимается вопрос о том, можно ли совместить 2 подхода (session/network based) и как этого можно достигнуть при помощи Cilium Service Mesh. И, конечно же, тесты на производительность! Куда же без них! Если верить текущим прогнозам, то функционал mutual authentication будет доступен в Cilium v1.13 (текущая версия – 1.12).

Визуализация JSON

Всем привет!

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

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

Но сперва надо понять, как он «устроен». Это не то, чтобы сложно, но иногда хочется простой визуализации, а не просто «красивой» формы, которые могут давать jq, Notepad++, VSCode и другие системы.

Если Вы согласны, то рекомендуем обратить внимание на проект JSONCrack, которые позволяет построить наглядную диаграмму из JSON-файла. И все это в минималистично-необходимом UI.

JSONCrack доступен как online, так и в качестве контейнеров, которые можно запустить on-premise.