Security Wine (бывший - DevSecOps Wine)
7.14K subscribers
281 photos
1 video
68 files
491 links
https://radcop.online/

"Security everywhere!"

🍷Канал, в котором публикуются материалы о "выращивании" безопасности в организации (а начиналось все с безопасного DevOps и shift security left!)

По всем вопросам: @surmatmg
Download Telegram
AquaSecurity_Cloud_Native_Threat_Report_2021.pdf
7.5 MB
Attacks in the Wild on the Container Supply Chain and Infrastructure

Помните отчет от Aqua, где они установили honeypot'ы для определения атак направленных на контейнерную среду? Они выпустили новый отчет, где атак было зафиксировано больше (рост на 26% за квартал), а результаты не менее интересны. Отчет достаточно хорошо описывает векторы атаки, связанные с MITRE ATT&CK, с приложенными скриншотами используемых скриптов.

#attack #docker #k8s #ops
Container Security в DevOps курилке

В эту пятницу в 20.00 состоится выход первой серии подкаста "DevOps курилка", который будет проводиться с помощью встроенных механизмов тг в известном чате @devops_ru. Тема первого выпуска - безопасность контейнеров, где я буду общаться с @Asgoret и @afidelina о формировании требований, моделировании угроз, слепых зонах и инструментах. Все вопросы можно будет задавать в чате @sec_devops_chat. Также постараюсь заготовить некоторый материал, чтобы закидывать его в режиме онлайн в чат.

Подключиться к подкасту:
https://t.me/devops_ru?voicechat

#talks
Application Threat Modeling или чего не хватает вашим приложениям

На подкасте упоминал про процесс моделирования угроз, который по-хорошему должен стоять в начале формирования требований безопасности к любой системе и приложению, в том числе Kubernetes. Тем не менее только сейчас нашел статью, которую хотел зашарить еще в пятницу в чат (в дополнение к тем, которыми уже поделился) - "Application Threat Modeling или чего не хватает вашим приложениям". Это небольшая статья от @icyberdeveloper о процессе моделирования угроз с применением методик STRIDE/DRIDE на примере простого приложения.

Основные шаги при моделировании угроз:
1. Декомпозиция приложения на объекты под угрозой.
2. Определение опасностей, грозящих системе.
3. Построение деревьев угроз.
4. Оценка риска безопасности для каждого дерева.
5. Сортировка опасностей в порядке убывания степени их серьезности.
6. Выбор методов борьбы с опасностями.
7. Отбор технологий для выбранных методов борьбы с опасностями.

Кстати, про все это вас будут спрашивать, если вы захотите пройти собеседование в иностранные компании на позицию AppSec или DevSecOps, поэтому однозначно стоит добавить в свой roadmap.

#dev #ops #threatmodeling
How do you feel about reading posts in english?
Anonymous Poll
42%
Cool!
22%
Okay, but only if the Russian language remains
30%
No difference
6%
Bad!
OPA instead of PSP

Большинство, кажется, уже в курсе, что PSP в Kubernetes перейдет в статус deprecated в версии 1.21, а альфа-релиз замены появится только в 1.22, но тем не менее проблема будущего встроенного policy движка все еще стоит на повестке. Один из вариантов - Open Policy Agent (OPA) Gatekeeper.

Недавно в чат вкинули репо с правилами для OPA, которые можно взять за основу, чтобы полностью заменить PSP. Спасибо @Uburro!

#ops #k8s #ops
RESTler - first stateful REST API fuzzing tool

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

#fuzzing #dev
Изучаем уязвимости в сервисах поставки кода

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

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

#attack
Forwarded from CloudSec Wine
🔸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
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
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
NCC_Group_Google_GOIST2005_Report_2020-08-06_v1.1 .pdf
849.7 KB
Announcing the results of Istio’s first security assessment

Команда Istio выпустила результаты аудита безопасности их продукта версии 1.6.5, который проводился NCC Group в прошлом году. К отчету идет сопутствующая статья, где поясняется, откуда взялись те или иные Security Best Practices.

#ops #attack #report #k8s
Forwarded from CloudSec Wine (Артем Марков)
🔶🔷🔴 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
Kubernetes Overview Diagrams

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

#k8s #ops
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