Detection Engineering Is Not a SIEM Subscription

Most organizations that deploy a SIEM believe they have detection capability. They have logging capability, which is different. The SIEM aggregates events from across the environment. The detection rules that come bundled with it tell it what to look for. Those rules were written by the vendor, for the median customer, against the median threat.

You are probably not the median customer.

What Vendor Rules Actually Are

When a SIEM vendor ships a rule library, those rules have to work for most of their customers. That means they are calibrated to environments the vendor can generalize about, built on data sources the vendor knows are commonly deployed, and tuned to keep false positives low enough that customers do not immediately disable everything.

This produces rules that detect well-known, broadly applicable attack patterns against common configurations. A rule that fires when there are 10 failed logins followed by one success. A rule that flags PowerShell using encoded commands. A rule that catches known bad file hashes.

These rules have value. But they have two problems. The first is coverage: they catch the techniques that everyone knows about, which are also the techniques that sophisticated attackers have already adjusted for. The second is context: they do not know what normal looks like in your environment. If your helpdesk team routinely runs encoded PowerShell because someone once automated a ticket workflow that way, your PowerShell rule is going to spend most of its life producing tickets that analysts close without reading.

A detection rule nobody investigates is not a detection. It is noise.

What Detection Engineering Actually Is

Detection engineering is the practice of treating detection logic as code. It means writing rules to detect specific adversary behaviors, testing those rules against real data to see if they fire correctly, building adversarial test cases to verify coverage, and maintaining rules over time as the environment and the threat landscape change.

The difference from "we have vendor rules enabled" is substantial. A detection engineering practice owns its detection coverage. It knows which ATT&CK techniques it can detect and which ones it cannot. It has a backlog of detections to write, prioritized by how relevant those techniques are to the specific adversary profile the organization faces. When a technique shows up in a threat intel report, someone asks whether the existing rules would have caught it and writes one if not.

This sounds like a lot of work because it is. It is also the only way to have detection coverage that reflects your actual environment rather than someone else's.

The ATT&CK Coverage Theater Problem

MITRE ATT&CK is a useful framework. It has also enabled a particular kind of security theater where organizations map their existing tool inventory to ATT&CK techniques and produce a heatmap showing that they have coverage.

The heatmap does not tell you whether the coverage is tuned, whether the detections actually fire on malicious activity in your environment, or whether an analyst would investigate and escalate if the alert triggered. A vendor rule for a technique is not the same as a functioning detection for that technique in your environment.

The useful version of ATT&CK coverage is running purple team exercises where you execute the technique in your environment and verify that your detection fires. If it does not fire, you write a rule that would. If it fires on legitimate activity, you tune it or find a different detection approach. The heatmap that comes out of that process reflects something real.

Where to Start

If your organization has a SIEM and no detection engineering practice, the place to start is not with ATT&CK coverage. It is with your environment.

Map out the paths an attacker would take to reach your crown jewels. This is basically threat modeling applied to detection priority. What would an attacker have to do to get from initial access to your payment systems, your customer data, your source code? Write detections for the specific behaviors that would appear in your logs along those paths.

These detections will be specific to your technology stack and your network. A detection for unusual service account behavior in your specific Active Directory environment, tuned against baseline data from the last 90 days, is worth more than ten vendor rules for generic techniques you have no log data to support.

From there, treat your detection backlog the way a development team treats technical debt. Something new always needs attention, existing rules need periodic tuning as the environment changes, and every incident is a chance to ask whether the detection that should have fired actually did.

Detections Decay

The last thing most organizations underestimate about detection engineering is maintenance. Environments change. New services come online. Logging configurations drift. Agents fall off. A detection rule written against a data source that is no longer reliably populated will not catch anything, and you probably will not notice until an incident review asks why the rule was silent.

Testing your detections is not optional if you want them to function. The simplest form is running benign versions of the behaviors your rules target and verifying the rules fire. The more rigorous form is building a continuous detection validation pipeline that confirms rule health against live data.

A detection you cannot verify is working is not a detection you can count on. And a SIEM license with vendor rules you have never tested is not a detection program. It is a logging system with a false sense of coverage.