Security Wine (бывший - DevSecOps Wine)

Jenkins secrets quiz Сегодня мы сделаем небольшой квиз. У команды разработки есть Jenkins, используемый для сборки. Jenkins в свою очередь необходимы секреты для получения доступа к сторонним prod-системам (разработчики используют плагин сredentials-binding). Разработчики самостоятельно пишут groovy-скрипты в Jenkins с выданными правами на запись и запуск согласно матрице доступов. Безопасно ли это? Ответ будет завтра. #dev #ops #talks

Threat Modelling & Supply-Chain (Part 3: Security Controls) В прошлых постах [1,2] мы определили угрозы, которые, как нам кажется, более или менее полно покрывают перечень действий, определенных нами в рамках процессов над активами. Следующее, что нам нужно сделать - определить меры безопасности (security controls). Здесь два варианта - начать указывать их на каждом процессе или потоке данных в рамках схемы, либо выписать отдельной табличкой напротив каждой нашей угрозы (чтобы убедиться, что мы закрываемся от всего, что сами для себя определили). Говоря более предметно, давайте вернемся к supply chain атакам. В частности возьмем за основу упоминаемый ранее фреймворк SLSA и рассмотрим угрозу компрометации CI/CD системы. Когда мы говорим про компрометацию системы, то речь, как правило, заходит о полноценности hardening'а этой системы, а именно о таких доменах, как аутентификация, авторизация, сетевая безопасность, конфигурация, логирование и безопасная работа с секретами. Соответственно в этих доменах и пробуем определить полный перечень мер безопасности. Вот примеры реализации hardening'а для разных решений CI/CD систем: - Security Practices in GitLab - Managing Security of Jenkins - Securing Jenkins CI Systems - Security hardening for GitHub Actions - TeamCity Security Notes (лучше всего на мой взгляд сделано здесь) - CircleCI Security К мерам защиты CI/CD может относиться ролевая модель, отсутствие анонимной аутентификации, обязательная интеграция с identity-провайдером, запрет на доступ в Интернет для сборки, требование к изолированности агентов от агентов развертывания и обязательному логированию с последующей отправкой в SIEM-систему. Конечный список требований зависит исключительно от возможностей вашей CI/CD системы. Рассматривая компрометацию системы хранения кода (Gitlab/Bitbucket) и артефактов (Nexus Repo, Artifactory) формируем требования безопасности по аналогии из тех же доменов. Если мы говорим про supply chain атаки, то помимо компрометации самих систем, участвующих в процессе разработки, отдельное внимание надо уделить угрозе нарушения целостности перемещаемых активов, а именно коду и артефактов. Здесь я советую снова обратиться к SLSA-фреймворку. Примеры угроз, реализуемых внутренним нарушителем: - Публикация вредоносного кода в релизную ветку от имени скомпрометированной УЗ разработчика - Указание в системе сборки кода из чужой системы хранения кода - Указание в системе развертывания артефакта из чужой системы хранения артефактов - Загрузка в Artifactory артефакта не прошедшего систему сборки Обратите внимание, что при отсутствии проверки целостности и прохождения дополнительной аутентификации между системами сборки, хранения кода и артефактов нам необязательно получать полный доступ над системами. Например, достаточно указать неверные входные значения (сторонний git-репозиторий) в качестве параметров сборки, либо опубликовать артефакт в Artifactory вручную через CLI минуя security-проверки в рамках централизованного процесса сборки. Ещё один пример - изменить скрипт развёртывания так, чтобы установить вредоносный дистрибутив в прод вместо проверенного security-сканерами. В помощь сюда приходят проекты вроде Notary или Sigstore. Кто-то реализует это посредством подписи SBOM на всех этапах разработки, кто-то ограничивается тэгированием артефактов без возможности перезаписи разработчиком. Неплохим требованием безопасности будет обязательный merge-approval для всех бизнесовых репозиториев, чтобы избежать нарушения целостности master/release ветки при компрометации УЗ разработчика. #dev #ops #threatmodeling

