Развитие SAST-программы в Razorpay

Всем привет!

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

Началось все с того, что они решили выбрать какой инструмент им подойдет. Для этого они определили перечень критериев и… самое интересное, что «наличие встроенных правил для анализа» вообще никак не влияло на выбор целевого решения! Почему это так - описано в статье.

Далее – как обычно: как они настраивали, когда сканировали, как работали с командами. Схемы, графики, описания. Особенно хочется отметить, что в их случае top-down подход не сработал, а bottom-up дал первые результаты.

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

В итоге, за год ребята прошли путь от 0 «подключенных» приложений до 200!!!

KubeEye: обнаружение и аудит ресурсов k8s

Всем привет!

KubeEye – утилита, которая позволяет обнаруживать и проводить аудит конфигураций ресурсов Kubernetes. «Внутри», как обычно, используются OPA-правила.

При помощи KubeEye можно:
🍭 Проводить аудит на соответствие лучшим практикам
🍭Идентифицировать проблемы в Control Plane компонентах
🍭Анализировать состояние nodes и идентифицировать, например, disk pressure

«Из коробки» доступно порядка 30 правил, например: PrivilegeEscalationAllowed, CanModifyWorkloads, ImageTagIsLatest, NodeStatus, KubeletStatus и другие. Также использование инструмента подразумевает возможность создания собственных проверок.

Прочитать про установку, конфигурацию и ознакомиться с планами дальнейшего развития (roadmap) можно в repo проекта.

iftree: визуализация сетевых интерфейсов

Привет!

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

С этим может помочь iftree – утилита, которая позволяет визуализировать veth/bridge и предоставлять данные в разных форматах:
🍭 Диаграмма (предоставляются данные для генерации в Graphviz)
🍭 Текст
🍭 Таблица

Инструмент достаточно минималистичный, но может пригодиться для изучения.

Istio Handbook

Всем привет!

Очень неплохой материал, посвященный Istio – статьей его язык не поворачивается назвать, т.к. материала очень много, но это и не полноценная книга.

В материале содержится информация о:
🍭 What Does Istio Do?
🍭 Introduction to Istio
🍭 Istio’s Architecture
🍭 How to Use Istio in Practice
🍭 How to Run the Services on the Mesh
🍭 Ingress Gateway – How to Admit Traffic into the Mesh
🍭 Observability
🍭 Traffic Management – Canary Deployments
🍭 Istio Security

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

The Path to GitOps от Red Hat Developer

Привет!

В приложении можно скачать книжку о том, что такое GitOps, зачем он нужен и как его можно реализовать.

Содержание книги:
🍭 What is GitOps
🍭 Tools of the Trade
🍭 Templating
🍭 Git Workflows
🍭 Repository and Directory Structures
🍭 CI/CD with GitOps
🍭 Handling Secrets

В книге ~ 45 страниц, все достаточно хорошо структурировано и много ссылок на полезные источники по каждой из рассматриваемых глав.

Создание plugins для ArgoCD

Всем привет!

В статье приводится пример создания plugin для ArgoCD. Автор захотел использовать kbld (утилита, которая «транслирует» tag в digest образа) с меньшим количеством действий.

Есть несколько способов создания plugin:
🍭 Добавление конфигурации в «основной» ConfigMap ArgoCD. Подходит для простых доработок, в несколько строк кода
🍭 Добавление plugin в качестве sidecar для repo-server pod. Подходит для «продвинутых» plugin

Т.к. kbld достаточно простая утилита, Автор выбрал первый вариант и решил его реализовать. Как он это делал, что куда добавлял и как модифицировал kind: Application ArgoCD – все это описано в статье. В итоге получился лаконичный механизм использования инструмента.

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

The Kubernetes Network Model

Всем привет!

По ссылке доступен ресурс, посвященный тематике сети в Kubernetes. Материал состоит из следующих разделов:
🍭 Network Model
🍭 CNI
🍭 Services
🍭 In(En)gress
🍭 Network Policies
🍭 IPv6
🍭 DNS

Каждый раздел, в свою очередь «раскрывается» еще на несколько областей. Например, Services -> Headless, ClusterIP, NodePort, LoadBalancer, ServiceMeshes и Optimisations. И да! Есть лабораторные работы, которые можно поделать, попутно изучая материал.

P.S. Увы, некоторые разделы не заполнены (например, Network Policies) и Автору требуется помощь. Возможно, это будете Вы ☺️

Обеспечение безопасности Deployments k8s

Всем привет!

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

Рассматриваются следующие области:
🍭 Использование Service Account, запрет automountServiceAccountToken
🍭 Использование Security Context, описание наиболее значимых из доступного множества
🍭 Использование Distroless и Container-Optimized Images, сканирование образов на наличие уязвимостей и мисконфигураций
🍭 Использование Pod Security Admission (или любого другого Policy Engine наподобие OPA/Gatekeeper или Kyverno)
🍭 Корректное использование Secrets

Из материалов статьи можно составить неплохой check list для последующего анализа Deployments и формирования планов по устранению ИБ-дефектов.

Pixie: network visibility and observability

Всем привет!

Pixie – инструмент, созданный с использованием все больше и больше набирающей популярность технологии eBPF. Является «Sandbox Project» CNCF.

При помощи Pixie можно:
🍭 Получить информацию о traffic flow внутри кластера, отследить DNS-request
🍭 Собрать данные об использовании ресурсов кластера (CPU, Sent/Received Traffic и т.д.)
🍭 Изучить Service Performance: HTTP requests, HTTP Errors, HTTP Latency и т.д.
🍭 Request Tracing (предоставление информации о full-body requests) и многое другое

