TTPs — Tactics, Techniques, and Procedures — is threat intelligence shorthand for describing how an adversary actually operates, at three levels of specificity that get more concrete as you move down. The term comes out of military doctrine, where it originally meant much the same thing about an opposing force's patterns of operation, and it migrated into cybersecurity because the same layered idea turned out to be exactly what defenders needed: a way to talk about attacker behavior that doesn't fall apart the moment the attacker changes a file hash.
Quick definition: Tactics are an adversary's goal at a given stage of an attack (the "why"). Techniques are the general method used to achieve that goal (the "how"). Procedures are the specific, observed implementation of a technique by a particular actor or campaign (the exact "how, in practice"). Together, TTPs describe attacker behavior at a level durable enough to be worth defending against directly.
The three levels, from goal to implementation detail
Each level answers a different question, and each is more specific — and more perishable — than the one above it:
| Level | Answers | Example |
|---|---|---|
| Tactic | Why is the attacker doing this right now? | Initial Access — they need a foothold before anything else is possible |
| Technique | How, in general, are they achieving that goal? | Phishing — a broad method, not tied to any one attacker or campaign |
| Procedure | How, specifically, does this actor implement that technique? | This group sends a PDF impersonating a vendor invoice, with a macro-enabled attachment that drops a specific loader — the exact, observed playbook |
The hierarchy is what makes TTPs useful. "Phishing" alone is too generic to build a detection around — nearly every organization already has some phishing control. "This specific group's invoice-themed PDF with this specific macro" is precise, but it's also disposable: the attacker can rename the file, swap the vendor they're impersonating, and the indicator is gone by next week. The technique in the middle — the general method — is the level that tends to survive both problems: specific enough to act on, general enough that the attacker can't trivially discard it.
TTPs vs. MITRE ATT&CK
TTPs is the concept; MITRE ATT&CK is the most widely adopted catalog that operationalizes it. ATT&CK's Tactics (Initial Access, Execution, Persistence, and so on) and Techniques (each with an ID like T1566 for Phishing) map directly onto the first two TTP levels, structured and named consistently so different teams can talk about the same behavior without re-describing it from scratch every time. Procedures show up in ATT&CK too, just not as their own top-level field — they live in the "Procedure Examples" documented under each technique, where MITRE records specific, cited instances of real groups implementing that technique a particular way.
In practice, when you tag an attack tree leaf with a MITRE ATT&CK technique ID, you're already working at the TTP level — you've picked the middle rung of the hierarchy on purpose, because it's the one durable enough to be worth naming.
Why TTPs matter more than IOCs
Indicators of Compromise — IP addresses, file hashes, domain names — are the easiest thing to detect and the easiest thing for an attacker to throw away. This tradeoff has a name in the threat intelligence world: David Bianco's "Pyramid of Pain," which ranks indicator types by how much genuine cost it inflicts on an attacker when you detect and block that type. Hashes and IP addresses sit at the bottom — trivial to regenerate or rotate, so blocking them barely inconveniences anyone. TTPs sit near the top: changing a whole technique, let alone a tactic, usually means retooling, retraining, or abandoning an approach the attacker has invested real time in.
The practical consequence for threat modeling: a threat written as "attacker uses IP 203.0.113.4" isn't a threat, it's a single obsolete data point. A threat written as "attacker gains initial access via phishing with a malicious attachment" describes a durable pattern worth actually building a mitigation around — because it will still be true, and still be the attacker's problem to work around, long after this week's specific indicators have rotated out.
Using TTPs in a threat modeling workflow
- Write attack tree leaves at the technique level, not the indicator level — "credential phishing via a spoofed login page" survives; "attacker uses phishing-site-xyz.com" doesn't.
- Tag leaves with the matching MITRE ATT&CK technique ID — this turns a plain-English TTP description into something searchable, comparable across forests, and traceable back to real-world procedure examples when you need supporting evidence.
- Use procedure-level detail from real incident reports to make a tree concrete — a generic "phishing" leaf is a start; a leaf informed by how a real, relevant campaign actually executed phishing against a similar target is a much sharper one.
- Build detections and mitigations around tactics and techniques, not today's IOC list — IOC feeds still have value operationally, but a mitigation that only works against this week's specific indicators needs to be re-earned every week.