4 Ways to Manage the Impact of Log4j in OT Environments

The Log4j vulnerability or Log4Shell is not the gift organizations wanted Santa to bring them just before the holiday season, but it is the unfortunate gift that will keep on giving in industrial and critical infrastructure environments.

There are multiple reasons why this vulnerability is one of the worst in the last decade. It is:

• highly exploitable if there is exposure – e.g., Internet access, and a vulnerable implementation
• present in a lot of different systems and applications – many affected products are still unknown
• found in 8% of all Java packages, whereas the median for other vulnerabilities is 0.1%.
• present in most OT / ICS environments where Java-based user-land applications are deployed, Java-based VPN clients are used, and on some edge devices.

What is Log4j?

The Log4j vulnerability is a sub-component for Java applications buried in various systems and applications, and some of the affected systems are used in industrial facilities.  The fix is available in source-code form, but vendors must provide the binary update.

Watch the full Log4j video here

How is Log4j exploited?

So, how can a potential threat actor exploit the Log4j vulnerability, and what might result in the case of an attack? One potential threat scenario where this vulnerability is exploited could be:

• A threat actor penetrates the network and compromises an unpatched system to exploit the log4j vulnerability and distribute a cyber payload to another critical server.
• The compromised systems are used as a launchpad to attack other adjacent systems.

For these reasons (and more), Log4j has occupied cybersecurity professionals for many weeks and will do so for the foreseeable future. So, what can asset owners do to mitigate the impact log4j will have on their OT environments?

How does Log4j impact OT environments?

Imagine for example that someone – Let’s call him Bob – is looking for a specific box in his new house after he just moved in, and that this box contains all the information necessary for a threat actor to potentially control the HVAC systems in his house. Bob knows that this box is in one of the many rooms in the house, but each room contains hundreds of boxes filled with other items. Bob knows that this specific box is probably somewhere in the house, but as he is looking for it, so are the threat actors.

To put this in computer terms, if the house represents an asset, then the rooms are systems or applications, and the boxes are embedded code inside those applications (Log Libraries), one of which is Log4j. Now imagine that Bob – who represents the company or the cybersecurity team in charge of managing this vulnerability – must do the same exercise for the entire city, a.k.a the network.

For starters, it is overwhelming for asset owners to find affected assets, it might grow the risk register, and consume invaluable time. But what happens if the cybersecurity team cannot find Log4J in their environment before threat actors do? Threat actors could potentially exploit the vulnerability and Log4Shell has the potential to impact people, process, and technology for organizations; particularly where there is enterprise integration or IT/OT convergence using commodity software.

Exploiting this vulnerability could also allow malicious actors into the network. Once inside, the possibilities drastically increase for further compromise and disruption. These threat actors can either gain access to other systems and subnets with lateral movement or they can stay where they are, but in either case, the next steps of this cyber kill chain is to prepare and execute a cyber-physical payload on the compromised network as shown in the threat scenario mentioned above.

How can Log4j be mitigated?

There are several methods for organizations to manage the Log4j vulnerability (and others like it), but at a high level, asset owners should:

1. Understand how the vulnerability may affect the environment, and which assets it applies to (if at all).
2. Use asset management to verify if relevant Log4j vulnerabilities to software known to potentially contain affected software.  This should include both commodity Windows/Linux-based systems, and edge devices.  Another approach might be to use Software Bill of Material (SBOM) and Vulnerability exChange (VEX) documents to augment risk decisions or suggest potential vulnerability hotspots.
3. Identify affected assets, assess for compromise, and patch where possible (and abide by change/compliance restrictions).
4. Enact compensating controls, limit access to vulnerable systems if absolute mitigation cannot be performed.

4 ways to manage Log4Shell

1.     Understand how the vulnerability may affect the environment, and which assets it applies to (if at all)

In order to manage this vulnerability, there are two initial problems:

• it’s hard to find without a proper inventory,
• and companies need to have a proper method of detecting affected assets.

Without a complete asset inventory, asset owners can only manage what they know. Therefore, how does one succeed when it comes to managing assets, monitoring, and understanding what’s happening in the environment or mitigating risks if there’s virtually no way to really know which assets can be affected/impacted, what the flows are between devices, and subnets, or even to know if those assets exist in the first place.

