Addressing the Log4j Vulnerability with Verve
This article outlines how Verve customers and other industrial organizations can effectively address Log4j vulnerabilities.
Learn MoreSubscribe to stay in the loop with the latest OT cyber security best practices.
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:
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
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:
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?
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.
There are several methods for organizations to manage the Log4j vulnerability (and others like it), but at a high level, asset owners should:
In order to manage this vulnerability, there are two initial problems:
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.
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.
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.
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:
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.
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:
This article outlines how Verve customers and other industrial organizations can effectively address Log4j vulnerabilities.
Learn MoreUnderstand the biggest challenges around OT vulnerability management and gain actionable recommendations to overcome them.
Learn MoreDownload this on-demand webinar to learn how 40 years of product outsourcing, corporate acquisitions, and bad spelling leaves OT security flaws hidden.
Learn More