BSIMM 11 - Что изменилось, event-driven security и платформа о рисках артефактов

Два дня назад вышла новая версия BSIMM, главного документа по организации безопасности SDLC с точки зрения оценки зрелости процессов и предоставления лучших практик. Для написания BSIMM независимая группа проводит исследование сотни компаний разных размеров, агрегируя их активности по безопасности SDLC в этот сборник.

Что изменилось, помимо перестановки активностей между практиками?

1) Появление активности "[ST3.6:0] Implement event-driven security testing in automation". Исследования BSIMM гласят, что инженеры в опрашиваемых компаниях идут по пути поиска дефектов на основе событий в процессе непрерывного мониторинга, а не поиска их на ранних стадиях жизненного цикла ПО. Тем не менее, развивается тенденция, при которой группа безопасности задает события-тригеры в рамках пайплайнов. То есть, например, привлекать инженеров ИБ не когда валится одна из проверок безопасности в пайплайне, а когда поступает какое-то конкретное событие от ботов или агентов. Эти агенты/боты могут следить как за результатами самого пайплайна, так и за реакцией со стороны dev-окружения. Также эти агенты/боты могут запускать собственные автоматические задачи по мере обнаружения необычных событий. Идею с event-driven automation можно найти в статьях Netflix от 2016 года. Тогда они описали свою платформу Winston, которая позволяла помочь инженерам не вскакивать посреди ночи из-за ложных событий.

2) Появление активности "[CMVM3.6: 0] Publish risk data for deployable artifacts", согласно которой растет значимость централизованных платформ управления безопасностью. Согласно BSIMM платформа должна содержать информацию об активах организации (артефактов, зависимостей) и связанных с ними рисками. При этом автоматическая актуализация информации и ее визуализация в платформе положительно сказывается на принятии стейкхолдерами решений, связанных с рисками.

#bsimm

🆖 Тут ребята взяли и прокачали секурити для Nginx. Запаковали это всё в образ и выложили на Github. Из коробки у нас доступен WAF, антивирусная проверка и подкрученные настройки безопасности. Интересно. https://github.com/bunkerity/bunkerized-nginx

#nginx #security

