Analyze differences in technical capabilities and feasibility for Falco and Wazuh
Analyze differences in technical capabilities and feasibility for Falco and Wazuh, starting with analysis started in #31901 (comment 315154002)
Since we are heavily focusing on container/k8s environments it's important to emphasis the fact that support for intrusion detection capabilities is important for both host and container environments, as well as k8s audit. Our most common host OS will be minimal linux distribution with a minimal userspace (for example Google's COS). Container's OS on other hand can be any linux distribution or in some cases have no OS at all (scratch containers are popular for golang's statically linked apps). We have to support at least docker and bare containerd runtimes, support for runc and cri-o will be nice to have.
Host OS
| Falco | Wazuh |
|---|---|
Roughly similar support for file, permission, process and syslog probes: https://falco.org/docs/rules/supported-fields/. Enough to monitor minimal host OS: https://documentation.wazuh.com/3.9/user-manual/capabilities/index.html.
Container OS
| Falco | Wazuh |
|---|---|
Falco can see syscals from the container OS, all probes should work for processes running inside container. Most of the probes provided by Wazuh will not be applicable to the OS running inside container since we can't install agent inside container (more about this below). We could try to leverage syscall module but it looks limited in comparison to Falco: https://documentation.wazuh.com/3.9/user-manual/capabilities/system-calls-monitoring/index.html
Container runtime
| Falco | Wazuh |
|---|---|
Falco traces LXC syscalls, this allows it to support various container runtimes transparently: https://falco.org/docs/rules/supported-fields/#container-field-class. Wazuh only has support for Docker runtime via Python client: https://github.com/wazuh/wazuh/blob/master/wodles/docker-listener/DockerListener.py. Support for other runtimes will be hard to add. Falco exposes more information about containers than Wazuh, Wazuh can only provide basic rules like container started, stopped etc. (https://github.com/wazuh/wazuh-ruleset/blob/master/rules/0455-docker_rules.xml).
k8s runtime
| Falco | Wazuh |
|---|---|
Falco provides k8s audit probes out of the box with a lot of useful rules: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml. Wazuh doesn't have k8s audit capabilities.
Default ruleset
| Falco | Wazuh |
|---|---|
Falco's ruleset by default focuses on basic protections for the host but also has various probes related to containers: https://github.com/falcosecurity/falco/blob/master/rules/falco_rules.yaml. Wazuh provides rules for host OS protection and rules for various applications (mostly non-applicable for us), doesn't have container related rules apart from docker ones mentioned above: https://github.com/wazuh/wazuh-ruleset/tree/master/rules. Some of the rules might be irrelevant since we can't run agent in a container (see below).
Installation
| Falco | Wazuh |
|---|---|
Falco is deployed as a single DaemonSet deployed via Helm. Wazuh requires centralized server with agents on all nodes, basic k8s manifests are provided. Wazuh's agent is responsible for actual data collection and it's important to install it to the monitored OS. For container this will mean installing agent inside container (not clear if even possible). Unfortunately we can't enforce agent installation to all deployed applications and in some cases (scratch containers) it won't be possible at all.
Summary
Overall I think Falco has much better feature set out of the box for our deployment environments. We could make Wazuh work for these environments but it will require a lot of work to make it close feature-wise to Falco.