Industrial Control Systems (ICS) and Operational Technology (OT) run the physical processes that power our world: electricity, oil and gas, water treatment, manufacturing, transportation, smart buildings, and more. As these systems become more connected—through IIoT, cloud platforms, and remote access—they also become more exposed to cyber threats.

1. Understanding the ICS Threat Landscape

Before you can gather the right intelligence or build a useful threat model, you need a clear picture of what you’re defending and who you’re defending against.

1.1 What Makes ICS and OT Different from IT?

Traditional IT security is mostly about data:

Protecting confidentiality of information
Ensuring integrity of systems and data
Maintaining availability of business services

In ICS and OT, the priorities look different. In practice they are often:

Safety – people, environment, and equipment
Availability and reliability of physical processes
Integrity of control logic and process data
Confidentiality of information

This difference drives everything:

You can’t just reboot a controller because of a security scan.
Patch cycles are tied to production schedules and safety certifications.
Some systems are decades old, running unsupported operating systems and proprietary protocols.
Stopping a process can mean millions in lost production or serious safety risks.

Because of this, the ICS threat landscape is shaped not only by technology but also by process safety, engineering constraints, and regulatory requirements.

1.2 Typical ICS and OT Environments

When we talk about ICS, we’re referring to a wide variety of environments, such as:

Electric power generation, transmission, and distribution
Oil and gas production, pipelines, and refineries
Water and wastewater treatment and distribution
Chemical and pharmaceutical manufacturing
Food and beverage production
Mining and metals
Transportation systems (rail, airports, ports)
Smart buildings and campuses (BMS, HVAC, access control)

Each has different technologies and risk profiles, but all share common characteristics:

Real-time control loops
Field devices (PLCs, RTUs, smart instruments)
Operator interfaces (HMIs, engineering workstations)
Industrial networks (fieldbus, industrial Ethernet, telemetry)
Increasing connections to enterprise IT and cloud systems

This diversity matters when you gather intelligence and build threat models. The threats to a remote pipeline station are not identical to those for an urban water treatment plant, even if some attacker techniques overlap.

2. Who Attacks ICS – and Why?

Understanding attackers’ motivations, capabilities, and typical behavior is a key part of both intelligence gathering and threat modeling.

2.1 Key Threat Actors in ICS

Nation-state and state-sponsored groups
- Goals: espionage, preparation of the battlespace, deterrence, or actual disruption.
- Capabilities: high; often capable of developing ICS-specific malware and zero-days.
- Typical targets: energy, defense, critical infrastructure, strategic manufacturing.
Cybercriminals (especially ransomware operators)
- Goals: financial gain through extortion.
- Capabilities: varied; from commodity ransomware to advanced intrusion sets.
- Typical attack path:
  - Compromise IT environment (phishing, credential theft, vulnerabilities).
  - Move laterally toward OT networks.
  - Impact ICS either directly (encrypting HMIs, historians, engineering workstations) or indirectly (disrupting business systems needed for operations).
Insiders (malicious or negligent)
- Goals: sabotage, revenge, financial gain, or simply convenience and shortcuts.
- Capabilities: high context and access; can bypass many perimeter defenses.
- Examples:
  - Misusing engineering tools.
  - Bypassing safety or security controls to “get the job done faster.”
  - Taking configuration backups offsite on unsecured devices.
Contractors, vendors, and integrators
- Not usually adversaries, but major risk vectors:
  - Use of insecure remote access tools.
  - Bringing malware on engineering laptops or USB drives.
  - Misconfigurations introduced during projects or maintenance.
Hacktivists and politically motivated actors
- Goals: draw attention, protest, cause disruption or symbolic damage.
- Targets: utilities, government-linked infrastructure, high-visibility sites.
Opportunistic attackers and automated scanning
- Goals: exploit whatever they find that is misconfigured and exposed.
- Tactics:
  - Internet-wide scanning (e.g., for open RDP, VNC, or known ICS ports).
  - Exploitation of default passwords and known vulnerabilities.

3. Common Attack Vectors in ICS

