Description

A focused course, tailored for you

The Security Engineer's Detection Engineering Playbook

Name: The Security Engineer's Detection Engineering Playbook
Price: 199 USD
Availability: InStock

Turn a noisy SIEM and a backlog of half-tuned detections into a measured, peer-reviewed detection program with documented coverage.

You inherited a detection stack where the top 20 rules carry the rotation and the next 200 mostly auto-close. Coverage is asserted, not measured. Every red-team finding turns into a new rule nobody owns six months later.

$199 one-time

Tailored to your situation. Access within 24 hours. 30-day money-back.

Includes a hand-built implementation playbook delivered alongside course access, generated for your specific situation.

Why this course

Security engineers running detection in a large product environment carry a specific kind of debt. The SIEM has rules that fired three years ago for a threat that no longer applies, rules added after a tabletop that were never tuned, rules with no documented owner, and rules that overlap so heavily nobody can say which one actually catches a given technique. The coverage matrix in the wiki cites ATT&CK techniques the team hasn't tested against in months. The on-call rotation knows which rules to trust and which to mute, but that knowledge lives in private Slack threads. Leadership asks for a coverage number and gets a percentage that nobody on the team would defend in a deposition. The work to fix this is not glamorous. It is detection-as-code review discipline, false-positive budget tracking per rule, deprecation criteria, and a peer-review workflow that makes a new rule cheaper to add than to skip. The course is the operating manual for that work.

What you walk away with

Run a measured, documented detection program where every active rule has an owner, a coverage statement, and a false-positive budget.
Map your detection stack to ATT&CK in a way that a sceptical red team will accept, with gaps explicit and prioritised.
Operate a detection-as-code workflow with peer review, version control, and a deprecation log that stops dead rules from accumulating.
Cut alert volume on the worst-offender rules by 60 to 80 percent without losing coverage on the threats those rules were written for.
Hand the on-call rotation a runbook that turns repeat incidents from a meeting into a rule update.

The 12 modules

Module 1. Auditing the rule estate you actually have

Pull the full rule inventory from the SIEM and the EDR, tag each rule with last-fired date, owner of record, fire volume over 90 days, and the percentage of fires that auto-closed. Run the same audit against the documented coverage matrix and find the rules nobody can map to a documented threat. The output is a spreadsheet that tells you which rules earn their keep and which are wallpaper.

Module 2. Detection-as-code repo layout that survives a team rotation

Set up a git repo for detection content with a directory structure that maps cleanly to the SIEM, sigma source files where the platform supports them, CI checks that lint syntax, a test harness that runs sample log lines through each rule, and a pull-request template that forces the author to declare threat coverage and expected FP rate. The repo becomes the single source of truth and the SIEM becomes a deployment target.

Module 3. ATT&CK coverage mapping a red team will accept

Map each active rule to specific ATT&CK techniques and sub-techniques with the evidence that justifies the mapping. Differentiate between detections that fire on the technique versus detections that fire on a precursor or a downstream artefact. Produce a coverage heat map that explicitly marks gaps, partial coverage, and overlapping coverage, and review it against the last red-team or purple-team report to find the rules that claim coverage and lost to a real test.

Module 4. False-positive budgets and the rule review form

Set a false-positive budget per rule expressed as fires per week or per analyst-hour. Build the rule review form that every new and every modified rule has to pass: threat statement, query logic, FP budget, suppression strategy, and rollback plan. Run a quarterly review of every rule against its budget and either tune, demote to log-only, or deprecate. The form is the brake that stops the rule estate growing faster than the team.

Module 5. Sigma-to-platform translation and the multi-SIEM problem

When the organisation runs more than one detection platform, write rules in a portable format and translate to platform-specific query languages with tested converters. Handle the cases the converters do not handle: field name differences, parsing differences, retention differences, and confidence scoring. Worked examples for Splunk SPL, Elastic ESQL, and a generic SQL-style SIEM, with the gotchas that show up in production but not in a vendor demo.

