Falco Rules

Falco rules are pre-defined detections used by Falco to monitor for security threats, abnormal behaviors, and compliance-related events. These rules primarily focus on syscalls and container events.

Key Considerations for Users:

• Customization: Users are encouraged to modify community-contributed rules or create their own custom rules to fit specific needs.
• Plugin Rules: Rules for Falco plugins are not in this repository; they are located in the subfolders of the Falco Plugins repository.
• Maturity Levels: Rules are categorized by maturity. Rules marked as maturity_stable in rules/falco_rules.yaml are included in the standard Falco release package. Other maturity levels (like Sandbox or Incubating) are released separately and require explicit installation and potential customization.
• Compatibility: The Falco Project guarantees compatibility between the most recent rules release and the latest Falco release. It is recommended to use the most recent Falco release to avoid issues.
• Development vs. Stable: The main branch contains the latest development. For production use, it is recommended to use rules from the release branches to avoid incompatibilities caused by changes like new output fields.

Falco rules are managed through a combination of community contributions, official documentation, and lifecycle management tools.

Rule Creation and Contribution

• Writing Rules: Detailed guidance on how to write rules, including references for supported fields in conditions and outputs, is available on the Falco documentation website.
• Contributing: Community members contribute new rules by opening a Pull Request (PR) against the falcosecurity/rules repository.

Rule Lifecycle Management

• falcoctl: Use the falcoctl CLI tool to manage the lifecycle of rules, including installation and updates.

Existing Rule Types

Rules are distributed in various YAML files depending on their source and scope:

• Main Rules (falco_rules.yaml): Based on syscall and container events.
• Application Rules (application_rules.yaml): Contains rules based on network-related syscalls.
• Plugin Rules: Rules based on third-party data sources (e.g., k8s_audit_rules.yaml, github.yaml, okta_rules.yaml, aws_cloudtrail_rules.yaml).

Rule Metadata and Structure

Rules include specific metadata to assist with filtering and prioritization:

• priority: Determines the level at which rules should be loaded and activated.
• tag: Provides additional filter fields and information. Tags may indicate if a rule targets host-level or container-level workloads and can include MITRE ATT&CK phase and TTP (Tactics, Techniques, and Procedures) codes.

Falco rules are categorized by a maturity framework to help users decide which rules to adopt as-is and which require engineering effort to tune. Rules are tagged with specific maturity levels that indicate their robustness, relevance, and stability:

• maturity_stable: Enabled by default. These rules are evaluated by experts, follow best practices, and are highly robust against bypasses. They focus on universal, system-level detections (e.g., generic reverse shells, container escapes) and provide a solid baseline.
• maturity_incubating: Disabled by default. These rules address relevant threats and follow best practices but are often more application-specific. They may require more tuning to fit your specific environment.
• maturity_sandbox: Disabled by default. Experimental rules used for inspiration or to assess potential broader usefulness.
• maturity_deprecated: Disabled by default. Rules deemed less applicable to the community. They are kept as examples but are no longer actively supported or tuned by The Falco Project.

Note: Maturity level does not directly correlate to the amount of noise (false positives) a rule generates; noise levels depend on your specific environment.

When designing your security monitoring strategy, it is important to understand what Falco is optimized for and where its visibility ends.

Primary Use Cases

• Threat Detection: Identifying indicators of compromise and suspicious system activities.
• Compliance: Monitoring for activities required by regulatory frameworks (rules may be tagged with compliance tags).

Capabilities and Limitations

Robust Falco rules move away from simple signature matching and instead focus on behavioral indicators and preconditions.

Characteristics of Robust Rules

• Use of Preconditions: Verifying necessary privileges (e.g., checking if a container has specific capabilities) before triggering an alert. This ensures the TTP (Tactic, Technique, or Procedure) is actually feasible.
• Behavioral Focus: Instead of checking for specific file paths (which can be easily changed by an attacker), focus on high-value kernel signals.

Examples of Robust Patterns

• Container Escapes: Rather than just looking for a specific file, a robust rule might monitor open syscalls for specific filenames (like release_agent) while verifying the container's privileges via preconditions.
• Suspicious Executions: Instead of inspecting all unusual executable paths, focus on identifying executables that were not part of the original container image and were executed from the container's upper overlayfs layer shortly after being dropped.

If you are using the official Falco Helm chart, you can include Incubating and Sandbox rules by configuring falcoctl and the falco.yaml settings.

To install the Helm chart and load all available rule tiers (Stable, Incubating, and Sandbox) with automatic updates enabled, use the following command. This configuration uses falcoctl.config.artifact.install.refs to download the rules at startup, falcoctl.config.artifact.follow.refs to enable automatic updates, and falco.rules_file to tell the Falco engine which files to load.

helm install falco falcosecurity/falco \
  --set "falcoctl.config.artifact.install.refs={falco-rules:2,falco-incubating-rules:2,falco-sandbox-rules:2}" \
  --set "falcoctl.config.artifact.follow.refs={falco-rules:2,falco-incubating-rules:2,falco-sandbox-rules:2}" \
  --set "falco.rules_file={/etc/falco/k8s_audit_rules.yaml,/etc/falco/rules.d,/etc/falco/falco_rules.yaml,/etc/falco/falco-incubating_rules.yaml,/etc/falco/falco-sandbox_rules.yaml}"

Tuning Falco rules helps reduce noise and increase detection precision. Depending on your environment, you can use the following strategies:

Profiling

Profile your environment to identify behaviors that are normal for system-critical applications but would be considered outliers in standard applications. A common technique is implementing an allow list for specific container names or namespaces. This is particularly useful when defining 'crown jewel' applications that require robust, high-fidelity detections.

Behavioral Indicators

Refine detections by incorporating Linux behavioral concepts. Instead of relying on simple signatures, tune rules based on process lineage or specific activity patterns, such as:

• Detecting the presence of a shell or a Java process in a parent process lineage.
• Detecting file manipulations that occur during manual interactive shell access to a container.

Beyond On-Host Tuning

In complex environments, on-host rule tuning may have limitations. For advanced operationalization, consider leveraging data lake systems to perform additional data analysis and contextual correlation of the alerts generated by Falco.