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- Минималистичную
AuditPolicyP.S. Кто-нибудь проводил замеры на сколько увеличивается нагрузка на
API Server при работе
Audit Logs или видел соответствующие работы на эту тему?