MID-039: Restrict Software Diagnostic Functions
Mitigation Tier: Foundational
Description
Diagnostic software functions or modes oftentimes give users who control them access to low-level device information. This control could involve read/write permissions of raw memory, process control, process monitoring, and power information, for example. To prevent a threat actor from having this level of access, device designers could either remove the functionality or, if it is needed, heavily restrict its usage.
If a device doesn’t need diagnostic functionality, it is more secure for that device to not have any present. Diagnostic functions provide a large threat vector for threat actors because of their inherently privileged nature. By removing the functionality, threat actors have no already-installed tool on the device that gives them such low level access.
If a device must have diagnostic functionality, those functions should be heavily restricted. One way this can be done is by restricting the diagnostic functions to certain processes. This could limit the potential impact of a threat actor because they would be scoped to a narrow part of the device. Another way to implement this is by using a processor that has features to prevent unintended tampering (open states, restricted state, and closed state). This would provide a hardware-enforced means to limit the ability of a remote threat actor from accessing the diagnostic functions.
Limitations: If threat actors are able to take control over the protection mechanisms that grant or revoke diagnostic functionality access, they may be able to escalate their privileges and take control over a device.
IEC 62443 4-2 Mappings
CR 1.1 - Human user interaction and authentication
CR 2.1 - Authorization Enforcement
CR 6.1 – Audit log accessibility
CR 3.7 – Error handling
CR 3.9 – Protection of audit information