To go back to the analogy that was presented above, what happens if Bob doesn’t know the size of the houses he has to manage, the number of rooms they have, and he potentially doesn’t even know that some of those houses and potentially entire neighborhoods exist? Then when it comes to Log4j, there’s no way for him to know where he should be looking in the first place.

2.     Use Software Bill of Material (SBOM) to augment CVE/CPE correlation mechanisms

SBOM allows organizations to know if they can have absolute trust regarding the components inside of their systems. When creating SBOM’s, software companies parse data that includes content in the system’s libraries. They generally are granular in their analysis of assets to ascertain a trust value for a given software and firmware that is part of a supply chain.  With this analysis, they can report back to asset owners which applications and systems may potentially contain that log file.

SBOMs alone are mostly a full “ingredients” list of a product, but they require enrichment, and ultimately, seamless integration into asset management solutions to be of full use to end-users.  It would be unfair to expect an asset owner to have the amount of skilled resources required to continuously manage this on top of their day-to-day demands; assuming they could humanly review thousands of SBOM artifacts in the first place.

Using this knowledge, ICS asset owners should look at their current stack of software and firmware and with simple correlations, identify owned assets that could potentially be vulnerable. They can also use it to look at their updates or at the new versions of software that they are planning on installing on their network.

3.     Identify affected assets, assess for compromise, and patch where possible

Once a company has an idea of where to look for Log4j – a solid and detailed asset inventory and SBOMs to suggest potential vulnerability hotspots – then it is time to detect the affected assets. Using available information, cybersecurity teams can target specific assets that could host the Log4j vulnerability and assess for compromise.

Although it is highly unlikely that a cybersecurity team will identify all the log4j affected assets in a single click, it’s important for an organization that they detect as much as possible so they can manage and patch those assets.

Even if an organization was able to gather and analyze all the information on their assets, not every vulnerable asset is eligible for patching. Based on environmental factors, roles, etc., some assets present challenges. Companies need to deal with the assets where patching is possible or isolate those assets from critical processes or from easy access points.

4.     Enact compensating controls, limit access to vulnerable systems if absolute mitigation cannot be performed

In most environments, there are multiple ways to treat risk, and most cyber hygiene basics carry a high level of risk reduction.  Basics such as implementing adequate network segmentation, knowing the status of assets, applying controls, and monitoring high-impact assets carry great weight; especially when patching is not an option.  However, when mitigating controls are not available or are considered infeasible due to the specificities of the environment, network, or assets – what should be done? In this case, if no mitigation control can be implemented to mitigate the Log4j vulnerability, it is critical that organizations should resort to alternative fall-back mechanisms that balance risk exposure to likelihood.  On one hand, a log4j compromise might be unlikely, but still managed to some degree, and others, actively controlled through the usage of extensive monitoring, audits, limited access, etc.

Compensating controls should include, but are not limited to:

• access control on vulnerable subnets and systems,
• continuous monitoring
• complete backups of critical systems – including configurations
• cyber security-focused training
• incident response and disaster recovery in case an incident cannot be prevented

A 360-degree cyber security program that recognizes that different levels of protection are required for a variety of systems or even technological eras is required.  It should contain actionable controls that span people, processes, and technology. It’s important that if the Log4j vulnerability cannot be mitigated suitably, all three verticals be covered to ensure risks are managed.

How does Verve Industrial manage Log4j and similar vulnerabilities?

The Verve Security Center provides organizations a complete view of their network while managing both traditional IT assets and OT/ICS assets in depth. Whenever a new vulnerability with widespread implications is discovered, Verve enables your organization to identify potentially affected assets and quickly move towards remediation.

In the case of Log4j, Verve added new specific detections to enhance the platform’s vulnerability detection capabilities allowing operators and/or analysts to find assets containing Log4j subcomponents.

End-users such as operators/analysts can:

• aggregate the results from that analysis and,
• review the list of assets for the presence of specific Log4j vulnerabilities
• assist users to directly patching or engaging in compensating controls