Антон Бабенко (https://github.com/antonbabenko) вернул к жизни свой канал на Youtube и теперь пилит там годноту.

Вот, например, он не только потрогал утилиту статического анализа checkov для IaC (https://github.com/bridgecrewio/checkov), но и пригласил на стрим автора оной тулы - Barak Schoster. В общем, если интересен Terraform и мир вокруг него, то рекомендую.

Terraform security tools review (part 1) - checkov
https://www.youtube.com/watch?v=KdH-7_vpFag

Falco Deefault Rule Bypass

Falco - известное open-source решение для предупреждения о подозрительных действиях на рабочих нагрузках Docker/Kubernetes. Так, например, можно определить процессы, которые могут быть запущены в Docker-контейнере и сообщать, если что-то идет не так.

Тем не менее, при определенных условиях Falco может стать бесполезным. В статье рассказывается о том, как можно обойти правила в Falco v.0.25.0 без правильно настроенного Admission Control. Берем во внимание и идем обновлять правила.

https://darkbit.io/blog/falco-rule-bypass

#k8s #ops #attack

"SonarQube in Action" by G.Ann Cambell and Patroklos P.Papapetrou

#literature #sast #dev

Gitlab - достаточно популярный продукт для разработки, благодаря self-hosted решению и его часто можно встретить на поддоменах компаний. Помимо того, что в нем также присутствует регистрация без подтверждения email’а (смотрим в предыдущие посты), это еще и отличная возможность собрать информацию о сотрудниках.

Без аутентификации доступен следующий API метод - gitlab.company.local/api/v4/users/{id}

На самом gitlab - эта ручка также доступна, например https://gitlab.com/api/v4/users/7154957:

{"id":7154957,"name":"Bo0oM","username":"webpwn","state":"active","avatar_url":"https://secure.gravatar.com/avatar/4e99709ca6b52f78d02cb92a5bc65d85?s=80\u0026d=identicon","web_url":"https://gitlab.com/webpwn","created_at":"2020-09-21T17:25:55.046Z","bio":"","bio_html":"","location":"","public_email":"","skype":"","linkedin":"","twitter":"@i_bo0om.ru","website_url":"https://t.me/webpwn","organization":"","job_title":"","work_information":null}

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

По логину также можно узнать открытые ключи - https://gitlab.com/webpwn.keys

Отдельного упоминания заслуживает avatar_url:

”avatar_url":"https://secure.gravatar.com/avatar/4e99709ca6b52f78d02cb92a5bc65d85?s=80\u0026d=identicon”

Сервис gavatar содержит email в пути к изображению - 4e99709ca6b52f78d02cb92a5bc65d85. Это ни что иное, как md5 от email’а в нижнем регистре.

echo -n "webpwn@bo0om.ru" | md5


4e99709ca6b52f78d02cb92a5bc65d85

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

Меня немного обогнали с описанием CVE, но я все равно дополню мысль примерами

Вот, например, CVE-2016-5195 - Race Condition в старых версиях ядра позволяет сделать docker escape.

PoC:
https://github.com/gebl/dirtycow-docker-vdso

Видео-демо:
https://youtu.be/BwUfHJXgYg0

Текстовое описание:
https://blog.paranoidsoftware.com/dirty-cow-cve-2016-5195-docker-container-escape/

#docker #ops #attack

Замечательная заметка "Impact of CVE-2020-14386 on Kubernetes and Containers (Docker)" лишний раз не дает забыть о том, что безопасность хоста, на котором работает Kubernetes это также часть безопасность Kubernetes инфраструктуры.

Здесь речь идет о критической уязвимости ядра Linux - CVE-2020-14386, благодаря которой можно поднять свои привилегии до root'а или сделать побег из контейнера на Node, на которой он работает. Атакующий способен эксплотировать данную уязвимость, выполняя свой код внутри Pod'а с CAP_NET_RAW capability.

Естественно, это далеко не первая и не последняя уязвимость в ядре Linux которая позволяет делать "container escape". И все это никакими правилами и сигнатурами заранее не описать, не предусмотреть.

Что в таком случае делать для защиты?
1) Можно/нужно мониторить аномальную активность внутри ваших контейнеров. Так или иначе атакующему придётся для побега из контейнера делать то, что ранее в контейнере у вас не происходило. Это позволит вам ловить не только попытки "container escape", но и другу. Вредоносную активность внутри контейнера (Lateral Movement, запуск манейров и т.д.)
2) Можно присмотреться к защищенным/усиленным вариантам Low-level Runtime (OCI Runtimes) о которых говорили ранее. Но стоит учитывать, что они, как и любое ПО сами не застрахованы от уязвимостей, а просто сильно уменьшают и усложняют attack surface. Так GKE Sandbox использует для этого gVisor.

Новый Awesome DevSecOps на русском

В силу того, что последняя статья с подборкой инструментов DevSecOps собрала весьма восторженные отзывы, решил вынести все тулзы (и добавить еще больше) в отдельный Awesome на GitHub. Туда же вставил все статьи и доклады на русском языке, которые я только знаю и смог найти в Интернете.

Итого:
- 16 различных практик
- 100+ инструментов
- 10+ сторонних подборок
- 30 статей на русском
- 26 докладов на русском

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

https://github.com/Swordfish-Security/awesome-devsecops-russia

#dev #ops

DevSecOps Wine Chat

А еще я создал чат, где можно обсуждать посты из канала и все, что относится к DevSecOps с приятным комьюнити. Кроме того, я кидаю туда материал, который не попадает в основной поток. Добро пожаловать!

https://t.me/sec_devops_chat

#talks

Whalescan - vulnerability scanner for Windows containers

Для тех, кто использует Windows base OS контейнеры вроде IIS и .NET есть соответствующий инструмент. Whalescan позволяет искать уязвимости в Windows контейнерах и проводить benchmark проверки, выявлять небезопасные команды в Dockerfile, вышедшие из жизни .NET версии и другое.

