TH0.3 The Detection Pyramid

Three categories of threat — three operational responses

David Bianco's Pyramid of Pain, published in 2013 during his work at Sqrrl (later acquired by Amazon), introduced a principle that now underpins modern detection strategy: not all indicators are equally valuable, because not all indicators are equally painful for the attacker to change. Hash values and IP addresses sit at the base — trivial for attackers to rotate. Tools and TTPs sit at the apex — expensive to replace because they represent the attacker's learned methodology.

The Pyramid of Pain answers a targeting question: where should detection effort concentrate to impose the highest cost on the attacker? But it assumes a detection rule exists. It does not address the category of threat where no rule exists at all. The detection pyramid extends Bianco's insight into a visibility model — not just what to detect, but which operational discipline detects it.

The three layers correspond to three categories of threat, each requiring a structurally different response.

Known-known threats are techniques where the attack pattern is documented, the telemetry that records it is available, and a detection rule exists in your SIEM. When the attack occurs, an alert fires. This is the domain of detection engineering, and it is the only category that automated detection covers. In M365 environments, these are your Sentinel analytics rules, your Defender XDR built-in detections, and your custom KQL rules. The CardinalOps 2025 State of SIEM Detection Risk report, analysing over 13,000 detection rules across hundreds of production SIEMs including Sentinel, found that the average enterprise covers just 21% of MITRE ATT&CK techniques — a 2% improvement from the previous year. Of the detection rules that do exist, 13% are non-functional due to misconfigured data sources or missing log fields. The base of the pyramid is narrower than most organisations believe.

Known-unknown threats are techniques that appear in ATT&CK, in threat intelligence reports, in conference presentations — but your environment has no detection rule for them. You know this category of attack exists. You may suspect it is occurring. The telemetry to surface it is probably flowing into your SIEM already. What is missing is someone formulating a hypothesis and looking. This is the domain of threat hunting. The hypothesis is formable because the technique is known. The data exists because the logs are collected. The gap is operational: nobody is querying that data for that pattern. Given that 79% of ATT&CK techniques have no corresponding SIEM rule in the average enterprise, the known-unknown layer represents the single largest category of unaddressed threat surface.

Unknown-unknown threats are novel techniques — attack paths that have not been documented, zero-day exploitation of platform behaviours, or creative abuse of legitimate features that security researchers have not yet classified. You cannot hunt for something you cannot hypothesise. This is the domain of anomaly detection and behavioural analytics: statistical baselining that identifies deviation from normal without requiring a predefined pattern. Microsoft Sentinel UEBA, Defender for Identity's behavioural models, and custom time-series decomposition queries all operate in this layer.

Figure TH0.3 — The detection pyramid. Detection engineering covers the base (known-known). Hunting covers the middle (known-unknown). Anomaly detection covers the apex (unknown-unknown). Updated with CardinalOps 2025 data: the average enterprise SIEM covers 21% of ATT&CK techniques.

The inverted damage distribution

The pyramid narrows as you move up — fewer unknown-unknown techniques exist than known-unknown techniques, and fewer known-unknown techniques than known-known techniques. But the damage distribution is inverted. The known-known threats at the base are high-volume, relatively low-impact individually: commodity phishing, opportunistic credential stuffing, known malware families. They produce alerts. They consume analyst time. They matter. But they rarely produce the intrusions that end careers and trigger regulatory investigations.

The threats at the top of the pyramid are low-volume but catastrophically high-impact. Nation-state actors with 122-day median dwell times. Ransomware affiliates who spend two weeks mapping Active Directory before encrypting anything. Insider threats who discover a data exfiltration method that nobody has thought to monitor. They succeed specifically because they operate above the detection rule layer. A SOC that invests exclusively in detection engineering optimises for the base — catching the most threats by volume, producing the busiest incident queue — while remaining structurally blind to the threats that cause the most damage.

This inversion explains a pattern that frustrates security leaders: the SOC is busy, the alert queue is full, the response metrics look healthy, but the organisation still suffers a major breach. The breach was not a detection engineering failure. It was a visibility architecture failure. The organisation had no operational capability addressing the middle and top layers of the pyramid.

How the three layers feed each other

The layers are not independent. In a mature operation, they form a cycle that makes the entire security capability smarter over time — but only if all three layers are active.

