Log4Shell vulnerability risks for OT environments — and how you can better protect against them.

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.

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.