OWASP in SDLC

На портале OWASP можно найти статью, которая показывает, как выглядят разные процессы SDLC с точки зрения зрелых и не зрелых организаций, ссылаясь на OWASP SAMM как основную модель оценки зрелости. Здесь также есть ссылки на разные статьи и инструменты, которые должны помочь. Есть, конечно, определенные вопросы к полезности многих инструментов (в том числе самих Dependency Check/Track, ZAP, Defect Dojo), но статья может стать хорошей отправной точкой для проведения самооценки старых и новых процессов.

https://owasp.org/www-project-integration-standards/writeups/owasp_in_sdlc/

https://owasp.org/www-project-integration-standards/

#dev #ops

Докладчик Александр Бутенко - очень крутой специалист по WAF, регистрируемся!

#talks

​​КРОК:
Вебинар "Практика обеспечения защиты критических бизнес-приложений"

Уровень защищенности веб-приложений продолжает постепенно расти, но все еще остается довольно низким. В 2019 году 19% киберинцидентов были связаны с наличием уязвимостей в веб-приложениях. О том, как крупному бизнесу эффективно организовать защиту веб-приложений и API на открытом вебинаре расскажет эксперт КРОК.

Программа выступления:
• Проблемы подходов DevOps / SDLC на примере CI/CD pipeline
• Общие проблемы классического DevOps с точки зрения ИБ
• Безопасная разработка DevSecOps / Secure SDLC: процессы + инструменты
• Как реализация принципа "Shift left" влияет на показатель Time to market на примере WAF
• WAF как элемент CI/CD pipeline
• Практика внедрения WAF и техническая экспертиза КРОК на примере реального кейса
• Экспертиза КРОК по формированию эффективных политик и усилению WAF
• Эволюция микросервисного подхода. Рост значимости API
• Кейс несанкционированного доступа к API крупной организации, предоставляющей сервис услуг
• Защита API средствами WAF
• Защита API средствами систем контроля аутентификации и авторизации
• Симбиоз WAF и механизмов контроля аутентификации как средство выполнения OWASP best practice по защите API

Дата проведения:
15 сентября 2020 г., | 11:00 (МСК)

Регистрация

#вебинар #сентябрь
@InfoBezEvents

Tracking Moving Clouds: How to continuously track cloud assets with Cartography

Непрерывный мониторинг облачных ассетов с помощью Catography (утилиты от Lyft для распределения ассетов публичных облаков на графе) и информирование о любых нелегитимных изменениях в среде AWS/GCP через Slack и Jira.

https://www.marcolancini.it/2020/blog-tracking-moving-clouds-with-cartography/

Другие статьи из этой же серии:

Mapping Moving Clouds:How to stay on top of your ephemeral environments with Cartography

Cross Account Auditing in AWS and GCP

#gcp #aws #ops

Организация фаззинга исходного кода

Вчера на Habr вышла статья от Digital Security, посвященная фаззинг-тестированию и встраивание ее в CI/CD. По сути это текстовая версия их же доклада, про который я писал ранее. Статья затрагивает определение фаззинга, чем это отличается от статического анализа, как устроена фаззинг-ферма у них, про continious fuzzing от google и почему данная схема подходит не всем.

https://habr.com/ru/company/dsec/blog/517596/

#fuzzing #dev

От Threat Modeling до безопасности AWS: 50+ open-source инструментов для выстраивания безопасности DevOps

Сделал то, что давно хотел - большая статья со всеми практиками DevSecOps с описанием open-source инструментов. В качестве формата была выбрана статья на Хабре в нашем корпоративном блоге. На мой взгляд получилось круто. Более 50 инструментов, распределенных по 16 практикам, включая моделирование угроз, SAST, DAST, SCA, защиту Docker и Kubernetes, фреймворки BDD, проверку IaC и даже Security Chaos Engineering. В результате не получилось охватить и половины всего того, что уже есть, поэтому постарался указать все ссылки на чужие подборки, которые я знаю. Приятного чтения, надеюсь это вам поможет на первых этапах построения DevSecOps.

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

#tools #dev #ops

Evolution of Attacks in the Wild on Container Infrastructure 2020

Только что прилетел на почту первый отчет по Cloud Native угрозам от Aqua Security. В нем можно прочитать про современные атаки, их классификацию, этапы, статистику, описание, примеры использования MITRE Techniques. Хочется отметить, что на первый взгляд материал не является каким-то маркетинговым булшитом (как часто бывает в вендорских отчетах).

#report #ops #k8s #docker #attack

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.