Threat Modelling & Supply-Chain (Part 2: Threats & Threat Actors) Следующим этапом определим пользователей наших процессов. Эти же пользователи будут нашими потенциальными нарушителями (threat actors). Рассматривая атаки на цепочки поставок это могут быть внутренние нарушители (разработчики, администраторы CI и CD систем, администраторы кластера, сопровождение ОС и так далее) и внешние (пользователь, который может повилять на общедоступные репозитории).Также на этом этапе мы понимаем, где еще могут использоваться наши защищаемые активы (секреты и код на рабочих станциях). Далее переходим к главному и самому сложному - раскидывание угроз. Сложность заключается в том, чтобы определить для себя исчерпывающий перечень угроз. В лучшем случаем вам может помочь банк угроз (например MITRE), в худшем случае придется опираться на собственный опыт и известные кейсы. На помощь могут придти методологии вроде STRIDE (она поможет нам раскидать угрозы по заранее определенным классам), а также деревья атак (поиск атак для реализации угроз посредством их зависимостей друг с другом). На этом этапе мы можем получить уже множество интересных открытий. Например, оказывается, что разработчик имеет возможность изменять пайплайн развертывания подменяя источник артефактов, внедряя backdoor или малварь. На этом же этапе мы можем определить у себя возможность реализации Dependency Confusion при скачивании зависимости разработчиком из Artifactory и многое другое. В следующих постах мы поговорим про приоритизацию угроз и формирование требований ИБ по результатам модели угроз. Если вы уже хотите попрактиковаться, то можете почитать пример моделирования угроз для облачного приложения в AWS с использованием STRIDE. Хорошим материалом является также Threat Modeling Training от компании Segment, где есть простые и понятные слайды по всем этапам моделирования угроз. #threatmodeling #dev #ops #talks

Threat Modelling & Supply-Chain (Part 1: Assets) Безопасность разработки стала весьма широким доменом в плане охватываемых проблемных зон и инструментов. За последние полгода в одну из решаемых задач попала митигация рисков, связанных с атаками на цепочку поставок (supply-chain attack). Для тех, кто следит за новостями, сразу вспоминаются атаки на SolarWinds (хотя в реальности примеров подобных атак значительно больше). Тем не менее, как связать примеры подобных атак с собственной инфраструктурой и цепочкой поставок не всегда очевидно (чем активно пользуются производители решений SCA). Чтобы понять, как мы можем защититься от атак на цепочку поставок, требуется декомпозировать задачу, а именно прибегнуть к процессу моделирования угроз: определить защищаемые активы, действия над этими активами, пользователей и потенциальные угрозы, связанные с этими действиями. Активами могут стать код, зависимости и итоговый артефакт, то есть те компоненты, которые участвуют в цепочке поставок. Также в качестве активов нередко рассматривают сами системы, которые участвуют в процессе сборки артефактов и их развертывания (CI и CD системы). Раскидывая все процессы разработки на схеме (мне нравится обычный draw.io с плагином dfd) мы имеем архитектуру нашего сборочного конвейера совместно с этапом раскатки. Детализация схемы зависит от вашего погружения вместе с DevOps командами. Модель угроз можно декомпозировать вплоть до всех компонентов Kubernetes. Чтобы точно убедиться, что мы ничего не пропустили, мы можем расписать процессы отдельно: CI Master: - Вызов сборки - Конфигурация сборки - Получение секретов git из встроенного хранилища секретов - .... К каждому процессу подписываются защищаемыми нами активы: A01: секреты git A02: код бизнес-приложения A03: итоговый артефакт A04: зависимость ... Совместно с определением процессов и активов рекомендуется определить так называемые доверенные зоны (trusted zones). Они помогают определить логические границы, за которых ответственны те или иные администраторы систем, а также поверхности атаки злоумышленника в случае, если он окажется внутри инфраструктуры. #threatmodeling #dev #ops #talks

Kubernetes Overview Diagrams Небольшой сборник диаграмм в помощь тем, кто начинает разбираться в Kubernetes. Диаграммы есть к архитектуре, workload's, network, storage, resource requests and limits и на картинке вы в частности видите RBAC. #k8s #ops

🔶🔷🔴 Mapping of On-Premises Security Controls Versus Services Offered by Major Cloud Providers By the link below you can find the fifth version of a diagram that started in March 2017, with just AWS and Azure versus On-Premises. The diagram began as an effort to make a translation between the typical on-premises security controls that everybody, more or less, knows what they do and the various services advertised by major public cloud providers. As the cloud providers tend to assign catchy names to products that quite often transcend the initial functionality of the on-prem control, it becomes harder and harder to stay up-to-date on what service does what. https://www.managedsentinel.com/mapping-of-on-premises-security-controls-versus-services-offered-by-major-cloud-providers/ #aws #azure #gcp

Выложены доклады DevSecCon24 - 2021 https://www.youtube.com/playlist?list=PLKWDDWZ_ETtDbTF3Xibc2VagzgHbkoKpA Программа доступна тут https://www.devseccon.com/devseccon24-2021/

Light-weighted API Firewall by Wallarm Wallarm выложили на Github свой легковесный вариант API Firewall. Это реверс-прокси, написанный на Go, который валидирует запросы и ответы для OpenAPI v3. Поддерживается инсталляция через Helm. Примеры: - API Firewall demo with Docker Compose - Protecting Kubernetes Application Hot-to guide: - Securing REST with free API Firewall. #waf #ops

