Cybatar Security Hub · Governance · Risk Management · Threat Resilience · Compliance & Audit
Unified enterprise security operations for modern organisations
Detection Engineering / Detection lifecycle
Detection engineering guide

Detection Engineering Lifecycle

What should a repeatable detection engineering lifecycle contain?

Direct answer

Treat each detection as a governed operational asset. Record the detection objective, behavioural reference, required telemetry, analytic logic, owner, severity/escalation expectations, validation evidence, deployment state, tuning history, performance feedback, known gaps and retirement rationale.

External reference

MITRE ATT&CK and NIST — ATT&CK Detection Strategies and NIST SP 800-137

This Cybatar lifecycle combines behavioural detection references with continuous-monitoring evidence principles; it is not an official MITRE or NIST lifecycle.

https://attack.mitre.org/detectionstrategies/

Detection engineering workflow

1

Hypothesis

State the behaviour, threat, risk or operational problem the detection is intended to surface.

2

Telemetry

Define and verify the required source, field, identity, time and enrichment dependencies.

3

Logic

Document analytic conditions, correlation, thresholds, exclusions and expected output.

4

Validation

Test representative positive and benign cases and record results against the detection version.

5

Operation

Monitor alert disposition, incident escalation, missing context, source health and analyst feedback.

6

Tuning / retirement

Record material changes, repeat validation when needed and retire detections that no longer serve a justified objective.

Relevant Cybatar operating surfaces

Claim boundary

The lifecycle is a Cybatar-authored operating model. It does not assert that Cybatar currently provides a dedicated rule-authoring language, automated ATT&CK coverage engine or universal detection-content marketplace.

These pages are Cybatar-authored detection-engineering guidance. External taxonomies and standards are referenced for context; the mappings are not official MITRE, NIST or vendor validations, certifications, endorsements or statements that a particular deployment will detect a technique.

Evidence and methodology