Property:Has mitigation description

From attackics
Jump to navigation Jump to search

This is a property of type Text.

Showing 50 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]]  +