Threat Hunting with Kubernetes Audit Logs

Серия из двух частей "Analyzing Kubernetes audit logs to look for potential threats" и "Using the MITRE ATT&CK® Framework to hunt for attackers".

В первой статье идет база:
- What is threat hunting?
- What are Kubernetes audit logs?
- Why are audit logs important?
- What does an audit log look like?
- Let’s Hunt! (на что и как стоит обращать внимание - по сути как правильно интерпретировать лог)

Во второй статье рассматривают как на каждой стадии MITRE ATT&CK® Framework можно строить гипотезы и проверять их - в принципе полезная вещь.

Странно что в статье совсем не упомянут трюк с детектом обращения к ресурсам/API SelfSubjectAccessReview и SelfSubjectRulesReview, что является результатом работы команды kubectl auth can-i. Атакующий же не знает, что может захваченный им token ;)

Очень часто в статьях про K8s каждый механизм ИБ рассматривается в отрыве от остальных (а их в K8s очень много) и может сложиться не верная картина по работе с безопасностью в k8s (а она отличается от классических систем сильно). Я люблю рассматривать это все комплексно, а с учетом того, что Kubernetes Audit Logs вообще мало кто активирует, из-за увеличения нагрузки на API server, это еще более актуально.

Чтобы с минимизировать нагрузку я рекомендую использовать:
- GitOps operator
- PolicyEngine
- Минималистичную AuditPolicy

P.S. Кто-нибудь проводил замеры на сколько увеличивается нагрузка на API Server при работе Audit Logs или видел соответствующие работы на эту тему?

k8s (in)security

Threat Hunting with Kubernetes Audit Logs

Серия из двух частей "Analyzing Kubernetes audit logs to look for potential threats" и "Using the MITRE ATT&CK® Framework to hunt for attackers".

В первой статье идет база:
- What is threat hunting?
- What are Kubernetes audit logs?
- Why are audit logs important?
- What does an audit log look like?
- Let’s Hunt! (на что и как стоит обращать внимание - по сути как правильно интерпретировать лог)

Во второй статье рассматривают как на каждой стадии MITRE ATT&CK® Framework можно строить гипотезы и проверять их - в принципе полезная вещь.

Странно что в статье совсем не упомянут трюк с детектом обращения к ресурсам/API SelfSubjectAccessReview и SelfSubjectRulesReview, что является результатом работы команды kubectl auth can-i. Атакующий же не знает, что может захваченный им token ;)

Очень часто в статьях про K8s каждый механизм ИБ рассматривается в отрыве от остальных (а их в K8s очень много) и может сложиться не верная картина по работе с безопасностью в k8s (а она отличается от классических систем сильно). Я люблю рассматривать это все комплексно, а с учетом того, что Kubernetes Audit Logs вообще мало кто активирует, из-за увеличения нагрузки на API server, это еще более актуально.

Чтобы с минимизировать нагрузку я рекомендую использовать:
- GitOps operator
- PolicyEngine
- Минималистичную AuditPolicy

P.S. Кто-нибудь проводил замеры на сколько увеличивается нагрузка на API Server при работе Audit Logs или видел соответствующие работы на эту тему?

Square Corner Blog

Threat Hunting with Kubernetes Audit Logs

Analyzing Kubernetes audit logs to look for potential threats

hottg.com/k8security/393

3.2K viewsD1g1, Sep 20, 2021 at 06:03