Threat Modeling with STRIDE: A Practical Guide for Industrial Systems

Security requirements shouldn’t be guessed—they should be derived from a structured analysis of the threats your system faces. Threat modeling provides exactly that: a systematic way to identify, analyze, and prioritize security risks.

What is Threat Modeling?

Threat modeling is a structured process for identifying and documenting security threats early in the development lifecycle. It answers the fundamental question: “What are we protecting against, and why?”

Why Threat Modeling Matters

Benefit	Description
Early risk identification	Find security issues before code is written
Focused security efforts	Spend resources on real threats, not hypothetical ones
Better security requirements	Requirements derived from actual threat scenarios
Compliance alignment	Required by IEC 62443-4-1 SR-2
Stakeholder communication	Makes security risks tangible to non-security experts

When to Threat Model

Development Lifecycle:
Requirements ──► Design ──► Code ──► Test ──► Release
       ▲                                    │
       └──────── Threat Modeling ───────────┘
       (Ideally at Requirements & Design phases)

Best practice: Threat model early, then update as the design evolves.

The STRIDE Methodology

STRIDE is a threat classification model developed by Microsoft that provides a systematic way to think about attacker goals.

STRIDE Acronym Explained

Letter	Threat	Description	Industrial Example
S	Spoofing	Impersonating something or someone	Fake HMI login to gain system access
T	Tampering	Modifying data or code	Altering control commands to damage equipment
R	Repudiation	Denying having performed an action	Attacker denies sending dangerous command
I	Information Disclosure	Exposing information to unauthorized parties	Leaking sensitive process configuration
D	Denial of Service	Disrupting service availability	Flooding network to disrupt control
E	Elevation of Privilege	Gaining unauthorized capabilities	Low-privilege user gaining admin rights

Threat Modeling for Industrial Systems

System Decomposition

Before identifying threats, you must understand your system. For an Energy Management System (EMS):

┌─────────────────────────────────────────────────────────────────┐
│                      EMS System Context                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  External Actors                                                │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐           │
│  │Cloud    │  │Grid     │  │Maintenance│ │Attacker  │           │
│  │Platform │  │Operator │  │Technician│  │         │           │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘           │
│       │            │            │            │                  │
│       └────────────┴────────────┴────────────┘                  │
│                         │                                       │
│  EMS Boundary                                                  │
│  ┌─────────────────────────────────────────────────────────────┐│
│  │  ┌───────────┐  ┌────────────┐  ┌──────────────────────┐  ││
│  │  │ Web API   │  │ Core Logic │  │ Data Store           │  ││
│  │  └─────┬─────┘  └─────┬──────┘  └──────────┬───────────┘  ││
│  │        │              │                    │              ││
│  │        └──────────────┴────────────────────┘              ││
│  │                       │                                   ││
│  │  Interfaces                                             ││
│  │  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐   ││
│  │  │Modbus│  │IEC104│  │MQTT  │  │HMI   │  │USB   │   ││
│  │  └──────┘  └──────┘  └──────┘  └──────┘  └──────┘   ││
│  └─────────────────────────────────────────────────────────────┘│
│                         │                                       │
│  External Systems                                               │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐                        │
│  │  BMS    │  │  PCS    │  │  Meter  │                        │
│  └─────────┘  └─────────┘  └─────────┘                        │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Data Flow Diagrams

For each interface, document:

1. Data flows (what is being sent?)
2. Protocols (how is it sent?)
3. Trust boundaries (where does trust end?)

Interface	Data	Protocol	Trust Boundary
EMS ↔ Cloud	Status, commands	MQTT over TLS	External
EMS ↔ BMS	Battery data, limits	Modbus RTU	Internal
EMS ↔ PCS	Power commands	Modbus TCP	Internal
HMI ↔ EMS	UI interactions	HTTP/WebSocket	Local

Applying STRIDE to EMS: A Detailed Example

S - Spoofing Threats

Threat	Scenario	Risk Level	Countermeasure
Fake HMI login	Attacker guesses password	Medium	Strong password policy, lockout
Spoofed BMS	Rogue device sends false battery data	High	Device authentication, certificate validation
Cloud impersonation	Man-in-the-middle cloud connection	Medium	Mutual TLS, certificate pinning

Security Requirement: “The EMS shall authenticate all external connections using mutually authenticated TLS with certificate validation.”

T - Tampering Threats

Threat	Scenario	Risk Level	Countermeasure
Modified control commands	Attacker alters power setpoints	Critical	Command signing, input validation
Firmware replacement	Malicious firmware installed	Critical	Secure boot, firmware signature verification
Configuration changes	Unauthorized setting changes	High	Change logging, approval workflow

Security Requirement: “The EMS shall verify the integrity of all received control commands using cryptographic signatures.”

R - Repudiation Threats

Threat	Scenario	Risk Level	Countermeasure
Denied command execution	Operator denies sending dangerous command	Medium	Comprehensive audit logging
Deleted logs	Attacker covers tracks	High	Immutable log storage, log forwarding

Security Requirement: “The EMS shall maintain tamper-evident audit logs of all security-relevant events.”

I - Information Disclosure Threats

Threat	Scenario	Risk Level	Countermeasure
Exposed credentials	Passwords sent in clear	High	Encrypted storage, no plaintext transmission
Leaked process data	Sensitive configuration exposed	Medium	Role-based access, data encryption at rest
Debug information	Error messages reveal system details	Low	Generic error messages

Security Requirement: “The EMS shall encrypt all sensitive data at rest and in transit.”

D - Denial of Service Threats

