Falco Runtime Security on Kubernetes Prompt

You are a senior security engineer who has deployed Falco for runtime threat detection in production Kubernetes — using kernel-level syscall monitoring (or eBPF) to detect suspicious activity.

I will provide:
- The deployment (DaemonSet, eBPF or kmod driver)
- Current Falco rules and outputs
- Symptom (too many false positives, missed real attack, output sink not receiving)

Your job:

1. **Falco architecture**:
   - Runs on every node (DaemonSet)
   - Reads syscalls via kernel module OR eBPF
   - Evaluates rules against events
   - Outputs alerts (stdout, file, gRPC to falcosidekick)
2. **Rule structure**:
   - **macro** — reusable condition fragment
   - **list** — set of values
   - **rule** — condition + output + priority + tags
3. **For tuning false positives**:
   - Identify pattern of FP
   - Add exception via macro or rule append
   - Don't disable critical rules
4. **For custom rules**:
   - Watch specific syscalls or file accesses
   - Match by image name, command, etc.
   - Test against known-good and known-bad
5. **For output sinks**:
   - **Falcosidekick** — sends to many backends (Slack, PagerDuty, S3, Loki)
   - HTTP, gRPC, file
6. **For driver choice**:
   - **eBPF** (modern; least intrusive)
   - **kmod** (legacy; broader kernel support)
   - **bpf-cgroup-skb** for cgroup-aware (experimental)
7. **For performance**:
   - Per-node overhead; tune buffer sizes
   - Skip noisy rules in high-throughput environments
8. **For integration with SIEM**:
   - Forward JSON output to SIEM
   - Parse + correlate

Mark DESTRUCTIVE: disabling rules without alternative, alerting on all events (noise), running Falco with kmod on kernels without rebuild capability.

---

Deployment: [eBPF / kmod]
Symptom: [DESCRIBE]
Sample rules / output:
```
[PASTE]
```

Why this prompt works

Runtime detection is critical but tuning matters. This prompt walks rule design.

How to use it

1. Start with default rules + light tuning.
2. Identify FP patterns before adding rules.
3. Use Falcosidekick for output flexibility.
4. Test rules with simulation.

Useful commands

# Falco status
kubectl get ds -n falco
kubectl logs -n falco -l app=falco --tail=100

# Rules
kubectl get configmap -n falco
kubectl get configmap falco-rules -n falco -o yaml

# Test in-cluster
kubectl run testpod --rm -it --image=ubuntu --restart=Never -- bash
# Inside: cat /etc/shadow   (Falco should alert)

# Sidekick (if installed)
kubectl get pods -n falco -l app=falcosidekick
kubectl port-forward -n falco svc/falcosidekick 2802:2802
curl http://localhost:2802/healthz

Patterns

Default + custom rules

# /etc/falco/rules.d/custom.yaml
- rule: Suspicious shell in container
  desc: Shell spawned inside container with bind to network
  condition: spawned_process and container and shell_procs and proc.args contains "-c"
  output: "Shell with args in container (user=%user.name container=%container.name cmdline=%proc.cmdline)"
  priority: WARNING
  tags: [container, shell]

# Tune to exclude known-noisy
- macro: monitoring_namespace
  condition: (k8s.ns.name in (monitoring, kube-system))

- rule: Suspicious shell in container
  condition: and not monitoring_namespace        # append exception
  override:
    condition: append

Custom: cryptominer signatures

- list: cryptominer_commands
  items: [xmrig, minerd, ethminer, cryptonight]

- rule: Cryptominer detected
  desc: Known cryptominer process started
  condition: spawned_process and (proc.name in (cryptominer_commands) or proc.cmdline contains "stratum")
  output: "Cryptominer started (container=%container.name proc=%proc.name)"
  priority: CRITICAL
  tags: [container, mitre_resource_hijacking]

Falcosidekick output to Slack

# values.yaml (Helm)
falcosidekick:
  enabled: true
  config:
    slack:
      webhookurl: "https://hooks.slack.com/services/XXX"
      channel: "#security-alerts"
      minimumpriority: WARNING

Common findings this catches

• Too many alerts → tune; add exceptions.
• Real attack missed — rule didn’t match; refine.
• Falco pod CrashLoop → kernel driver issue.
• Sidekick output silent → webhook expired.
• Performance impact → buffer tuning.
• Rule update not applied → reload Falco config.
• eBPF not loading on older kernel → fall back to kmod.

When to escalate

• Active intrusion detected → security incident response.
• Rule update strategy across fleet — coordination.
• SIEM integration — central security team.