<p>There was a question I saw the other day asking if detection engineers (DE), the folks who author alerts, should also be primarily responsible for their triage. There was large support for having the detection authors also play a large role in initial triage, often as part of the oncall. I largely disagree with this stance and am going to use some time Friday to quickly argue why you’re likely compensating for technology and process failures if you do that.</p>

<p>This is Part 1 of the container escape telemetry series. The <a href="../intro">series overview</a> has the project goals, key findings, and reading guide. If you’re already comfortable with namespaces, cgroups, capabilities, and how eBPF ring buffers work, skip ahead to <a href="../methodology">Part 2: Methodology and Tool Architecture</a>.</p>

<p>This is Part 2 of the container escape telemetry series (<a href="../intro">overview</a>). <a href="../isolation">Part 1</a> covered the isolation primitives and eBPF observability model. This post covers the lab architecture, the three tools under test, the 15 escape scenarios, and the detection coverage matrix. If you want to skip straight to what the telemetry actually looks like, jump to <a href="../deepdives">Part 3: Per-Scenario Deep Dives</a>.</p>

<p>This is Part 3 of the container escape telemetry series (<a href="../intro">overview</a>). <a href="../isolation">Part 1</a> covered isolation primitives and the eBPF observability model. <a href="../methodology">Part 2</a> covered the lab, the tools, and the detection coverage matrix. This post is the meat: per-scenario telemetry breakdowns showing what each tool actually captured, where the qualitative differences behind the checkmarks become concrete.</p>

<p>This is Part 4 of the container escape telemetry series (<a href="../intro">overview</a>). <a href="../isolation">Part 1</a> covered isolation primitives and the eBPF observability model. <a href="../methodology">Part 2</a> covered the lab and detection coverage matrix. <a href="../deepdives">Part 3</a> walked through per-scenario telemetry. This post is about the operational questions: how much data do these tools produce, what percentage of it matters, and which tool should you actually…

<p>This is Part 5 of the container escape telemetry series (<a href="../intro">overview</a>). <a href="../isolation">Part 1</a> covered isolation primitives. <a href="../methodology">Part 2</a> covered the lab and tools. <a href="../deepdives">Part 3</a> was the per-scenario data. <a href="../production">Part 4</a> covered volume, signal-to-noise, and tool selection. This post is for the practitioner who just installed one of these tools and wants to know what to do next.</p>

<p>This is Part 6 of the container escape telemetry series (<a href="../intro">overview</a>). Parts <a href="../isolation">1</a>-<a href="../tuning">5</a> covered isolation primitives, methodology, per-scenario telemetry, production considerations, and tuning. This post takes the lab findings and pressure-tests them against a real threat actor operating in the wild right now.</p>

<p>As a detection engineer, container escapes have always fascinated me. Detections focused on control bypasses can be both extremely difficult to make and extremely valuable when they fire. The challenge is that most discussions about container runtime security focus on <em>whether</em> a tool detected an escape – a binary yes/no that doesn’t tell you much about the underlying telemetry that makes detection possible in the first place.</p>

<p>As you may know by now if you’ve read a few of my blog articles, I’m a big fan of decomposing ideas in threat detection into various frameworks. This latest blog post will touch on another area that I feel strongly about - specifically, that detection engineers need to take a step back and realize that they’re part of a larger “security monitoring” capability which consists of related but distinct pillars. We’ll explore these interrelated pillars of…

<p>In the ever-evolving landscape of cybersecurity, the methodologies and tools we rely on are continually advancing. One of the latest trends is Detection as Code (DaC), which promises to revolutionize threat detection by integrating software engineering practices into security operations. Having worked in an organization that practices DaC for several years, I’ve come to realize that it’s not simply a matter of whether or not to adopt DaC.</p>