Module 6. Tuning the worst-offender rules without losing coverage

Identify the five to ten rules generating the majority of low-value alerts. For each one, decompose the rule into the threat it covers, the false-positive sources, and the suppression options. Rewrite or split the rule, deploy in shadow mode, measure the new FP rate, then promote. Document the tuning rationale so the next engineer who looks at the rule six months from now knows why it is shaped the way it is.

Module 7. Cloud-native log pipelines and the cost of detection

Detection in a cloud-native environment is constrained by ingest cost. Decide which log sources earn full ingest, which earn sampled ingest, which earn summary metrics only, and which are queried on demand. Build the architecture diagram and the cost model. Cover the trade-offs between centralised SIEM and edge detection in EDR or cloud-native tools, with the data points that make the call defensible to finance and to the SOC manager.

Module 8. Peer review workflow and the new-hire on-ramp

Stand up a peer-review rotation where every new detection is reviewed by another engineer before merge. Define what the reviewer is checking for, how disagreements are escalated, and what the reviewer does when the author is more senior. Add the new-hire on-ramp: the first three weeks for a new detection engineer, the rules they ship in week four, the safety net that catches their early mistakes before they reach production.

Module 9. On-call runbook and the repeat-incident loop

Build the on-call runbook so that every page from a detection has a documented expected outcome, a triage path, and a place to record whether the page was useful. Tie the on-call feedback loop back to the rule review process: an alert that was triaged and closed as expected becomes a tuning input, a repeat incident becomes a rule update, a missed detection becomes a coverage gap entered into the heat map from Module 3.

Module 10. Red team and purple team integration

Run a structured purple-team exercise against your own rule estate. The red side executes a documented technique. The blue side reports what fired, what did not fire, and what fired late. Update the coverage matrix and the rule backlog from the result. Handle the politics of an exercise where the red team is internal versus contracted, and the data hygiene that keeps the exercise honest.

Module 11. Detection metrics that hold up to a board review

Define and instrument the metrics that describe the health of the detection program: rule count by status, coverage by ATT&CK technique, false-positive rate distribution, time-to-tune for new rules, on-call alert volume, and the percentage of incidents that started from a detection versus a report. Build the dashboard that the security leader takes into a board meeting and the supporting evidence pack that backs every number on it.

Module 12. Quarterly program review and the deprecation log

Run the quarterly review of the detection program as a structured exercise. Audit the rule estate, the coverage matrix, the false-positive budgets, and the on-call feedback. Deprecate rules that no longer earn their place and log the rationale so the same rule does not get rebuilt next year. Set the priorities for the next quarter, the staffing needed, and the explicit list of threats the program will not cover and why.

How this addresses your situation

Specific modules that map to what you said you are dealing with.

Module 1 and Module 4 are where you start: an honest audit of the rule estate plus the review form that stops the next round of debt accumulating.

Modules 2, 5, and 8 set up the detection-as-code workflow, the multi-platform translation, and the peer-review rotation that make the team scale.

Modules 3, 6, 7, and 11 are the measurement and tuning loop: coverage, worst-offender rewrites, pipeline cost, and the metrics that survive scrutiny.

Modules 9, 10, and 12 close the loop: on-call to rule update, purple team to coverage, and the quarterly review that resets the priorities.

What you get with this course

Twelve written modules in the Art of Service learning environment.
Rule inventory spreadsheet template with the columns the audit in Module 1 needs.
Detection-as-code repo skeleton with CI lint, sample tests, and pull-request template.
ATT&CK coverage heat map template, populated with worked examples.
Rule review form, false-positive budget worksheet, and deprecation log template.
Sigma-to-platform translation cheat sheet for Splunk, Elastic, and a generic SQL-style SIEM.
On-call runbook template tied to the rule review process.
Detection metrics dashboard mock-up with the supporting query patterns.
Hand-built implementation playbook scoped to your stack and team size, delivered alongside course access.

