Module 06 · Lesson 01

Behavioral Analytics

Detect what a workload does at runtime, and tell normal from suspicious.

Hands-on
Learning objectives
  • Establish what normal looks like for a workload.
  • Spot a process that does not belong and stop it precisely.
  • Explain why manual inspection does not scale.
Falco Runtime

Detection needs a baseline

"Suspicious" only means anything relative to expected behaviour. A web server container should run one process tree belonging to the web server. A shell in it, an outbound connection to an address nothing should be calling, or a compiler running are all anomalies precisely because the normal set is small and knowable.

Containers make this far easier than traditional hosts: a single-purpose container has a tiny expected behaviour set, which is what makes runtime detection practical here at all.

terminal
$kubectl exec deploy/webapp -- sh -c "ps -ef 2>/dev/null || ps"

Stop the anomaly, not the workload

terminal
$kubectl exec deploy/webapp -- pkill -f "while true"
$kubectl exec deploy/webapp -- sh -c "ps -ef 2>/dev/null || ps"

Killing the pod would also work and would destroy the evidence along with any chance of understanding how the process got there. Terminating precisely keeps the service up and the rest of the container intact for investigation.

Nobody finds this by running ps

Reading process lists by hand, once, after being told to look, is not detection. Falco watches every syscall a container makes through eBPF, compares it against rules for known-suspicious patterns such as spawning a shell or writing to a sensitive path, and alerts within seconds. The lab teaches you what the anomaly looks like; the tool is what finds it at three in the morning.

Why is behavioural detection more tractable for containers than for general-purpose servers?

You find an unexpected process in a running container. Why not just delete the pod?

What does Falco use to observe container behaviour?

Recap

Detection needs a baseline, and containers have small ones. Terminate the anomaly precisely rather than deleting the pod, so you keep both the service and the evidence. Automate it with a syscall-level tool. Next: threats to the infrastructure underneath.