Detection Engineering vs Alerting
What is it?
Detection engineering is the disciplined practice of building, testing, tuning and maintaining detections as engineered products — with requirements, versioning, test cases and documentation — rather than switching on vendor alerts and hoping. The output is a portfolio of durable, measurable detections tied to real threats.
Why it matters
Turning on default alerts gives noise without coverage guarantees; engineering detections gives measurable, maintainable coverage of the threats that matter to THIS organization.
Where you see it
The detection team at Jisr Bank building rules the SOC actually trusts, each traceable to a threat and a test.
What normal looks like
Detections with a stated requirement, known data source, test cases, a severity and an owner — engineered, not improvised.
What suspicious looks like
Not applicable directly — detection engineering is the discipline; the suspicious thing is what a detection catches.
How analysts investigate
By treating each detection as a product: define the requirement, choose telemetry, write logic, test against fixtures, tune, document, and maintain it over its life.
Common beginner mistakes
- Equating 'we have a SIEM with alerts enabled' with 'we have detection coverage' — enabled alerts are not engineered, tested or measured against real threats.
Jisr Bank's SOC has 400 vendor alerts enabled and still missed the last intrusion. The detection-engineering team asks a different question: not 'what alerts does the tool have?' but 'what attacker behaviors must we detect, do we have the data, and can we prove each rule works?' That shift — from switches to engineered products — is the whole discipline.
Quick check
What distinguishes detection engineering from simply enabling vendor alerts?
A quick self-check — it doesn't affect your XP or progress.
Sign in to save your progress on the server.