The log4j vulnerability is a cybersecurity loop-hole that exploits a small, nearly ubiquitous piece of software called log4j, which is used for recording the activities of various computer programs. This logging of events, errors, and routine system operations is performed so that diagnostic messages can be communicated to system administrators and users. However, log4j also allows third-party servers to submit software code which, in the hands of a hacker, could be used to perform malicious actions on a targeted system, such as stealing sensitive information, taking control of a system, or passing malicious content onto other users communicating with the affected server.
Currently, no information has been made available about log4j compromises to any industrial control systems (ICS). Still, because the code is so commonly used, it remains entirely possible. To learn more about how industrial operators can protect their systems, Automation World spoke with Dennis Hackney, head of industrial cybersecurity services development at ABS Group, an operational risk management company and provider of cybersecurity consulting services.
How the Log4j Vulnerability Can Affect an ICS If a log4j attack occurs, malicious code could be executed on an ICS, granting a threat actor the ability to take control of applications used to view and control physical processes, Hackney says. If an ICS safety system is in place, this loss of control may only result in a temporary system shutdown from which the ICS can be rebooted to an earlier state. However, if no safety system is in place and the software controlling the ICS is compromised, a hacker could gain control. This can occur even if the software on the breached ICS is not controlling a process directly. In a worst-case scenario where an application controls physical processes involving large machinery such as pumps, valves, or tanks that contain hazardous materials or are in close proximity to employees, catastrophic and severe safety risks could result.
According to Hackney, a log4j breach could lead to several hypothetical situations:
- If a historian server were compromised, historical process data pertaining to process trending or control system performance could be stolen.
- If a SCADA (supervisory control and data acquisition) server is compromised, threat actors could view or control processes by interpreting the data, making control changes, or modifying sensor readings in a way that goes unnoticed by operators. This could lead to equipment damage, environmental accidents, or even injuries to employees.
- If ransomware were to be installed on an ICS, the entire system could be shut down, forcing operators to either pay a ransom fee or engage in a complete rebuild of their ICS servers and workstations.
How Can Industrial Operations be Protected Against Log4j Attacks? Hackney also offers several suggestions on how end users of control systems can become more proactive in preventing a potential log4j attack:
- Identify and isolate any critical ICSs from the internet and business networks.
- Develop isolation and manual control workarounds that limit the number of operational impacts that could occur if a vulnerability like log4j is discovered.
- Monitor necessary outgoing connections for cyber threats. Many ICS produce outgoing communications pertaining to maintenance, metering, diagnostics, and more.
- Ensure that frequent backups are made, and that rigid backup procedures exist. If operators have a stable backup of their ICS, they can guarantee that, should an incident occur, they can bring their systems back online as quickly as possible.
- Update the version of log4j used in your systems. The National Institute of Standards National Vulnerability Database reports that Log4Shell (the name for the log4j vulnerability) has been disabled from log4j 2.15.0 and completely removed from version 2.16.0.
In addition, there are steps that ICS vendors and original equipment manufacturers (OEMs) can take, Hackney says. For one, they should announce any log4j vulnerabilities that exist in their products, since end users might not even be aware of them. From there, they should release remediations, mitigations, and patches to help prevent a log4j breach. OEMs can also assist their clients in the discovery of log4j vulnerabilities through the development of specialized support services. Not only would this help end users to protect themselves more easily, but it could also advantage the OEMs by giving their customers access to a premium service that competitors may not be providing. According to Hackney, this service could be provided via a cyber response hotline that customers could call to receive guidance on how best to discover and address vulnerabilities in their ICS. Finally, Hackney recommends that all ICS vendors and OEMs update their design, engineering, and acceptance testing processes to include cybersecurity practices and vulnerability management.