https://github.com/nccgroup/whalescan

#tools #docker #dev #ops

Выложены доклады с GitLab Commit Virtual 2020

Там был отдельный поток посвящённый DevSecOps
https://www.youtube.com/playlist?list=PLFGfElNsQthbJaOG4pV450Y_eIdfr2p9Y

Ссылка на все потоки
https://www.youtube.com/c/Gitlab/playlists?view=50&sort=dd&shelf_id=5

Программа
https://about.gitlab.com/events/commit/#schedule

Красота

Ко всему прочему было проведено моделирование угроз через drawio-threatmodeling , выведены требования безопасности, организована проверка IaC и автоматический аудит через ScoutSuite.

#aws

🔸Security Architecture Review Of A Cloud Native Environment

Walkthrough of a cloud security assessment performed on an organisation which had recently moved their infrastructure from an on-prem to a cloud native solution (AWS).

https://notsosecure.com/security-architecture-review-of-a-cloud-native-environment/

#aws

How to enforce Kubernetes network security policies using OPA

Статья на CNCF из серии Open Policy Agent (OPA) про Network Security Policies и усиление мер защиты. В частности, как написать политики OPA на языке Rego
1) Чтобы, нельзя было задеплоить приложение, если сетевая политика не установлена
2) Чтобы сетевая политика удовлетворяла требованиям к приложению (например, подключиться мог только фронтенд)

https://www.cncf.io/blog/2020/09/09/how-to-enforce-kubernetes-network-security-policies-using-opa/

#ops #k8s #opa

5 tips for using the Rego language for Open Policy Agent (OPA)

В продолжении к предыдущему посту, несколько трюков и полезных советов по написанию правил OPA на Rego

https://www.fugue.co/blog/5-tips-for-using-the-rego-language-for-open-policy-agent-opa

#ops #k8s #opa

Гитхаб официально запускает возможность проведения сканирования кода в публичных репозиториях. Для создания кастомизированных правил используется движок CodeQL, а база доступных правил насчитывает более 2000 оных. Все настраиваемо и даже есть возможность внедрения своих SAST инструментов.

https://github.blog/2020-09-30-code-scanning-is-now-available/

Как написать правила для Checkmarx и не сойти с ума

Тем временем Юра(@Mr_R1p) выпустил статью по кастомным правилам Checkmarx. Это вторая статья в русскоговорящем сообществе, объясняющая queries в чеке (первая статья от Максима). Здесь есть и словарь, и методика написания правил и то, что можно уже использовать прямо сейчас в своих проектах. Плюс к статье прилагается полезное репо с правилами.

https://habr.com/ru/company/swordfish_security/blog/521396/

#sast #dev

Безопасная разработка - российские стандарты.

Когда-то давно я описывал резюме совещания во ФСТЭК касательно обсуждения безопасной разработки. Вчера пообщался с опытным человеком, который успел в этих документах повариться. Подборка от него по российскому compliance и не только.

"ГОСТ 56939 Разработка безопасного ПО. Общие требования." - фактически главный документ сейчас по SDL в России. Здесь общая структура процесса, приседаний вокруг продукта и документации.

"ГОСТ 58412 Разработка безопасного ПО. Угрозы безопасности информации при разработке ПО" С него в идеале должна строиться модель угроз продукта, но документ имхо не очень удачный. Обычно все пользуются STRIDE от майкрософта.

Бесплатный учебный курс по STRIDE от Майкрософта на русском языке.

Утилита, по которой выполняется верхнеуровневое описание угроз по STRIDE'у.

Проект стандарта "Руководство по реализации мер по разработке безопасного программного обеспечения". Он доступен на сайте ФСТЭКа. Этот документ служит неким шаблоном для разработки инструкций по SDL.

Для того, чтобы в организации засчитали SDL, в ней должны быть поставлены ИБ процессы по ГОСТ Р ИСО МЭК 27001 Мэнеджмент ИБ. Это линейка стандартов, она также включает в себя ISO IEC 27034.

#compliance