What belongs in the ODE Core Curriculum?

[mndtrcks]

Below is a proposed outline for the core modules of the Open Detection Engineering (ODE) curriculum.

These core modules will be focused on the universal, platform-agnostic body of knowledge required for detection engineering. Platform, vendor, and technology specific material will be developed separately into specialized tracks after the core curriculum is established.

1. Detection Engineering Foundations
2. Telemetry & Data
3. Detection Requirements
4. Detection Design
5. Detection Development
6. Testing & Validation
7. Detection-as-Code
8. Deployment, Tuning & Operations
9. Detection Health & Lifecycle
10. Detection Program Engineering

Critique is welcome. The goal at this point is to establish an initial structure that can be refined through feedback and contributions.

[andy-ddlabs]

cant wait

[rich-ddlabs]

👀

[Treyrob3]

Greetings, I believe this is a wonderful and strong outline for this. Just a few initial thoughts that come to mind when immediately glancing, and I may be getting ahead of myself, so just let me know if I am:

1.) Risk/Exposure Context in 3:
From my understanding of DE, it's "what should we detect" as a pure threat-driven question. In practice, prioritization should factor in the environment. What's internet-facing, what's vulnerable, what's unpatched, where are controls missing, etc. A detection for exploitation of a CVE you can’t patch for 90 days is worth more than coverage for a technique you’ve already mitigated. Could/should/would this be a part of number 3?

2.) Threat research as input:
Where do detection ideas come from, and could/should/are they going to be included here? I could see if it's part of 2 or 3, depending on what the data part means. Part is it threat reports, incidents, findings, feeds, or what?

3.) Coverage:
Is ATT&CK mapping and analysis planned for any?

[mndtrcks]

1.) Yes, it should absolutely be a part of Module 3.
2.) We can incorporate this into Module 3 as well. I think this is a step in the process that many tend to gloss over when teaching/mentoring junior DEs, including myself at times.
3.) Yes, this should be introduced in Module 4.

HardCounter has previously written content that we'll introduce to kick off some of these modules once the community has agreed upon a base curriculum.

[vkarthyk]

This looks like a pretty strong outline. A few other ideas that we could possibly include:

1.) Enrichment in Module 2:
Identity, asset, threat intel, and behavioral baseline context often turn a noisy alert into a high-fidelity one. Is enrichment planned under Telemetry & Data, or as its own topic?

2.) Alert & response design in Module 4:
Is there room for what a good alert looks like (triage context, severity/confidence, pivot queries, playbooks) as part of the design, not an afterthought?

3.) Security data lake vs. traditional SIEM in 2?
More teams are running detections on data lakes rather than (or alongside) a SIEM, and the trade-offs in cost, retention, latency, batch vs. streaming, and normalization effort shape how detections get designed. Is there room for an architecture-level comparison that stays vendor-neutral?

Happy to help flesh any of these out. Thanks for putting this together.

[mndtrcks]

1.) Agreed, we can probably stuff these into Telemetry & Data when we're establishing the lessons.

2.) Yes, this will be an integral part of the content in Modules 4/5.

3.) I think we can fit that in, no reason why we couldn't.

And absolutely, once the issues are posted, feel free to claim stake in any modules/lessons you can/want to contribute to.

[mndtrcks]

Comments now closed, module research issues now open.