A good mental model of how attackers actually get into ICS helps drive your intelligence priorities and threat models.

3.1 From IT to OT – The Most Common Path

Most real-world ICS incidents begin in the corporate IT network:

Phishing email leads to malware on a user’s workstation.
Attackers steal credentials and move laterally.
They discover OT-related systems: jump servers, historians, engineering file shares.
Eventually they find paths into the OT network via:
- Misconfigured firewalls
- Shared domain services
- Remote access gateways
- VPNs used by engineers or vendors

From a threat modeling perspective, the IT–OT boundary is one of the most critical attack surfaces.

3.2 Direct Remote Access and Exposed Services

In some environments, attackers don’t even need to go through IT:

Exposed remote desktop (RDP, VNC) servers directly connected to ICS networks.
Unsecured VPNs with shared credentials.
Cloud-based remote access tools installed by vendors without proper controls.
Misconfigured industrial gateways or IoT devices reachable from the internet.

Intelligence gathering should track:

What remote access tools are approved and in use.
External exposure (attack surface management).
Vendor access paths and habits.

3.3 Supply Chain and Third-Party Risk

Attackers may compromise:

ICS software vendors and update servers.
Integrators and engineering firms with access to your systems.
Managed service providers (MSPs) or remote monitoring service providers.

Threat models must consider that trusted updates, tools, and partners can be turned into delivery vehicles for malicious code or misconfigurations.

3.4 Engineering Workstations and Portable Media

Engineering workstations (EWS) and laptops are high-value targets:

Used for configuring PLCs, DCS, SIS, and network devices.
Often travel between sites and networks.
May run older OS versions or vendor-specific software that conflicts with modern security tools.

Portable media (USB drives, portable hard disks) used to:

Move logic and configuration files.
Install patches offline.
Transfer data between isolated networks.

These create opportunities for:

Malware introduction.
Unauthorized tools or scripts entering the ICS environment.
Accidental data loss or exposure.

3.5 Physical and Local Access

Don’t forget the physical dimension:

Unauthorized individuals in control rooms or electrical rooms.
Access to network cabinets and panels.
Tampering with field devices or local engineering ports.

Threat models that ignore physical security are incomplete—especially in remote or lightly staffed sites.

4. Intelligence Gathering in ICS: Defender’s Perspective

Now that we understand who is attacking ICS and how, the next question is: How do we stay ahead?

That’s where intelligence gathering comes in.

4.1 What Is Cyber Threat Intelligence (CTI) for ICS?

Cyber Threat Intelligence (CTI) is information about potential or actual threats that is:

Collected
Analyzed
Refined
Distributed

…to help you make better security decisions.

In ICS, CTI helps you answer questions like:

Which threat actors are targeting organizations like mine?
What tactics, techniques, and procedures (TTPs) do they use against ICS?
Which vulnerabilities in my ICS environment are being actively exploited?
What misconfigurations and exposures are most likely to be abused?
How should we prioritize defenses, monitoring, and incident response in OT?

4.2 Levels of CTI Relevant to ICS

Think about CTI at four levels:

Strategic intelligence
- High-level trends, geopolitical context, sector-level targeting.
- Audience: executives, risk managers.
- Example: analysis of how tensions in a region increase the likelihood of targeting energy infrastructure.
Operational intelligence
- Campaigns and intrusion sets, specific adversaries and their playbooks.
- Audience: security architects, ICS security leads, incident responders.
- Example: “Group X is using ICS-specific malware targeting PLCs from vendor Y.”
Tactical intelligence
- TTPs: how attackers perform discovery, lateral movement, and ICS-specific actions.
- Audience: SOC analysts, OT security engineers.
- Example: repeated use of PsExec from jump hosts into OT, or specific ICS protocol commands for reconnaissance.
Technical intelligence
- Indicators of compromise (IOCs) like IP addresses, hashes, domains, signatures.
- Audience: SOC analysts, detection engineers.
- Example: YARA rules for ICS-related malware, IPs used for C2 infrastructure.

