Threat Hunting with Kubernetes Audit Logs

Небольшая статья (из серии) на тему, на что можно смотреть при разборе логов Kubernetes API, чтобы выявлять подозрительные действия. Здесь же есть примеры правил, которые можно переиспользовать как-то в своих SIEM. Принцип простой - выявляем наиболее частые запросы, где пользователю было недостаточно прав доступа и собираем инфу о том, кто, куда и с каким verb. Также предлагается фильтровавать по конкретному verb (например list) и user.username (чтобы отметать системный трафик).

Да, это просто и далеко не всегда эффективно, но в качестве первых шагов вполне себе смахивает на меру защиты.

#ops #k8s #attack

Security as code: The best (and maybe only) path to securing cloud applications and systems

Статья на тему, как выстроить "безопасность как код" (SaC) по мнению McKinsey. Обратите внимание на картинку с описанием мер безопасности на каждом этапе процесса разработки (No developer access to binary artifacts, Deployments must be approved by product owner, ...).

Чего мне не хватает в подобных статьях, так это примеров. Особенно, если говорить про "SaC", то есть то, что вообще нечасто встретишь в enterpise. Для меня, например, одна из реализаций SaC - это внедрение подхода BDD с помощью Gauntlt. У кого-то SaC - это прежде всего "Compliance as Code" в виде Chef InSpec или OpenSCAP. У кого-то это реализация policy engine в виде OPA. Сами McKinsey приводят в качестве примера автоматическое шифрование ПДн, которое "запускается всякий раз, когда разработчик отправляет код."

А что для вас Security as Code?

#dev #ops

Cloud Native Security

Свежая книга по cloud native безопасности (kubernetes, aws) с упоминанием некоторых DevSecOps-подходов (есть даже про "deprecation of PSP"). В основном все строится на практической составляющей с вводом-выводом на консоль и примерами интеграций конкретных инструментов.

#literature #dev #ops #k8s #aws

kubescape

Кажется уже все слышали, что NSA (National Security Agency) выпустили Kubernetes Hardening Guidance, но не все знают, что вслед за этим вышел open-source инструмент Kubescape от компании Armo для проверки кластера на соответствие этому гайду. Подобный набор проверок можно встретить в том же kubeaudit, но kubescape отличает тот факт, что правила написаны на языке OPA (Rego). Тут стоит отметить, что речь идет именно о кластере, а не о манифестах, которые хранятся в git, где может подойти любой IaC сканер вроде kics.

UPD. Исходя их сорсов, тула ходит во внешние серверы Armo за правилами. Спасибо @ttffdd

#k8s #ops

Опрос: что вы думаете о DevSecOps?

Коллеги из PT расшифровали доклад с PHDays о применении Security Gym в обучении разработчиков писать безопасный код: "Безопасность для айтишников: как научить разработчиков устранять уязвимости и создавать безопасные приложения". Помимо теории (описания уязвимости в коде), обучение также предполагает написание функциональных и security-тестов, участие в CTF.

Также PT запустили опрос: "Что вы думаете о DevSecOps?", в котором просят пользователей Habr рассказать о том, как обстоят дела с безопасной разработкой в компании. Предлагаю помочь им собрать как можно больше данных для исследования :)

#talks #dev

Threat Hunting with Kubernetes Audit Logs - Part 2

Вторая статья на тему обработки событий с Kubernetes API для поиска аномалий (первую можно прочитать здесь). Событий стало чуть больше и теперь они привязаны к матрице MITRE ATT&CK.

#k8s #ops

🔶 KONTRA's AWS Top 10

A series of free interactive security training modules that teach developers how to identify and mitigate security vulnerabilities in their AWS-hosted cloud applications.

https://application.security/free/kontra-aws-clould-top-10

#aws

Cloud Security Orienteering

Статья на тему, что нужно делать, чтобы разобраться в безопасности AWS организации, про которую ты ничего не знаешь. Приведено большое количество фреймворков в стиле awesome, такие как AWS Security Maturity Roadmap 2021, The AWS Security Reference Architecture и Cloud Penetration Testing Playbook. Плюс сам автор статьи поделился своим собственным чеклистом.

#aws #ops

Yandex Cloud Security Checklist

