Автостопом по HashiCorp Vault

Всем привет!

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

В ней Автор описывает:
🍭 Общая информация о том, что есть «секрет» и какие системы управления бывают
🍭 Базовые концепты Vault (API, Storage, (Un)seal, Secret Engine и т.д.)
🍭 Способы доставки Token (Response Wrapping, AppRole)
🍭 Управление политиками доступа к секретам
🍭 Интеграции с приложениями (SDK, Agent) и многое другое

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

Привет!

Мы проводим небольшое исследование и нам нужна ваша помощь. Далее будет 3 маленьких опроса, на которые просим вас ответить.

Все анонимно :) Интересует статистика. Спасибо! ☺️

Шифрование и подпись образов контейнеров

Всем привет!

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

Авто рассматривает следующие примеры
🍭 Подпись образов с использованием Cosign
🍭 Размещение подписанного образа в Registry с использованием Podman
🍭 Создание политики контроля подписи для Podman с последующим тестированием
🍭 Шифрование образа контейнера с использованием возможностей Podman

В статье приводятся примеры всех необходимых команд и комментарии к ним.

Для того, чтобы контролировать подпись образов в кластерах Kubernetes можно использовать, например, Kyverno. Подробнее об этом можно прочесть в документации.

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

Mini-hardening-guides от Hadess

Всем привет!

Материал с немного обманчивым названием – «DevSecOps Checklist». Однако, внутри можно найти ~86 страниц, на которых описаны способы hardening для разнообразный технологий.

В выборку попали: Apache, ArgoCD, Auth0, AWS, Ceph, Consul, CouchDB, Docker, eBPF, ElasticSearch, etcd, git, GitLab, GlusterFS, Gradle, IIS, Jenkins, Kubernetes, Memcached, MongoDB, MySQL, Nginx, OpenShift, Redis, SaltStack, Terraform, Tomcat, Weblogic

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

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

OpenCRE: mapping ИБ-стандартов

Всем привет!

По ссылке доступен проект OpenRCE. Его задача в том, чтобы сделать mapping практик между различными ИБ-стандартами.

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

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

На текущий момент в нем есть:
🍭 OWASP (Top 10, ASVS, SAMM и т.д.)
🍭 CWE
🍭 CAPEC
🍭 NIST 800 53
🍭 NIST SSDF

Пользоваться им просто – переходите в раздел «Map Analysis», выбираете 2 интересующих вас стандарта – готово!

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

История Kubernetes

Всем привет!

Пятница – самое время для интересного и приятного чтения чего-то не очень сложного, а даже наоборот, расслабляющего!

Думаем, что статья Brian Grant подойдет! В ней он описывает долгий и интересный путь создания того, что мы знаем, как Kubernetes.

Материал разделен на этапы:
🍭 Lessons from Borg and Omega: 2009–2013
🍭 Early Container Product API Design: 2H2013
🍭 Ramp to Launch: 1H2014
🍭 Finishing the Implementation of the Design: 2H2014
🍭 The Home Stretch: 1H2015

Началось все с того, что нужно было оптимизировать производительность за счет параллельной обработки запросов…

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

А еще можно поиграть в игру – «угадай как эта %сущность% теперь называется в Kubernetes» 😊

Подпись артефактов: необходимое и/или достаточное условие?

Всем привет!

В статье приведены интересные мысли Автора по вопросу: «Является ли подпись артефактов достаточным механизмом контроля целостности и мерой противодействия supply chain атакам?»

С его точки зрения – нет. Да, она подтверждает авторство, но на ряд вопросов она ответить не сможет.

Например:
🍭 Как был собран артефакт?
🍭 Какой исходный код использовался?
🍭 Какие параметры сборки передавались и т.д.?

По этой причине Автор считает, что лучше (вместе с подписью) формировать provenance – набор metadata о процессе сборке. Например: информация об используемом исходном коде, процессе сборке, реализованных ИБ-проверках и вообще все, что вам кажется важным. Данные подписываются электронной подписью, формируя аттестацию.

В завершении Автор рассказывает про slsa-github-generator – набор GitHub Actions, которые позволяют создавать те самые provenance в соответствии с рекомендациями SLSA.

А что вы думаете по этому поводу? Нужны ли эти metadata или это «перебор» и привычной подписи вполне хватает?

Mindmap на все случаи жизни!

Всем привет!

Многие, для структурирования информации, любят использовать mind map. Выглядит наглядно, красиво и всегда можно «подсмотреть» что и как.

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