For ICS, operational and tactical intelligence are especially useful for threat modeling and control design, while strategic and technical levels guide priorities and detection.

4.3 Key Intelligence Sources for ICS Defenders

Effective intelligence gathering pulls from internal and external sources.

4.3.1 Internal Sources

Incident and alert data from:
- OT network monitoring tools.
- Firewalls between IT and OT.
- Remote access gateways.
- Engineering workstations and OT servers.
Change management records:
- Which systems are changing frequently?
- Any unauthorized or undocumented changes?
Asset and vulnerability data:
- OT asset inventory.
- Known vulnerabilities relevant to your specific ICS products.
Process anomalies:
- Unexpected trips or shutdowns.
- Deviations in process variables that might indicate malicious interference.

Internal data tells you how your specific environment behaves, where the weak spots are, and which systems are most exposed or attractive to attackers.

4.3.2 External Sources

ICS-specific advisories and alerts:
- National or sector CERTs.
- ICS-focused government advisories.
- Vendor security bulletins.
Threat intelligence providers:
- ICS/OT-focused CTI feeds.
- Reports on ICS campaigns and malware families.
Information sharing communities:
- ISACs/ISAOs for your sector (e.g., energy, water, manufacturing).
- Regional or national critical infrastructure forums.
Open-source intelligence (OSINT):
- Public reports of ICS incidents.
- Research from security conferences and academic work.
- Exposed ICS devices or remote access endpoints (as identified by tools like Shodan) – handled carefully and ethically.
Dark web and underground sources (through vetted providers):
- Leaked access credentials.
- Offers of access to industrial environments.
- Sale of ICS-related exploits or tools.

Together, these sources inform your view of what adversaries are doing right now and what might come next.

4.4 The CTI Lifecycle in an ICS Context

You can structure ICS-focused intelligence gathering using a simple lifecycle:

Requirements
- Define what you need to know.
- Example ICS questions:
  - “Which vulnerabilities in our PLC families are being actively exploited?”
  - “How do ransomware groups typically pivot into OT networks from IT?”
  - “Are there emerging threats against our specific sector (e.g., water, energy)?”
Collection
- Gather data from internal and external sources listed above.
- Avoid aggressive scanning or intrusive testing directly on production ICS networks.
Processing
- Normalize, deduplicate, and enrich data.
- Map IOCs and TTPs to frameworks like MITRE ATT&CK for ICS.
Analysis
- Turn raw data into insights:
  - What does this mean for our assets?
  - Which attack paths in our environment are most likely or most dangerous?
Dissemination
- Deliver tailored intelligence to:
  - Executives (strategic summaries)
  - Architects and ICS security leads (operational and tactical reports)
  - SOC and monitoring teams (technical indicators and detection rules)
  - OT and engineering teams (impacted assets, required mitigations)
Feedback
- Collect feedback:
  - Were the indicators useful?
  - Did predictions match what was seen on the ground?
- Refine requirements and focus areas.

Intelligence that doesn’t change decisions or behavior is just noise. Always connect CTI back to specific decisions (what to patch, what to monitor, what to simulate in tabletop exercises).

5. Intelligence Gathering from the Attacker’s Perspective (Reconnaissance)

To build realistic threat models, you must also understand how attackers gather intelligence on you.

5.1 External Reconnaissance

Attackers start outside your organization:

Open-source intelligence (OSINT):
- Company websites and press releases.
- Job postings (which reveal technologies and vendors).
- Public procurement documents and regulatory filings.
- Social media (LinkedIn profiles of engineers, photos of control rooms, etc.).
Internet scanning and search engines:
- Discover exposed services, including:
  - Remote access gateways.
  - Web interfaces of industrial gateways or routers.
  - Misconfigured cloud or IIoT platforms.
- Identify ICS-specific devices by banners and ports.
Third-party and supply chain research:
- Which integrators or vendors work with you?
- Are they known to be vulnerable or previously compromised?

From a defender’s standpoint, you should know what attackers can see before they even touch your network.

5.2 Internal Reconnaissance (Once Inside)

After gaining some form of foothold—often in IT—attackers pivot to gather more intelligence:

