Property:Has mitigation description

From attackics
Jump to navigation Jump to search

This is a property of type Text.

Showing 250 pages using this property.
A
Restrict configurations changes and firmware updating abilities to only authorized individuals.  +
Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.  +
Protocols used for device management should authenticate all network messages to prevent unauthorized system changes.  +
Segment operational network and systems to restrict access to critical system functions to predetermined management systems.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Filter for protocols and payloads associated with firmware activation or updating activity.  +
Devices that allow remote management of firmware should require authentication before allowing any changes. The authentication mechanisms should also support <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0936]]</span></span></span></span>, <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0927]]</span></span></span></span>, and <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0918]]</span></span></span></span>  +
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.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
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.  +
Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support.  +
Unauthorized connections can be prevented by statically defining the hosts and ports used for automation protocol connections.  +
Segment operational assets and their management devices based on their functional role within the process. Enabling more strict isolation to more critical control and operational information within the control environment.[[CiteRef::Guidance - NIST SP800-41]][[CiteRef::Guidance - NIST SP800-82]][[CiteRef::Guidance - DHS Defense in Depth - 201609]][[CiteRef::mitigation - SANS whitelisting]]  +
Provide an alternative method for alarms to be reported in the event of a communication failure.  +
Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support.  +
Prevent unauthorized systems from accessing control servers or field devices containing industrial information, especially services used for common automation protocols (e.g., DNP3, OPC).  +
B
Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support.  +
Unauthorized connections can be prevented by statically defining the hosts and ports used for automation protocol connections.  +
Provide an alternative method for sending critical commands message to outstations, this could include using radio/cell communication to send messages to a field technician that physically performs the control function.  +
Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support.  +
Unauthorized connections can be prevented by statically defining the hosts and ports used for automation protocol connections.  +
Provide an alternative method for sending critical report messages to operators, this could include using radio/cell communication to obtain messages from field technicians that can locally obtain telemetry and status data.  +
Restrict unauthorized devices from accessing serial comm ports.  +
Ensure devices have an alternative method for communicating in the event that a valid COM port is unavailable.  +
Implement network allowlists to minimize serial comm port access to only authorized hosts, such as comm servers and RTUs.  +
Devices should authenticate all messages between master and outstation assets.  +
Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support.  +
Segment operational assets and their management devices based on their functional role within the process. Enabling more strict isolation to more critical control and operational information within the control environment.[[CiteRef::Guidance - NIST SP800-41]][[CiteRef::Guidance - NIST SP800-82]][[CiteRef::Guidance - DHS Defense in Depth - 201609]][[CiteRef::mitigation - SANS whitelisting]]  +
Allow/denylists can be used to block access when excessive I/O connections are detected from a system or device during a specified time period.  +
C
All field controllers should restrict operating mode changes to only required authenticated users (e.g., engineers, field technicians), preferably through implementing a role-based access mechanism. Further, physical mechanisms (e.g., keys) can also be used to limit unauthorized operating mode changes.  +
Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.  +
All field controllers should require users to authenticate for all remote or local management sessions. The authentication mechanisms should also support <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0936]]</span></span></span></span>, <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0927]]</span></span></span></span>, and <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0918]]</span></span></span></span>.  +
Protocols used for device management should authenticate all network messages to prevent unauthorized system changes.  +
Segment operational network and systems to restrict access to critical system functions to predetermined management systems.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Authenticate all access to field controllers before authorizing access to, or modification of, a device's state, logic, or programs. Centralized authentication techniques can help manage the large number of field controller accounts needed across the ICS.  +
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.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Execution prevention may block malicious software from accessing protected resources through the command line interface.  +
Consider removing or restricting features that are unnecessary to an asset's intended function within the control environment.  +
Ensure that unnecessary ports and services are closed to prevent risk of discovery and potential exploitation.  +
All field controllers should require users to authenticate for all remote or local management sessions. The authentication mechanisms should also support <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0936]]</span></span></span></span>, <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0927]]</span></span></span></span>, and <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0918]]</span></span></span></span>.  +
Configure internal and external firewalls to block traffic using common ports that associate to network protocols that may be unnecessary for that particular network segment.  +
Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific protocol used by a particular adversary or tool and will likely be different across various malware families and versions. Adversaries will likely change tool C2 signatures over time or construct protocols in such a way as to avoid detection by common defensive tools.[[CiteRef::University of Birmingham C2]]  +
If it is possible to inspect HTTPS traffic, the captures can be analyzed for connections that appear to be domain fronting.  +
Network allowlists can be implemented through either host-based files or system host files to specify what external 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 the <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0937]]</span></span></span></span> mitigation.  +
Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific C2 protocol used by a particular adversary or tool and will likely be different across various malware families and versions. Adversaries will likely change tool C2 signatures over time or construct protocols in such a way as to avoid detection by common defensive tools.[[CiteRef::University of Birmingham C2]]  +
Traffic to known anonymity networks and C2 infrastructure can be blocked through the use of network allow and block lists. It should be noted that this kind of blocking may be circumvented by other techniques like Domain Fronting.  +
D
Ensure that all SIS are segmented from operational networks to prevent them from being targeted by additional adversarial behavior.  +
Protection devices should have minimal digital components to prevent exposure to related adversarial techniques. Examples include interlocks, rupture disks, release valves, etc.[[CiteRef::mitigation - applying IEC 61511 - 2004]]  +
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.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Utilize central storage servers for critical operations where possible (e.g., historians) and keep remote backups. For outstations, use local redundant storage for event recorders. Have backup control system platforms, preferably as hot-standbys to respond immediately to data destruction events.[[CiteRef::reference - NIST SP 800-53]]  +
Protect files stored locally with proper permissions to limit opportunities for adversaries to impact data storage.[[CiteRef::reference - NIST SP 800-53]]  +
Minimize permissions and access for service accounts to limit the information that may be impacted by malicious users or software.[[CiteRef::reference - NIST SP 800-53]]  +
All remote services should require strong authentication before providing user access.  +
All remotely accessible services should implement access control mechanisms to restrict the information or services accessible to users.  +
Consider the disabling or removal of features or programs which are not required by that asset's function within the environment.  +
Network allowlists can be implemented through either host-based files or system host files to specify what external 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 the <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0937]]</span></span></span></span> mitigation.  +
Consider the principle of least functionality when configuring ICS software to limit host or network-based capabilities within the control environment.  +
All communication sessions with the historian should be authenticated to prevent unauthorized access.  +
Filter network traffic to data historians to ensure only authorized data flows are allowed, especially across network boundaries.  +
Consider placing the historian into a demilitarized zone (DMZ) to allow access from enterprise networks, while protecting the control system network[[CiteRef::Guidance - NIST SP800-82]][[CiteRef::Guidance - DHS Defense in Depth - 201609]].  +
Consider periodic reviews of accounts and privileges for critical and sensitive repositories.  +
Information which is sensitive to the operation and architecture of the process environment may be encrypted to ensure confidentiality and restrict access to only those who need to know.[[CiteRef::Guidance - NIST SP800-82]][[CiteRef::reference - NIST SP 800-53]]  +
Develop and publish policies that define acceptable information to be stored in repositories.  +
Ensure users and user groups have appropriate permissions for their roles through Identity and Access Management (IAM) controls to prevent misuse. Implement user accounts for each individual that may access the repositories for role enforcement and non-repudiation of actions.  +
Protect files stored locally with proper permissions to limit opportunities for adversaries to interact and collect information from databases.[[CiteRef::Guidance - NIST SP800-82]][[CiteRef::reference - NIST SP 800-53]]  +
Minimize permissions and access for service accounts to limit the information that may be exposed or collected by malicious users or software.[[CiteRef::reference - NIST SP 800-53]]  +
Review vendor documents and security alerts for potentially unknown or overlooked default credentials within existing devices  +
Ensure embedded controls and network devices are protected through access management, as these devices often have unknown default accounts which could be used to gain unauthorized access.  +
Provide operators with redundant, out-of-band communication to support monitoring and control of the operational processes, especially when recovering from a network outage [[CiteRef::reference - NIST SP 800-53]]. Out-of-band communication should utilize diverse systems and technologies to minimize common failure modes and vulnerabilities within the communications infrastructure. For example, wireless networks (e.g., 3G, 4G) can be used to provide diverse and redundant delivery of data.  +
Take and store data backups from end user systems and critical servers. Ensure backup and storage systems are hardened and kept separate from the corporate network to prevent compromise. Maintain and exercise incident response plans[[CiteRef::mitigation - developing IR - 200910]], including the management of "gold-copy" back-up images and configurations for key systems to enable quick recovery and response from adversarial activities that impact control, view, or availability.  +
Hot-standbys in diverse locations can ensure continued operations if the primarily system are compromised or unavailable. At the network layer, protocols such as the Parallel Redundancy Protocol can be used to simultaneously use redundant and diverse communication over a local network.[[CiteRef::mitigation - redundancy - 201302]]  +
System and process restarts should be performed when a timeout condition occurs.  +
Provide operators with redundant, out-of-band communication to support monitoring and control of the operational processes, especially when recovering from a network outage [[CiteRef::reference - NIST SP 800-53]]. Out-of-band communication should utilize diverse systems and technologies to minimize common failure modes and vulnerabilities within the communications infrastructure. For example, wireless networks (e.g., 3G, 4G) can be used to provide diverse and redundant delivery of data.  +
Take and store data backups from end user systems and critical servers. Ensure backup and storage systems are hardened and kept separate from the corporate network to prevent compromise. Maintain and exercise incident response plans [[CiteRef::mitigation - developing IR - 200910]], including the management of "gold-copy" back-up images and configurations for key systems to enable quick recovery and response from adversarial activities that impact control, view, or availability.  +
Hot-standbys in diverse locations can ensure continued operations if the primarily system are compromised or unavailable. At the network layer, protocols such as the Parallel Redundancy Protocol can be used to simultaneously use redundant and diverse communication over a local network.[[CiteRef::mitigation - redundancy - 201302]]  +
All field controllers should restrict the modification of programs to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism.  +
Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.  +
All field controllers should require users to authenticate for all remote or local management sessions. The authentication mechanisms should also support <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0936]]</span></span></span></span>, <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0927]]</span></span></span></span>, and <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0918]]</span></span></span></span>.  +
Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs).  +
Segment operational network and systems to restrict access to critical system functions to predetermined management systems.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Authenticate all access to field controllers before authorizing access to, or modification of, a device's state, logic, or programs. Centralized authentication techniques can help manage the large number of field controller accounts needed across the ICS.  +
Perform inline allowlisting of automation protocol commands to prevent devices from sending unauthorized command or reporting messages. Allow/denylist techniques need to be designed with sufficient accuracy to prevent the unintended blocking of valid messages.  +
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.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
All field controllers should restrict the modification of programs to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism.  +
Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.  +
All field controllers should require users to authenticate for all remote or local management sessions. The authentication mechanisms should also support <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0936]]</span></span></span></span>, <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0927]]</span></span></span></span>, and <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0918]]</span></span></span></span>.  +
Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs).  +
Segment operational network and systems to restrict access to critical system functions to predetermined management systems.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Ensure remote commands that enable device shutdown are disabled if they are not necessary. Examples include DNP3's 0x0D function code or unnecessary device management functions.  +
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.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Application denylists can be used to block automation protocol functions used to initiate device shutdowns or restarts, such as DNP3's 0x0D function code, or vulnerabilities that can be used to trigger device shutdowns (e.g., CVE-2014-9195, CVE-2015-5374).  +
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.  +
Utilize exploit protection to prevent activities which may be exploited through malicious web sites.  +
Built-in browser sandboxes and application isolation may be used to contain web-based malware.  +
Restrict browsers to limit the capabilities of malicious ads and Javascript.  +
Ensure all browsers and plugins are kept updated to help prevent the exploit phase of this technique. Use modern browsers with security features enabled.  +
E
Ensure all communication is filtered for potentially malicious content, especially for mobile workstations that may not be protected by boundary firewalls.  +
Enforce system policies or physical restrictions to limit hardware such as USB devices on workstations.  +
All remotely accessible services should implement access control mechanisms to restrict the information or services accessible to users.  +
Network allowlists can be implemented through either host-based files or system host files to specify what external 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 the <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0937]]</span></span></span></span> mitigation.  +
Consider implementing full disk encryption, especially if engineering workstations are transient assets that are more likely to be lost, stolen, or tampered with.[[CiteRef::reference - NIST SP 800-53]]  +
Update software on control network assets when possible. If feasible, use modern operating systems and software to reduce exposure to known vulnerabilities.   +
Segment and control software movement between business and OT environments by way of one directional DMZs. Web access should be restricted from the OT environment. Engineering workstations, including transient cyber assets (TCAs) should have minimal connectivity to external networks, including Internet and email, further limit the extent to which these devices are dual-homed to multiple networks.[[CiteRef::mitigation - transient cyber asset - 201912]]  +
Integrity checking of engineering workstations can include performing the validation of the booted operating system and programs using TPM-based technologies, such as Secure Boot and Trusted Boot.[[CiteRef::mitigation - TPM]] It can also include verifying filesystem changes, such as programs and configuration files stored on the system, executing processes, libraries, accounts, and open ports. [[CiteRef::mitigation - NSA positive zero - 201602]]  +
Install anti-virus software on all workstation and transient assets that may have external access, such as to web, email, or remote file shares.  +
Minimize the exposure of API calls that allow the execution of code.  +
All APIs used to perform execution, especially those hosted on embedded controllers (e.g., PLCs), should provide adequate authorization enforcement of user access. Minimize user's access to only required API calls.[[CiteRef::mitigation - CWE api abuse]]  +
All APIs on remote systems or local processes should require the authentication of users before executing any code or system changes.  +
Access Management technologies can be used to enforce authorization policies and decisions, especially when existing field devices do not provide capabilities to support user identification and authentication.[[CiteRef::mitigation - NIST 1800-2 IDAM - 201807]] 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.  +
Web Application Firewalls may be used to limit exposure of applications to prevent exploit traffic from reaching the application.[[CiteRef::Guidance - NIST SP800-41]]  +
Regularly scan externally facing systems for vulnerabilities and establish procedures to rapidly patch systems when critical vulnerabilities are discovered through scanning and public disclosure.  +
Segment externally facing servers and services from the rest of the network with a DMZ or on separate hosting infrastructure.  +
Use least privilege for service accounts.[[CiteRef::Guidance - NIST SP800-82]][[CiteRef::reference - NIST SP 800-53]]  +
Application isolation will limit the other processes and system features an exploited target can access. Examples of built in features are software restriction policies, AppLocker for Windows, and SELinux or AppArmor for Linux.  +
Regularly scan externally facing systems for vulnerabilities and establish procedures to rapidly patch systems when critical vulnerabilities are discovered through scanning and public disclosure.  +
Develop a robust cyber threat intelligence capability to determine what types and levels of threat may use software exploits and 0-days against a particular organization.  +
Make it difficult for adversaries to advance their operation through exploitation of undiscovered or unpatched vulnerabilities by using sandboxing. Other types of virtualization and application microsegmentation may also mitigate the impact of some types of exploitation. Risks of additional exploits and weaknesses in these systems may still exist.[[CiteRef::mitigation - VM escape eattack]]  +
Update software regularly by employing patch management for internal enterprise endpoints and servers.  +
Security applications that look for behavior used during exploitation such as Windows Defender Exploit Guard (WDEG) and the Enhanced Mitigation Experience Toolkit (EMET) can be used to mitigate some exploitation behavior.[[CiteRef::mitigation - windows exploit guard Eattack]] Control flow integrity checking is another way to potentially identify and stop a software exploit from occurring.[[CiteRef::mitigation - wikipedia control flow]] Many of these protections depend on the architecture and target application binary for compatibility and may not work for all software or services targeted.  +
Develop a robust cyber threat intelligence capability to determine what types and levels of threat may use software exploits and 0-days against a particular organization.  +
Make it difficult for adversaries to advance their operation through exploitation of undiscovered or unpatched vulnerabilities by using sandboxing. Other types of virtualization and application microsegmentation may also mitigate the impact of some types of exploitation. Risks of additional exploits and weaknesses in these systems may still exist.[[CiteRef::mitigation - VM escape eattack]]  +
Update software regularly by employing patch management for internal enterprise endpoints and servers.  +
Security applications that look for behavior used during exploitation such as Windows Defender Exploit Guard (WDEG) and the Enhanced Mitigation Experience Toolkit (EMET) can be used to mitigate some exploitation behavior.[[CiteRef::mitigation - windows exploit guard Eattack]] Control flow integrity checking is another way to potentially identify and stop a software exploit from occurring.[[CiteRef::mitigation - wikipedia control flow]] Many of these protections depend on the architecture and target application binary for compatibility and may not work for all software or services targeted.  +
Segment networks and systems appropriately to reduce access to critical system and services communications.  +
Develop a robust cyber threat intelligence capability to determine what types and levels of threat may use software exploits and 0-days against a particular organization.  +
Regularly scan the internal network for available services to identify new and potentially vulnerable services.  +
Ensure that unnecessary ports and services are closed to prevent risk of discovery and potential exploitation.  +
Make it difficult for adversaries to advance their operation through exploitation of undiscovered or unpatched vulnerabilities by using sandboxing. Other types of virtualization and application microsegmentation may also mitigate the impact of some types of exploitation. Risks of additional exploits and weaknesses in these systems may still exist.[[CiteRef::mitigation - VM escape eattack]]  +
Update software regularly by employing patch management for internal enterprise endpoints and servers.  +
Security applications that look for behavior used during exploitation such as Windows Defender Exploit Guard (WDEG) and the Enhanced Mitigation Experience Toolkit (EMET) can be used to mitigate some exploitation behavior.[[CiteRef::mitigation - windows exploit guard Eattack]] Control flow integrity checking is another way to potentially identify and stop a software exploit from occurring.[[CiteRef::mitigation - wikipedia control flow]] Many of these protections depend on the architecture and target application binary for compatibility and may not work for all software or services targeted.  +
Minimize permissions and access for service accounts to limit impact of exploitation.[[CiteRef::Guidance - NIST SP800-82]]  +
Configure features related to account use like login attempt lockouts, specific login times, and password strength requirements as examples. Consider these features as they relate to assets which may impact safety and availability.[[CiteRef::Guidance - NIST SP800-82]]  +
Use strong multi-factor authentication for remote service accounts to mitigate an adversary's ability to leverage stolen credentials. Be aware of multi-factor authentication interception techniques for some implementations.  +
Deny direct remote access to internal systems through the use of network proxies, gateways, and firewalls. Consider a jump server or host into the DMZ for greater access control. Leverage this DMZ or corporate resources for vendor access.[[CiteRef::Guidance - NIST SP800-82]]  +
Limit access to remote services through centrally managed concentrators such as VPNs and other managed remote access systems.  +
Consider removal of remote services which are not regularly in use, or only enabling them when required (e.g., vendor remote access). Ensure all external remote access point (e.g., jump boxes, VPN concentrator) are configured with least functionality, especially the removal of unnecessary services.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Consider utilizing jump boxes for external remote access. Additionally, dynamic account management may be used to easily remove accounts when not in use.  +
Set and enforce secure password policies for accounts.  +
G
Once an adversary has access to a remote GUI they can abuse system features, such as required HMI functions.  +
H
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.  +
Restrict the use of untrusted or unknown libraries, such as remote or unknown DLLs.  +
I
This technique may not be effectively mitigated against, consider controls for assets and processes that lead to the use of this technique.  +
Protect files stored locally with proper permissions to limit opportunities for adversaries to remove indicators of their activity on the system.[[CiteRef::Guidance - NIST SP800-82]][[CiteRef::reference - NIST SP 800-53]]  +
Deny direct remote access to internal systems through the use of network proxies, gateways, and firewalls. Steps should be taken to periodically inventory internet accessible devices to determine if it differs from the expected.  +
L
Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware or unusual data transfer over known tools and protocols like FTP can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific obfuscation technique used by a particular adversary or tool and will likely be different across various malware families and versions. Adversaries will likely change tool C2 signatures over time or construct protocols in such a way as to avoid detection by common defensive tools.[[CiteRef::University of Birmingham C2]]  +
Hot-standbys in diverse locations can ensure continued operations if the primarily system is compromised or unavailable. At the network layer, protocols such as the Parallel Redundancy Protocol can be used to simultaneously use redundant and diverse communication over a local network.[[CiteRef::mitigation - redundancy - 201302]]  +
Provide operators with redundant, out-of-band communication to support monitoring and control of the operational processes, especially when recovering from a network outage [[CiteRef::reference - NIST SP 800-53]]. Out-of-band communication should utilize diverse systems and technologies to minimize common failure modes and vulnerabilities within the communications infrastructure. For example, wireless networks (e.g., 3G, 4G) can be used to provide diverse and redundant delivery of data.  +
Take and store data backups from end user systems and critical servers. Ensure backup and storage systems are hardened and kept separate from the corporate network to prevent compromise. Maintain and exercise incident response plans [[CiteRef::mitigation - developing IR - 200910]], including the management of "gold-copy" back-up images and configurations for key systems to enable quick recovery and response from adversarial activities that impact control, view, or availability.  +
Provide operators with redundant, out-of-band communication to support monitoring and control of the operational processes, especially when recovering from a network outage [[CiteRef::reference - NIST SP 800-53]]. Out-of-band communication should utilize diverse systems and technologies to minimize common failure modes and vulnerabilities within the communications infrastructure. For example, wireless networks (e.g., 3G, 4G) can be used to provide diverse and redundant delivery of data.  +
Take and store data backups from end user systems and critical servers. Ensure backup and storage systems are hardened and kept separate from the corporate network to prevent compromise. Maintain and exercise incident response plans [[CiteRef::mitigation - developing IR - 200910]], including the management of "gold-copy" back-up images and configurations for key systems to enable quick recovery and response from adversarial activities that impact control, view, or availability.  +
Hot-standbys in diverse locations can ensure continued operations if the primarily system are compromised or unavailable. At the network layer, protocols such as the Parallel Redundancy Protocol can be used to simultaneously use redundant and diverse communication over a local network.[[CiteRef::mitigation - redundancy - 201302]]  +
Take and store data backups from end user systems and critical servers. Ensure backup and storage systems are hardened and kept separate from the corporate network to prevent compromise. Maintain and exercise incident response plans [[CiteRef::mitigation - developing IR - 200910]], including the management of "gold-copy" back-up images and configurations for key systems to enable quick recovery and response from adversarial activities that impact control, view, or availability.  +
Ensure that all SIS are segmented from operational networks to prevent them from being targeted by additional adversarial behavior.  +
Protection devices should have minimal digital components to prevent exposure to related adversarial techniques. Examples include interlocks, rupture disks, release valves, etc.[[CiteRef::mitigation - applying IEC 61511 - 2004]]  +
Provide operators with redundant, out-of-band communication to support monitoring and control of the operational processes, especially when recovering from a network outage [[CiteRef::reference - NIST SP 800-53]]. Out-of-band communication should utilize diverse systems and technologies to minimize common failure modes and vulnerabilities within the communications infrastructure. For example, wireless networks (e.g., 3G, 4G) can be used to provide diverse and redundant delivery of data.  +
Take and store data backups from end user systems and critical servers. Ensure backup and storage systems are hardened and kept separate from the corporate network to prevent compromise. Maintain and exercise incident response plans [[CiteRef::mitigation - developing IR - 200910]], including the management of "gold-copy" back-up images and configurations for key systems to enable quick recovery and response from adversarial activities that impact control, view, or availability.  +
Hot-standbys in diverse locations can ensure continued operations if the primarily system are compromised or unavailable. At the network layer, protocols such as the Parallel Redundancy Protocol can be used to simultaneously use redundant and diverse communication over a local network.[[CiteRef::mitigation - redundancy - 201302]]  +
M
To protect against MITM, authentication mechanisms should not send credentials across the network in plaintext and should also implement mechanisms to prevent replay attacks (such as nonces or timestamps). Challenge-response based authentication techniques that do not directly send credentials over the network provide better protection from MITM.  +
Network intrusion detection and prevention systems that can identify traffic patterns indicative of MiTM activity can be used to mitigate activity at the network level.  +
Use network appliances and host-based security software to block network traffic that is not necessary within the environment, such as legacy protocols that may be leveraged for MiTM.  +
Limit access to network infrastructure and resources that can be used to reshape traffic or otherwise produce MiTM conditions.  +
Network segmentation can be used to isolate infrastructure components that do not require broad network access. This may mitigate, or at least alleviate, the scope of MiTM activity.  +
Utilize out-of-band communication to validate the integrity of data from the primary channel.  +
Communication authenticity will ensure that any messages tampered with through MITM can be detected, but cannot prevent eavesdropping on these. In addition, providing communication authenticity around various discovery protocols, such as DNS, can be used to prevent various MITM procedures.  +
Statically defined ARP entries can prevent manipulation and sniffing of switched network traffic, as some MitM techniques depend on sending spoofed ARP messages to manipulate network host's dynamic ARP tables.  +
Disable unnecessary legacy network protocols that may be used for MiTM if applicable.  +
This technique may not be effectively mitigated against, consider controls for assets and processes that lead to the use of this technique.  +
Take and store data backups from end user systems and critical servers. Ensure backup and storage systems are hardened and kept separate from the corporate network to prevent compromise. Maintain and exercise incident response plans [[CiteRef::mitigation - developing IR - 200910]], including the management of "gold-copy" back-up images and configurations for key systems to enable quick recovery and response from adversarial activities that impact control, view, or availability.  +
Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs).  +
Utilize out-of-band communication to validate the integrity of data from the primary channel.  +
Take and store data backups from end user systems and critical servers. Ensure backup and storage systems are hardened and kept separate from the corporate network to prevent compromise. Maintain and exercise incident response plans [[CiteRef::mitigation - developing IR - 200910]], including the management of "gold-copy" back-up images and configurations for key systems to enable quick recovery and response from adversarial activities that impact control, view, or availability.  +
Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs).  +
Utilize out-of-band communication to validate the integrity of data from the primary channel.  +
Use tools that restrict program execution via application control by attributes other than file name for common system and application utilities.  +
Use file system access controls to protect system and application folders.  +
Require signed binaries.  +
Segment operational network and systems to restrict access to critical system functions to predetermined management systems.[[CiteRef::Guidance - DHS Defense in Depth - 201609]][[CiteRef::mitigation - alarm management]]  +
Limit privileges of user accounts and groups so that only designated administrators or engineers can interact with alarm management and alarm configuration thresholds.  +
Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.  +
All field controllers should require users to authenticate for all remote or local management sessions. The authentication mechanisms should also support <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0936]]</span></span></span></span>, <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0927]]</span></span></span></span>, and <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0918]]</span></span></span></span>.  +
Only authorized personnel should be able to change settings for alarms.  +
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.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
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.  +
Utilize code signatures to verify the integrity of the installed program on safety or control assets has not been changed.  +
Provide the ability to verify the integrity of control logic or programs loaded on a controller. While techniques like CRCs and checksums are commonly used, they are not cryptographically strong and can be vulnerable to collisions. Preferably cryptographic hash functions (e.g., SHA-2, SHA-3) should be used.[[CiteRef::Guidance - 62443:4-2]]  +
All field controllers should restrict the modification of programs to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism.  +
Provide the ability to verify the integrity of control logic or programs loaded on a controller. While techniques like CRCs and checksums are commonly used, they are not cryptographically strong and can be vulnerable to collisions. Preferably cryptographic hash functions (e.g., SHA-2, SHA-3) should be used.[[CiteRef::Guidance - 62443:4-2]]  +
Utilize code signatures to verify the integrity of the installed program on safety or control assets has not been changed.  +
Provide the ability to verify the integrity of control logic or programs loaded on a controller. While techniques like CRCs and checksums are commonly used, they are not cryptographically strong and can be vulnerable to collisions. Preferably cryptographic hash functions (e.g., SHA-2, SHA-3) should be used.[[CiteRef::Guidance - 62443:4-2]]  +
The encryption of firmware should be considered to prevent adversaries from identifying possible vulnerabilities within the firmware.  +
Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.  +
The encryption of firmware should be considered to prevent adversaries from identifying possible vulnerabilities within the firmware.  +
Check the integrity of the existing BIOS or EFI to determine if it is vulnerable to modification. Use Trusted Platform Module technology.[[CiteRef::mitigation - trusted platform module eattack]] Move system's root of trust to hardware to prevent tampering with the SPI flash memory.[[CiteRef::mitigation - UEFI rootkit eattack]] Technologies such as Intel Boot Guard can assist with this.[[CiteRef::mitigation - intel hw security eattack]]  +
Protocols used for device management should authenticate all network messages to prevent unauthorized system changes.  +
Segment operational network and systems to restrict access to critical system functions to predetermined management systems.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Devices that allow remote management of firmware should require authentication before allowing any changes. The authentication mechanisms should also support <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0936]]</span></span></span></span>, <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0927]]</span></span></span></span>, and <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0918]]</span></span></span></span>.  +
Filter for protocols and payloads associated with firmware activation or updating activity.  +
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.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
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.  +
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.  +
Devices should verify that firmware has been properly signed by the vendor before allowing installation.  +
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.  +
N
Minimize the exposure of API calls that allow the execution of code.  +
Network connection enumeration is likely obtained by using common system tools (e.g., netstat, ipconfig).  +
Segment networks and systems appropriately to reduce access to critical system and services communications.  +
Restrict root or administrator access on user accounts to limit the ability to capture promiscuous traffic on a network through common packet capture tools.[[CiteRef::reference - NIST SP 800-53]]  +
Ensure that wired and/or wireless traffic is encrypted when feasible. Use best practices for authentication protocols, such as Kerberos, and ensure web traffic that may contain credentials is protected by SSL/TLS.[[CiteRef::Guidance - NIST SP800-82]]  +
Use multi-factor authentication wherever possible.  +
Statically defined ARP entries can prevent manipulation and sniffing of switched network traffic, as some MitM techniques depend on sending spoofed ARP messages to manipulate network host's dynamic ARP tables.  +
P
Devices should authenticate all messages between master and outstation assets.  +
All field controllers should require users to authenticate for all remote or local management sessions. The authentication mechanisms should also support <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0936]]</span></span></span></span>, <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0927]]</span></span></span></span>, and <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0918]]</span></span></span></span>.  +
Systems and devices should restrict access to any data with potential confidentiality concerns, including point and tag information.  +
Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs).  +
Segment operational assets and their management devices based on their functional role within the process. Enabling more strict isolation to more critical control and operational information within the control environment.[[CiteRef::Guidance - NIST SP800-41]][[CiteRef::Guidance - NIST SP800-82]][[CiteRef::Guidance - DHS Defense in Depth - 201609]][[CiteRef::mitigation - SANS whitelisting]]  +
Authenticate all access to field controllers before authorizing access to, or modification of, a device's state, logic, or programs. Centralized authentication techniques can help manage the large number of field controller accounts needed across the ICS.  +
Perform inline allowlisting of automation protocol commands to prevent devices from sending unauthorized command or reporting messages. Allow/denylist techniques need to be designed with sufficient accuracy to prevent the unintended blocking of valid messages.  +
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.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
All field controllers should restrict the modification of programs to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism.  +
Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.  +
Utilize code signatures to verify the integrity of the installed program on safety or control assets has not been changed.  +
All field controllers should require users to authenticate for all remote or local management sessions. The authentication mechanisms should also support <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0936]]</span></span></span></span>, <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0927]]</span></span></span></span>, and <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0918]]</span></span></span></span>.  +
Filter for protocols and payloads associated with program download activity to prevent unauthorized device configurations.  +
Protocols used for device management should authenticate all network messages to prevent unauthorized system changes.  +
Segment operational network and systems to restrict access to critical system functions to predetermined management systems.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Provide the ability to verify the integrity of control logic or programs loaded on a controller. While techniques like CRCs and checksums are commonly used, they are not cryptographically strong and can be vulnerable to collisions. Preferably cryptographic hash functions (e.g., SHA-2, SHA-3) should be used.[[CiteRef::Guidance - 62443:4-2]]  +
Authenticate all access to field controllers before authorizing access to, or modification of, a device's state, logic, or programs. Centralized authentication techniques can help manage the large number of field controller accounts needed across the ICS.  +
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.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Filter for protocols and payloads associated with program upload activity to prevent unauthorized access to device configurations.  +
Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.  +
All field controllers should restrict program uploads to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism.  +
All field controllers should require users to authenticate for all remote or local management sessions. The authentication mechanisms should also support <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0936]]</span></span></span></span>, <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0927]]</span></span></span></span>, and <span class="smw-format list-format "><span class="smw-row"><span class="smw-field"><span class="smw-value">[[Mitigation/M0918]]</span></span></span></span>.  +
Protocols used for device management should authenticate all network messages to prevent unauthorized system changes.  +
Segment operational network and systems to restrict access to critical system functions to predetermined management systems.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Authenticate all access to field controllers before authorizing access to, or modification of, a device's state, logic, or programs. Centralized authentication techniques can help manage the large number of field controller accounts needed across the ICS.  +
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.[[CiteRef::Guidance - DHS Defense in Depth - 201609]]  +
Review the integrity of project files to verify they have not been modified by adversary behavior. Verify a cryptographic hash for the file with a known trusted version, or look for other indicators of modification (e.g., timestamps).  +
Allow for code signing of any project files stored at rest to prevent unauthorized tampering. Ensure the signing keys are not easily accessible on the same system.  +
Ensure permissions restrict project file access to only engineer and technician user groups and accounts.  +
When at rest, project files should be encrypted to prevent unauthorized changes.[[CiteRef::reference - NIST SP 800-53]]  +
R
Access Management technologies can help enforce authentication on critical remote service, examples include, but are not limited to, device management services (e.g., telnet, SSH), data access servers (e.g., HTTP, Historians), and HMI sessions (e.g., RDP, VNC).  +
Limit the accounts that may use remote services. Limit the permissions for accounts that are at higher risk of compromise; for example, configure SSH so users can only run specific programs.  +
All remote services should require strong authentication before providing user access.  +
All communication sessions to remote services should be authenticated to prevent unauthorized access.  +
Enforce strong password requirements to prevent password brute force methods for lateral movement.  +
Provide privileges corresponding to the restriction of a GUI session to control system operations (examples include HMI read-only vs. read-write modes). Ensure local users, such as operators and engineers, are giving prioritization over remote sessions and have the authority to regain control over a remote session if needed. Prevent remote access sessions (e.g., RDP, VNC) from taking over local sessions, especially those used for ICS control, especially HMIs.  +
Filter application-layer protocol messages for remote services to block any unauthorized activity.  +
Segment and control software movement between business and OT environments by way of one directional DMZs. Web access should be restricted from the OT environment. Engineering workstations, including transient cyber assets (TCAs) should have minimal connectivity to external networks, including Internet and email, further limit the extent to which these devices are dual-homed to multiple networks.[[CiteRef::mitigation - transient cyber asset - 201912]]  +
Network allowlists can be implemented through either host-based files or system host files to specify what external connections (e.g., IP address, MAC address, port, protocol) can be made from a device.  +
Ensure that unnecessary ports and services are closed to prevent risk of discovery and potential exploitation.  +
ICS environments typically have more statically defined devices, therefore minimize the use of both IT discovery protocols (e.g., DHCP, LLDP) and discovery functions in automation protocols.[[CiteRef::mitigation - CSIAC discovery assets]][[CiteRef::mitigation - SEL discovery SDN]] Examples of automation protocols with discovery capabilities include OPC UA Device Discovery [[CiteRef::mitigation - OPC discovery]], BACnet [[CiteRef::mitigation - bacnet discovery]], and Ethernet/IP.[[CiteRef::mitigation - EthernetIP discovery]]  +
Use network intrusion detection/prevention systems to detect and prevent remote service scans.  +
Ensure proper network segmentation is followed to protect critical servers and devices.  +