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

Доклад Security Compliance & DevOps

Вот также полезный доклад от Степана Носова по опыту сертификации компании по требованиям ISO 27001, а так же о том, как DevOps и ИБ могут в этом помочь друг другу.

https://youtu.be/BtFeWnR1xXE

#compliance

UPD от @Yorik2016

25 сентября 2020 г. вступил в силу приказ, определяющий требования к ПО, которые применяются для защиты КИИ. В частности, статический и динамический анализы, а также фаззинг-тестирование будут являться обязательными процессами.

P.S. Для тех, кому стало интересно разобраться в базовой нормативке ИБ, я когда-то делал огромный майнд-мап.

#compliance

Безопасность разработки в Agile проектах, Лаура Белл, Майкл Брантон-Сполл, Рич Смит, Джим Бэрд.

Наконец попала в руки электронная версия книги "Безопасность разработки в Agile-проектах". До этого я ее публиковал только на английском языке.

Хорошая книга, которая слабо поможет в безопасности разработки с технической точки зрения, но даст ориентир в части организации процессов в компании. Тем не менее, здесь есть описание работы с BDD-Security, ZAP, Gauntlt. К тому же это отличный старт для тех, кто только погружается в тему.

#literature #dev #ops

Enforce Ingress Best Practices Using OPA

До этого я поделился статьей от CNCF о том, как усилить Network Policy через OPA. В этот раз небольшая статья про решение коллизий на разных Ingress'ах через OPA. Например, у вас один и тот же хост есть на нескольких разных Ingress, что создает коллизию в маршрутизации трафика через Ingreess-controller. Такое бывает по мере роста ресурсов Ingress. OPA позволяет определить политику, которая не даст создавать ресурсы, образовав коллизию.

https://www.cncf.io/blog/2020/09/29/enforce-ingress-best-practices-using-opa/

Если вы все еще говорите про себя "Да кто такой этот ваш OPA", то я нашел еще одну прекрасную статью:

Fitness Validation For Your Kubernetes Apps: Policy As Code

#k8s #ops #opa

How I’d attack your HashiCorp Vault (and how you can prevent me): System Hardening.
https://medium.com/hashicorp-engineering/how-id-attack-your-hashicorp-vault-and-how-you-can-prevent-me-system-hardening-ce151454e26b

Can We Have “Detection as Code”?

Интересные мысли на тему возможности существования “Detection as Code" от Антона Чувакина, автора множества статей про обнаружение событий и SOC. Данная концепция идет от принципа "event-driven security", который также был упомянут в BSIMM 11.

Ключевые аспекты:
- Правила обнаружения как код (на примере Python здесь и Jupyter notebooks здесь)
- Отслеживание событий по мере работы пайплайна
- Кросс-вендорский и кросс-инструментальный подход для работы с событиями (правда пока что одинаково распространены Sigma, YARA-L и ATT&CK)
- Версионноcть и повторная воспроизводимость правил
- Надлежащий QA для сформированных правил
- Формирование метрик и их улучшение (от широты покрытия и failure rate)

https://medium.com/anton-on-security/can-we-have-detection-as-code-96f869cfdc79

#ops

GitLab's security trends report – our latest look at what's most vulnerable
https://about.gitlab.com/blog/2020/10/06/gitlab-latest-security-trends/

A Tale of Escaping a Hardened Docker container

Как многим известно, docker.sock крайне не рекомендуется пробрасывать внутрь Docker контейнера согласно CIS. Это может значительно упростить жизнь злоумышленнику для побега за пределы контейнера, но CIS не дает советов как обезопасить подобный сценарий, если "ну очень надо". Так, например, одна организация решила пробрасывать в контейнер некий somethtingelse.sock с аутентификацией и авторизацией на Reverse Proxy для работы с docker.sock.

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

P.S. В документации Docker есть отдельная страничка, посвященная защите docker.sock. Вот также ряд слайдов, которые помогут познакомиться с docker escape и механизмами ядра Linux для работы Docker.

https://www.redtimmy.com/a-tale-of-escaping-a-hardened-docker-container/

#docker #ops #attack

Gruntwork объясняют, почему важно подписывать свои коммиты на GitHub

#security

OAuth 2.0 Security Best Current Practice

Лучшие практики для обеспечения безопасности для OAuth 2.0 от 5 октября 2020 года. Статья построена в формате атака/контрмера. Кроме рекомендаций также можно познакомиться с моделью злоумышленника.

Материалы по безопасности OAuth, опубликованные ранее.

#dev

GitLab Watchman

GitLab Watchman - инструмент для поиска чувствительной информации в GitLab через GitLab API. Под поиск попадают код, коммиты, вики страницы, issue, merge requests, milestones.

От этого же автора есть инструмент Slack Watchman, который делает все то же самое для Slack.


#dev #secret

The State of Exploit Development: 80% of Exploits Publish Faster than CVEs

Palo Alto провели исследование, согласно которому только для 26% опубликованных публичных эксплоитов есть закрепленная CVE. Из них 14% - 0-day, 23% публиковались через неделю после выхода патча, 50% через месяц после патча. При этом 80% эксплоитов публикуется до CVE (в среднем за 23 дня до выхода CVE).

Вывод один - своевременно обновляйтесь.

Кстати также вот интересное репо Vulhub, в котором собраны сборки с публичными CVE, которые можно попробовать проэксплуатировать, либо протестировать SAST,SCA,DAST (сборки обернуты в docker compose). Здесь есть уязвимые версии Jenkins, Elasticsearch, Nexus Repo, Jira, Kibana и много чего еще.

#dev #attack