The Pyramid of Pain, Applied: How Threat Intel Should Reorder Your Detections
Threat intelligence has a quiet failure mode that almost no one admits to: most CTI programmes spend most of their effort on the indicators that matter least. Hashes, IPs, domains — easy to collect, easy to feed into a SIEM, and trivial for an adversary to change. The pyramid of pain is the model that explains why this is backwards, and applied properly, it reorders where you invest detection effort toward the indicators that actually hurt an adversary to abandon.
This is a practitioner’s view of using the pyramid as a prioritisation function for detection, not as a poster on the SOC wall.
The pyramid, briefly
The pyramid of pain ranks indicator types by how much pain it causes an adversary when you can reliably detect and deny that indicator. From bottom (trivial to change) to top (painful to change):
- Hash values — change a byte, new hash. Trivial.
- IP addresses — rotate infrastructure. Easy.
- Domain names — register another. Easy-ish.
- Network/host artifacts — requires some retooling. Annoying.
- Tools — adversary must find or build a replacement. Challenging.
- TTPs (tactics, techniques, procedures) — the adversary’s behaviour. Changing this means changing how they operate. Painful.
The insight is brutal and simple: the indicators easiest for you to collect and operationalise are the ones cheapest for the adversary to discard. The indicators that genuinely disrupt an adversary — their behaviours — are the hardest for you to detect. Effort and value are inversely correlated, which is exactly why undisciplined programmes drift toward the bottom.
Why programmes drown at the bottom
Low-level indicators are seductive for reasons that have nothing to do with their value:
- They are abundant — feeds emit them by the million.
- They are easy to operationalise — drop a hash or IP into a blocklist, done.
- They produce activity that looks like progress — “we ingested 40,000 new indicators this month” is a metric, even if it is a meaningless one.
So programmes optimise for volume of low-value indicators because that is what is easy to measure and easy to do. Meanwhile the adversary rotates their infrastructure on a schedule and your beautiful blocklist is stale before it deploys. You are detecting the disposable and missing the durable.
The pyramid reframes the goal: success is not how many indicators you process. It is how high up the pyramid your reliable detections reach. A programme that detects ten TTPs reliably is worth more than one that ingests a million hashes, because the adversary can shrug off the million hashes and cannot easily shrug off the ten behaviours.
Applying the pyramid as a prioritisation function
Used properly, the pyramid is not a description — it is a decision rule for where detection effort goes. The application:
Treat low-level indicators as cheap, perishable, and automated. Hashes, IPs, domains still have value — they are cheap to act on and catch the lazy and the recycled. So automate them completely and spend zero human effort there. Auto-ingest, auto-expire, do not let an analyst spend a minute on what a pipeline should handle. Their value is real but bounded, and the right human investment in them is none.
Invest human effort where the pyramid is painful. Analyst time — the scarcest resource — goes toward detecting tools and TTPs. These are hard to detect precisely because they are behavioural, which means they need engineering, not ingestion. A TTP detection is a behavioural detection (see the kill-chain, the sequence-matching discipline), and building those is where threat intel meets detection engineering. The CTI function should be feeding the detection-engineering function with prioritised behaviours to catch, not feeding the SIEM with indicators to blocklist.
Let the pyramid reorder your roadmap. When new intel arrives about an adversary, the question is not “what indicators can I extract and block?” It is “what is the highest-pyramid thing I can reliably detect about how this adversary operates?” That question pushes investment upward, toward durability.
The bridge to detection engineering
This is the connection that makes the pyramid more than a model: the top of the pyramid is behavioural detection. A TTP is a behaviour, and detecting a behaviour reliably is the same structure-matching, kill-chain-recognising, sequence-scoring work that distinguishes good detection engineering from atomic signature-matching.
So the pyramid is not just a CTI concept — it is the thing that points CTI at detection engineering. The intel function’s highest-value output is not a feed of indicators; it is a prioritised list of adversary behaviours, each of which becomes a detection-engineering task. The pyramid tells you which behaviours are worth the engineering effort (the ones high enough to hurt the adversary) and the detection engineering tells you how to catch them (structure-matching, not counting).
A CTI programme and a detection-engineering programme that are not tightly coupled are both underperforming. The pyramid is the coupling: intel identifies the painful behaviours, engineering builds the detections that catch them, and validation (purple teaming) confirms they fire. That is a flywheel; a feed of hashes is not.
The honest limits
The pyramid is a model, and models simplify:
- Low-level indicators are not worthless — they are cheap, and cheap-but-low-value is a perfectly good thing to automate. The error is human investment there, not the indicators themselves.
- TTP detection is genuinely hard and noisy — pushing up the pyramid means accepting the false-positive tension from behavioural detection. You do not get the durability for free; you pay for it in tuning effort.
- Attribution at the top is fuzzy — TTPs are shared and evolve, and reading too much adversary-identity into a behaviour is its own trap. Detect the behaviour because it is hostile, not because you are certain who is behind it.
The takeaway
If your threat-intel programme measures itself by indicators ingested, it is optimising the bottom of the pyramid — the disposable layer the adversary changes without effort. The pyramid of pain, applied as a prioritisation function, flips that: automate the cheap perishable indicators to zero human cost, and spend your scarce analyst and engineering effort climbing toward tools and TTPs, where reliable detection actually costs the adversary something.
The reframe in one line: stop counting indicators, start counting how high your reliable detections reach. And the moment you take that seriously, your CTI function and your detection-engineering function fuse into the same flywheel — which is where threat intelligence finally starts to earn its name.
An independent piece by johlem.net — IT security, Luxembourg. Threat intelligence and detection engineering for regulated finance.