Completed upto lesson 28

lessons/0020-runtime-shell-detection.html

@@ -0,0 +1 @@
+<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>CKS lesson 20: Runtime shell detection</title><link rel="stylesheet" href="../assets/course.css"></head><body><main><p class="eyebrow">Lesson 0020 · 35 minutes · Monitoring, Logging, and Runtime Security</p><h1>Detect an interactive shell in a production container</h1><p class="lede">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.</p><div class="callout"><strong>Incident reflex:</strong> make detection rules precise enough to reduce noise, but include enough event context in the alert that responders can identify the workload without re-running the search.</div><h2>Timed task: 25 minutes</h2><p>Review <code>lab/lesson-20-runtime-event.json</code>. Create <code>lab/lesson-20-falco-rule.yaml</code> from scratch containing one custom Falco rule.</p><p>The rule must:</p><ul><li>Use source <code>syscall</code>.</li><li>Match a process named <code>sh</code> or <code>bash</code> only when it runs in a container in Kubernetes namespace <code>payments</code>.</li><li>Use priority <code>WARNING</code>.</li><li>Include the process command line, Kubernetes namespace, Pod name, and container name in its output.</li><li>Include tags <code>container</code> and <code>mitre_execution</code>.</li></ul><p>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.</p><h2>Evidence and response</h2><p>In <code>lab/lesson-20-answer.md</code>, give:</p><ol><li>The exact suspicious command from the supplied event.</li><li>The affected namespace, Pod, and container.</li><li>Two immediate containment actions in priority order.</li></ol><p>This environment does not run Falco, so validate the YAML structure in your editor. On a Falco-equipped Linux node, use <code>falco --validate /path/to/rule.yaml</code> before reloading the rules.</p><h2>Retrieval check</h2><div class="quiz"><h3>Question</h3><p>Which condition component prevents a rule from alerting on every shell launched directly on a Kubernetes node?</p><label><input type="radio" name="q" value="container">The <code>container</code> condition.</label><label><input type="radio" name="q" value="process">The <code>proc.name</code> condition.</label><label><input type="radio" name="q" value="priority">The <code>priority</code> field.</label><button onclick="check()">Check answer</button><p id="feedback" class="feedback" aria-live="polite"></p></div><h2>Documentation target</h2><p>Use the official <a href="https://falco.org/docs/reference/rules/">Falco rules reference</a> to confirm condition syntax and available output fields.</p><h2>What to send me</h2><p>Paste the rule and your three incident answers. I’ll assess false-positive scope, alert context, and containment quality.</p><footer>Previous: <a href="0019-platform-binary-verification.html">Platform binary verification</a> · CKS domain: Monitoring, Logging, and Runtime Security</footer></main><script>function check(){const c=document.querySelector('input[name=q]:checked'),f=document.getElementById('feedback');if(!c){f.textContent='Choose an answer.';f.className='feedback bad';return;}if(c.value==='container'){f.textContent='Correct. container limits the rule to containerized processes instead of host-level activity.';f.className='feedback good';}else{f.textContent='Not quite. proc.name matches host processes too; container scopes the event to a container.';f.className='feedback bad';}}</script></body></html>