В продолжение поста про многообразие способов и инструментов аудита AWS я решил выпустить первый чеклист по безопасной конфигурации Яндекс.Облака. В основе лежит агрегация всего, что есть в документации YC на тему безопасности, плюс некоторый свой опыт, выявленный в рамках аудитов. Глобально чеклист разбит на домены сетевой безопасности и контроля доступа.

Основная проблема в том, что почти все механизмы безопасности (Security Groups, Audit Trails), которых и так немного, находятся либо на стадии Preview, либо подключаются по запросу. Остальные механизмы подключаются через маркетплейс из числа сторонних коммерческих решений.

UPD. Кстати, если хотите часть проверок пройти автоматизированными средствами, то рекомендую Cloud Advisor. Там, в частности, пока еще есть возможность провести бесплатное сканирование.

#yandex #ops

CVE-2021-26084

Для тех, кто не видел (CVSS: 9.8 Critical), советую проверить свой confluence и обновиться до безопасной версии. В Интернете уже полно PoC'ов.

Уязвимые версии - до версии 6.13.23, от версии 6.14.0 до 7.4.11, от версии 7.5.0 до 7.11.6 и от версии 7.12.0 до 7.12.5.

#attack #ops

Тут Confluence похекали

CVE-2021-26084 Confluence RCE

https://github.com/httpvoid/writeups/blob/main/Confluence-RCE.md

Introduction to OWASP Top 10 2021

OWASP выпустили драфт документа OWASP Top 10 2021!

Из нового, что отсутствовало в последнем Top 10 2017:
- A04:2021-Insecure Design
- A08:2021-Software and Data Integrity Failures
- A10:2021-Server-Side Request Forgery

Также по списку поднялись уязвимости класса A06:2021 – Vulnerable and Outdated Components, что автоматически повышает перспективы инструментов SCA.

В начале этого года Wallarm также представили свою версию Top10, основанную на анализе базы данных Vulners.

#web #dev

ZeroNights 2021

Выложили записи и слайды с Zero Nights 2021. Самое интересное для этого канала находится в секции Defensive Track.

- О метриках с практической точки зрения - доклад про метрики (в частности про те, что были приведены в HP MagicNumbers), а также немного про OWASP SAMM и ASVS.
- Побег из контейнера: Kubernetes - доклад, где название говорит само за себя от автора @k8security. Доклад начинается с вводной части о работе k8s, после чего приводятся способы побега из контейнера через capabilities, маунты и CVE (есть очень много полезных ссылок).
- CVEhound: проверка исходников Linux на известные CVE - доклад про проблемы инструментов SCA и поиск CVE в Linux с помощью CVEhound.
- DevSecOps на Open Source: бурление в стакане - про построение классического процесса на базе gosec, trufflehog, defectdojo, semgrep и т.д. Автор также поделился пайплайнами gitlab в public.
- Атаки на микросервисные приложения: методы и и практические советы - доклад про то, на что надо обращать внимание с точки зрения безопасности, когда речь заходит о микросервисах (как проверять безопасность аутентификации, авторизации, какими инструментами, где брать чеклисты).
- Лезем невидимой рукой аппсека в релизные сборки - доклад про поиск уязвимостей в мобилках и написание своей тулы CheckKarlMarx.

Все слайды можно найти здесь.

#talks #dev #ops

Отличный опрос для выходных!
Поможет понять, с чего начать обучение в безопасности aws, в изобилии сервисов
Также в ответ рекомендую @aws_notes

#aws #ops

Top 20 AWS services for Security

С вашей помощью получился следующий список AWS сервисов, который Security (специалистам по ИБ) обязательно нужно знать / стоит знать / можно рекомендовать для изучения (по убыванию важности):

1️⃣ IAM
2️⃣ CloudTrail
3️⃣ KMS
4️⃣ GuardDuty
5️⃣ Config
6️⃣ Security Hub
7️⃣ Organizations
8️⃣ SSO
9️⃣ CloudWatch
🔟 WAF (Web Application Firewall)
11. Secrets Manager
12. ACM (AWS Certificate Manager)
13. Shield
14. VPC
15. Inspector
16. Route53
17. Network Firewall
18. Firewall Manager
19. Audit Manager
20. EC2

AWS сервисов по безопасности в реальности ещё полтора десятка, уже более специализированных. Про которые тоже стоит/нужно знать безопасникам. 😀