Network mapping:
- Enumerating domains, subnets, and routing.
- Discovering firewalls and gateways connecting to OT networks.
Credential and configuration harvesting:
- Capturing credentials from memory, password managers, or configuration files.
- Finding VPN profiles and saved RDP sessions to OT devices.
File share and documentation mining:
- Searching for:
  - ICS network diagrams.
  - Vendor manuals and project documentation.
  - PLC logic backups.
  - Engineering tool installers.
Protocol reconnaissance:
- Discovering ICS protocols in use (Modbus/TCP, Ethernet/IP, DNP3, OPC UA, proprietary protocols).
- Identifying critical servers (SCADA, historians, domain controllers in OT).

When you build threat models, imagine this progression step-by-step: what can the attacker learn at each stage, and how does that open up new options?

5.3 Countering Adversary Intelligence Gathering

Intelligence gathering is a two-way game. You can:

Reduce what’s visible externally (attack surface management).
Harden internal documentation and file shares (least privilege, careful labeling).
Monitor and alert on suspicious reconnaissance behavior, such as:
- Large-scale network scans from unusual hosts.
- Access to engineering documents by non-engineering accounts.
- Unusual logins to OT-related jump servers or historians.

These countermeasures become concrete requirements in your threat models and security architecture.

6. Threat Modeling Fundamentals for ICS

With the threat landscape and intelligence picture in mind, we can turn to threat modeling.

6.1 What Is Threat Modeling?

Threat modeling is a structured way of thinking like an attacker about your systems so you can:

Identify what you need to protect (assets).
Understand how it can be attacked (threats and attack paths).
Estimate the potential impact (risk).
Decide which defenses to implement (controls and mitigations).

Instead of reacting to incidents, threat modeling helps you proactively design and prioritize defenses.

6.2 Why Threat Modeling Is Critical in ICS

Threat modeling is especially valuable in ICS because:

You can’t “try and see” by running intrusive security tools on live systems.
Changes are expensive and slow; you want to get it right the first time.
Many ICS systems are black boxes from a security standpoint; the vendor may not think like an attacker.
Safety and availability constraints require careful analysis of side effects of security controls.

Threat modeling gives you a structured way to reason about:

Safety-critical functions and failure modes.
Attack paths that cross between IT and OT.
Legacy systems and vendor-imposed limitations.

6.3 When to Apply Threat Modeling in ICS

You don’t need a threat model for every cable and sensor. Focus on:

New projects and greenfield ICS deployments
- Design security into architecture, communications, and access from day one.
Major upgrades or migrations
- Example: migrating SCADA to a new platform, implementing an OT data lake, or adding remote access for vendors.
High-risk processes or assets
- Safety instrumented systems, critical substations, large continuous processes.
Recurring “problem areas”
- Where incidents, near-misses, or repeated findings keep appearing.

Threat modeling should become a standard step in your ICS/OT change and project lifecycle.

7. A High-Level Threat Modeling Process Tailored to ICS

There are many formal methodologies, but in ICS you often need something practical and understandable to operations, engineering, and security teams alike.

Here is a high-level, ICS-focused threat modeling process:

Step 1 – Define Scope and Objectives

Clarify:

Which system or process you’re analyzing.
What you’re trying to protect:
- Safety
- Production continuity
- Environmental compliance
- Regulatory obligations
What level of detail is needed (not every device, but key components and flows).

Example scope:
“Remote monitoring and control of the water treatment plant via the SCADA system, including remote access solutions used by internal engineers and external vendors.”

Step 2 – Build a System Model

Create a simple, shared picture of the system:

Diagrams showing:
- Main components: PLCs, RTUs, HMIs, engineering workstations, servers, gateways.
- Networks and zones (e.g., field, control, site operations, OT DMZ, IT).
- Connections to IT and cloud.
Data flows:
- Telemetry, control commands, configuration updates.
- Maintenance and remote access flows.
- Interfaces with safety systems, if relevant.

The goal is not artistic perfection; it’s shared understanding.

