Перед прочтением новой статьи "Better Together: Real Time Threat Detection for Kubernetes with Atomic Red Tests & Falco" у нас были (хоть и маленькие) надежды на что-то интересное, но они были быстро развеяны ...

Что можно узнать из статьи:
1) Как Atomic Red Team запустить в виде Kubernetes Deployment manifest
2) Чтобы не отставать от атакующего нужно постоянно писать свои правила: "revising the executed techniques and crafting custom rules." , "This iterative process aims to extend MITRE ATT&CK coverage"
3) Чем больше правил, тем больше шансов что-то поймать (и пускай для этого даже лучше ставить не последнюю версию Falco): "we can install Falco via Helm on a fixed version prior to the segregation of rules into different rules feeds" (а про вычислительные ресурсы при таком раскладе писать не будем)
4) Проще искать, когда знаешь что искать: "To ignore this noise, let’s instead just check for the specific Falco rule we are looking to detect".
5) Правил из коробки никогда не бывает достаточно: "Again, we have an [out-of-the-box rule]" , "CUSTOM RULE".
6) Пост вроде про Kubernetes, но для убедительности все будем показывать из темы хостовых ОС: "Adversaries may clear system logs to hide evidence of an intrusion. macOS and Linux both"
7) Но где-то глубоко внутри самих описаний правил все же будем признавать, что сначала надо разобраться как у нас вообще все работает: "However, it requires customization after profiling your environment."

В общем какая-то очень слабая статья получилась у Developer Advocate из Project Falco - хотя опять же все претензии выше не к конкретному решению, а к самому сигнатурному подходу, что мы уже не раз рассматривали. На пример, в нашем докладе. «EDR vs Containers: актуальные проблемы».