Most SOCs operate on vendor-supplied detection rules with minimal customisation — alerts fire when SIEM correlation rules from the vendor or open-source rule sets match. The model is workable for known threats described well by generic rules. It fails for threats that require organisation-specific context, for techniques that vendor rules do not yet cover, and for adversaries who deliberately operate below the radar of generic detection. The SOCs that meaningfully detect attacks build and tune their own detections through deliberate detection engineering — a discipline that has matured rapidly over the past few years and is increasingly necessary at any SOC of meaningful sophistication.
What Detection Engineering Actually Is
The discipline of treating detection rules as engineered artefacts — with requirements (what threat the detection addresses), design (the logic the rule implements), testing (validation that the rule fires correctly and does not produce excessive false positives), deployment (controlled rollout into production), and maintenance (tuning, deprecation, version control). Detection engineering applies software engineering rigour to security detection logic. Done well, it produces detections that fit the organisation's environment, address specific threats the organisation faces, and operate with manageable false positive rates.
How It Differs From Operating Vendor Detections
Vendor-supplied detections are designed for the average customer — generic enough to be broadly applicable, calibrated for false positives across heterogeneous environments. The detections work reasonably for the generic threats they cover and miss the threats specific to your environment. Organisation-engineered detections account for the specific systems, identities, business processes, and threat exposure of the organisation. They cover what the organisation is actually exposed to rather than the lowest-common-denominator threat. Both have value; relying entirely on either misses opportunities the other addresses.
The MITRE ATT&CK Foundation
MITRE ATT&CK — the framework of adversary tactics and techniques — is the operational language detection engineering speaks. Detection coverage is assessed by ATT&CK technique; gaps are identified by techniques without detection coverage; new detections are typically built to address specific techniques. The framework has become standard across detection engineering programmes because it provides a shared structure for reasoning about what to detect and what to prioritise. Detection engineers without ATT&CK fluency are operating without the field's shared vocabulary.
A useful diagnostic for SOC sophistication: how many detection rules in the SIEM were authored by the organisation versus inherited from vendor or open-source rule sets? Sophisticated SOCs have substantial organisation-authored detection content addressing the organisation's specific threat exposure. Less sophisticated SOCs run almost entirely on inherited rules. Neither extreme is right — vendor rules have value — but the ratio is informative about programme maturity.
Tuning False Positives as Engineering Work
False positives are the largest operational drag on SOC capacity. Detection engineering treats false positive reduction as engineering work — analysing the patterns that produce false positives, refining detection logic to exclude them, validating that the refinement does not introduce false negatives. The discipline produces detections with substantially lower false positive rates than the same detections deployed without engineering attention. The capacity reclaimed from false positive reduction is what enables the SOC to investigate true positives thoroughly rather than triaging alert volume.
Detection-as-Code
Mature detection engineering practices treat detection content as code — version-controlled, peer-reviewed, tested, deployed through CI/CD. Tooling has emerged around this pattern (Sigma rules as portable detection format, detection development frameworks, automated testing harnesses). Organisations adopting detection-as-code report better detection quality, faster iteration, and stronger collaboration across the detection engineering team. The discipline is one of the clearer maturity markers in modern SOC operations.
Components of a Detection Engineering Programme
- ATT&CK-mapped detection coverage assessment, refreshed periodically
- Detection development workflow with requirements, design, testing, deployment, maintenance
- False positive analysis as routine work, with engineering attention to systematic causes
- Detection-as-code practices — version control, peer review, automated testing
- Integration with threat intelligence — new detection content driven by emerging threat understanding
- Detection performance metrics — true positive rate, false positive rate, time-to-detect, coverage by ATT&CK technique
- Career development for detection engineers — the role is distinct from analyst work and deserves its own path
When the Discipline Pays Back
For SOCs that handle meaningful alert volume and want detection quality rather than just detection volume, detection engineering pays back through better signal-to-noise, broader threat coverage, and reduced reliance on vendor cycles for new detection capability. The investment is real — dedicated headcount, training, tooling — and produces returns that increase as the SOC matures. For smaller SOCs operating at scale where detection engineering is unaffordable, managed detection providers offer detection engineering as part of their service; the discipline matters either way, and the question is whether to build or buy.