Step 3 – Identify Assets and “Crown Jewels”

List what really matters:

Critical process functions (e.g., maintaining pressure, controlling chemical dosing).
Safety functions (e.g., shutdown logic in SIS/ESD systems).
Key systems and components:
- Controllers for critical units.
- SCADA servers and historians.
- Engineering workstations and configuration repositories.
Supporting infrastructure:
- OT domain controllers, jump servers, backup servers.

For each, note:

Impact if compromised:
- Safety impact
- Production impact
- Environmental impact
- Regulatory and reputational impact

This step helps ensure your threat model stays focused on what matters most.

Step 4 – Identify Threat Actors and Use Cases

Based on your environment and CTI, list the most relevant threat actors:

Nation-state APT concerned with your sector?
Ransomware groups actively targeting companies like yours?
Insider with engineering access?
Contracting companies with inconsistent security?

For each actor, define scenarios such as:

“Ransomware group enters IT via phishing and attempts to reach OT.”
“Disgruntled contractor misuses vendor remote access.”
“State-sponsored group conducts long-term reconnaissance and pre-positioning in OT.”

You don’t need perfect detail—just enough to think realistically from their perspective.

Step 5 – Enumerate Threats and Attack Paths

Now, step through your system model and ask:

“Given this actor, and this asset, what could go wrong here?”

Helpful techniques include:

STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) for general IT/OT components.
ICS-specific attack paths reflecting known patterns:
- IT → OT pivot via misconfigured firewall.
- Remote access gateway compromise → SCADA server → PLC.
- Engineering workstation infection → logic changes in PLC or SIS.
- Rogue configuration or firmware updates.

Bring in MITRE ATT&CK for ICS as a catalog of real-world adversary techniques and behaviors. Map relevant techniques to your system components and data flows.

Ask questions like:

How could an attacker:
- Gain unauthorized remote access?
- Move from SCADA to PLCs or safety systems?
- Tamper with setpoints or logic?
- Hide their presence or changes?
- Cause loss of visibility, control, or safety?

Document these as threat scenarios or attack chains, each with:

Entry point
Steps of escalation and pivot
Targeted asset or process
Potential outcome

Step 6 – Assess Risk (Likelihood and Impact)

For each threat scenario, estimate:

Likelihood
- Based on CTI: are these TTPs common or rare?
- Exposure: is the attack surface reachable from the internet or only from internal networks?
- Complexity: does it require inside knowledge or just commodity tooling?
Impact
- Safety: could this harm people or cause major equipment damage?
- Production: downtime duration and financial loss.
- Environmental: spills, emissions, or regulatory violations.
- Reputation/Legal: potential legal action and brand damage.

In ICS, impact often dominates; even low-likelihood but catastrophic scenarios deserve attention (e.g., targeted manipulation of a safety system).

You don’t need precise numbers. A simple scale (e.g., Low/Medium/High or numeric categories) is usually enough for prioritization.

Step 7 – Identify Mitigations and Defense-in-Depth

For high- and medium-risk scenarios, propose and evaluate mitigation strategies:

Preventive controls
- Network segmentation and firewall rules.
- Strong authentication and multi-factor for remote access.
- Hardening of engineering workstations and servers.
- Application whitelisting or allow-listing on critical hosts.
- Secure configurations and removal of default credentials.
Detective controls
- OT-aware monitoring for unusual protocol use or command patterns.
- Alerting on unauthorized changes to PLC logic or SCADA configurations.
- Detection of new or suspicious remote access sessions.
Corrective and recovery controls
- Reliable, tested backups of logic and configurations.
- Playbooks for safe recovery and validation.
- Clear incident response procedures that integrate with safety processes.

Where controls are not feasible (e.g., due to vendor limitations), identify compensating controls (e.g., increased isolation, stricter procedures, enhanced monitoring).

Step 8 – Document and Validate with Stakeholders

Write up the threat model in a way that:

Clearly describes:
- Scope and assumptions.
- System model and assets.
- Major threats and scenarios.
- Risk levels.
- Recommended controls and priorities.
Is understandable to:
- OT engineers and operators.
- Security teams.
- Project managers and leadership.