Threat	Scenario	Risk Level	Countermeasure
Network flooding	Attacker overwhelms EMS network interface	High	Rate limiting, traffic filtering
Resource exhaustion	Malicious requests consume CPU/memory	Medium	Resource quotas, connection limits
Protocol abuse	Exploiting protocol weaknesses	Medium	Protocol validation, anomaly detection

Security Requirement: “The EMS shall implement rate limiting and resource quotas to prevent service exhaustion.”

E - Elevation of Privilege Threats

Threat	Scenario	Risk Level	Countermeasure
Privilege escalation	Regular user gains admin rights	High	Privilege separation, access control
Role confusion	User performs action outside role	Medium	Role-based access control, principle of least privilege
Session hijacking	Attacker takes over valid session	Medium	Session timeout, secure session management

Security Requirement: “The EMS shall enforce role-based access control with the principle of least privilege.”

Threat Modeling Process

Step-by-Step Workflow

┌─────────────────────────────────────────────────────────────────┐
│                   Threat Modeling Workflow                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  1. Decompose System                                            │
│     └─ Create architecture diagram, identify trust boundaries    │
│                                                                  │
│  2. Identify Threats (STRIDE)                                   │
│     └─ Apply STRIDE to each element, data flow, and interaction  │
│                                                                  │
│  3. Analyze Threats                                             │
│     └─ Assess impact, likelihood, and risk for each threat     │
│                                                                  │
│  4. Mitigate Threats                                            │
│     └─ Define countermeasures for prioritized threats          │
│                                                                  │
│  5. Validate                                                    │
│     └─ Confirm mitigations effectively reduce risk              │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Risk Assessment

For each identified threat, assess:

Factor	Questions
Impact	What’s the worst case? Safety impact? Equipment damage?
Likelihood	How easy is this to exploit? Required skill level?
Existing Mitigations	What already protects against this?

Risk Matrix:

                High Impact
                    │
        High  │    ┌───┐
        Risk  │    │ █ │ ← Priority for mitigation
              │    └───┘
     Medium    │  ┌─────┐
        Risk   │  │ ██  │
              │  └─────┘
              │
     Low     │  ┌───────┐
        Risk  │  │ ███  │
              │  └───────┘
              └────────────────────────────▶
                 Low Likelihood      High Likelihood

From Threats to Security Requirements

Each mitigated threat should result in one or more security requirements:

Example Traceability

Threat ID	Threat Description	Mitigation	Requirement ID	Security Requirement
EMS-T-001	Tampered control commands	Command signing	SR-01	Verify command signatures
EMS-I-001	Exposed credentials	Encryption at rest	SR-02	Encrypt stored passwords
EMS-D-001	Network flooding	Rate limiting	SR-03	Implement rate limiting

This creates the threat-to-requirements traceability required by IEC 62443-4-1.

Industrial-Specific Considerations

Safety vs. Security

In industrial systems, always consider the safety impact:

Threat: Unauthorized firmware update
Security Mitigation: Require signature verification
Safety Consideration: What if verification fails mid-update?
Refined Mitigation: Verify before installation, allow rollback

Availability Priority

Some security measures may conflict with availability:

Security Measure	Availability Concern	Compromise
Account lockout	Legitimate user locked out	Time-based lockout, override
Strict authentication	Emergency access delayed	Local emergency accounts
Network isolation	Maintenance access blocked	Configurable zones

Threat Modeling Tools

Manual Approaches

Tool	Description	Best For
Whiteboard diagrams	Collaborative threat identification	Brainstorming sessions
Excel spreadsheets	Structured threat documentation	Small teams, simple systems
STRIDE-per-element	Systematic application	Comprehensive coverage

Automated Tools

Tool	Description	Consideration
Microsoft Threat Model	Free threat modeling tool	Designed for Azure, adaptable for OT
IriusRisk	Open-source threat modeling	Good for risk management integration
OWASP PyTM	Python-based framework	Developer-friendly

Note: Manual threat modeling often yields better insights for OT systems where domain expertise matters.

Common Threat Modeling Mistakes

Mistake 1: Threat Modeling Too Late

Wrong: Threat modeling after implementation
Right: Threat modeling during requirements and design

Mistake 2: Only Considering External Threats

Wrong: "Attackers come from the internet"
Right: Consider insider threats, supply chain, physical access

Mistake 3: Ignoring Legacy Constraints

Wrong: "Use modern security protocol X"
Right: "What can we secure with existing protocols?"

Key Takeaways

1. Threat modeling is essential for IEC 62443-4-1 compliance (SR-2 requirement)
2. STRIDE provides structure for systematic threat identification
3. Industrial context matters—always consider safety and availability
4. Create traceability—from threats to requirements to testing
5. Iterate continuously—update as system and threats evolve

Getting Started Checklist

□ Assemble threat modeling team (security, engineering, operations)
□ Define system scope and boundaries
□ Create system architecture diagram
□ Identify trust boundaries
□ Apply STRIDE to each element
□ Document threats in threat register
□ Assess and prioritize threats
□ Define mitigations and security requirements
□ Get stakeholder review and approval
□ Plan for periodic re-modeling

Conclusion

Threat modeling transforms security from guessing to engineering. By systematically identifying threats using STRIDE, you build security requirements that actually address the risks your industrial systems face.

In the world of industrial cybersecurity, understanding your threats isn’t optional—it’s foundational. Start threat modeling early, and make it a continuous practice throughout your product lifecycle.

---

Effective threat modeling is the bridge between “we need security” and “here’s what we need to secure against.”