You’d have to look far and wide to find an IT professional who isn’t aware of (and probably responding to) the Log4Shell vulnerability. The Operational Technology (OT) sector is no exception, yet the exact exposure the vulnerability poses to OT technology is yet to be fully uncovered.

The vulnerability was first made public earlier this month and you can learn more about it here, including information on the most recent patch. As the IT world continues to fortify their networks to defend against possible intrusions, OT environments may require a more focused approach.

The Potential Risk for the OT Sector

While we’re not aware of any published OT compromises, they’re an easy target for attackers looking to exploit Log4j given how pervasive it is in Java programs developed over the past decade.

One potential vector could target companies that have OT networks. Think about this hypothetical scenario: an attacker could gain initial access to the IT network through a vulnerable soft phone management system. After setting up that system to act as a proxy into the internal network, they may discover a vulnerable logging and monitoring system configured as dual homed for information collection. With access to such a system on both networks, an attacker could then begin directly accessing OT technology — which may be insecure by design — or the attacker could access engineering workstations and HMIs that may be directly connected to unauthenticated OT devices.

For all the types of devices mentioned in this potential scenario, at least one public advisory has been issued for a Log4Shell-related vulnerability.

Therefore, the Log4Shell vulnerability can affect the key technologies that comprise and support OT systems. Some of these include:

• Servers (ex. Historians, Edge servers)
• Workstations (ex. HMI’s)
• Network equipment (firewalls, routers, and switches)
• Embedded devices (ex. web cams, car navigation systems, parking meters and medical devices)

Actions OT Security Teams Should Take Now

The Log4Shell vulnerabilities (CVE-2021-44228 and CVE-2021-45046) are new, but not novel. The best mitigation strategies for OT environments can still be found in proper system design and architecture (ex. ISA 62443 Reference Model) or zero trust architecture. To that effect, the following are IBM Security X-Force’s critical considerations for constraining Log4Shell impact in OT:

1. Identify high risk systems and proactively patch as feasible:

• OT systems closest to enterprise networks have the greatest risk exposure and are most likely to be leveraged by a threat actor as a pivot point into OT.
• Some key ICS vendors have already released advisories (e.g., Siemens, Schneider and Prosys). Prioritize Log4j identification and remediation using these vendor advisories or active scans (where feasible) capable of identifying Log4j implementations.
• OT environments are typically full of equipment that can’t be patched, End-of-Life (EOL), cyber fragile, or “insecure by design.” If patching is not feasible, ensure these systems are isolated to secure zones and/or mitigating controls are in place.

2. Ensure, at minimum, IT/OT segmentation and perimeter protection exists:

• In OT cybersecurity the enterprise zone is considered untrusted, so the greatest risk reduction activity will be to ensure a least privilege ruleset limits dataflow between IT and OT to only “business justified” ports/protocols and source/destinations.
• This least privilege ruleset should significantly reduce the threat of Log4j command and control capabilities by threat actors.

3. Monitor the OT network:

• If Intrusion Detection System (IDS) and network monitoring systems are deployed in the OT network, you can configure it with Log4Shell IOCs to detect and escalate the alerts for faster response to potential exploitation. Note these advisories from OT IDS vendors (Armis, Claroty, and Nozomi).
• Use your log management software to hunt for exploitation attempts.
• The following visual is an example of a hypothesis-driven threat hunting using X-Force’s Threat Hunting Framework. We recommend cybersecurity teams develop exhaustive lists of TTPs and execute hypothesis-based hunts as future exploits are released:

Figure 1: IBM X-Force Threat Hunting Framework to Detect Log4Shell RCE Vulnerability. (Credit: John Dwyer, X-Force IR Research)

4. Software Bill of Materials:

• OT systems are typically proprietary in nature. A full software inventory of these systems is often not available. Work with your vendors to collect, maintain, and update software inventory to keep track of what components vendors may be using in their systems.

5. Refresh and practice OT incident response plans:

• Ensure a dedicated incident response plan is developed for OT environments.
• Ensure OT playbooks and procedures are developed and rehearsed to ensure incident response team members can effectively support such events. Use lessons learned from these exercises to update your plans on a regular basis.

Don’t Overlook Your IIoT Systems

In addition, organizations should not ignore their IIoT systems. These systems connect to cloud or private networks using embedded and edge devices and can include web cams, medical devices, parking meters, navigation systems, and more. If left vulnerable, these devices could allow attackers to pivot into enterprise or cloud environments.

This is a rapidly evolving issue. All OT security teams should continue to be diligent, and ensure these systems are protected as described above.

Assistance for customers suspecting a potential compromise due to Log4j is available 24/7 via IBM Security X-Force’s US hotline 1-888-241-9812 | Global hotline (+001) 312-212-8034. Requests for updates on IBM products and services should not be directed to the hotline. Updates on the status of products can be found via bulletins posted on the IBM PSIRT blog.