Threat Modeling Methodologies: STRIDE and PASTA — A Chaotic TA's Guide for IoT/OT

You already poked firmware, mapped OT networks, and obsessively refreshed SBOMs. Now let us stop improvising and start predicting the bad things that will happen before they do.

This lesson builds on our previous excursions through defense-in-depth for IoT/OT, device lifecycle and patching, and automotive/transportation concerns. We will translate that gritty, hardware-flavored knowledge into two practical threat modeling methodologies: STRIDE and PASTA. Think of STRIDE as the quick, sticky-note checklist; PASTA as the full crime-scene investigation report that someone will actually use to arrest the attacker (or at least to satisfy the compliance auditor).

---

Why threat modeling matters for IoT/OT (and why you should care)

• IoT and OT systems are cyber-physical: breaches can flip switches, derail trains, or brick medical devices.
• Patch cycles are long and provenance is messy (hello, SBOM gaps). Threat modeling forces you to be intentional about where to spend limited resources.

Question to grind your brain: Which is worse — a remote code execution on an HVAC thermostat or privilege escalation on a plant PLC? Threat modeling helps you answer that by mapping impact to context.

---

STRIDE: Fast, focused, and excellent at pointing fingers

STRIDE is an acronym for six threat categories:

• Spoofing identity
• Tampering with data
• Repudiation
• Information disclosure
• Denial of service
• Elevation of privilege

Why STRIDE here? Because for IoT/OT you need a taxonomy you can apply to many components quickly — sensors, gateways, firmware update paths, CAN buses, MQTT brokers, etc.

How to use STRIDE (5-minute ritual)

1. Map system components: sensors, actuators, gateways, PLCs, cloud, maintenance workstation.
2. For each component, run the STRIDE checklist and list plausible threats.
3. Note impact and exploitability — be realistic about physical access and network segmentation.
4. Prioritize fixes where impact × likelihood is highest.

Example: Firmware update flow for a PLC

• Spoofing: An attacker impersonates the update server to push malicious firmware.
• Tampering: Update binary modified in transit if signature check is missing.
• Repudiation: No logs of who triggered the update — impossible to prove intent.
• Info disclosure: Update exposes debug logs containing credentials.
• DoS: Malicious update bricks PLC.
• Elevation: Malicious firmware grants root to an attacker.

If you spot signature verification missing or weak, you stop the attack chain early.

---

PASTA: The cinematic, attacker-centric multi-act play

PASTA stands for Process for Attack Simulation and Threat Analysis. It is a seven-stage methodology that centers on understanding attacker intent and modeling attack scenarios end-to-end.

PASTA stages (compressed):

1. Define objectives (business and security goals)
2. Define technical scope (assets, data flows, trust boundaries)
3. Application decomposition (detailed architecture and components)
4. Threat analysis (identify threats and attacker profiles)
5. Vulnerability and weakness analysis
6. Attack modeling and simulation (construct attack paths)
7. Risk and impact analysis (prioritize mitigations)

Why PASTA for IoT/OT? Because when lives or physical processes are involved, you need scenario-based thinking: how could an attacker chain a trivial vulnerability into a catastrophic physical effect?

Example: Connected vehicle telematics unit (high-level PASTA application)

• Objectives: Prevent remote takeover and protect passenger data.
• Scope: Telematics unit, CAN gateway, cloud backend, smartphone app, OTA update service.
• Decompose: Data flows from sensors to cloud; trust boundary at mobile app pairing; OTA pipeline components.
• Threats: Remote code exec via vulnerable diagnostic port; MITM of OTA; lateral movement to CAN.
• Vulnerabilities: Unauthenticated debug port; weak TLS on legacy backend; missing CAN firewall rules.
• Attack simulation: Attacker exploits debug port during dealership maintenance, injects a CAN message that disables braking assist.
• Risk analysis: High impact, medium likelihood at scale — prioritize physical access controls and OTA signing.

---

STRIDE vs PASTA: When to use which (table time)

Dimension	STRIDE	PASTA
Speed	Fast	Slow(er)
Depth	Shallow to moderate	Deep and scenario-driven
Best for	Checklists, quick audits	Comprehensive risk programs
Output	Threat list per component	Attack paths, risk treatment plans
Good with IoT/OT?	Yes — great for surface mapping	Yes — essential for high-impact cyber-physical risks

---

AI and threat modeling: friend or bad karaoke partner?

AI can help accelerate both methods:

• Automate component inventory from network scans and SBOM data.
• Generate candidate threats from STRIDE templates for each component.
• Simulate attack chains in PASTA with probabilistic scoring.

But watch out:

AI amplifies biases. If your training data lacks OT incidents, it will understate physical attack chains.

If you use AI, validate its suggestions with domain experts (plant engineers, automotive safety engineers). AI is a clever assistant, not the PI.

---

Quick templates and cheats

Pseudocode for a simple risk score using STRIDE outputs:

for each component:
  for each threat in STRIDE:
    likelihood = estimate_likelihood(threat)
    impact = estimate_impact(threat)   # factor in physical consequences
    score = likelihood * impact
rank threats by score

A checklist for OT-specific STRIDE additions:

• Physical access required? (yes/no)
• Can exploit cause physical harm? (severity 0-5)
• Is there a manual fail-safe? (yes/no)
• Does the mitigation require hardware change?

---

Closing: How to not suck at threat modeling

• Use STRIDE for rapid, repeatable scans across devices and firmware.
• Use PASTA when risk is high or attack surfaces are complex and cross domains.
• Combine both: STRIDE to enumerate, PASTA to simulate realistic attack chains and remediation.
• Put engineers, field techs, safety officers, and an AI assistant in the same room. Yes, it will be chaotic. Do it anyway.

Key takeaways:

• Threat modeling is about choices: you cannot patch everything. Prioritize what would actually break the plant, the car, or the body.
• IoT/OT adds real-world consequences. That changes your impact calculations and timelines.
• AI speeds things up, but validation and domain expertise remain king.

Final insight: If your threat model does not change how you spend money or change behavior, it is a pretty drawing on a wall. Make it actionable.

---

Tags: use STRIDE for quick wins, PASTA for courtroom-grade analysis, and always, always log update events.