Интересную заметку в своем блоке опубликовали исследователи из одной security-компании - "Falco Default Rule Bypass".
Обходы заключаются в логической ошибке в описании двух достаточно серьезных правил детектирования: "Launch Sensitive Mount Container" и "Launch Privileged Container". Из-за этой ошибки атакующий может создать такие
За данным проектом я наблюдаю давно и для меня всегда оставалась загадкой его целевая аудитория?!
Если предполагается что предопределённые правила нужны новичкам, то в это не укладывается конфигурирование файла
Если предполагается что предопределённые правила нужны большим и зрелым security командам, то большинство из его детектов можно закрыть другими механизмами, встроенными в сам Kubernetes. Например,
Также Falco позиционирует себя как детектор аномального поведения и при этом базируется на человека созданных предопределенных правилах... При этом абсолютно естественно, когда, например, в одном
Обходы заключаются в логической ошибке в описании двух достаточно серьезных правил детектирования: "Launch Sensitive Mount Container" и "Launch Privileged Container". Из-за этой ошибки атакующий может создать такие
images, что при их использовании система Falco ничего не увидит и промолчит. За данным проектом я наблюдаю давно и для меня всегда оставалась загадкой его целевая аудитория?!
Если предполагается что предопределённые правила нужны новичкам, то в это не укладывается конфигурирование файла
falco_rules.yaml (объем которого боле 1600 строк). Для его грамотной настройки явно порог входа не новичок. Тут нужно и Kubernetes понимать и то, как работают все ваши сервисы. Часть правил к вам вообще может быть не применима или применима не всегда и не везде в вашей инфраструктуре. А с учетом того, что сервисы меняются/развиваются, то и данный файл с правилами также надо своевременно редактировать. И как мы видим в блоге ни сами авторы инструмента, ни вы при редактировании правил не застрахованы от ошибок. Если предполагается что предопределённые правила нужны большим и зрелым security командам, то большинство из его детектов можно закрыть другими механизмами, встроенными в сам Kubernetes. Например,
Admission Control, PodSecurityPolicy, NetworkPolicy + Logging. Есть конечно и прецеденты, кто использует его, но тут надо иметь очень зрелый цикл разработки, слаженное взаимодействие между командами + приличную security team, что могут позволить себе далеко не все. Так как иначе это поддерживать в актуальном состоянии будет очень-очень тяжело.Также Falco позиционирует себя как детектор аномального поведения и при этом базируется на человека созданных предопределенных правилах... При этом абсолютно естественно, когда, например, в одном
image запуск процесса bash это аномально, а для другого это нормально. Так что это будет в итоге? Или на этот случай надо модифицировать правила для каждого image?