Anatomy of a Cloud Infrastructure Attack via a Pull Request

В продолжение темы с извлечением секретов из сборки [1,2] нашел свежую статью от Teleport (разработчики одноименного решения для контроля привилегированных пользователей) с разбором этой атаки в их инфраструктуре. Они, в частности, используют Drone CI в связке с dind. В статье разбирается специфика этой уязвимости у них и приводится небольшой чек-лист, как они митигируют соответствующие риски.

#ops #attack

Kubernetes Security Checklist and Requirements

В канале было много того, что касается безопасности ванильного Kubernetes, но, когда дело доходит до составления перечня требований или чеклиста для аудита, так или иначе приходится тратить время для сведения всего этого воедино. Чтобы упростить эту задачу мы зарелизили собственный чек-лист безопасности k8s: Kubernetes Security Checklist and Requirements 🎉

Здесь важно отметить,что этот чек-лист - это лишь один из путей повышения безопасности кластера. Этот путь самый сложный и во многом самый противоречивый и утрированный. Многое из того, что здесь есть, запросто может не подойти для вашей инфраструктуры в силу культуры или технических ограничений. Все это сделано с той целью, чтобы напомнить вам о тех мерах, про которые вы могли забыть, но для вас они подходят больше всего. PR'ы приветствуются!

Кстати, есть также версия на русском.

#k8s #ops

Implementation of DevSecOps for a Microservices-based Application with Service Mesh - SP 800-204C (Draft)

Сначала в эту историю влетели NSA и CISA, а теперь время пришло и для NIST. Вышел драфт документа SP 800-204C "Implementation of DevSecOps for a Microservices-based Application with Service Mesh" о внедрении DevSecOps в связке с Kubernetes.

#k8s #ops #dev

Introducing Snowcat: World’s First Dedicated Security Scanner for Istio

Snowcat - инструмент для аудита конфигурации Istio на предмет безопасности. В основу взята официальная страница Istio Security Best Practices. На текущий момент инструмент поддерживает:
- проверку наличия mTLS,
- поиск небезопасных паттернов политики авторизации (доступность эндпоинтов без авторизации),
- проверку контроля сертификата при egress-трафике
- проверку политики JWT-токенов ( first-party-jwt / third-party-jwt) для корректного контроля получателя
- поиск небезопасных версий Istio

Для поиска мисконфигураций инструмент может быть натравлен на yaml-файлы в качестве статического анализатора кода, XDS-порт, kubelet API или Istiod debug API без аутентификации. Подробнее об инструменте можно прочитать в блоге.

#ops #k8s

RBAC Tool For Kubernetes

RBAC-tool - инструмент от Alcide (которую недавно приобрела широкоизвестная Rapid7), позволяющий формировать RBAC-роли в Kubernetes по результатам анализа audit events (в основу был взят движок audit2rbac), строить карту ролей и выявлять небезопасные роли.

#k8s #ops

Common Threat Matrix for CI/CD Pipeline

В рамках доклада “Attacking and Securing CI/CD Pipeline” на конференции CODE BLUE 2021 Opentalks вышла матрица угроз MITRE ATT&CK для CI/CD: Threat Matrix for CI/CD Pipeline. Частично она переиспользует идеи, предложенные SLSA, расширяя перечень потенциальных угроз и мер безопасности. Про многое я писал в серии постов по моделированию угроз CI/CD [1,2,3] и возможности извлечения секретов из CI.

Очень понравился перечень мер безопасности, который сильно пересекается с тем, что прорабатывал я в рамках аналогичной активности (но не успел пока выложить в открытый доступ). Не стоит забывать, что создание модели угроз и требований ИБ для таких широких процессов, как сборка и деплой - это всегда про кастомизацию. Кому-то будет важно ограничить прямой доступ к CD, отделив процесс отдельной системой (например, AWX, для которого есть свой набор security практик) и закрыв PAM'ом. Для кого-то верификация сигнатур в CI/CD может быть очень дорогим процессом и они ограничиваются проставлением метатэгов на уровне централизованного репозитория артефактов. Сама по себе мера "Hardening CI/CD pipeline servers" может завезти вереницу проверок и возможных "переключателей" (пример вариации настроек).

#ops

Minimum Viable Secure Product

Небольшой чеклист, состоящий из минимальных необходимых мер безопасности продукта. Общий список поделен на следующие категории:
- Business controls
- Application design controls
- Application implementation controls
- Operational controls

Если ваши продукты далеки от MVP, то есть также стриница, посвященная Enterprise Ready системам, где собраны гайдлайны по разным доменам и опросник.

#dev #ops

Практика управления безопасностью ПО в масштабных продуктах

Доклад от CISO Тинькофф об угрозах, присущих платформам разработки (куда также относятся CI/CD системы). В число угроз попали:
- Уже многим известный Dependency Confussion
- Использование одних и тех же ключей для всех сборок и деплоев
- Повышение привилегий через shared раннеры (в т.ч. привилегированный DinD)
- Внесение изменений в код за счет отсутствия правил approve/review
- Использование небезопасных сторонних библиотек
- Публикация внутренних API во внешнюю среду через единый ingress
- Открытие полного доступа в Интернет для закрытых ресурсов