Anomaly detection at the top surfaces statistical outliers that no human hypothesised. A UEBA alert flags a user whose SharePoint download volume is 400% above their 90-day baseline. That finding does not explain itself. An analyst must investigate it: is this a legitimate project, a data migration, or an exfiltration campaign? That investigation is a hunt — even if the analyst does not call it one. It uses the same skills, the same queries, and the same reasoning chain that formal hunting uses.

If the hunt confirms malicious activity, the finding produces a detection rule. The analyst writes a KQL query that catches the same pattern — high-volume SharePoint downloads from accounts that recently registered new MFA methods — and deploys it as a Sentinel analytics rule. The finding has moved from the unknown-unknown layer (anomaly detection surfaced it) through the known-unknown layer (hunting investigated it) to the known-known layer (a detection rule now catches it automatically). The pyramid gets wider at the base because the top and middle layers fed it.

If neither hunting nor anomaly detection is active, the cycle stops. Detection engineering only improves when someone discovers new patterns to detect. Without hunting, new patterns are discovered only through incident response — meaning the organisation learns exclusively from breaches. That is the most expensive way to build detection coverage.

Measuring your pyramid investment

Your Sentinel rules metadata tells you which layer of the pyramid your current investment addresses. The query below classifies your active analytics rules by their operational origin.

// Classify Sentinel analytics rules by detection pyramid layer
// Known-known = active rule, Known-unknown = hunting, Unknown-unknown = anomaly
SentinelAudit
| where TimeGenerated > ago(90d)
| where SentinelResourceType == "Analytic Rule"
| where Status == "Success"
| extend RuleData = parse_json(ExtendedProperties)
| extend RuleName = tostring(RuleData.RuleName)
| extend PyramidLayer = case(
    RuleName has_any ("ML", "Anomal", "UEBA", "Behavior"),
        "Unknown-Unknown (Anomaly Detection)",
    RuleName has_any ("Hunt", "Proactive", "Hypothesis"),
        "Known-Unknown (Hunting-Derived)",
    "Known-Known (Detection Engineering)")
| summarize RuleCount = dcount(RuleName) by PyramidLayer
| extend Percentage = round(100.0 * RuleCount / toscalar(
    SentinelAudit
    | where TimeGenerated > ago(90d)
    | where SentinelResourceType == "Analytic Rule"
    | where Status == "Success"
    | summarize dcount(tostring(
        parse_json(ExtendedProperties).RuleName))), 1)
| sort by RuleCount desc

The output will almost certainly show 90%+ of your rules in the Known-Known layer. That is normal. It is also the structural deficit you are here to address. The percentage of rules derived from hunting findings (rules that were not in any vendor content pack, but were created because a hunt found something worth detecting permanently) is the single best leading indicator of whether hunting is producing lasting value or just generating one-time reports.

Why the known-unknown layer is where hunting lives

Hunting does not operate across all three layers equally. Its natural home is the middle: known-unknown threats. The technique is documented. ATT&CK describes it. Threat intelligence reports reference it. The telemetry that would surface it is flowing into your SIEM. What is missing is the hypothesis that connects the known technique to a query against your data.

This positioning matters because it makes hunting tractable. You are not searching for something completely unknown — that would be random exploration. You are searching for something specific: a known technique that your rules do not cover, tested against your environment's data. The hypothesis is the mechanism that converts "we think this might be happening" into "we queried for this specific pattern and here is what we found." Every hunt in this course follows that structure: hypothesis, data source, query, evaluation, finding, detection rule.

The positioning also explains why hunting and detection engineering are complementary rather than competitive. Detection engineering builds and maintains the base layer. Hunting investigates the middle layer and, when it finds something, produces a new rule that permanently widens the base. A healthy operation funds both because they serve different layers. An operation that defunds hunting to add more detection engineers is the equivalent of deciding to pave more of the road you can already see while ignoring the territory beyond the streetlights.

This hypothesis targets a technique that is well-documented, frequently exploited in M365 environments, and typically absent from default Sentinel analytics rule sets. TH7 (Hunting Application Compromise) teaches you to execute exactly this class of hunt. The detection pyramid tells you why it matters: consent phishing sits in the known-unknown layer because the technique is known, the telemetry exists, and the rule does not. Every day it remains in that layer is a day an attacker can use it without generating an alert.