Detection use case management
What is MaGMa?
Detection use cases rarely fail because teams lack rules. They fail because nobody can reliably manage those rules over time.
Ownership fragments. ATT&CK mappings drift. Tuning backlog grows. Detections decay quietly after telemetry or platform changes.
MaGMa structures and governs detection use cases in practice — ownership, threat alignment, effectiveness assessment, and change over time.
The objective is simple: managing detections as governed operational assets, not static content in a spreadsheet.
What breaks without structured use case management?
- Rules pile up ad hoc; duplicate and conflicting logic accumulates
- Threat intel maps techniques, engineering writes rules, operations triages alerts — but no one owns the use case record
- Tuning prioritisation follows the loudest ticket, not the highest-risk gap
- Improvements happen after incidents, audits, or annual reviews — not as a normal operating rhythm
- ATT&CK heatmaps stay green while production drift goes unrecorded
When leadership asks whether a priority threat is detectable today, teams often answer from memory, stale slides, or last quarter’s review — not from a record they trust.
What is detection use case management?
The day-to-day work of defining, owning, prioritising, and improving what your programme detects — and showing that deployed logic still matches intent.
Teams call it detection content management, rule governance, detection operations, or security detection management. SOC engineering, purple teams, and CTEM programmes touch the same object from different angles.
MaGMa (Management, Growth, Metrics & Assessment) structures that work. It sits above your SIEM, EDR, BAS, and CTI — it does not replace them.
Rules, use cases, content, and analytics — one operational problem
Different teams use different language for the same operational problem. On this page, these terms refer to the same challenge unless stated otherwise:
- Use case — the intended outcome, structured in the MaGMa UCF from strategic threat context through tactical intent to operational procedures
- Rule / analytic / detection logic — what is deployed in SIEM, EDR, or other platforms
- Detection content — the corpus of rules, queries, and supporting logic your programme maintains
- Coverage artifact — heatmaps, technique mappings, and gap lists tied to ATT&CK or internal taxonomies
The failure mode is the same: no single record of what should exist, what is live, what was validated, and what production proves. That is why detection coverage debates often confuse declared intent with operational truth.
What is MaGMa?
MaGMa (from the FI-ISAC community) structures how security monitoring use cases are managed over time — not as a one-off documentation exercise.
It focuses on three pillars:
- Management — how detection use cases are organised, owned, and governed
- Growth — how they evolve with threats, incidents, and business priorities
- Metrics & Assessment — how maturity and effectiveness are evaluated
Use cases follow the MaGMa Use Case Framework (UCF) — named layers from threat context to deployed logic (below), not generic level labels.
How the MaGMa UCF hierarchy works
Three layers trace from threat context to deployed logic:
| UCF layer | What it represents | Example |
|---|---|---|
| Strategic threat context | Grouping by threat model — commonly Cyber Kill Chain stages, or other threat frameworks your programme adopts | Delivery, command-and-control, actions on objectives |
| Tactical Use Case (Intent) | The adversary behaviour or risk you intend to detect — intent before implementation detail | Credential Theft, Internal Reconnaissance, Lateral Movement |
| Operational procedures | Concrete monitoring procedures and detection logic, typically aligned to MITRE ATT&CK techniques | Procedures for T1078 (Valid Accounts), T1110 (Brute Force), linked rules and analytics |
Traceability runs strategic threat context → tactical intent → operational procedures → deployed logic. That is the minimum bar for ATT&CK operationalization — not a poster heatmap, but a maintained link from Kill Chain (or equivalent) grouping through intent to owned procedures and live rules.
Common questions teams ask
Different phrasing, same underlying need:
| What teams search or ask | Operational need | MaGMa pillar |
|---|---|---|
| Detection use case management | Defined records, ownership, UCF hierarchy (Kill Chain → Tactical Use Case → operational procedures) | Management |
| Detection rule governance / sprawl | Authoritative logic, retirement, conflict resolution | Management |
| How to prioritise detection engineering | Backlog tied to threat and business risk | Growth |
| ATT&CK use case management | Threat-aligned use cases, not static heatmaps alone | Growth + Management |
| Detection lifecycle management | State transitions from design through production and retirement | Management + Growth |
| How to measure detection effectiveness | Evidence that controls work in production, not rule counts | Metrics & Assessment |
| Detection drift / why detections stop working | Continuous health vs periodic review | Metrics & Assessment |
| Detection governance / detection assurance | Programme maturity, auditability, executive confidence | All three pillars |
How MaGMa connects business risk to deployed logic
Beyond the UCF table, MaGMa describes traceability across three familiar layers:
- Business layer — why monitoring exists: risk, impact, organisational priorities
- Threat layer — observable adversary activity under your chosen threat model (Kill Chain, ATT&CK, or sector frameworks)
- Operational layer — tactical use cases and procedures implemented as rules, telemetry requirements, and validation hooks
In practice, a Tactical Use Case (Intent) such as Credential Theft sits between strategic threat grouping and the operational procedures your engineers deploy. Ownership and lifecycle apply at each layer — not only at the rule level.
Day-to-day workflows
Management: ownership and rule governance
Assign owners across the UCF, retire duplicate rules, and keep an authoritative record of what each control is for. Without that, programmes live in a shared drive of exports and stale Confluence pages.
Growth: prioritisation and threat-driven change
When a campaign, incident, or intel priority lands, the question is which use cases need creation, update, or retirement — not which engineer has capacity this sprint.
Metrics & Assessment: effectiveness, not inventory
Maturity on paper is not measurement. Assessment means detection effectiveness evidence — validation results, operational outcomes, drift signals — not a checklist that every row has an owner.
Capability detail: Detection Lifecycle Management, Detection Coverage Management.
What MaGMa defines — and what it does not
MaGMa sets structure and maturity expectations. It is not, by itself:
- Continuous measurement of detection effectiveness
- Live visibility into drift and production performance
- Validation traceability tied to current threats
- A persistent record linking use cases to deployed logic
The challenge is no longer defining use cases. It is maintaining live traceability between threat intent, deployed logic, validation evidence, and production outcomes — see detection infrastructure health when signal or platform change breaks detections quietly.
From use case management to Detection System of Record
Most teams discover the problem at the operational layer. The strategic category — Detection System of Record (DSoR) — describes what is required once use case management, lifecycle, and measurement need to persist at programme scale.
| Layer | Market understanding | Where to go next |
|---|---|---|
| Immediate operational pain | Detection use case management | This page (MaGMa) |
| Program maturity | Detection lifecycle management | Lifecycle management |
| Measurement need | Detection effectiveness / assurance | Measure effectiveness |
| Hidden failure | Detection infrastructure health | Infrastructure health |
| Governance requirement | Detection governance, coverage maintenance | Detection coverage |
| Strategic synthesis | Detection System of Record | DSoR hub |
A Detection System of Record (DSoR) keeps that traceability continuous: linking threat context, use cases, deployed logic, validation evidence, and production outcomes in one governed record.
SecuMap implements the DSoR category as a platform above SIEM, EDR, BAS, and CTI. The canonical definition lives on the Detection System of Record hub.
Detections are living assets — mapped to threats, owned through state changes, measured in production, and retired when logic no longer holds.
How SecuMap keeps use cases live
- Use case records tied to deployed rules and platform context
- Effectiveness and health signals, not annual maturity reviews
- Validation results (BAS, purple team) linked to the use case they prove
- Improvement tracked through the threat-to-detection operating loop
How do you know detections still work?
Mature programmes ask:
- Is it working?
- How well is it working?
- Has it improved or decayed since validation?
- Where should we invest next?
Not “Do we have this use case?” but whether declared, validated, and operational coverage still align — see detection coverage and measuring detection effectiveness.
ATT&CK, MaGMa, and a governed record
- MITRE ATT&CK — what to detect (explainer)
- MaGMa — how use cases are managed over time
- Detection System of Record — where intent, logic, validation, and outcomes stay linked (explainer)
Heatmaps alone do not prove coverage. MaGMa alone does not prove effectiveness. Together with a governed record, use case management becomes a programme you can defend under scrutiny.
Frequently asked questions
What is MaGMa?
A use case maturity model from the FI-ISAC community — Management, Growth, and Metrics & Assessment — for how monitoring use cases are owned and evolved.
What is detection use case management?
Owning, prioritising, and improving detections over time — from threat context through deployed logic to validation and production outcomes.
How does MaGMa relate to MITRE ATT&CK?
ATT&CK defines what to detect; MaGMa defines how use cases are managed. Heatmaps are not a substitute for ownership or measurement.
Why do detections decay over time?
Parser drift, integration changes, tuning backlog, stale mappings. Lifecycle docs on paper do not stop that — see detection infrastructure health.
Does MaGMa replace a Detection System of Record?
No. MaGMa sets structure. A DSoR holds the live record linking use cases to logic, validation, and outcomes.
Next steps
- Detection Lifecycle Management in practice
- How to measure detection effectiveness
- Detection coverage and gap visibility
- What is a Detection System of Record? (strategic synthesis)
- MITRE ATT&CK explained
- SecuMap methodology
- See it in action (interactive demo)
Platform overview and detection engineering platform connect this model to day-to-day workflows.