The Detection Lifecycle
What is it?
A detection moves through a lifecycle: requirement → data validation → logic development → testing → tuning → deployment → monitoring → maintenance/retirement. Each stage has an exit criterion, and skipping one (deploying before testing, deploying without data) is where noisy or blind detections come from.
Why it matters
The lifecycle is what makes detection a repeatable engineering process instead of a one-off script. It also makes rules maintainable as the environment and threats change.
Where you see it
The workflow board of every detection team: rules tracked by lifecycle stage.
What normal looks like
A rule that passed each stage's exit criterion before advancing — tested before deployment, data-validated before logic.
What suspicious looks like
Not applicable directly — this is process.
How analysts investigate
By moving each detection through the stages in order, enforcing exit criteria, and never deploying a rule that has not been data-validated and tested.
Common beginner mistakes
- Deploying straight from an idea to production — skipping data validation and testing produces the false positives and blind spots the lifecycle exists to prevent.
A Jisr engineer has a great detection idea at 2pm and wants it live by 3. The lifecycle says: first prove the data exists and parses (data validation), then write the logic, then test it against known-malicious AND known-benign samples, tune out the false positives, and only then deploy — with documentation and an owner. The extra hour is what stops a 3pm deployment from becoming a 3:30 flood of false alerts.
Quick check
Why does the lifecycle put data validation BEFORE logic development?
A quick self-check — it doesn't affect your XP or progress.
Sign in to save your progress on the server.