Lesson 0020 · 35 minutes · Monitoring, Logging, and Runtime Security
Detect an interactive shell in a production container
Runtime detection turns suspicious behavior into an actionable alert. A shell inside a workload is not automatically malicious, but in a defined production scope it deserves timely investigation—especially when it touches mounted credentials.
Timed task: 25 minutes
Review lab/lesson-20-runtime-event.json. Create lab/lesson-20-falco-rule.yaml from scratch containing one custom Falco rule.
The rule must:
- Use source
syscall. - Match a process named
shorbashonly when it runs in a container in Kubernetes namespacepayments. - Use priority
WARNING. - Include the process command line, Kubernetes namespace, Pod name, and container name in its output.
- Include tags
containerandmitre_execution.
Write the condition so it does not match a host-level shell or a shell in another namespace. Do not suppress the alert because the process is running as root; identity is evidence for triage, not a reason to skip detection.
Evidence and response
In lab/lesson-20-answer.md, give:
- The exact suspicious command from the supplied event.
- The affected namespace, Pod, and container.
- Two immediate containment actions in priority order.
This environment does not run Falco, so validate the YAML structure in your editor. On a Falco-equipped Linux node, use falco --validate /path/to/rule.yaml before reloading the rules.
Retrieval check
Question
Which condition component prevents a rule from alerting on every shell launched directly on a Kubernetes node?
Documentation target
Use the official Falco rules reference to confirm condition syntax and available output fields.
What to send me
Paste the rule and your three incident answers. I’ll assess false-positive scope, alert context, and containment quality.