# Falco Runtime Detection Practical Guide

> **Intro:** Falco remains one of the most important open-source runtime detection tools for cloud-native environments. The core idea from the Falco book still holds: detect suspicious behavior from runtime events, enrich them with container and Kubernetes context, and route the signal to people or systems that can act.

## What this page covers

* what Falco is good at and what it is not good at;
* how older Falco examples map to the current project;
* practical installation, rule, output, and tuning examples;
* where Falco fits next to SIEM, CloudTrail, audit logs, and incident response.

## What Falco is good at

Falco is strong when you need:

* near-real-time detection of unexpected runtime behavior;
* signals from syscalls, container context, Kubernetes metadata, and cloud plugins;
* low-latency rule evaluation close to the workload;
* event forwarding to alerting, observability, and response systems.

## What Falco is not

Falco is not:

* a full vulnerability scanner;
* a replacement for cloud audit logs;
* a substitute for good RBAC and Pod hardening;
* magic without rule tuning and ownership.

## Legacy versus current Falco reality

| Topic                  | Older book-era example              | Current 2026 note                                                              |
| ---------------------- | ----------------------------------- | ------------------------------------------------------------------------------ |
| Falco version          | examples around 0.32                | current docs surface 0.43 line and newer packaging                             |
| Driver model           | kernel module and legacy eBPF focus | modern eBPF is the default direction; legacy eBPF is deprecated                |
| Local rules management | hand-maintained rule files only     | falcoctl and chart-driven rules management are now part of the normal workflow |
| Kubernetes deployment  | Helm was already valid              | Helm remains the recommended path for most clusters                            |
| Output routing         | stdout/syslog/program output        | Falcosidekick, exporters, HTTP, SIEM, and automation patterns are common       |

## Recommended deployment choices

### For Kubernetes

Use Helm unless you have a strong reason not to.

```bash
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set tty=true
```

### For host-based testing or lab work

Use packages or a local container, depending on how close you want the lab to production.

```bash
docker run --rm -it --privileged falcosecurity/falco:latest /usr/bin/falco --version
```

## Old snippet versus current snippet

### Older style from book-era examples

```bash
curl -L -O https://download.falco.org/packages/bin/x86_64/falco-0.32.0-x86_64.tar.gz
tar -xvf falco-0.32.0-x86_64.tar.gz
sudo cp -R falco-0.32.0-x86_64/* /
sudo falco-driver-loader
sudo falco
```

### Current-friendly approach

* prefer package-manager or Helm installation;
* prefer modern eBPF where supported;
* use falcoctl-managed rule lifecycle where appropriate;
* keep custom rules isolated from upstream defaults.

## Practical rule example

```yaml
- rule: Terminal shell in container
  desc: Detect an interactive shell started in a container
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh, ash) and
    not proc.pname in (pause)
  output: >
    Terminal shell in container
    (user=%user.name container=%container.name image=%container.image.repository
    pod=%k8s.pod.name namespace=%k8s.ns.name cmd=%proc.cmdline)
  priority: WARNING
  tags: [container, mitre_execution, tty]
```

## Practical tuning notes

### Reduce noise by carving out expected activity

Use lists and macros for:

* approved admin tools;
* expected package managers in build namespaces;
* known maintenance jobs;
* platform namespaces you do not want to alert on the same way as product namespaces.

### Use severity intentionally

* `NOTICE` or `INFO` for learning mode or new rules;
* `WARNING` for suspicious but plausible admin actions;
* `ERROR` or `CRITICAL` for behavior that should never happen in production namespaces.

### Keep outputs investigation-friendly

Include:

* process name and command line;
* container image and container name;
* pod name and namespace;
* user and parent process where available.

## Practical snippet — custom rules mounted through Helm values

```yaml
customRules:
  product-security-rules.yaml: |-
    - macro: product_namespaces
      condition: k8s.ns.name in (billing, identity, checkout)

    - rule: Write below /etc in product namespace
      desc: Detect writes below /etc for application containers
      condition: >
        product_namespaces and container and evt.type in (open, openat, openat2)
        and fd.name startswith /etc and evt.is_open_write=true
      output: >
        Unexpected write below /etc
        (namespace=%k8s.ns.name pod=%k8s.pod.name container=%container.name file=%fd.name proc=%proc.cmdline)
      priority: ERROR
      tags: [filesystem, container, config-drift]
```

## Practical snippet — Falcosidekick event routing

```yaml
falcosidekick:
  enabled: true
  config:
    webhook:
      address: http://event-router.security.svc.cluster.local/falco
```

This keeps Falco focused on detection while letting another service handle fan-out, chat, webhooks, case creation, or response hooks.

## Practical CloudTrail plugin note

Falco is not only for syscalls. For AWS-oriented use cases, the CloudTrail plugin path is especially useful for:

* console login without MFA;
* unusual IAM actions;
* sensitive cloud control-plane changes;
* tying runtime and cloud-control events together.

## Where Falco fits in the bigger stack

| Need                         | Better primary source            | Where Falco helps                                   |
| ---------------------------- | -------------------------------- | --------------------------------------------------- |
| cloud control plane changes  | CloudTrail / provider audit logs | correlate runtime and cloud actions                 |
| Kubernetes object changes    | Kubernetes audit logs            | detect runtime consequences or suspicious execution |
| workload execution anomalies | Falco                            | primary runtime signal                              |
| long-term case search        | SIEM / data lake                 | consume Falco events as one input                   |
| automated response           | SOAR or custom controller        | react to selected Falco events                      |

## Practical response patterns

Falco should usually trigger one of these:

* enrich and route to SIEM;
* create an alert in chat/on-call tooling;
* snapshot runtime context for investigation;
* optionally trigger a narrow automated action for high-confidence rules.

Do **not** start by auto-killing everything. Build confidence first.

## Common mistakes

* enabling many default rules without tuning ownership or namespace context;
* forgetting to ship events anywhere durable;
* expecting Falco to replace posture management or vulnerability management;
* writing highly specific rules that nobody maintains;
* treating all shell events as equally urgent.

## Related pages

* [Logging and Telemetry Strategy](/attack-paths-testing-detection-and-hardening/index/logging-and-telemetry-strategy.md)
* [High-Signal Detection Patterns and SIEM Examples](/attack-paths-testing-detection-and-hardening/index/high-signal-detection-patterns-and-siem-examples.md)
* [🧭 Runtime Investigation Playbook for Kubernetes and Containers](/cloud-kubernetes-and-infrastructure-security/index-1/runtime-investigation-playbook.md)
* [☸️ Kubernetes Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-hardening.md)

\---*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*

## v3.2 companion page

For a broader runtime strategy that places Falco next to other runtime and control-plane signals, see [🛎️ Runtime Detection Stack — Falco, Tetragon, and Cloud Signals](/attack-paths-testing-detection-and-hardening/index/runtime-detection-stack-falco-tetragon-and-cloud-signals.md).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/attack-paths-testing-detection-and-hardening/index/falco-runtime-detection-practical-guide.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.