Безопасную разработку и DevSecOps тоже не обошли стороной:
🍭 DevOps Roadmap
🍭 DevOps Tools
🍭 MITRE ATT&CK Container Matrix
🍭 Vulnerability Scanners и другие

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

Однако, картинки не являются интерактивными и перейти по ссылке на интересующую «ветку» карты не получится.

Идентификация Broken Access Control с использованием Semgrep

Всем привет!

Если упростить, то Broken Access Control можно описать примерно так: уязвимость, которая появляется за счет отсутствия/недостаточности проверок на стороне сервера того, что некоторый субъект (subject) может реализовывать определенные действия (operation) над некоторым объектом (object).

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

В статье Автор предлагает свой подход к идентификации указанных недостатков. В качестве tech stack он использует NestJS и Semgrep, как SAST-инструмент.

«Вымышленное» приложение представляет из себя набор микросервисов, обладает ролевой моделью, а авторизация реализуется с использованием JWT Token. Для контроля действий пользователей предлагается использовать NestJS Guards.

Автор предлагает следующий набор правил Semgrep, чтобы убедиться, что все реализовано "как надо":
🍭 Поиск endpoints у которых отсутствуют Guards
🍭 Использование «нестандартных» Guards
🍭 Идентификация случаев некорректного использования Guards
🍭 Поиск IDOR, где стандартных Guards может быть недостаточно и не только

Каждое правило содержит его YAML-код, описание с комментариями и ссылку на Semgrep-playground.

Статья затрагивает интересный момент: не стоит «слепо» полагаться на SAST-решение. Что оно само все найдет и само предложит, как можно устранить дефект. Альтернативным сценарием использования SAST может быть поиск определенных конструкций. Но только надо знать, что искать 😊

Linx Cloud предлагает потестировать Штурвал и Deckhouse в своем облаке.

Всем привет!

Если у вас стоит вопрос выбора коммерческой версии кубер-платформы, но нет ресурсов на то, чтобы их развернуть, - это можно сделать в облаке Linx Cloud https://linx.ru/cloud/kubernetes-clusters. Сейчас в нем развернуты два решения от российских производителей: Штурвал от компании “Лаборатория Числитель” и Deckhouse от компании “Флант”.

Trail of Bits Testing Handbook, Web!

Всем привет!

Trail of Bits продолжает радовать отличными материалами и развивать свой проект – «Testing Handbook».

К Static Analysis и Fuzzing (о которых мы писали тут и тут) добавилась новая «глава» Web Application Security, посвященная Burp Suite Professional.

Внутри можно найти:
🍭 Step-by-step guide по первому запуску
🍭 «Ручная» работа с HTTP-запросами
🍭 Работа с Burp Repeater, Intruder, Collaborator
🍭 Общие советы по работе с Burp и не только

Материал будет полезен как и тем, кто только начинает знакомство с Burp, так и тем, кто с ним работает. Если хочется чего-то еще – можно обратить внимание на Web Security Academy.

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

Чем плохи Long Lived Service Account Tokens в K8S?

Всем привет!

Многие риски ИБ Kubernetes связаны с некорректными конфигурациями ресурсов, включая настройки прав доступа и повышенные привилегии у некоторых ролей (включая роли системных сервисов).

В статье команда GitGuardian рассматривает близкую проблематику, связанную с проблемами использования Long Lived Service Accounts Tokens

В статье рассматривается:
🍭 Что из себя представляют Service Account Tokens
🍭 Зачем они нужны, как используются
🍭 Риски ИБ, связанные с использованием Long Lived Service Account Tokens и другие вопросы

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

Завершают статью рекомендации о том, как можно управлять Long Lived Service Account Tokens более безопасно – от использования Service Mesh до TokenRequest API и контроля монтирования Tokens в Pod.

Istio AuthN/Z политики и Otterize!

Всем привет!

Service Mesh – достаточно популярный ответ, когда появляется вопрос про контроль сетевого трафика в Kubernetes.

А одной из самых часто вспоминаемых реализаций Service Mesh является Istio. Нюанс в том, что порог входа в работу с ней может быть высок. Чтобы сделать его чуть проще предлагаем вам ознакомиться со статьей.

Авторы рассматривают основные концепты:
🍭 Authorization Policies и их «компоненты»
🍭 Логика «вычисления» политик, если их несколько
🍭 Использование внешних ресурсов для аутентификации и не только

В завершении Авторы рассматривают как их собственные наработки могут оптимизировать управление сетевым трафиком в Kubernetes. Про Otterize Network Mapper и Intents Operator мы писали тут и тут.

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

Spectra Assure Community: анализ open source!

Всем привет!