Managing SSH Access at Scale with HashiCorp Vault Выходим из затяжной паузы по постам и начинаем неделю с материала HashiCorp Vault об управлении SSH-ключами. Подобная интеграция может быть нужна по нескольким причинам. Во-первых, закрытые ключи пользователей хостов нередко становятся скомпрометированными по той или ной причине. Во-вторых, управление закрытыми ключами зачастую становится довольно сложной задачей, как и масштабирование данного процесса. Как итог процесс сопровождается отсутствием инвентаризации, что ведет к хаосу с точки зрения управления доступами. В результате интеграции Vault предоставляет механизм управления ключами совместно с политиками (порядок того, кто куда имеет доступ) и аудитом. Теперь вместо долгосрочных ключей используются кратковременные сертификаты с помощью SSH CA хранилища, которые можно создать в несколько экземпляров для различных сред (dev, stage, prod, infra). Managing SSH Access at Scale with HashiCorp Vault #vault #ops

🔸Building an end-to-end Kubernetes-based DevSecOps software factory on AWS "DevSecOps software factory implementation can significantly vary depending on the application, infrastructure, architecture, and the services and tools used. In a previous post, I provided an end-to-end DevSecOps pipeline for a three-tier web application deployed with AWS Elastic Beanstalk. The pipeline used cloud-native services along with a few open-source security tools. This solution is similar, but instead uses a containers-based approach with additional security analysis stages. It defines a software factory using Kubernetes along with necessary AWS Cloud-native services and open-source third-party tools. Code is provided in the GitHub repo to build this DevSecOps software factory, including the integration code for third-party scanning tools." https://aws.amazon.com/ru/blogs/devops/building-an-end-to-end-kubernetes-based-devsecops-software-factory-on-aws/ #aws

Изучаем уязвимости в сервисах поставки кода Увидел тут в Античате вырезку из журнала "Хакер" - "Опасная разработка. Изучаем уязвимости в сервисах поставки кода". Рассматриваются уязвимости и мисконфигурации таких продуктов как Jira, Confluence, Asana, GitLab, TeamCity и нескольких других.

"Большую часть перечисленного я обнаружил в 2019 году, так что не жди, что проделанное мной можно будет повторить на актуальных версиях перечисленных программ. Большинство уязвимостей уже закрыты, но моя цель в данном случае - продемонстрировать, как нужно думать, что бы их обнаруживать."

#attack

RESTler - first stateful REST API fuzzing tool RESTler - инструмент от Microsoft, принимающий в качестве входных значений OpenAPI/Swagger спецификацию, а на выходе формирующий набор тестов, направленных на повышение безопасности. Сам же инструмент выполняет и фаззинг. Пока что среди багов находит утечку ресурсов, неавторизованный доступ, наличие ошибок (500), use-after-free, доступность дочерних ресурсов не из родительских. #fuzzing #dev

Application Threat Modeling или чего не хватает вашим приложениям На подкасте упоминал про процесс моделирования угроз, который по-хорошему должен стоять в начале формирования требований безопасности к любой системе и приложению, в том числе Kubernetes. Тем не менее только сейчас нашел статью, которую хотел зашарить еще в пятницу в чат (в дополнение к тем, которыми уже поделился) - "Application Threat Modeling или чего не хватает вашим приложениям". Это небольшая статья от @icyberdeveloper о процессе моделирования угроз с применением методик STRIDE/DRIDE на примере простого приложения. Основные шаги при моделировании угроз: 1. Декомпозиция приложения на объекты под угрозой. 2. Определение опасностей, грозящих системе. 3. Построение деревьев угроз. 4. Оценка риска безопасности для каждого дерева. 5. Сортировка опасностей в порядке убывания степени их серьезности. 6. Выбор методов борьбы с опасностями. 7. Отбор технологий для выбранных методов борьбы с опасностями. Кстати, про все это вас будут спрашивать, если вы захотите пройти собеседование в иностранные компании на позицию AppSec или DevSecOps, поэтому однозначно стоит добавить в свой roadmap. #dev #ops #threatmodeling

Container Security в DevOps курилке В эту пятницу в 20.00 состоится выход первой серии подкаста "DevOps курилка", который будет проводиться с помощью встроенных механизмов тг в известном чате @devops_ru. Тема первого выпуска - безопасность контейнеров, где я буду общаться с @Asgoret и @afidelina о формировании требований, моделировании угроз, слепых зонах и инструментах. Все вопросы можно будет задавать в чате @sec_devops_chat. Также постараюсь заготовить некоторый материал, чтобы закидывать его в режиме онлайн в чат. Подключиться к подкасту: https://t.me/devops_ru?voicechat #talks