Время от времени получаю различные запросы на проведение аудита Kubernetes и DevSecOps процессов. В рамках одного из них столкнулся с тем, что заказчик использует Falco совместно со встроенными правилами. Основными здесь являются
falco_rules.yaml и k8s_audit_rules.yaml. На первый взгляд все очень красиво. Отдельным тэгом выделена классификация правил по MITRE ATT&CK. Каждое правило проставлено тэгом, который говорит о принадлежности правила к тому или иному этапу развития атаки. На этот счет в 2019 году Sysdig выпустили даже отдельную статью "MITRE ATT&CK framework for container runtime security with Falco", а в 2021 году вышло две статьи о том, как Falco может определить реализацию атак на практике:
- MITRE ATT&CK framework for container runtime security with Falco.
- Detecting MITRE ATT&CK: Defense evasion techniques with Falco
Можно ли применить сразу данные правила и почему подобного пака нет в OPA? Все дело в том, что встроенный пак от Falco никак не учитывает специфику вашей организации и используемые инструменты. Если мы посмотрим на правило "Write below etc", то увидим более 30 различных исключений, которые потенциально могут использоваться злоумышленником. По этой причине весь встроенный пак нуждается в серьезной кастомизации, чтобы не повторить кейса, похожего на Falco Bypass. Даже если вы не готовы выделять деньги на коммерческие решения с встроенным механизмом профилирования, всегда придерживайтесь концепции Least Privilege и Zero Trust.
#ops #attack
