Tactics, Techniques, and Procedures (TTPs) are the observable behavior patterns attackers or defenders use to achieve goals. Analogy: TTPs are the playbook, like a sports team\u2019s plays versus individual moves. Formal: A structured framework mapping intent (tactics) to methods (techniques) and stepwise execution (procedures).<\/p>\n\n\n\n
TTPs describe repeatable actions and choices used to accomplish objectives. In security, TTPs capture how adversaries accomplish reconnaissance, exploitation, lateral movement, persistence, and exfiltration. For defenders, TTPs codify detection logic, response runbooks, and preventive configurations.<\/p>\n\n\n\n
What it is NOT<\/p>\n\n\n\n
Key properties and constraints<\/p>\n\n\n\n
Where it fits in modern cloud\/SRE workflows<\/p>\n\n\n\n
Diagram description<\/p>\n\n\n\n
A TTP is the mapping from an adversary or defender’s strategic goal through concrete techniques to operational procedures that produce observable behaviors and controls.<\/p>\n\n\n\n
ID | Term | How it differs from Tactics Techniques and Procedures | Common confusion\nT1 | Indicator of Compromise (IOC) | IOC is a specific artifact not a behavior pattern | People conflate IOCs with full TTPs\nT2 | Playbook | Playbook is a prescriptive document; TTPs describe actual behaviors | Playbook implies stepwise steps only\nT3 | Threat Actor | Actor is the person or group; TTPs are their behaviors | Actors sometimes equated to TTPs\nT4 | Control | Control is a mitigation; TTPs can inform controls | Controls are not TTPs though related\nT5 | Detection Rule | Rule is implementation; TTPs inform rule design | Rule is often mistaken as complete TTP\nT6 | Threat Intelligence | Intelligence includes context; TTPs are a subset focused on behavior | Intelligence is broader than TTPs\nT7 | Incident Response | IR is process; TTPs feed IR playbooks | IR and TTPs are frequently used interchangeably\nT8 | MITRE ATT&CK | ATT ACK maps tactics and techniques; TTPs include procedural detail | ATT ACK is a framework, not full procedural playbooks<\/p>\n\n\n\n
Business impact<\/p>\n\n\n\n
Engineering impact<\/p>\n\n\n\n
SRE framing<\/p>\n\n\n\n
What breaks in production \u2014 realistic examples<\/p>\n\n\n\n
ID | Layer\/Area | How Tactics Techniques and Procedures appears | Typical telemetry | Common tools\nL1 | Edge and network | Recon and initial access techniques like port scanning and exploit chains | Flow logs TLS metadata WAF logs | Network IDS WAF SIEM\nL2 | Identity and access | Credential theft MFA bypass role misuse | Auth logs token issuance SSO events | IAM tools SIEM PAM\nL3 | Service and application | Exploits, injection, abnormal API use | App logs traces request rates | APM WAF Runtime protection\nL4 | Data and storage | Exfiltration, lateral data access | DB audit logs access patterns DLP alerts | DLP DB audit SIEM\nL5 | Orchestration and infra | Lateral movement via orchestration misconfig | K8s audit kubelet logs cloud trail | K8s audit CloudTrail IaC scanners\nL6 | CI\/CD and supply chain | Build compromise malicious dependencies | Build logs artifact provenance SBOM | CI scanners SBOM registry\nL7 | Serverless and managed PaaS | Function abuse, over-privileged services | Function logs cold starts outbound calls | Cloud function tracing IAM\nL8 | Observability and tooling | Evasion and log tampering techniques | Missing telemetry gaps synthetic checks | Observability pipelines SIEM<\/p>\n\n\n\n
When it\u2019s necessary<\/p>\n\n\n\n
When it\u2019s optional<\/p>\n\n\n\n
When NOT to use \/ overuse it<\/p>\n\n\n\n
Decision checklist<\/p>\n\n\n\n
Maturity ladder<\/p>\n\n\n\n
Components and workflow<\/p>\n\n\n\n
Data flow and lifecycle<\/p>\n\n\n\n
Edge cases and failure modes<\/p>\n\n\n\n
ID | Failure mode | Symptom | Likely cause | Mitigation | Observability signal\nF1 | Telemetry blindspot | No alerts for known technique | Missing agent or log config | Deploy agents enrich logs verify pipelines | Missing logs metric increased\nF2 | Alert fatigue | Alerts ignored by on-call | High false positives | Tune rules add thresholds and suppression | High ack latency alert volume\nF3 | Automation misfire | Automated rollback loops | Unsafe automation policy | Add safety gates manual approvals | Repeated deployment events\nF4 | Rule evasion | Adversary bypasses detection | Signature dependence not behavior | Move to behavior analytics | Increase in anomalous sessions\nF5 | Configuration drift | Controls not applied consistently | Manual changes in infra | IaC enforcement drift detect | Config drift alerts\nF6 | Runbook mismatch | Playbook fails in ops | Outdated procedures | Regular validation and drills | Runbook execution errors\nF7 | Supply chain compromise | Malicious artifact in build | Unverified dependencies | SBOM verify signed artifacts | Unexpected build artifact hashes<\/p>\n\n\n\n
(40+ terms; each line: Term \u2014 definition \u2014 why it matters \u2014 common pitfall)<\/p>\n\n\n\n
Adversary \u2014 an entity performing malicious actions \u2014 core actor to model \u2014 conflating actor with technique\nAttack surface \u2014 exposed assets that can be targeted \u2014 identifies scope to protect \u2014 omitting internal services\nBehavioral detection \u2014 detection based on actions not artifacts \u2014 resilient to polymorphism \u2014 noisy if poorly tuned\nBlue team \u2014 defenders implementing detection and response \u2014 operationalizes TTPs \u2014 siloed from engineering\nCanary deployment \u2014 phased rollout to limit blast radius \u2014 reduces deployment risk \u2014 misconfigured canaries fail\nChaos engineering \u2014 controlled failure injection for validation \u2014 validates TTP resiliency \u2014 inadequate rollbacks\nCloud native \u2014 services designed for cloud scale \u2014 affects TTP manifestation \u2014 assuming monolith patterns\nControl plane \u2014 orchestration components managing infrastructure \u2014 high-value target \u2014 under-monitoring control plane\nCredential stuffing \u2014 automated login attempts using leaked creds \u2014 common initial access \u2014 ignoring rate limits\nDetection engineering \u2014 building reliable detection logic \u2014 converts TTPs to rules \u2014 overfitting to datasets\nDefense in depth \u2014 layered security controls \u2014 limits single point of failure \u2014 false sense of completeness\nDLP \u2014 data loss prevention systems \u2014 detect exfiltration \u2014 blind to encrypted exfiltration\nEgress filtering \u2014 restrict outbound network flows \u2014 prevents exfiltration \u2014 overly strict blocks legitimate traffic\nElasticity \u2014 dynamic scaling of services \u2014 changes timing of TTPs \u2014 misinterpreting scale behaviors\nEndpoint detection \u2014 host-based monitoring \u2014 catch local techniques \u2014 incomplete coverage across fleet\nEvent correlation \u2014 linking discrete events into incidents \u2014 reduces noise \u2014 complex rules cause lag\nFalse positive \u2014 benign event flagged as malicious \u2014 erodes trust \u2014 tuning often deprioritized\nForensic imaging \u2014 snapshotting evidence for analysis \u2014 preserves chain of custody \u2014 resource intensive\nIdentity and access management \u2014 controls who can do what \u2014 foundational to many TTPs \u2014 overly permissive roles\nIncident response \u2014 structured process to handle incidents \u2014 executes procedures \u2014 skipping lessons learned\nInstrumentation \u2014 adding telemetry points \u2014 necessary to observe TTPs \u2014 instrumenting too much noise\nInventory \u2014 catalog of assets and services \u2014 enables scope and risk assessment \u2014 often outdated\nIOC \u2014 artifact indicating compromise like IP or hash \u2014 quick detection aid \u2014 easily evaded\nKillswitch \u2014 method to stop malicious activity quickly \u2014 limits damage \u2014 complex to implement safely\nLateral movement \u2014 attacker moving within network \u2014 critical to detect early \u2014 noisy heuristics\nLeast privilege \u2014 granting minimal required access \u2014 reduces exploitation impact \u2014 difficult to implement fully\nLog retention \u2014 how long logs are kept \u2014 enables retrospective analysis \u2014 cost and privacy trade-offs\nMFA \u2014 multifactor authentication \u2014 reduces credential-based attacks \u2014 can be bypassed by phishing\nMITRE ATT ACK \u2014 taxonomy mapping tactics to techniques \u2014 shared reference for TTP mapping \u2014 treated as exhaustive\nObservability pipeline \u2014 ingestion, storage, analysis of telemetry \u2014 backbone for TTP detection \u2014 single point of failure\nPlaybook \u2014 prescriptive steps for response \u2014 operationalizes TTPs \u2014 stale playbooks fail during incidents\nPurple team \u2014 collaborative testing between red and blue \u2014 accelerates detection maturity \u2014 requires coordination\nRate limiting \u2014 throttle requests to reduce abuse \u2014 mitigates automated attacks \u2014 may block legitimate traffic\nRBAC \u2014 role based access control \u2014 practical access model \u2014 role explosion complexity\nRemediation automation \u2014 scripted fixes triggered by detection \u2014 reduces MTTK\/MTTR \u2014 unsafe automation causes regressions\nRunbook \u2014 stepwise instructions for practitioners \u2014 reduces cognitive load \u2014 missing preconditions\nSBOM \u2014 software bill of materials \u2014 tracks component provenance \u2014 not universally available\nSIEM \u2014 security analytics and correlation tool \u2014 centralizes detections \u2014 noisy without tuning\nSOAR \u2014 security orchestration and automation \u2014 coordinates automated response \u2014 brittle playbooks cause loops\nSLO \u2014 service level objective \u2014 applies to detection and response performance \u2014 poor SLOs misalign priorities\nSLI \u2014 service level indicator \u2014 measurable metric for SLOs \u2014 selecting wrong SLI is misleading\nSupply chain \u2014 dependencies and vendors in software delivery \u2014 common attack vector \u2014 incomplete visibility\nTelemetry integrity \u2014 assurance logs\/events are untampered \u2014 critical for trust \u2014 rarely validated\nThreat modeling \u2014 structured analysis of attacker paths \u2014 guides TTP prioritization \u2014 often skipped\nThreat feed \u2014 list of current IOCs and campaigns \u2014 enriches detection \u2014 noisy and low precision\nTLS metadata \u2014 connection metadata useful for detection \u2014 less privacy-invasive than payload \u2014 limited visibility\nZero trust \u2014 assume no implicit trust between components \u2014 reduces lateral movement \u2014 complex migration<\/p>\n\n\n\n
ID | Metric\/SLI | What it tells you | How to measure | Starting target | Gotchas\nM1 | Time to detect | How long until a technique is detected | Median time from event to alert | 15 minutes for high-risk | Depends on telemetry latency\nM2 | Time to remediate | Time from detection to containment | Median time from alert to containment | 1 hour for critical | Automation may mask manual gaps\nM3 | Detection coverage | Percent of techniques with detection | Techniques detected divided by catalog size | 70 percent initial | Coverage quality varies\nM4 | False positive rate | % alerts that are benign | Number of false alerts over total alerts | <5 percent for critical alerts | Depends on labeling consistency\nM5 | Alert volume per service | Alert noise and scale | Alerts per hour per service per team | <5 per hour per team | High traffic services skew rates\nM6 | Runbook success rate | % runbook executions that resolved incident | Successful outcomes over attempts | 95 percent | Requires clear success criteria\nM7 | Automation rollback rate | Frequency of automation-induced rollbacks | Rollbacks per deployment due to automation | <1 percent | Tracking causal links is hard\nM8 | Mean time to acknowledge | Time until on-call acknowledges alert | Median ack latency | 5 minutes for pages | Alert routing affects this\nM9 | Adversary dwell time | Duration attacker persists before removal | From compromise to containment | <24 hours target | Requires forensic fidelity\nM10 | Telemetry completeness | Percent of services with required logs | Services emitting required events \/ total | 100 percent for critical assets | Cost and retention trade-offs<\/p>\n\n\n\n
(Each tool section follows exact structure)<\/p>\n\n\n\n
Executive dashboard<\/p>\n\n\n\n
On-call dashboard<\/p>\n\n\n\n
Debug dashboard<\/p>\n\n\n\n
Alerting guidance<\/p>\n\n\n\n
1) Prerequisites\n– Inventory critical assets, data classification, and owners.\n– Centralize logging and ensure identity catalog.\n– Baseline threat model and attack surface map.<\/p>\n\n\n\n
2) Instrumentation plan\n– Define telemetry requirements per layer (network, host, app, infra).\n– Add standardized fields and context like service name and environment.\n– Ensure secure transport and integrity of telemetry.<\/p>\n\n\n\n
3) Data collection\n– Centralize logs in a scalable store with retention aligned to risk.\n– Normalization and enrichment with identity and asset metadata.\n– Implement sampling where necessary without losing critical signals.<\/p>\n\n\n\n
4) SLO design\n– Choose SLIs tied to detection and response metrics.\n– Set SLOs based on risk and capability, and document error budgets.<\/p>\n\n\n\n
5) Dashboards\n– Build executive, on-call, and debug views.\n– Map panels directly to runbook steps.<\/p>\n\n\n\n
6) Alerts & routing\n– Define severity levels and on-call rotations.\n– Implement automated routing and escalation paths.<\/p>\n\n\n\n
7) Runbooks & automation\n– Create concise runbooks with preconditions and rollback steps.\n– Automate low-risk remediation with observational gating.<\/p>\n\n\n\n
8) Validation (load\/chaos\/game days)\n– Run purple team exercises, scheduled chaos security and game days.\n– Test automation safety gates under load.<\/p>\n\n\n\n
9) Continuous improvement\n– Postmortem analysis, update playbooks, and iterate on detection rules.<\/p>\n\n\n\n
Checklists<\/p>\n\n\n\n
Pre-production checklist<\/p>\n\n\n\n
Production readiness checklist<\/p>\n\n\n\n
Incident checklist specific to Tactics Techniques and Procedures<\/p>\n\n\n\n
Provide 8\u201312 use cases<\/p>\n\n\n\n
1) Use Case: Protecting customer PII\n– Context: SaaS storing PII across microservices.\n– Problem: Unauthorized access and exfiltration risk.\n– Why TTPs help: Map exfiltration tactics to detection and egress controls.\n– What to measure: Time to detect data access anomalies, DLP alerts.\n– Typical tools: DLP, SIEM, APM.<\/p>\n\n\n\n
2) Use Case: CI\/CD compromise prevention\n– Context: Automated builds and artifact publishing.\n– Problem: Build pipeline compromise injects malicious code.\n– Why TTPs help: Define pipeline-specific techniques and hardening steps.\n– What to measure: Build provenance verification, SBOM coverage.\n– Typical tools: SBOM tools, CI scanners, artifact signing.<\/p>\n\n\n\n
3) Use Case: Kubernetes cluster protection\n– Context: Multi-tenant K8s clusters.\n– Problem: Privilege escalation via misconfigured RBAC.\n– Why TTPs help: Map control plane tactics to audit and policy enforcement.\n– What to measure: Suspicious pod execs, abnormal kube API calls.\n– Typical tools: K8s audit log, policy engine, EDR.<\/p>\n\n\n\n
4) Use Case: Serverless data exfiltration prevention\n– Context: Event-driven functions with wide permissions.\n– Problem: Function abused to exfiltrate secrets.\n– Why TTPs help: Define least privilege techniques and runtime telemetry.\n– What to measure: Outbound traffic patterns, secret access frequency.\n– Typical tools: Function tracing, IAM policies, egress filters.<\/p>\n\n\n\n
5) Use Case: Ransomware containment\n– Context: Hybrid cloud with Windows file shares.\n– Problem: Rapid file encryption across machines.\n– Why TTPs help: Early detection techniques for mass file modifications.\n– What to measure: File change rates, process spawning patterns.\n– Typical tools: EDR, backup monitors, antivirus orchestration.<\/p>\n\n\n\n
6) Use Case: Supply chain compromise detection\n– Context: Use of third-party packages.\n– Problem: Malicious dependency included in build.\n– Why TTPs help: Track provenance and behavior of dependencies.\n– What to measure: SBOM anomalies, build artifact hashes.\n– Typical tools: SBOM, CI scanners, artifact registries.<\/p>\n\n\n\n
7) Use Case: Fraud detection in payments\n– Context: High volume API transactions.\n– Problem: Credential stuffing and synthetic accounts.\n– Why TTPs help: Behavioral techniques detect unusual transaction patterns.\n– What to measure: Transaction velocity, device fingerprint anomalies.\n– Typical tools: APM, fraud detection engines, rate limiters.<\/p>\n\n\n\n
8) Use Case: Insider threat detection\n– Context: Trusted employees with access.\n– Problem: Data exfiltration using legitimate credentials.\n– Why TTPs help: Define lateral movement and exfiltration techniques for insiders.\n– What to measure: Data access spikes, unusual access times.\n– Typical tools: DLP, IAM analytics, UBA.<\/p>\n\n\n\n
9) Use Case: Post-deployment anomaly detection\n– Context: Frequent deployments across services.\n– Problem: Malicious or buggy releases cause abnormal behavior.\n– Why TTPs help: Map deployment-related techniques and rollout checks.\n– What to measure: Error rates post-deploy, latency spikes.\n– Typical tools: APM, deployment monitoring, canary tooling.<\/p>\n\n\n\n
10) Use Case: API abuse prevention\n– Context: Public APIs with usage tiers.\n– Problem: Abuse via scraping, replay, or automated attacks.\n– Why TTPs help: Define techniques for rate attacks and bot behavior.\n– What to measure: Request patterns, anomaly scores.\n– Typical tools: WAF, API gateway, rate limiter.<\/p>\n\n\n\n
Context:<\/strong> Multi-tenant K8s cluster hosting customer workloads. Context:<\/strong> Company uses serverless functions for image processing with external API calls. Context:<\/strong> Mid-size org suffered database leak via misconfigured backup scripts. Context:<\/strong> High traffic API sees exponential logs growth making detection expensive. (List 15\u201325 mistakes with Symptom -> Root cause -> Fix)<\/p>\n\n\n\n 1) Symptom: Silent compromises discovered late -> Root cause: telemetry blindspots -> Fix: instrument missing data sources and validate pipelines. Observability-specific pitfalls (at least 5 included above)<\/p>\n\n\n\n Ownership and on-call<\/p>\n\n\n\n Runbooks vs playbooks<\/p>\n\n\n\n Safe deployments (canary\/rollback)<\/p>\n\n\n\n Toil reduction and automation<\/p>\n\n\n\n Security basics<\/p>\n\n\n\n Weekly\/monthly routines<\/p>\n\n\n\n Postmortem reviews should include<\/p>\n\n\n\n ID | Category | What it does | Key integrations | Notes\nI1 | SIEM | Centralizes and correlates security events | Cloud logs EDR SOAR | Use for long-term retention\nI2 | SOAR | Orchestrates response and automation | SIEM ticketing IAM | Automate low-risk remediations\nI3 | EDR | Host-level telemetry and response | SIEM ORCHESTRATION | High-fidelity process data\nI4 | APM | Application traces and performance | Logs CI\/CD | Useful for detecting app-layer attacks\nI5 | K8s audit | Control plane event logging | SIEM policy engines | Critical for orchestration visibility\nI6 | IAM analytics | Detect anomalous access patterns | SIEM SSO | Focus on identity-based techniques\nI7 | SBOM registry | Track software component provenance | CI\/CD artifact store | Enables supply chain validation\nI8 | DLP | Prevents or alerts on data exfiltration | Storage and email systems | Works best with contextual policies\nI9 | Policy engine | Enforces IaC and runtime policies | Git repo K8s API | Use for prevention at gate\nI10 | Observability platform | Metrics traces logs correlation | App runtime infrastructure | Bridge to security telemetry<\/p>\n\n\n\n Tactics are high-level goals like initial access, persistence, privilege escalation, lateral movement, and exfiltration.<\/p>\n\n\n\n TTPs are behavior and process oriented; indicators are specific artifacts like IPs or hashes.<\/p>\n\n\n\n Yes. Defensive procedures can be automated via SOAR and policy engines but must include safety gates.<\/p>\n\n\n\n Regularly; after incidents, quarterly during threat model reviews, and when platform changes occur.<\/p>\n\n\n\n Yes. Defensive TTPs codify detection and response procedures and are essential for operations.<\/p>\n\n\n\n Use risk, asset value, and exploitability to prioritize; focus on high-impact tactics first.<\/p>\n\n\n\n Use SLIs like time to detect, detection coverage, and adversary dwell time.<\/p>\n\n\n\n Frameworks provide taxonomy mapping tactics to techniques; TTPs include procedural details and context.<\/p>\n\n\n\n TTPs shift to runtime and identity abuse patterns with higher need for telemetry from cloud providers.<\/p>\n\n\n\n Lack of enrichment and contextual metadata leading to generic rule matches.<\/p>\n\n\n\n Classify services by criticality and use adaptive sampling and tiered retention.<\/p>\n\n\n\n Developers should contribute context; runbook ownership typically rests with ops or SRE with dev input.<\/p>\n\n\n\n Use purple team exercises, red team engagements, and automated security chaos tests.<\/p>\n\n\n\n It can support compliance, but its primary use is operational detection and response.<\/p>\n\n\n\n Implement safety gates, approve lists, and circuit breakers in automated playbooks.<\/p>\n\n\n\n Depends on risk; common starting target for critical assets is 15 minutes detection and 1 hour remediation.<\/p>\n\n\n\n Store logs in tamper-evident storage, use signed shipping, and monitor for missing segments.<\/p>\n\n\n\n It’s a valuable taxonomy but must be extended for cloud-native and AI-driven techniques.<\/p>\n\n\n\n Tactics, Techniques, and Procedures are the operational bridge between strategic threat understanding and practical defensive action. In cloud-native and AI-driven environments of 2026, TTPs must be behavior-focused, automated, and continuously validated. Building reliable telemetry, SLO-driven detection, and safe automation reduces dwell time, limits impact, and supports organizational velocity.<\/p>\n\n\n\n Next 7 days plan<\/p>\n\n\n\n Primary keywords<\/p>\n\n\n\n Secondary keywords<\/p>\n\n\n\n Long-tail questions<\/p>\n\n\n\n Related terminology<\/p>\n\n\n\n —<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-2025","post","type-post","status-publish","format-standard","hentry"],"yoast_head":"\n\n
Scenario #2 \u2014 Serverless Function Abuse<\/h3>\n\n\n\n
\n
Scenario #3 \u2014 Incident Response Postmortem Using TTPs<\/h3>\n\n\n\n
\n
Scenario #4 \u2014 Cost vs Performance Trade-off During Detection Scaling<\/h3>\n\n\n\n
\n
\n\n\n\nCommon Mistakes, Anti-patterns, and Troubleshooting<\/h2>\n\n\n\n
\n
\n\n\n\nBest Practices & Operating Model<\/h2>\n\n\n\n
\n
\n
\n
\n
\n
\n
\n
\n\n\n\nTooling & Integration Map for Tactics Techniques and Procedures (TABLE REQUIRED)<\/h2>\n\n\n\n
Row Details (only if needed)<\/h4>\n\n\n\n
\n
\n\n\n\nFrequently Asked Questions (FAQs)<\/h2>\n\n\n\n
What are examples of tactics?<\/h3>\n\n\n\n
How do TTPs differ from indicators?<\/h3>\n\n\n\n
Can TTPs be automated?<\/h3>\n\n\n\n
How often should TTPs be updated?<\/h3>\n\n\n\n
Do TTPs apply to defenders as well as attackers?<\/h3>\n\n\n\n
How do you prioritize which TTPs to address first?<\/h3>\n\n\n\n
How to measure success of TTP coverage?<\/h3>\n\n\n\n
Are frameworks like MITRE ATT ACK the same as TTPs?<\/h3>\n\n\n\n
How do serverless environments change TTPs?<\/h3>\n\n\n\n
What’s a common cause of false positives?<\/h3>\n\n\n\n
How to handle noisy telemetry data cost-effectively?<\/h3>\n\n\n\n
Should developers maintain runbooks?<\/h3>\n\n\n\n
How to test TTP-based detections?<\/h3>\n\n\n\n
Is TTP documentation a compliance artifact?<\/h3>\n\n\n\n
How to prevent automation causing outages?<\/h3>\n\n\n\n
What SLO should I set for time to detect?<\/h3>\n\n\n\n
How to track telemetry integrity?<\/h3>\n\n\n\n
Is ATT ACK static enough for 2026?<\/h3>\n\n\n\n
\n\n\n\nConclusion<\/h2>\n\n\n\n
\n
\n\n\n\nAppendix \u2014 Tactics Techniques and Procedures Keyword Cluster (SEO)<\/h2>\n\n\n\n
\n
\n
\n
\n