Tactics describe the attacker’s objective at each stage of an intrusion, such as persistence or lateral movement. Techniques are the specific methods used to achieve those objectives, and sub techniques add further detail. In Kubernetes security, that distinction helps teams map controls to both the goal of an attack and the concrete actions used to carry it out.
Why the ATT&CK distinction matters in Kubernetes security
In Kubernetes, the difference between tactics and techniques helps defenders separate attacker intent from attacker method. That matters because one control may disrupt a goal like persistence, while another may block the concrete action used to achieve it. Thinking this way improves detection logic, hardening priorities, and incident triage across clusters, nodes, workloads, and control-plane dependencies.
When teams treat everything as a technique list, they often miss the attack storyline. Tactics give you the stage of intrusion to look for, while techniques tell you what telemetry, permissions, or misconfigurations to inspect. In practice, that means a Kubernetes analyst can ask whether an event reflects discovery, credential access, lateral movement, or exfiltration, then map the observed behavior to the specific procedure used.
The same distinction also helps when multiple Kubernetes controls could apply. For example, a tactic such as privilege escalation may be realized through different techniques, including abusing overly broad RBAC, stealing tokens, or manipulating container execution paths. The goal is not to memorize ATT&CK as a catalog, but to use it as a structured way to connect cluster activity to defensive action. For a broader ATT&CK reference, see the MITRE ATT&CK Enterprise Matrix.
How to map Kubernetes observations to tactics and techniques
Start with the outcome you think the attacker wants, then work backward to the observable mechanism. If the cluster is showing signs of persistence, the tactic is the objective; the technique may be a persistence mechanism such as a modified deployment, a scheduled controller action, or a backdoored configuration. If the issue is lateral movement, the tactic is the movement objective, while the technique may be service-account token abuse, namespace hopping, or over-permissive network reachability.
That mapping is useful because Kubernetes often creates shared control points. A single weakness, such as a writable manifest store, a weak admission policy, or a broadly scoped token, can support several techniques under different tactics. Defenders should therefore read alerts at two levels: the tactic tells you what phase of the intrusion you are in, and the technique tells you what exact object, permission, or workload path must be checked.
-
Use the tactic to choose the incident-workflow branch: persistence, privilege escalation, lateral movement, discovery, or exfiltration.
-
Use the technique to choose the evidence source: audit logs, RBAC bindings, workload specs, container images, runtime events, or network flows.
-
Use sub techniques when the same method needs a more precise label for hunting or reporting.
This approach is especially helpful in container platforms because the same adversary objective can appear through different layers, from the API server to the pod filesystem to the underlying node. The security value is not in naming the ATT&CK label alone, but in using that label to narrow what should be verified first. For container-specific context, NIST’s NIST SP 800-190 Container Security is a useful companion when you need to connect ATT&CK thinking to platform risk.
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 | TA0003 — Persistence | Kubernetes attackers often use persistence tactics to retain cluster access. |
| TA0004 — Privilege Escalation | Kubernetes compromise commonly involves gaining higher permissions through cluster misconfigurations. | |
| TA0008 — Lateral Movement | Kubernetes attacks often move between pods, namespaces, and nodes after initial access. | |
| Recommendation — Map persistence observations to TA0003 and inspect workloads, controllers, and startup paths for hidden re-entry. Map privilege-escalation activity to TA0004 and review RBAC, tokens, and admission controls for excess rights. Map lateral movement indicators to TA0008 and trace service-account reachability, network paths, and trust edges. | ||
| CIS Controls v8 | CIS 5 — Account Management | Kubernetes identity and access paths depend on controlling accounts, tokens, and permissions. |
| Recommendation — Apply CIS 5 to review and revoke unused Kubernetes accounts, tokens, and access paths. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Kubernetes attack paths are constrained or enabled by access controls and permission boundaries. |
| DE.CM — Continuous Monitoring | Tactic-to-technique mapping depends on monitoring cluster activity and control-plane events. | |
| Recommendation — Use PR.AC to enforce least privilege across cluster access, service accounts, and administrative actions. Use DE.CM to monitor Kubernetes audit logs, runtime activity, and workload changes for technique-level evidence. | ||
Practitioner Guidance
What to verify: Make sure the alert or finding is anchored to a tactic before you optimize the response, because the same technique can serve different objectives depending on where it appears in the intrusion chain. In Kubernetes, that usually means validating whether the event is isolated misuse, preparatory discovery, or evidence of an active control-plane or workload compromise.
Decision rule: If you can only name the method but not the adversary objective, keep investigating before assigning priority. If you can name the objective but not the method, treat the detection as incomplete and look for the cluster object, permission, or runtime artifact that proves the path used.
Practitioner takeaway: Tactics answer “why this behavior matters now,” while techniques answer “what specifically to fix or hunt.” Strong Kubernetes defense depends on pairing both, because the operational response changes depending on whether you are seeing a goal, a method, or a sub technique inside a larger attack path.
Related resources from NHI Mgmt Group
- What is the difference between tactics and techniques in the MITRE ATT&CK framework?
- What is the difference between attack emulation and simply reviewing MITRE ATT&CK techniques on paper?
- What is the difference between using MITRE ATT&CK for API defence and using the OWASP API Security Top 10?
- What is the difference between CIS Kubernetes Benchmarks and MITRE ATT&CK for Kubernetes?