Решение обладает web-интерфейсом и документацией, в которой описано как установить/настроить и использовать Pixie. Из приятного – разработчики отдельно приложили Software Bill of Materials, правда только со сведениями о лицензиях.

Если хочется чуть больше – можно ознакомиться со статьей, в которой Автор использует Pixie для анализа сети.

Kubernetes Hardening при помощи Policy Engine

Всем привет!

Существует много разных подборок с политиками ИБ (и не только), которые можно реализовать при помощи Policy Engine. С одной стороны, это очень хорошо, т.к. есть где «подсмотреть» и что переиспользовать. С другой – не очень, т.к. не всегда понятно, что из этого реально полезно, а что решает локальной задачи в Компании N.

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

Например:
🍭 block-endpoint-edit-default-role
🍭 disallowanonymous
🍭 read-only-root-filesystem
🍭 block-nodeport-services и другие

Пример реализации политик осуществлен с помощью Gatekeeper. Однако, ничего не мешает использовать наиболее удобный Вам инструмент: Kyverno, Datree, Kubewarden и т.д.

STRIDE и ASVS

Всем привет!

Для моделирования угроз можно использовать разные методологии и практики. Одним из часто встречающихся инструментов является STRIDE.

Его использование позволяет обобщенно взглянуть на то, какие угрозы могут быть актуальны для приложения. Дальше – надо выбрать mitigations (контроли, меры защиты, контрмеры и т.д. – наименования не так важны).

Чтобы упростить процесс Автор repo сделал собственный mapping между STRIDE и Application Security Verification Standard (ASVS).

Процесс выглядит примерно так:
🍭 Моделирование угроз с использованием STRIDE и Rapid Threat Modelling (личное предпочтение Автора, можно выбрать наиболее интересную Вам)
🍭 Использование таблицы-mapping STRIDE и ASVS, чтобы понять, где и какие контроли искать
🍭 Адаптация требований под проект

Больше деталей по процессу, также как и сами материалы (включая небольшую книгу про Rapid Threat Modelling) можно найти в repo.

P.S. Проект только в начале своего пути ☺️

Faraday: vulnerability management tool

Всем привет!

Faraday – решение, которое позволяет агрегировать информацию по уязвимостям и работать с ними в соответствии с используемым в Компании процессом по управлению уязвимостями.

Решение обладает достаточно приятным web-интерфейсом и большим количеством plugins, которые можно использовать для импорта данных по уязвимостям. Например:
🍭 Bandit
🍭 Grype
🍭 Nikto
🍭 ZAP и многие другие

Полный перечень доступных plugins можно посмотреть тут. Если чего-то не хватает, то можно написать свой. Faraday написан на Python, есть инструкции в документации о том, как писать plugins.

Также в документации можно найти сведения о возможностях решения (их достаточно много и точно не описать в ТГ-посте), про его установку/настройку.

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

Визуализация сети k8s в Grafana

Всем привет!

В статье описывается подход, использование которого позволит строить графики, отображающие сетевое взаимодействие pods в… Grafana!

Все достаточно просто:
🍭 Использование k8spacket, в качестве инструмента сбора информации. Он представляет из себя ПО, написанное на Golang, которое умеет взаимодействовать с кластером Kubernetes. Устанавливается в качестве DaemonSet и каждые 10 секунд опрашивает об изменениях.
🍭 Node API Plugin для Grafana. Он позволит построить графы зависимостей.
🍭 И, конечно же, наборы Dashboards для Grafana, которые можно найти в repo k8spacket.

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

Supply Chain Awesome

Всем привет!

В repo собраны материалы, посвященные безопасности Supply Chain – от общих статей с практиками до конкретных инструментов, которые можно использовать.

Если не знакомы с термином "Supply Chain" - ничего страшного. Если упростить, то это цепочка поставки программного обеспечения, в том числе, использование внешних компонентов. Атаки на Supply Chain зачастую связаны с попыткой модифицировать/изменить/дополнить часто используемый компонент.

Подборка структурирована по следующим блокам:
🍭 Policy. Полезные статьи/книги
🍭 Incidents/Threats. Описание угроз, реальные примеры (включая Dependency Confusion и Log4j)
🍭 Solutions. Различные frameworks и средства автоматизации, которые можно использовать для повышения безопасности supply chain
🍭 Organizations. «Открытые» сообщества, которые занимаются тематикой
🍭 Reports and summaries. Отчеты и whitepapers

А если этого мало – рекомендуем обратить внимание на блог компании ChainGuard. В нем можно найти много интересного ☺️

Безопасность Source Code Management (SCM) систем

Привет!

В статье приведена краткая выжимка из исследования «Controlling the Source: Abusing Source Code Management Systems», посвященная теме защиты SCM. Само исследование мы приложим в следующем посте.

Рассматриваются варианты компрометации наиболее популярных SCM-систем (GitHub, GitLab, Bitbucket). Например, для GitLab аналитика состоит из следующих разделов:
🍭 Reconnaissance
🍭 User Impersonation
🍭 Promoting User to Admin Role
🍭 Modifying CI/CD Pipeline
🍭 SSH Access

Отдельный раздел посвящен использованию утилиты SCMKit, которая может быть использована для воспроизведения и автоматизации рассмотренных сценариев. Рекомендуем обратить внимание и детально ознакомиться с ее возможностями, которые описаны в repo.

В завершении – общие рекомендации о том, как повысить уровень информационной безопасности SCM-систем.

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