Также порекомендую, чтобы быть в курсе по теме безопасности, обязательно стоит подписаться на @sec_devops, где всегда много тем по AWS.

p.s. Ранее было аналогичное для бэкенда, фронта, фуллстэк и QA.

#top #security #опрос

"If you use Travis CI, your supply chain was compromised."

Тут в твиттере набирает популярность тред, связанный с утечкой секретов из публичных репозиториев, собираемых через Travis CI. Дело в том, что до 10 сентября (когда был внедрен фикс) любой пользователь мог получить доступ к закрытым переменным абсолютно любого публичного репозитория. Для этого достаточно было сделать fork репозтория и вывести переменную через print в процессе сборки. Основная проблема, согласно автору треда, в том, что разработчики Travis CI никак не оповестили своих клиентов, когда получили информацию об этой уязвимости. Очень, кстати, напомнило пост, который я делал про вывод секретов через Jenkins в процессе сборки.

Если вы используете Travis CI для своих публичных репозиториев, рекомендуется сменить секреты.

https://twitter.com/peter_szilagyi/status/1437646118700175360

#ops #attack #news

The Show Must Go On: Securing Netflix Studios At Scale

Статья от Netflix о том, как они сделали аутентификацию аспектом архитектуры, а не вопросом реализации того или иного приложения. Как итог Netflix отказались от security-листа для разработчика, заменив весь пул вопросов на один - "Будете ли вы использовать наш gateway Wall-E"? (доработанная версия Zuul с точки зрения безопасности). Команда рассказывает, с какими сложностями она при этом столкнулась и к каким решениям пришла.

Основной вывод статьи в следующем - вместо предоставления разработчикам вариации путей, по которым они могут сделать свой продукт безопасным, целесообразнее (в том числе и с точки зрения масштабирования на скорости Netflix) создать "единую асфальтированную дорогу", которой можно воспользоваться для быстрого решения security-проблем.

#ops

Saint HighLoad++ 2021

20 и 21 сентября в Санкт-Петербурге пройдет конференция разработчиков высоконагруженных систем Saint HighLoad++ 2021. На ней, в частности, будет представлено 3 доклада по безопасности:
- Безопасность DNS, посвященный, как можно понять из названия, современной теории и практике защиты DNS
- Отказ в обслуживании: как положить высоконагруженную систему, посвященный DoS глазами злоумышленника и примерам из жизни падения высоконагруженных систем
- Киберучения: методы проведения и реализация, посвященный тому, какие бывают security awarness, какие есть готовые решения и как провести этот процесс самостоятельно

На Highload регулярно появляются интересные доклады по ИБ, в частности, "Безопасность AI-пайплайнов" (доступны слайды). Один из самых известных докладов, доступных с записью, - Хайлоад и безопасность в мире DevOps, где Юрий Колесков поднял многие злободневные темы еще в далеком 2017 году.

Для просмотра достаточно регистрации: https://conf.ontico.ru/polls/3875667/onepage

#talks #dev #ops

Месяц назад гремела новость про "Kubernetes Hardening Guidance" от NSA (и я об этом писал), затем все писали про инструмент Kubescape для проверки по данному гайду (я об то не писал).

И пока совсем без внимания остается статья "NSA & CISA Kubernetes Security Guidance – A Critical Review" от известной security компании. Статья состоит из 3-х частей: что хорошего, что плохого и что забыто в данном гайде.

На том что там хорошего - останавливаться не будем, лишь процитирую авторов по этому поводу: "Each of these points relate back to the generic guidance for almost any platform, regardless of the technology in use"

Про плохое (страдает точность, актуальность и полнота):
- PSP Deprecation - про данный факт ни слова.
- Admission Controllers - практически не упоминаются, хотя это мощнейший инструмент k8s.
- Inconsistencies/Incorrect Information - опечатки/неточности про порты.
- Authentication Issues - ошибка что в k8s нет аутентификации по умолчанию.

Последнюю часть характеризует цитата: "With a project as complicated as Kubernetes, it is not possible to cover every option and every edge case in a single document, so trying to write a piece of one size fits all guidance won’t be possible. "). То есть там авторы говорят о том, что вообще не было рассмотрено в документе:
- Levels of Audit Data
- Sidecar Resource Requirements
- External Dependencies are essential
- RBAC is hard
- Patching Everything is hard