Operational technology (OT) environments are equally at risk from the Apache Log4j flaw. Here’s what you can do today.
The internet is on fire; but you knew that already. CVE-2021-44228: Log4j Remote Code Execution Vulnerability (Log4Shell) is being categorized as one of the most pervasive and potentially far reaching vulnerabilities in history. Log4j is an open source Java logging library used extensively by developers. The use of third party libraries for core functionality isn’t just an IT problem. Log4j is embedded in operational technology (OT) environments. In fact OT vendors are already releasing advisories on how their products are impacted.
In the weeks and months ahead, we will begin to understand the pervasiveness and extent of this particular vulnerability in OT infrastructure; but it is most certainly used to perform critical OT logging functions making that system vulnerable to trivial remote code execution. But even if you do not use this in your OT infrastructure, you may still be at risk.
As organizations have converged their IT and OT operations, it would not be the first time where an attack has migrated between IT and OT. Even if your facility is fully air-gapped, there is a better than average chance that you may be “accidentally converged.” Without taking definitive steps to secure the OT infrastructure, your operation may be at risk.
Here are five steps to take in order to secure your OT environment against Log4j:
- Follow official guidance. Organizations such as the U.S. Cybersecurity and Infrastructure Security Agency (CISA) have issued specific guidance. It is crucial to be familiar and follow this guidance on an ongoing basis. Compliance with, and reliance on, frameworks from MITRE, the U.S. National Institute of Standards and Technology (NIST), the U.K. Network and Information Systems (NIS) and the North American Electric Reliability Corporation (NERC) can help your organization establish best practices in order to stay vigilant against dynamic threat conditions.
- Know what you have. Asset inventory is a cornerstone of any security program and can provide deep situational awareness. It involves more than capturing the make-and-model of everything in your environment. It requires having an up-to-date inventory of firmware versions, patch levels, communication paths, access and much more. Network monitoring alone will only provide some of the detail; active and device-specific querying is also necessary in order to get the specifics.
- Run a targeted scan of IT assets. Once you have a good asset inventory, you should be able to run a vulnerability scan to see where else you may be impacted. Tenable research has identified and rolled out the signatures for detecting Log4J or Log4Shell exploit. Our ongoing release of plugins can be found here. Running a targeted scan with newly issued plugins is recommended in order to identify at-risk elements.
- Understand your wider OT exposure. A best practices is to have a good scan option, like Nessus, to run a vulnerability scan of your IT assets, and have an OT-specific option like Tenable.ot to specifically deal with your OT assets. In fact, Tenable.ot contains Nessus inside and runs vulnerability checks for both IT and OT assets. Specific safeguards are employed to ensure that Nessus only ever scans IT assets while Tenable.ot addresses OT assets.
- Be proactive in reducing risk. If you are relying only on intrusion detection alerts to warn you of a compromise or an exploited system, it is already too late. Ongoing threat assessments must involve the most up-to-date intelligence and sources. IT and OT networks are already interconnected in most environments and threat actors are taking advantage of this convergence. If you are concerned that Log4j may have already been leveraged in your environment, Tenable can help.
Longer-term, the entire manufacturing and critical infrastructure community needs to improve its understanding of what is being used within systems in order to achieve the deep situational awareness required to address new threats as they emerge in the wild. The Software Bill of Materials (SBOM) initiative was directed by Executive Order issued in May 2021. An SBOM can provide end users the transparency required to know if their products rely on vulnerable software libraries.
There is no doubt that we will be dealing with the Log4j vulnerability for years to come and, unfortunately, there will undoubtedly be other vulnerabilities in the future. With the right people, processes and technologies in place, organizations around the world can quickly and collectively use risk-based decision making to minimize the consequences of vulnerabilities like Log4Shell and protect the world’s critical infrastructure.
Michael Rothschild, Tenable’s senior director of OT solutions, also contributed to this blog post.
Learn more
- Visit the Tenable Log4j solutions center: https://www.tenable.com/log4j
- Read the SRT alert: CVE-2021-44228: Proof-of-Concept for Critical Apache Log4j Remote Code Execution Vulnerability Available (Log4Shell)
- Read the CISO perspective: Apache Log4j Flaw Puts Third-Party Software in the Spotlight
- Visit our user community to learn more about how Tenable can help: https://community.tenable.com/s/
