Introduction
In this article, I will show how I used the MITRE EMB3D™ Threat Model to identify vulnerabilities in SIEMENS PLCs that were exploited by the Stuxnet worm to sabotage the Iran’s nuclear centrifuges.
About the MITRE EMB3D™ Threat Model
EMB3D™ is a Cybersecurity Threat Model release by MITRE in May 2024 and dedicated for Embedded Devices.
EMB3D is aligned with and expands on several existing models, including Common Weakness Enumeration, MITRE ATT&CK®, and Common Vulnerabilities and Exposures, but with a specific embedded-device focus. The threats defined within EMB3D are based on observation of use by threat actors, proof-of-concept and theoretical/conceptual security research publications, and device vulnerability and weakness reports. These threats are mapped to device properties to help users develop and tailor accurate threat models for specific embedded devices.
Coming in the next release of EMB3D in Summer 2024, each threat description will include a set of Foundational, Intermediate, and Leading mitigations. These mitigations will provide guidance on what technical mechanisms can best prevent or reduce the risk of that threat.
For each threat, EMB3D will suggest technical mechanisms that vendors should build into the device to mitigate the given threat. EMB3D is a comprehensive framework for the entire security ecosystem—device vendors, asset owners, security researchers, and testing organizations.
To know more about the MITRE EMB3D™ Cybersecurity Threat Model for Embedded Devices, check our article here.
About the Stuxnet attack
Stuxnet is a highly sophisticated worm discovered in 2010, believed to be developed jointly by the United States and Israel. It targeted supervisory control and data acquisition (SCADA) systems, particularly those used in Iran’s nuclear program. Stuxnet specifically aimed at disrupting uranium enrichment processes by sabotaging centrifuges, demonstrating the potential of cyber weapons to physically damage critical infrastructure. Its complex code and ability to spread rapidly made it one of the most advanced and impactful cyber weapons ever deployed.
Stuxnet specifically targeted industrial process control systems manufactured by Siemens, including programmable logic controllers (PLCs). It exploited vulnerabilities in the software and communication protocols used by these systems to infiltrate and take control of the PLCs. Once infected, the PLCs could be manipulated to disrupt the operation of the centrifuges used in the Iranian nuclear program.
What is STEP 7 in Siemens PLC and how does Siemens PLC work
STEP 7 is a software platform developed by Siemens for programming and configuring its programmable logic controllers (PLCs). It is part of the Totally Integrated Automation (TIA) Portal, which provides a comprehensive suite of tools for automation tasks, including PLC programming, human-machine interface (HMI) design, and more.
Siemens PLCs are industrial control devices used to automate processes in various industries, such as manufacturing, energy, and transportation. They consist of hardware components, such as the CPU (central processing unit), input/output modules, and communication modules, which interface with sensors, actuators, and other devices in the physical environment.
The PLC’s operation is based on a programmed logic controller, which executes a control program created using software like STEP 7. The program defines the behavior of the PLC in response to inputs from sensors and other sources. When inputs change, the PLC processes this information according to the program’s logic and produces outputs to control actuators, machinery, or other devices.
- More about the Siemens STEP 7 software platform here.
- More about programming with STEP 7 here (PDF).
About Siemens S7-300 PLC
Iran’s nuclear centrifuges were using Siemens S7-300 and S7-400 PLCs.
To identify the main features and device properties of the Siemens S7 series PLC, I used the following datasheets (PDF) :
Identifying properties of the Siemens embedded device
What I consider as an embedded device is the STEP7 Workstation and the Siemens S7 series PLCs.
Device Property #1
Siemens S7-300 PLC does not include a traditional operating system (OS) or kernel in the same sense as a general-purpose computer. Instead, it operates using firmware that is specifically designed for real-time control tasks. This firmware is tightly integrated with the hardware of the PLC and is optimized for deterministic and reliable operation in industrial environments.
So, in the EMB3D™ Device Properties tool / System Software, I checked PID-23 – Device includes OS/kernel
Device Property #2
Applications and softwares are present and running on Siemens PLCs. These softwares are used for programming and configuring the PLC to perform specific control tasks. In the case of Siemens PLCs, the programming software is typically part of the Totally Integrated Automation (TIA) Portal suite, which includes tools like STEP 7 for programming.
Programmers use this application-level software to create control logic using programming languages such as ladder logic, function block diagram (FBD), or structured text. Once the control program is developed, it is downloaded to the PLC, where it runs directly on the PLC’s firmware.
This application-level software allows users to define the behavior of the PLC, specify how inputs should be processed, define control logic, and configure outputs to interact with the physical environment. It also provides tools for debugging, monitoring, and maintaining the PLC program during operation.
So, in the EMB3D™ Device Properties tool / Application Software, I checked PID-31 – Application-level software is present and running on the device
Device Property #3
Siemens PLCs, including the S7-300 series, have the ability to deploy custom programs created using engineering software or integrated development environments (IDEs). Siemens provides programming software such as STEP 7 (part of the TIA Portal suite) for developing custom control logic programs.
So, in the EMB3D™ Device Properties tool / Application Software, I checked PID-321 – Device includes ability to deploy custom programs from engineering software or IDE
Device Property #4
Siemens PLCs do include system function blocks, which are pre-defined blocks of logic that perform specific tasks within the PLC’s firmware. These function blocks are provided by Siemens as part of the PLC’s programming environment and are used for various system-level tasks, such as reading system information, manipulating data blocks, managing communication protocols, and performing other administrative functions.
So, in the EMB3D™ Device Properties tool / Application Software, I checked PID-3231 – Device includes ability to run custom/external programs as native binary without a confined/restricted environment
Siemens PLCs Properties to Threats Mapping
The following table is mapping the Device Properties to a list of Threats the Siemens S7 series PLCs may be exposed to because it incorporates those properties and features.
| System Software | |||
| Device Properties | Threats | ||
| PID-23 | Device includes OS/kernel | TID-218 | Operating System Susceptible to Rootkit |
| TID-202 | Exploitable System Network Stack Component | ||
| Application Software | |||
| Device Properties | Threats | ||
| PID-31 | Application-level software is present and running on the device | TID-301 | Applications Binaries Modified |
| PID-32 | Device includes the ability to deploy custom or external programs | TID-302 | Install Untrusted Application |
| PID-321 | Device includes ability to deploy custom programs from engineering software or IDE | TID-303 | Excessive Trust in Offboard Management/IDE Software |
| PID-3231 | Device includes ability to run custom/external programs as native binary without a confined/restricted environment | TID-305 | Program Executes Dangerous System Calls |
Threat Heat Map for Siemens PLCs
The following tables represent a list of threats that pose a viable risk to the Siemens S7 series PLC.
| SIEMENS S7-300 / S7-400 PLCs Heat Map |
||
| System Software | Application Software |
|
| TID-218 | TID-301 | TID-303 |
| TID-202 | TID-302 | TID-305 |
Threats exploited by the Stuxnet worm
It’s confirmed that the following threats have been exploited by the Stuxnet worm. “It means that the threat modeling we have done is accurate.”
| System Software | |||
| Device Properties | Threats | ||
| PID-23 | Device includes OS/kernel | TID-218 | Operating System Susceptible to Rootkit |
| TID-202 | Exploitable System Network Stack Component | ||
| Application Software | |||
| Device Properties | Threats | ||
| PID-31 | Application-level software is present and running on the device | TID-301 | Applications Binaries Modified |
| PID-32 | Device includes the ability to deploy custom or external programs | TID-302 | Install Untrusted Application |
| PID-321 | Device includes ability to deploy custom programs from engineering software or IDE | TID-303 | Excessive Trust in Offboard Management/IDE Software |
| PID-3231 | Device includes ability to run custom/external programs as native binary without a confined/restricted environment | TID-305 | Program Executes Dangerous System Calls |
Associated mitigations
The following table represents a list of associated mitigations to the threats that pose a viable risk to the Siemens S7 series PLC.
| System Software | ||||
| Threats | Associated mitigations | |||
| Foundational | Intermediate | Leading | ||
| TID-218 | Operating System Susceptible to Rootkit | MID-001 – Software Only Bootloader Authentication | MID-002 – Hardware-backed Bootloader Authentication MID-009 – Operating System-based Runtime Integrity Check |
MID-003 – Periodic/Continuous Integrity Measurement and Remote Attestation |
| Application Software | ||||
| TID-301 | Applications Binaries Modified | MID-001 – Software Only Bootloader Authentication | MID-002 – Hardware-backed Bootloader Authentication MID-009 – Operating System-based Runtime Integrity Check |
MID-003 – Periodic/Continuous Integrity Measurement and Remote Attestation |
| TID-303 | Excessive Trust in Offboard Management/IDE Software | MID-041 – Cryptographically Signed Vendor-supplied Programs MID-042 – Device Checks Consistency Between Binary/Running Code and Textual Code |
||
| TID-305 | Program Executes Dangerous System Calls | MID-012 – OS-based Access Control Mechanisms | MID-014 – Sandboxing MID-015 – Containerization |
|
Associated mitigations with IEC 62443 4-2 Mappings
|
System Software |
||||
| Threats | Associated mitigations | |||
| Foundational | Intermediate | Leading | ||
| TID-218 | Operating System Susceptible to Rootkit | MID-001 – Software Only Bootloader Authentication
•EDR / HDR / NDR 3.14 – Integrity of the boot process |
MID-002 – Hardware-backed Bootloader Authentication
•EDR / HDR/ NDR 3.14 – Integrity of the boot process MID-009 – Operating System-based Runtime Integrity Check •CR 3.4 – Software and information integrity |
MID-003 – Periodic/Continuous Integrity Measurement and Remote Attestation
•CR 3.4 – Software and information integrity |
|
Application Software |
||||
| TID-301 | Applications Binaries Modified | MID-001 – Software Only Bootloader Authentication
•EDR / HDR / NDR 3.14 – Integrity of the boot process |
MID-002 – Hardware-backed Bootloader Authentication
•EDR / HDR/ NDR 3.14 – Integrity of the boot process) MID-009 – Operating System-based Runtime Integrity Check •CR 3.4 – Software and information integrity |
MID-003 – Periodic/Continuous Integrity Measurement and Remote Attestation
•CR 3.4 – Software and information integrity |
| TID-303 | Excessive Trust in Offboard Management/IDE Software | MID-041 – Cryptographically Signed Vendor-supplied Programs
•CR 3.4 – Software and information integrity MID-042 – Device Checks Consistency Between Binary/Running Code and Textual Code •CR 3.4 – Software and information integrity |
||
| TID-305 | Program Executes Dangerous System Calls | MID-012 – OS-based Access Control Mechanisms
•CR 2.1 – Authorization Enforcement |
MID-014 – Sandboxing
•SAR / EDR / HDR / NDR 3.2 – Protection from malicious code MID-015 – Containerization •SAR / EDR / HDR / NDR 3.2 – Protection from malicious code •CR 3.4 – Software and information integrity |
|
Modeling an attack on an Industrial Control Systems (ICS)
To model an attack on an Industrial Control Systems (ICS), it’s recommanded to use an offensive model.
There are two offensive models dedicated to Industrial Control Systems (ICS):
- The MITRE ATT&CK for ICS matrix
- The ICS Cyber Kill Chain
To know more how to model an attack on an Industrial Control Systems (ICS) but also about the MITRE ATT&CK for ICS matrix and the ICS Cyber Kill Chain, go to out entire and complete article on this subject here.
Mapping of Stuxnet attack on the MITRE ATT&CK for ICS matrix
Below is the mapping of Stuxnet attack on the ATT&CK for ICS matrix (Than’ks to Airbus Cybersecurity). « Mapping Stuxnet to the ATT&CK for ICS matrix, as shown in figure 3, quickly shows how complex this attack was. Business risk owners can now identify which techniques to focus on if they need to minimise the risk from strikes like Stuxnet. »
ICS Cyber Kill Chain applied to STUXNET
The figure below is the ICS Cyber Kill Chain applied to STUXNET.