Тема безопасности open source не перестает быть актуальной и даже наоборот – все больше и больше набирает обороты. Вспомнить хотя бы то, что было недавно - xz, Polyfill. И это не говоря о том, что «следы» Log4Shell нет-нет, да найдутся.

Поэтому важно получать как можно больше информации о том, насколько тот или иной пакет «здоров». Есть множество ресурсов, которые помогают получить информацию: БДУ ФСТЭК,  NVD, OpenSSF Scorecard, OSV, SCALIBR, Vet, CVEMap, Trusty и много-много-много чего еще.

Сегодня хотим рассказать про еще один такой ресурс – Spectra Assure Community. При помощи него можно проверять более 5 миллионов пакетов из NPM, PyPi и RubyGems.

Он позволяет получить информацию о: вредоносном ПО, code tampering, известным уязвимостям, проблемах с лицензиями, сведения о секретах и общий статус «здоровья» пакета.

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

Cloud Threat Landscape!

Всем привет!

Команда Wiz подготовила отличный сюрприз для всех, кто любит Cloud Native технологии и их безопасность! Интерактивный Threat Landscape!

Внутри можно найти:
🍭 Incidents. Информация по реальным инцидентам в мире Cloud Native
🍭 Actors. Информация о hack-группировках и инцидентах, совершенных ими
🍭 Techniques. Набор атакующих техник, характерных для Cloud Native
🍭 Tools. Перечень наиболее часто используемых средств автоматизации злоумышленниками
🍭 Targeted Technologies. Наиболее частые «цели», на которые совершают атаки
🍭 Defenses. Набор мер по противодействию Cloud Native Attack

Каждый из разделов интерактивен и содержит дополнительную информацию. Видно, что Wiz подошли к делу со стилем и любовью 😊

P.S. А еще там есть офигенная периодическая таблица Cloud Security – можно скачать и хоть на стену вешай. Красиво и содержательно!

Global DevSecOps Report от GitLab (2024)

Всем привет!

Команда GitLab выпустила очень интересный объемный отчёт аж на 78 листов!

Хорошие новости! Согласно результатам опроса более 5 000 специалистов интерес к ИБ растет. Среди основных приоритетов выделяются: Security, AI, DevSecOps Platform, Automation, Cloud Computing.

И, конечно, много аналитики-графиков и всего такого по темам:
🍭 Приоритеты инвестиций в IT
🍭 Использование AI в жизненном цикле разработке ПО
🍭 Количество инструментов, которые используются при разработке ПО
🍭 Среднее время onboarding новых специалистов и много другой интересной информации

Особенно интересно то, что статистика ответов «разбита» отдельно для разных стран: Австралия, Канада, Франция, Франция, Индия, Япония и т.д.

Как оптимизировать образ контейнера?

Всем привет!

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

Под оптимизацией в статье, в большей степени, понимается сокращение размера итогового образа. Это может быть полезно, как для ИТ, так и для ИБ (например, для сокращения поверхности атаки, «противодействия» LotL-атакам и т.д.)

В итоге Автор прошел путь:
🍭 Обычная сборка образа, использование Alpine в качестве базового
🍭 Multi-stage сборка. Удаление всего, что не требуется для корректной работы ПО, помещенного в контейнер
🍭 Идентификация транзитивных зависимостей, которые надо поместить в образ
🍭 Использование Docker Slim и неожиданный результат
🍭 Использование Docker Squash и не тот результат, который должен был получиться

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

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

Поиск Compromised Cookies, опыт Slack

Всем привет!

Компрометация Cookie не самая приятная вещь, которая может быть использована для доступа к данным пользователя. Одной из практик противодействия является контроль времени жизни сессии пользователя.

Но всегда ли этого достаточно? У ребят из команды Slack свое мнение на этот счет и свои подходы к реализации защиты. Ознакомиться с ними можно в статье.

Основная идея Slack заключается в поиске «Session Forking» (т.е. когда один и тот же Cookie используется одновременно на разных устройствах).

Для этого они используют Last Access Timestamp – дату «установки» Cookie, которая постоянно обновляется (как в самой Cookie, так и в БД).

Сценарий примерно следующий:
🍭 Злоумышленник получил Cookie и пытается с помощью нее получить доступ. Временная метка, скорее всего, будет старой и Session Forking будет найден
🍭 Злоумышленник получил «свежий» Cookie и запросил доступ. Last Access Timestamp обновился. Session Forking будет найден уже когда легитимный пользователь запросит доступ (его метка будет старее)

Однако, такая логика привела к наличию большого количества False Positive и False Negative при тестировании. И решение… было найдено! Какое? Ответ в статье 😊

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