Review it in a workshop:

Validate assumptions with engineers (“Is this how you actually connect to the remote station?”).
Refine attack paths based on real-world process knowledge.
Agree on which mitigations are practical and highest value.

Step 9 – Integrate into Lifecycle and Governance

Threat modeling should not be a one-off deliverable. Integrate it with:

Change management/MOC – Significant ICS changes trigger threat model updates.
Project governance – Projects must demonstrate that high-risk scenarios are addressed.
CTI and monitoring – Threat models shape what you look for and how you respond.
Training and exercises – Use threat scenarios in tabletop drills and operator training.

This turns threat modeling into a living asset, not a forgotten PDF.

8. Threat Modeling Frameworks and Techniques for ICS

Several well-known frameworks can be adapted to ICS. The key is to apply them pragmatically, not dogmatically.

8.1 STRIDE for ICS Components

STRIDE is a classic approach for identifying threats to a system, based on six categories:

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

In ICS, you can apply STRIDE to:

Remote access gateways
SCADA servers and historians
Engineering workstations
OT jump servers

For each component and data flow, ask STRIDE-style questions:

How could an attacker spoof an operator or engineer?
How could they tamper with commands or configurations in transit?
How could they cause or deny repudiation (e.g., alter logs)?
How could they cause information disclosure (e.g., leak plant recipes)?
How could they cause denial of service (e.g., overload PLC communications)?
How could they achieve elevation of privilege (e.g., from operator to administrator)?

This structured approach helps ensure you don’t overlook major threat types.

8.2 Attack Trees and Kill Chains

Attack trees visualize how an attacker can reach a goal through multiple paths. For ICS, example goals might be:

“Remotely change pump setpoints above safe limits.”
“Disable visibility of a critical process in the control room.”

You break down the goal into sub-goals and prerequisites, such as:

Gain remote access to OT network.
Gain write access to target PLC.
Learn tag names and register addresses.
Deliver modified logic.

Kill chains (or attack chains) model the sequential phases of an attack:

Reconnaissance
Initial access
Execution
Persistence
Lateral movement
Command and control
Impact

For ICS, you may extend this with IT-to-OT pivot phases and physical impact.

Using these perspectives helps you:

Identify opportunities to disrupt the chain early.
Choose monitoring and response measures at multiple stages.

8.3 MITRE ATT&CK for ICS

MITRE ATT&CK for ICS is a curated knowledgebase of adversary techniques specifically observed in ICS environments.

Examples of techniques include:

Initial access via external remote services.
Discovery of control system devices and engineering configuration.
Execution of remote system discovery using ICS protocols.
Manipulation of control logic and inhibit response functions.

By mapping your system components to relevant ATT&CK techniques, you can:

See which parts of your architecture are most exposed.
Design detections and controls for the most relevant techniques.
Align your intelligence gathering with known adversary patterns.

ATT&CK doesn’t replace threat modeling but provides a rich dictionary of real-world techniques to incorporate.

8.4 Bow – Tie Diagrams for ICS Safety and Security

A bow-tie diagram connects:

Threats on the left
Unwanted events or top events in the center (e.g., “Loss of containment,” “Runaway reaction”)
Consequences on the right (safety, environmental, financial)
Preventive and mitigative barriers around the top event

ICS and process safety teams often use bow-ties for safety risk. You can extend them to cyber threats, integrating:

Cyber-based initiating threats (e.g., “Unauthorized remote change to SIS logic”).
Cybersecurity controls as barriers (technical and procedural).

This helps safety and security teams speak a common language and see how ICS security failures can translate into process safety incidents.

9. Example: High-Level Threat Model for a Remote-Access-Enabled ICS

To make things concrete, consider a simplified example:

9.1 Scope

Remote access to a manufacturing plant’s ICS environment for:

Internal engineers (on-call support).
External vendor (PLC/DCS support).

Key components:

Corporate IT network.
Secure remote access gateway (VPN + jump server in OT DMZ).
SCADA and engineering workstations in OT network.
PLCs controlling a critical continuous process.
Safety instrumented system (SIS) that shuts down the process on hazardous conditions.

9.2 Assets and Crown Jewels

Safety functions implemented in SIS logic.
Control logic and configuration in PLCs and DCS.
SCADA server and engineering workstations.
Remote access gateway and jump server.
Credentials and client configurations used for remote access.

9.3 Relevant Threat Actors

Ransomware group that typically starts in IT and attempts to impact OT for leverage.
Malicious insider with knowledge of remote access configuration.
Compromised vendor account (phishing or password reuse).

9.4 Example Threat Scenarios

Compromised vendor VPN account
- Attacker steals vendor credentials (phishing).
- Logs into remote access gateway.
- Abuses jump server to access engineering workstation.
- Uploads modified logic to PLC, altering process behavior.
- Potential consequence: unsafe operating conditions, unplanned shutdown, or even a safety incident if SIS is also tampered with.
Ransomware actor pivots from IT to OT
- Initial access via phishing in corporate IT.
- Lateral movement to server managing OT VPN or jump server.
- Uses stolen credentials to connect to OT.
- Deploys ransomware on SCADA server and historian.
- Consequence: loss of visibility and control, forcing manual or emergency shutdown.
Insider misusing remote access
- Disgruntled engineer with valid credentials.
- Connects remotely outside normal working procedures.
- Deletes or alters configuration backups and logic.
- Consequence: extended downtime, difficult recovery, potential safety risk if changes are undetected.

9.5 Selected Mitigations

Preventive
- Multi-factor authentication (MFA) for all remote access accounts.
- Time-bound and approval-based vendor access.
- Role-based access control on jump servers.
- No direct access to PLCs from remote sessions; changes must go through controlled engineering workstations.
- Network segmentation between SCADA, engineering workstations, and SIS, with strict firewall rules.
Detective
- Monitoring and alerting on:
  - New or unusual remote access sessions.
  - Off-hours access from unfamiliar locations.
  - Changes to PLC or SIS logic (via engineering tools or vendor features).
- Session recording for vendor remote access.
Corrective
- Verified and tested backups of PLC, DCS, and SIS logic stored offline.
- Playbooks for reverting to known-good logic and verifying safe states.
- Incident response procedures including coordination with process safety.

This kind of example, even if simplified, helps stakeholders visualize real risks and understand how intelligence (e.g., new ransomware TTPs) could change the threat model over time.

10. Connecting Intelligence Gathering and Threat Modeling

Intelligence gathering and threat modeling are mutually reinforcing:

Intelligence informs threat models:
- New campaigns and TTPs may highlight:
  - Previously overlooked attack paths.
  - New high-value targets (e.g., specific vendor products).
  - Techniques for bypassing standard controls.
Threat models focus your intelligence:
- Once you know your high-risk assets and attack paths, you can:
  - Prioritize CTI relevant to those systems and technologies.
  - Tune monitoring for the techniques most dangerous in your environment.
  - Ask specific questions of CTI providers and sharing communities.

Practically, you can implement a feedback loop:

Build or update your ICS threat model.
Derive intelligence requirements from it (e.g., “Are there new exploits for our PLC family?”).
Collect and analyze CTI against those requirements.
Adjust threat model and controls based on CTI.
Feed outcomes back into engineering, operations, monitoring, and governance.

Over time, this transforms your ICS security posture from checklist-driven to intelligence-led and risk-based.

11. Getting Started: A Practical Roadmap for ICS Teams

If your organization is early in its intelligence and threat modeling journey, you don’t need to do everything at once. Start small, but start deliberately.

11.1 Phase 1 – Foundations (0–6 Months)

Build or refine a basic OT asset inventory and network diagram.
Identify and document:
- The most critical processes and systems (crown jewels).
- Current remote access paths and tools.
Establish a small OT security working group including:
- OT engineering
- Operations
- IT security
Subscribe to ICS-relevant advisories (vendors, CERTs, sector ISACs).
Perform a simple threat model for one high-risk system:
- Example: remote access to SCADA or SIS maintenance workstation.

