> For the complete documentation index, see [llms.txt](https://0xzoro.gitbook.io/0xzoro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xzoro.gitbook.io/0xzoro/soc-operations/detection-engineering/00-notes-skill.md). # 00 notes skill ## Detection Engineering Note-Taking Standard *A note-taking standard tuned for the detection engineering discipline.* *** ### Purpose These notes are **not summaries**. They are a **technical knowledge base** that should eventually replace the need to go back to the original source — a course video, a slide, a vendor doc, a threat report, or a conversation where a concept was worked through. The objective is to understand each topic deeply enough to: * Explain it to someone else, from scratch * Build a detection for it * Hunt for it when no detection exists yet * Defend against it in a real environment * Apply it inside a real detection-as-code pipeline * Answer it correctly in an interview or certification exam Every topic should read like a chapter from a detection engineering textbook — not classroom notes, and not a chat transcript. *** ## Writing Philosophy The notes should answer: 1. What is it? 2. Why does it exist? 3. How does it work? 4. Why is it implemented / done this way? 5. How do attackers abuse it, or how does it fail in practice? 6. How do you engineer a detection for it? 7. What are the limitations? 8. What matters for long-term retention and interviews? 9. How is it actually used in the real world? The goal is understanding, not memorization. *** ## Writing Style * Explain before listing. * Teach instead of documenting. * Never copy the source verbatim — including chat transcripts. Rewrite in a structured voice. * Preserve technical terminology. * Expand concepts when necessary, beyond what the source covered. * Cut repetition ruthlessly. * Connect ideas — every topic should link back to the wider lifecycle. * Every paragraph should answer "why?" The reader should never ask: > "Okay... but why?" ### House Style These notes follow a consistent voice. Every topic should read the same way: * **Question-headings and question-openers.** Prefer a Socratic frame — *"Why five inputs and not one?"*, *"What is a CI/CD pipeline?"* — over flat statement headings. A question pulls the reader forward into the answer. * **"Think of it as…" analogies.** Bridge an unfamiliar idea to a known one. *"The queries are the cargo; the pipeline is the skill."* One good analogy is worth a paragraph of definition. * **Explicit `> **Mindset:**` callouts.** The single most important idea in a section gets pulled out of the prose into a blockquote labelled **Mindset** (or **Reconciling…**, **The hinge…**, etc.). This is where the *thinking*, not the facts, is captured — it's the part worth re-reading six months later. * **Understand the architecture, not the brand names.** Whenever a slide lists vendors/tools, the note's job is to explain the *category and its role*, and to say plainly what is *not* worth memorising. Facts age; structure doesn't. * **Bold on first use.** The first appearance of a key term is **bolded**, then used plainly after. * **Connect every topic back to the lifecycle.** End with *Related Topics* cross-links so the notebook is a graph, not a stack of pages. The through-line: capture the *reasoning*, not just the content. A reader should finish a section able to reconstruct *why*, not just recite *what*. *** ## Level of Detail Assume the reader will **never go back to the original video, slide, or conversation**. The notes must be detailed enough to become the primary reference. Do not shorten explanations to save space. When in doubt: prefer understanding over brevity. *** ## Structure Every major topic follows this structure **whenever applicable**. Sections that would only restate something already covered are omitted — a section that has to be contorted to fit is a section that doesn't belong on that topic. ``` # Topic --- ## Definition ## Why It Exists ## How It Works ## Workflow ## Components ## Rule Logic ## Example ## Attacker Tradecraft <- technique topics ## Detection <- technique topics ## Common Failure Modes <- process topics ## Process Health & Metrics <- process topics ## Limitations & Assumptions ## Evasion & Bypass <- technique topics ## MITRE ATT&CK ## Validation & Testing <- technique topics ## Real-World Notes ## Key Takeaways (Quick Reference) ## External Resources ## Lab Ideas ## Related Topics ``` #### Two Kinds of Topics Detection engineering notes cover two different kinds of material, and several sections apply to only one of them. **Technique / technology topics** — a specific attacker behaviour, a log source, an Elastic integration, a security control. These get the full technical treatment: *Attacker Tradecraft*, *Detection*, *Evasion & Bypass*, *Rule Logic*, and *Validation & Testing* are all central. **Process / methodology topics** — the detection engineering lifecycle, unit testing methodology, tuning philosophy, detection-as-code practice, prioritisation. For these, the technique-only sections are **dropped entirely** rather than reframed, and replaced by two process-native sections: * *Common Failure Modes* — what actually goes wrong when the process is skipped or done badly * *Process Health & Metrics* — how you know the process itself is working #### Why some common sections were cut A general-purpose security-technology note template usually carries a few sections that turn out redundant for detection engineering specifically. Three were removed or repurposed: | Common section | Disposition | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Defender Perspective** | **Cut.** In general security study you cover technologies both sides interact with, so splitting the lenses is informative. In detection engineering the defender lens is the entire frame — a Defender Perspective section on every topic is a no-op. Its content belongs in *Detection*, *Common Failure Modes*, and *Real-World Notes*. | | **Purple Team Notes** | **Renamed to Validation & Testing**, and scoped to technique topics only — where it carries concrete reproduction steps instead of restating testing philosophy that the lifecycle topic already covers. | | **Security Considerations** | **Renamed to Limitations & Assumptions**, and pointed at the detection rather than the technology: what does this detection assume, and where does it fail silently? | The general rule: **if a section restates something already covered elsewhere on the same page, cut it.** Duplication in a knowledge base is worse than omission, because the reader can't tell which copy is authoritative. *** ### Definition Explain what the thing is. Avoid dictionary definitions. Explain it the way a senior detection engineer would teach a junior analyst in their first week — plain language first, precise terminology second. *** ### Why It Exists Explain what problem it solves, what existed before it, and why the industry, vendors, attackers, or defenders converged on this approach. *** ### How It Works The most important section. Explain the mechanism end to end — internal architecture, protocol flow, authentication flow, OS internals, network flow, execution flow, or the operational flow of a process. Do not skip intermediate steps; the gaps are where understanding breaks down later. *** ### Workflow A simplified ASCII flow. Example: ``` Behavior ↓ Telemetry Generated ↓ Log Source ↓ Detection Logic ↓ Alert ``` Use diagrams when they beat prose, not as decoration. *** ### Components Explain every important component, stage, or actor individually. For each: what is it, why does it exist, how does it interact with the rest? *** ### Rule Logic For Sigma, KQL, EQL, TOML rules, YARA, or any detection logic: explain every condition separately. Never just paste the rule. Explain what behaviour each condition isolates and why *that* condition rather than a broader or narrower one. *** ### Example A practical, worked example. Prefer realistic enterprise scenarios over toy ones. *** ### Attacker Tradecraft *(Technique topics only.)* What the adversary actually does at the keyboard — the commands, the tooling, the order of operations, and how real-world implementations differ. This is the section that most determines detection quality, because you write logic against **behaviour**, not against a description of behaviour. Cover why attackers use the technique, which actors are documented using it, and where implementations vary — that variation decides whether your detection generalises or only catches one tool. *** ### Detection *(Technique topics only.)* Whenever detection is applicable, include: **Log Source / Telemetry** — which sources see this, and what visibility they actually provide. **Fields / Event IDs** — never dump identifiers without explaining what they mean and why they matter here. **Detection Logic** — describe *what suspicious behaviour should be hunted*, not a list of logs. This is a behavioural question, not a field inventory. **Network Detection** — when applicable: Zeek, Suricata, firewall, proxy, DNS. **Detection Engineering Notes** — strategy, known false positives, known false negatives, tuning considerations. *** ### Common Failure Modes *(Process topics only.)* What actually goes wrong when this process is skipped or done badly — and, critically, why each failure is invisible from the inside. The most dangerous process failures are the ones that produce a green dashboard. *** ### Process Health & Metrics *(Process topics only.)* How you know the process itself is working. Per-artifact checks (can you trace this detection's input, test, review, and documentation?) and program-level metrics (coverage, quality, volume, MTTD/MTTR, rule health). *** ### Limitations & Assumptions What the detection or process quietly assumes in order to work, and where it fails silently. Cover assumptions about telemetry availability, environment, volume, and organisational maturity; known blind spots; and conditions under which it degrades without signalling that it has degraded. Silent failure is the dangerous kind — a detection that breaks loudly gets fixed. *** ### Evasion & Bypass *(Technique topics only.)* How an attacker who knows this detection exists would get around it — not just bypassing the underlying control, but bypassing **your logic specifically**. Cover the evasion method, why it defeats this detection, what it costs the attacker, and whether a broader or behaviour-based rule would survive it. Writing this section honestly is the fastest way to discover your detection is narrower than you thought. *** ### MITRE ATT\&CK Include Tactic, Technique, and Sub-technique — and explain *why* it maps there. Never just list IDs. *** ### Validation & Testing *(Technique topics only.)* Concrete, reproducible proof that the detection works — not a restatement of testing philosophy, which belongs in the lifecycle topic. This section holds: * The **specific test** that reproduces the behaviour — Atomic Red Team test ID, the actual command, or manual steps. * The **expected telemetry** — which index, which fields, what values should appear. * The **negative test** — a benign look-alike that must *not* trigger the rule. * Where relevant, how the test is automated in CI. If this section can't be filled with something a reader could run themselves, the detection hasn't been validated yet. *** ### Real-World Notes One of the most important sections. Incident response observations, enterprise deployment considerations, lessons learned, relevant threat reports, practical advice. This section goes beyond the source material — it's where outside research and hands-on experience get folded in. *** ### Key Takeaways (Quick Reference) The facts that are easy to forget, frequently confused concepts, small implementation details, and anything worth a fast review pass later. *** ### External Resources Elastic docs, MITRE ATT\&CK, SigmaHQ, Microsoft Learn, SANS, SpecterOps, Red Canary, Huntress, RFCs, tool documentation. Never add a link without explaining why it's useful. *** ### Lab Ideas How to reproduce the concept hands-on — course lab, home lab, detection lab, purple team exercise. The reader should be able to rebuild it, not just read about it. *** ### Related Topics Cross-reference previously covered concepts to build a connected knowledge graph: ``` Unit Testing → Alert Development → Documentation TOML rules → Detection-as-Code → CI validation Atomic Red Team → Validation & Testing → Rule Health ``` *** ## Diagrams Prefer ASCII workflows over paragraphs when they improve understanding. Use them only when they add clarity. *** ## Code Never explain code or rule logic as one block. Break it into logical sections and explain what each part does, why it exists, and what happens if it's removed. Teach the reasoning, not the syntax. *** ## Detection Engineering Mindset Do not only explain what works. Explain: * Why it works * Why it fails * False positives * False negatives / coverage gaps * Detection quality (signal vs. noise) The thought process behind a detection is more valuable than the rule itself. This applies to every topic, not just detection-specific ones. *** ## Real Knowledge > Source Knowledge If the source material is incomplete, expand it with industry best practice and hands-on experience — but clearly distinguish: * Source content (the course, or a specific conversation) * Additional explanation (synthesis) * Real-world experience (labs, incidents, the job) Never contradict the source without explicitly saying so and explaining why. *** ## Writing Quality Checklist Before finishing a topic: * Did I explain WHY? * Did I explain HOW? * Would someone understand this six months later with zero other context? * Could someone build a lab from these notes alone? * Could someone explain this in an interview? * **Does every section earn its place, or is one of them restating another?** If any answer is "No," the notes are incomplete. *** ## Ultimate Goal A complete **personal Detection Engineering Field Guide** that is easier to read, more practical, and better connected than the original source — suitable for real blue team work, and for interview or certification review. These are a long-term knowledge base, not temporary study notes.