TTPs stands for tactics, techniques, and procedures, the recurring methods an adversary uses during an operation. Tactics describe the objective, techniques describe the method, and procedures describe the specific implementation. In operational intelligence, TTPs help defenders recognize repeatable behavior across incidents and build detections around how attackers operate.
How TTPs shape operational detection
TTPs are the part of adversary tradecraft that defenders can actually observe and compare across incidents. Tactics describe the attacker’s objective, techniques describe the method used to pursue it, and procedures show the concrete implementation choices that may vary from one campaign to another.
That structure matters because tactics are often too broad to detect directly, while procedures can be too specific to a single incident. The practical value of TTP analysis is in linking the two: it helps analysts recognise repeated behaviour, cluster related activity, and build detections around methods rather than one-off indicators.
For that reason, TTPs are central to threat intelligence, detection engineering, and incident analysis. They help a team answer not just “what happened?” but “how is this adversary likely to operate again?”
Why TTPs matter in threat intelligence
TTPs turn raw incident detail into reusable intelligence. When teams catalogue how an adversary gains access, moves laterally, persists, or exfiltrates data, they create a behavioural profile that can inform hunting and response decisions long after the original indicator of compromise has gone stale.
They are also a useful bridge between offensive analysis and defensive planning. A detection rule that only keys on a hash or domain may be fragile, but a detection strategy informed by a recurring technique or procedure is usually more durable because it tracks the adversary’s method, not just one artifact.
In practice, TTP analysis is strongest when it is tied to observable evidence, such as logs, alerts, endpoint telemetry, and incident narratives. That is what allows teams to distinguish a familiar attack pattern from unrelated noise.
Common ways TTPs are organised and used
Security teams often organise TTPs into a structured knowledge base so they can compare incidents consistently. The most useful view is usually the one that separates objective, method, and implementation, because that lets analysts see both pattern and variation at the same time.
- Tactics answer the question, “Why is the attacker doing this now?”
- Techniques answer, “How is the attacker trying to do it?”
- Procedures answer, “What exactly did this actor do in this environment?”
This hierarchy is especially valuable in detection engineering, where a single technique may appear in many different procedures. It also helps with adversary emulation and purple-team exercises, because defenders can test whether controls detect the method even when the specific implementation changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TTPs — Adversary Tactics, Techniques, and Procedures | ATT&CK is built around recurring adversary tactics, techniques, and procedures. |
| T1027 — Obfuscated Files or Information | Technique-level analysis often identifies evasive attacker methods that recur across procedures. | |
| Recommendation — Map observed behaviour to ATT&CK techniques and use those mappings to improve hunting and detections. Track obfuscation patterns as a reusable technique and add detections for the underlying behaviour. | ||
| CIS Controls v8 | 8 — Audit Log Management | TTP analysis depends on logs and telemetry to recognise repeatable attacker behaviour. |
| 13 — Network Monitoring and Defense | Network and endpoint monitoring help expose recurring adversary methods in motion. | |
| Recommendation — Centralise and review logs so TTP-driven patterns can be detected and investigated quickly. Correlate network and endpoint telemetry to spot repeated attacker techniques across incidents. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | TTPs support continuous monitoring by turning observed behaviour into repeatable detections. |
| RS.AN — Incident Analysis | Incident analysis relies on understanding the method behind the event, not only the artifact. | |
| Recommendation — Use continuous monitoring to identify recurring attacker techniques and update detections accordingly. Analyse incidents for techniques and procedures so lessons improve future response and hunting. | ||
Practitioner Guidance
Why practitioners should care: TTPs are one of the few intelligence formats that can directly improve detections, hunts, and response playbooks. If your team only tracks indicators, you will often miss the repeatable behaviour that reveals a campaign.
What to watch for: The best TTP work is precise enough to support action but not so narrow that it dies with one event. A good habit is to record both the high-level technique and the concrete procedure observed, then use that pairing to refine monitoring logic and incident patterns.
Practitioner takeaway: Treat TTPs as a behaviour model, not a label, because the value comes from what the adversary consistently does, not from the name attached to the incident.
Risk and Threat Considerations
TTPs are risky for defenders because they describe the repeatable part of an attack, the part most likely to survive individual indicator changes. If analysts only track artifacts, adversaries can repackage the same method and still achieve the same objective.
Failure mechanism: Defenders miss the underlying behaviour when they focus on isolated indicators instead of the tactic, technique, and procedure pattern. That creates blind spots in detection, hunting, and post-incident learning.
Impact: The same attacker tradecraft can recur across multiple incidents, extend dwell time, and make response slower and less reliable because the organisation never learns the method well enough to spot it early.
