| ID | Name |
|---|---|
| T1693.001 | System Firmware |
| T1693.002 | Module Firmware |
Adversaries may install malicious or vulnerable firmware onto modular hardware devices. Control system devices often contain modular hardware devices. These devices may have their own set of firmware that is separate from the firmware of the main control system equipment.
This technique is similar to System Firmware, but is conducted on other system components that may not have the same capabilities or level of integrity checking. Although it results in a device re-image, malicious device firmware may provide persistent access to remaining devices.[1]
An easy point of access for an adversary is the Ethernet card, which may have its own CPU, RAM, and operating system. The adversary may attack and likely exploit the computer on an Ethernet card. Exploitation of the Ethernet card computer may enable the adversary to accomplish additional attacks, such as the following:[1]
| ID | Asset |
|---|---|
| A0017 | Distributed Control System (DCS) Controller |
| A0018 | Programmable Automation Controller (PAC) |
| A0003 | Programmable Logic Controller (PLC) |
| A0010 | Safety Controller |
| ID | Mitigation | Description |
|---|---|---|
| M0801 | Access Management |
All devices or systems changes, including all administrative functions, should require authentication. Consider using access management technologies to enforce authorization on all management interface access attempts, especially when the device does not inherently provide strong authentication and authorization functions. |
| M0947 | Audit |
Perform integrity checks of firmware before uploading it on a device. Utilize cryptographic hashes to verify the firmware has not been tampered with by comparing it to a trusted hash of the firmware. This could be from trusted data sources (e.g., vendor site) or through a third-party verification service. |
| M0946 | Boot Integrity |
Check the integrity of the existing BIOS or EFI to determine if it is vulnerable to modification. Use Trusted Platform Module technology.[2] Move system's root of trust to hardware to prevent tampering with the SPI flash memory.[3] Technologies such as Intel Boot Guard can assist with this.[4] |
| M0945 | Code Signing |
Devices should verify that firmware has been properly signed by the vendor before allowing installation. |
| M0802 | Communication Authenticity |
Protocols used for device management should authenticate all network messages to prevent unauthorized system changes. |
| M0808 | Encrypt Network Traffic |
The encryption of firmware should be considered to prevent adversaries from identifying possible vulnerabilities within the firmware. |
| M0941 | Encrypt Sensitive Information |
The encryption of firmware should be considered to prevent adversaries from identifying possible vulnerabilities within the firmware. |
| M0937 | Filter Network Traffic |
Filter for protocols and payloads associated with firmware activation or updating activity. |
| M0804 | Human User Authentication |
Devices that allow remote management of firmware should require authentication before allowing any changes. The authentication mechanisms should also support Account Use Policies, Password Policies, and User Account Management. |
| M0807 | Network Allowlists |
Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.[5] |
| M0930 | Network Segmentation |
Segment operational network and systems to restrict access to critical system functions to predetermined management systems.[5] |
| M0813 | Software Process and Device Authentication |
Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ID | Name | Analytic ID | Analytic Description |
|---|---|---|---|
| DET0790 | Detection of Module Firmware | AN1922 |
Real-time monitoring identifies a firmware write command targeting a specific Input/Output (I/O) module slot address within a controller chassis from a source not in the approved engineering workstation list, distinguishing module-level firmware modification from main-processor firmware updates by its slot-addressed targeting. OT operational-fidelity gate: Alert only when the action is not attributable to an authorized operator/engineering source for the specific target and function, and it is either outside an approved change/maintenance window or lacks matching change-control context; where telemetry permits, require corroborating device, configuration, or process-state effect. Suppress activity that fully matches approved maintenance, commissioning, failover, recovery, or tested control procedures. |