IT-OT Convergence and Log4j

By: Baksheesh Singh Ghuman

IT-OT Convergence

By now, we’re all likely tired of talking about Log4j and nodding our heads over Zoom when we all discuss the ramifications of exploitation of this small, but very pervasive and powerful vulnerability. At the risk of adding another layer of complexity to the information we have learned about Log4j, I think we are remiss not to mention IT-OT (Information Technology-Operational Technology) convergence and how it could be an enabler for Log4j to impact our critical infrastructure. 

Digital transformation, Internet of Things (IoT), Industrial Internet of Things (IIoT) all are driving a lot of IT-OT convergence, which means that once air-gapped OT networks are  slowly integrating with IT systems to drive efficiencies, productivity, and profitability. The majority of critical infrastructure such as aviation, utilities, electric grid, banking, railroads, food processing, and pipeline operators are all moving in that direction. This means that the attack surface is now extending to parts of the network that were not previously accessible. What makes it more complicated is that often the entire attack surface is not visible, which creates   blind spots that can be used by threat actors to access an unguarded part of the network and cause havoc. 

There is one example in recent history that helps us understand the impact of IT-OT convergence in cybersecurity by the reaction of the affected operator:Colonial Pipeline. The Colonial Pipeline cyberattack was a ransomware attack, the threat actors targeted their IT business systems. Colonial Pipeline employees, upon realizing they were under attack, reacted by disconnecting their OT networks from IT networks as a precautionary move. This caused them to halt operations that had business consequences, but there was no reported breach. This reaction indicates that their OT networks were at risk and they were concerned that the threat actors would laterally move and attack their Operational Technology/Industrial Control Systems (OT/ICS) networks, potentially causing more damage than just suspension of operations.

Mutational Log4j and What it Means for OT/ICS Networks

The impact of threat actors gaining access to the critical systems can be catastrophic ranging from data loss, power loss, or even potential loss of life. There are numerous examples of  critical infrastructure being disrupted by threat actors. Below are a few examples from the last 5 years.  

• Oldsmar, Florida water treatment plant causing potential dangerous levels of sodium hydroxide 

• Ukraine’s power grid attack causing loss of power

• San Francisco, California Muni rail system causing disruption of ticketing systems

• NTT Communications breach lead to customer data loss 

• Toyota cyberattack caused loss of customer data 

Log4j is the logging utility of the Java logging systems. There are a large number of applications, particularly open source, that use this utility within the OT networks. Log4j equally impacts open source as well as first party software. The Apache Log4j cyberattack and its pervasive nature across millions of interconnected devices, and now converged networks made me think: 

• Since Log4j is a zero-day vulnerability, did Log4j play any role in the previous critical infrastructure cyberattacks?

• Did the threat actors use Log4j to gain access to their OT networks by moving laterally from IT to OT?

• Are threat actors lying dormant and persisting within the attack surface waiting for the right opportunity to attack?

One question that really requires some analysis is – does Log4j really impact OT networks? The answer depends on the answer to a question. Do the applications used by your OT networks have the Log4j package? If the answer is yes, then they are impacted. If no, then you are not impacted. But given the pervasive nature of the Log4j library, it is highly probable that this will impact OT/ICS networks.

Devices that could be potential targets in the OT/ICS world include:  

• Human machine interfaces (HMIs) 

• Data Historians

• Edge servers, firewalls, routers, and switches

• Embedded systems and IIoT devices

• Supervisory control and data acquisition (SCADA) and Energy management systems (EMS) systems that use Java in their code base and configured for remote access are highly vulnerable

To make matters even more complicated, there have been many versions of the Log4j vulnerability. Log4j has already mutated from its first public appearance on Dec 9, 2021:

• Started with CVE-2021-44228, was patched with Apache Log4j 2.15.0

• A Remote code execution (RCE) vulnerability CVE-2021-45046  was found within CVE-2021-44228 was patched with Apache Log4j 2.16.0

• CVE-2021-4104, also emerged, allowing RCE like CVE-2021-44228 and CVE-2021-45046 in certain non-default configurations of log4j 1.2

• CVE-2021-45105, allows a Denial-of-Service (DoS) was patched with Apache Log4j 2.17.0 

A mutational vulnerability like Log4j may be the “in” that threat actors need in order to exploit and cause damage. So I say, Log4j is not just an IT vulnerability. In a converged, digitally transformed, interconnected reality Log4j is an IT, OT, on-prem, cloud, hybrid, home, network… threat that can disrupt our lives in many ways. OT network operators who are interconnected to cloud, IT, and other systems should adopt the same strategy and urgency that their IT counterparts are adopting. The threat is not just limited to what we know, but it is what we don’t know and what could happen when new mutations of the Log4j vulnerabilities show up.

What Should OT/ICS Operators Do

CISA has issued an advisory urging Critical infrastructure operators to patch any Log4j vulnerabilities within their networks ASAP. There is a growing concern that threat actors, including nation states and their proxies, could compromise networks and cause significant long term damage to our nation’s critical infrastructure. 

Rezilion recommends that in addition to following the official directives, as well as guidance from their vendors (such as Schneider, Siemens, or Prosys, who have already issued guidance), OT and critical infrastructure organizations should take the following three steps:

• Get Dynamic Visibility – One of the biggest challenges for OT/ICS networks is visibility. A Dynamic SBOM, like the one offered by Rezilion provides comprehensive and continuous visibility into the entire attack surface, including the interconnected IT attack surface which may be cloud, onprem, devops, etc. to know where the Log4j vulnerabilities are

• Vulnerability Contextualization – Once you know your attack surface, you should contextualize these vulnerabilities to find out which ones are exploitable and which ones are not. This contextualization is similar to the VEX proposed by NTIA, except that it should be dynamic 

• Remediation – With the right contextualized understanding of risk, follow the remediation that lowers that risk. Remediation can range from, but not limited to, patching, disconnecting, recommended workarounds, to even deleting files, libraries, or packages necessary.  Additionally OT/ICS operators can take steps such as isolating/moving these devices to secure zones and implement mitigating controls.

We understand that patching may not be a quick remediation in the OT world and CISA along with several vendors have made recommendations which you can find here. You can find Apache’s workarounds here. Additionally, CISA created a community-sourced GitHub repository that it plans to populate with publicly available information and vendor-supplied advisories. Another CISA resource for mitigating Log4j related vulnerabilities can be found here.

The Rezilion platform can help you catch up and stay ahead of your Log4j vulnerabilities through its 3 step approach in under 3 minutes. You can find out more and contact us at rezilion.com.