11.2 Phase 2 – Integrate Intelligence and Threat Modeling (6–18 Months)

Formalize an ICS-focused CTI process:
- Define requirements.
- Assign roles for collection and analysis.
- Start using MITRE ATT&CK for ICS in analysis.
Develop threat modeling templates aligned with your environment:
- Standard diagrams, asset categories, and risk scales.
Expand threat modeling to:
- New ICS projects and major upgrades.
- Known high-risk sites or plants.
Introduce basic OT monitoring and align detection rules with threat models:
- Focus on remote access misuse, unauthorized changes, and suspicious lateral movement.

11.3 Phase 3 – Maturing and Scaling (18+ Months)

Embed threat modeling into:
- Engineering standards.
- ICS project management methodologies.
- Management of Change (MOC) procedures.
Use CTI and threat modeling to drive:
- OT segmentation designs.
- Remote access architectures.
- Backup and recovery strategies.
Conduct tabletop exercises based on real threat scenarios:
- Mix security, operations, engineering, and safety teams.
Continuously update threat models as:
- New threats emerge.
- Plants modernize.
- Cloud and IIoT components are introduced.

12. FAQ: Intelligence Gathering and Threat Modeling for ICS

Q1. What is the main difference between intelligence gathering for IT and for ICS?
In ICS, intelligence must reflect safety and process risk, not just data loss. You care deeply about threats that can disrupt or manipulate physical processes. That means prioritizing CTI about ICS-specific malware, OT-focused threat groups, and vulnerabilities in industrial products, and combining it with knowledge of your own processes.

Q2. Do I need a dedicated threat intelligence team for ICS?
Not necessarily. Many organizations start by:

Assigning an existing security team member as ICS CTI focal point.
Using external CTI services and sector information-sharing.
Leveraging existing SOC capabilities while adding ICS context.
As your ICS program matures, you may choose to develop more specialized capabilities.

Q3. Is threat modeling only useful for new, modern ICS projects?
No. Threat modeling is equally valuable for legacy systems—perhaps more so, because those systems often have:

Known vulnerabilities
Limited patching options
High dependency for production
Threat modeling helps you identify where to use compensating controls like isolation, enhanced monitoring, and stricter procedures.

Q4. Which threat modeling methodology is best for ICS?
There is no single “best” methodology. Many organizations combine:

A simple asset–threat–control approach.
Elements of STRIDE for general components.
Attack trees or kill chains for attack paths.
MITRE ATT&CK for ICS as a catalog of real-world techniques.
The most important thing is that the method is understandable to OT stakeholders and consistently applied.

Q5. How often should we update our ICS threat models?
Update threat models:

When you make major architectural or system changes.
When significant new threats emerge (e.g., new ICS malware targeting your technology stack).
Periodically (e.g., annually) as part of ICS risk assessments and audits.
Treat them as living documents, not one-time exercises.

Q6. Can intelligence gathering and threat modeling help with compliance?
Yes. Many ICS-related standards and regulations (such as IEC 62443-based frameworks and NIST guidance) expect:

A risk-based approach to ICS security.
Documented analysis of threats and mitigations.
Ongoing monitoring of emerging threats.
Intelligence gathering and threat modeling provide structured evidence of this risk-based, proactive approach.

13. Conclusion: Building an Intelligence-Led ICS Security Program

Intelligence gathering and threat modeling are not abstract exercises for consultants; they are practical tools that help real plants and infrastructures stay safe and reliable in a hostile digital world.

By:

Understanding your ICS threat landscape
Systematically gathering and using relevant intelligence
Applying threat modeling to critical systems and projects
Embedding these practices into your engineering and security lifecycles

…you move from a reactive, checklist-driven posture to an intelligence-led, risk-based ICS security program.

The result is not just fewer cyber incidents, but:

Safer operations
More resilient production
Better-informed investment decisions
Stronger alignment between IT security, OT engineering, and process safety

Intelligence Gathering and Threat Modeling for ICS: A Complete Practical Guide