What you will have in hand by Day 1, Week 1, Month 1

Account in the Art of Service learning environment provisioned within 24 hours of purchase.

Hand-built implementation playbook delivered alongside course access, scoped to your SIEM, EDR, and team size.

Two follow-up check-ins by email at week 2 and week 6 to surface blockers on the audit and the peer-review workflow.

Before and after

Before

The rule estate is a pile. Top 20 rules carry the rotation. The rest auto-close. Coverage is a percentage nobody on the team would defend. New rules get added after every incident and never deprecated. The on-call rotation knows which rules to trust but that knowledge lives in private Slack threads. Leadership asks for a number and gets one that nobody really believes.

After

Every active rule has an owner, a threat statement, a false-positive budget, and a documented review date. The coverage heat map matches what a red team finds when they test. The peer-review workflow makes a new rule cheaper to add than to skip. On-call pages drive rule updates instead of meetings. The dashboard the security leader takes to a board review is one the team built and stands behind.

What happens if you do not address this

The rule estate keeps growing faster than the team can review it. Real attacks land on techniques the coverage matrix claims to cover. The on-call rotation burns out on auto-closing low-value alerts. The next red-team report or board-level review forces the program rebuild on a deadline rather than on a plan, and the rebuild gets handed to a vendor who does not know your stack.

Who it is for

Security engineers responsible for detection content in a high-volume, multi-platform environment. Typical context: a SIEM with hundreds to thousands of rules, an EDR platform, a cloud-native logging pipeline, an on-call rotation that has run for years, and a coverage story that needs to hold up to a board-level security review.

Who this is NOT for. SOC analysts who only triage alerts and do not own rule logic. CISOs looking for a strategy deck. Vendors building a detection product. People who want a generic intro to threat detection.

How it arrives

Text-based course in the Art of Service learning environment, plus downloadable templates and worked examples for every module, plus the hand-built implementation playbook delivered alongside course access.

Time investment. Roughly 12 to 16 hours of reading and template work across the twelve modules. The rule estate audit in Module 1 takes a working day for a mid-sized team. The detection-as-code repo set up in Module 2 takes one to two days including CI. Most engineers run the course over four to six weeks alongside normal duties.

Why $199 is the right number

Free blog posts cover detection-as-code at a conceptual level but not the rule review form, the false-positive budget worksheet, or the on-call to rule-update loop. Vendor whitepapers cover their own platform's rule library but not the workflow that keeps the estate honest. A consulting engagement to do the same work runs into five figures and leaves the team without the documented templates. The course delivers the templates, the workflow, and the implementation playbook scoped to your stack at 199 USD.

FAQ

Does the course assume a specific SIEM?

No. Worked examples are given for Splunk SPL, Elastic ESQL, and a generic SQL-style SIEM. The detection-as-code repo skeleton and the rule review form are platform-agnostic. Translation gotchas are covered in Module 5.

How is the hand-built implementation playbook tailored?

After purchase you send a short brief: SIEM and EDR in use, approximate rule count, team size, current coverage matrix if one exists, and the top three pain points. The playbook is shaped to that brief and delivered alongside course access.

Is the course suitable for a team lead rather than an individual contributor?

Yes. The peer-review workflow, the on-call runbook, and the quarterly program review modules are written for the person who has to defend the program to a security leader.

Can the course be expensed?

Yes. A receipt is issued at purchase. Most security teams expense the course under training and development.

What if our detection stack is mostly in the EDR rather than the SIEM?

The same workflow applies. The implementation playbook is scoped to where your detection content actually lives. The ATT&CK coverage mapping and the rule review form do not depend on the SIEM being the primary platform.

30-day money-back guarantee. If after a week of working through the materials this is not what you needed, reply to the receipt email and a full refund is processed. No questions, no forms.

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.