Property:Has mitigation description

From attackics
Jump to navigation Jump to search

This is a property of type Text.

Showing 100 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.   +