Version 18.0 19.0
Mitigations : ICS ATT&CK Changelog
Modified Mitigations
| Description |
|---|
The device or system should restrict read, manipulate, or execute privileges to only authenticated users who require access based on approved security policies. Role-based Access Control (RBAC) schemes can help reduce the overhead of assigning permissions to the large number of devices within an ICS. For example, IEC 62351 provides examples of roles used to support common system operations within the electric power sector [1], while IEEE 1686 defines standard permissions for users of IEDs. [2] References:
|
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2023-10-20 17:01:38.562000+00:00 | 2026-04-23 00:54:03.965000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.1 | 1.2 |
| Description |
|---|
Access Management technologies can be used to enforce authorization polices and decisions, especially when existing field devices do not provide sufficient capabilities to support user identification and authentication. [1] These technologies typically utilize an in-line network device or gateway system to prevent access to unauthenticated users, while also integrating with an authentication service to first verify user credentials. [2] References: |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-03-12 16:11:54.933000+00:00 | 2026-04-23 00:47:44.798000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
When communicating over an untrusted network, utilize secure network protocols that both authenticate the message sender and can verify its integrity. This can be done either through message authentication codes (MACs) or digital signatures, to detect spoofed network messages and unauthorized connections. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:32.013000+00:00 | 2026-04-23 00:54:21.289000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
Require user authentication before allowing access to data or accepting commands to a device. While strong multi-factor authentication is preferable, it is not always feasible within ICS environments. Performing strong user authentication also requires additional security controls and processes which are often the target of related adversarial techniques (e.g., Valid Accounts, Default Credentials). Therefore, associated ATT&CK mitigations should be considered in addition to this, including Multi-factor Authentication, Account Use Policies, Password Policies, User Account Management, Privileged Account Management, and User Account Control. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2023-10-20 17:02:00.299000+00:00 | 2026-04-23 00:50:55.165000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.1 | 1.2 |
| Description |
|---|
Network allowlists can be implemented through either host-based files or system hosts files to specify what connections (e.g., IP address, MAC address, port, protocol) can be made from a device. Allowlist techniques that operate at the application layer (e.g., DNP3, Modbus, HTTP) are addressed in Filter Network Traffic mitigation. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:31.149000+00:00 | 2026-04-23 00:56:32.131000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
Utilize strong cryptographic techniques and protocols to prevent eavesdropping on network communications. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:29.147000+00:00 | 2026-04-23 00:55:38.098000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
Have alternative methods to support communication requirements during communication failures and data integrity attacks. [1] [2] References:
|
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:31.696000+00:00 | 2026-04-23 00:56:53.267000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
Require the authentication of devices and software processes where appropriate. Devices that connect remotely to other systems should require strong authentication to prevent spoofing of communications. Furthermore, software processes should also require authentication when accessing APIs. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2024-10-14 20:31:04.927000+00:00 | 2026-04-23 00:55:20.765000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.1 | 1.2 |
| Description |
|---|
Configure hosts and devices to use static network configurations when possible, protocols that require dynamic discovery/addressing (e.g., ARP, DHCP, DNS) can be used to manipulate network message forwarding and enable various AiTM attacks. This mitigation may not always be usable due to limited device features or challenges introduced with different network configurations. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:28.312000+00:00 | 2026-04-23 00:50:32.432000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.1 | 1.2 |
| Description |
|---|
Restrict access by setting directory and file permissions that are not specific to users or privileged accounts. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:33.651000+00:00 | 2026-04-23 00:57:09.061000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
Architect sections of the network to isolate critical systems, functions, or resources. Use physical and logical segmentation to prevent access to potentially sensitive systems and information. Use a DMZ to contain any internet-facing services that should not be exposed from the internal network. Restrict network access to only required systems and services. In addition, prevent systems from other networks or business functions (e.g., enterprise) from accessing critical process control systems. For example, in IEC 62443, systems within the same secure level should be grouped into a zone, and access to that zone is restricted by a conduit, or mechanism to restrict data flows between zones by segmenting the network. [1] [2] References:
|
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:26.551000+00:00 | 2026-04-23 00:46:09.190000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
Use intrusion detection signatures to block traffic at network boundaries. In industrial control environments, network intrusion prevention should be configured so it will not disrupt protocols and communications responsible for real-time functions related to control or safety. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:27.092000+00:00 | 2026-04-23 00:47:04.457000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
Use network appliances to filter ingress or egress traffic and perform protocol-based filtering. Configure software on endpoints to filter network traffic. Perform inline allow/denylisting of network messages based on the application layer (OSI Layer 7) protocol, especially for automation protocols. Application allowlists are beneficial when there are well-defined communication sequences, types, rates, or patterns needed during expected system operations. Application denylists may be needed if all acceptable communication sequences cannot be defined, but instead a set of known malicious uses can be denied (e.g., excessive communication attempts, shutdown messages, invalid commands). Devices performing these functions are often referred to as deep-packet inspection (DPI) firewalls, context-aware firewalls, or firewalls blocking specific automation/SCADA protocol aware firewalls. [1] References: |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:26.074000+00:00 | 2026-04-23 00:45:45.801000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
Protect sensitive data-at-rest with strong encryption. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:31.005000+00:00 | 2026-04-23 00:56:16.357000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
Enforce binary and application integrity with digital signature verification to prevent untrusted code from executing. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:28.975000+00:00 | 2026-04-23 00:54:56.965000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
Use secure methods to boot a system and verify the integrity of the operating system and loading mechanisms. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:29.725000+00:00 | 2026-04-23 00:55:57.931000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |
| Description |
|---|
Perform audits or scans of systems, permissions, insecure software, insecure configurations, etc. to identify potential weaknesses. Perform periodic integrity checks of the device to validate the correctness of the firmware, software, programs, and configurations. Integrity checks, which typically include cryptographic hashes or digital signatures, should be compared to those obtained at known valid states, especially after events like device reboots, program downloads, or program restarts. |
Details
Values Changed
| FIELD | OLD VALUE | NEW VALUE |
|---|---|---|
| modified | 2025-04-16 21:26:31.848000+00:00 | 2026-04-23 00:54:39.756000+00:00 |
| x_mitre_attack_spec_version | 3.2.0 | 3.3.0 |
| x_mitre_version | 1.0 | 1.1 |