#dev #ops #attack

Подводные камни DevSecOps и "безопасности как сервис".

Отдельное внимание мне хотелось бы уделить фразе "Безопасность как сервис". Дмитрий интерпретирует ее в контексте предоставления шаблонов подключения WAF/SAST/DAST, которые могут быть легко встроены как код разработчиками. По сути - это классическое видение DSO, где каждый разработчик может встроить все проверки отдельными стейджами в свой пайплайн.

Здесь, правда, есть большое количество "но", с которыми часто сталкиваются крупные компании, что зачастую препятствует закреплению DSO в культуре разработки.

Разберем некоторые из них:
- До сих пор в компаниях не везде есть единый согласованный CI, под который нужно писать шаблоны
- До сих пор есть разработчики, которые собирают код руками
- Разработчики могут буквально забить на проверку ИБ и не встроить ее в пайплайн, а у ИБ нет механизмов это своевременно выявить
- Все решения (SAST/SCA/DAST) имеют свой flow по работе с уязвимостями. Где-то нужно проставлять комментарии и статусы, а где-то таких механизмов в принципе нет (не говоря про то, что у многих инструментов нет UI)
- У каждого решения (SAST/SCA/DAST) есть своя консоль и, соответственно, свой набор доступов, который нужно предоставлять для разработчиков для триажа.
- Специалистов со стороны ИБ <5, а разработчиков 500+

Но чем больше мне удается пообщаться со зрелыми командами из компаний с большой разношерстной инфраструктурой разработки, тем больше прихожу к концепции предоставления безопасности не просто в виде шаблонов, а в виде полноценного SaaS-решения (DevSecOps/AppSec-платформа). В следующих частях мы поговорим подробнее об этом явлении, которое активно набирает обороты в large enterprise.

#dev #ops

Vulnerability subsprition

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

Вариант #1 - подписаться на CVE

Есть множество сервисов, где это можно сделать. Один из них - opencve.io. Сервис абсолютно бесплатный, можно подписаться на определенного вендора или продукт с отбивками на почту. Достаточно удобно, но наблюдаются задержки в 1-2 дня.

Вариант #2 - узнавать о новых уязвимостях от первоисточника.

Информация о важных обновлениях, решающих вопросы безопасности, может содержаться в еженедельных отчетах вендоров через их официальные страницы (как, например, страница релизов на примере Gitlab). Здесь мы имеем очевидную проблему c отсутствием унификации поступающей информации. В случае, если продукт open source и он находится на Github или Gitlab, то здесь у нас есть возможность отслеживать уязвимости через страницу Issues. Так, например, чтобы узнавать раньше всех о найденных уязвимостей Kubernetes, надежнее всего подписаться на label kind/bug (в сочетании с triage/accepted) через desktop client (как описано в этом топике).

Вариант #3 - воспользоваться агрегатором

Другой вариант - воспользоваться сервисами вроде Vulners. Vulners, помимо возможности отслеживания CVE, предоставляет язык запросов, на результаты которого можно подписываться. Например, запрос affectedSoftware.name:"nginx" OR affectedPackage.packageName:"nginx" OR cpe:nginx order:published выдаст агрегированную информацию обо всех уязвимостях, связанных с nginx.

В заключение хочу поделиться также интересным ресурсом - cvetrends.com, который собирает информацию о "хайповых" CVE из twitter.

#dev #ops

CodeQL for Log4j

“Пятница-пятницей, а Log4j JNDI инъекцию никто не отменял :) все про нее уже в курсе, но если нет, то почитать можно тут или тут, ну или по-русски тут. Для CodeQL соответственно сразу же подъехали экспериментальные запросы: https://github.com/github/codeql/pull/7354/files
Можно уже погонять на своём коде. Сами запросы используют csv-модели, то есть разделенные точкой с запятой однострочные описания неймспейса, типа, подтипа, имени класса и еще нескольких параметров для задания source'a, sink'a и summary. Это укорачивает спецификацию этих элементов, позволяет их писать быстрее, но читать это чуть непривычнее :)”

За текст спасибо @shad0wrunner

Из чата @codeql

#dev #ops #attack #sast

Acra 0.90.0: application-level encryption and searchable encryption for any SQL and NoSQL databases

Acra - проект с открытым исходным кодом для обеспечения безопасности sensitive-информации, хранящейся в базе данных за счет application-level шифрования. Что из себя представляет проект, из каких компонентов состоит и какими принципами руководствуется можно прочитать в статье. Помимо шифрования данных, есть возможность их маскирования, токенизации и поиска. Более того, есть модуль SQL firewall, который позволяет задавать политики для извлечения данных из БД, и модуль Intrusion Detection, расширяющий ваши данные honey-токенами, извлечение которых свидетельствует об атаке. Все это, ко всему прочему, интегрируется с SIEM.

#ops