Cyber Whack-a-Mole Continues: Log4j

Concerns about building with open-source technologies have come to pass and represent a genuine threat to industrial controls systems. On December 9, cyber security researchers discovered a vulnerability in a widely used open-source logging library that could allow an intruder to take over an affected device remotely. Cybersecurity and Infrastructure Security Agency (CISA) Director Jen Easterly called it “one of the most serious I’ve seen in my entire career, if not the most serious.”

Cyber security research firm Dragos, which has been following the development of the vulnerability and offers tools to detect it reports the following:

• The vulnerability is in the Java Log4j2 logging library, which is widely used in open-source repositories used in industrial applications, such as Object Linking and Embedding for Process Control (OPC) Foundation’s Unified Architecture (UA) Java Legacy.
• Adversaries can leverage this vulnerability in proprietary Supervisory Control and Data Acquisition (SCADA) and Energy Management Systems (EMS) which make use of Java in their codebase.
• Dragos Intelligence has observed both attempted and successful exploitation of the Log4j vulnerability in the wild.
• The vulnerability is vendor-agnostic and affects both proprietary and open-source software and will expose a wide swathe of industries to remote exploitation, including electric power, water, food and beverage, manufacturing, transportation, and more.

Although Java is owned by Sun Microsystems it has become a de-facto standard and has actually been endorsed as such by the Supreme Court. See our story: Supreme Court Strikes a Blow for Open earlier this year. Some have touted Java as the key to the next generation of industrial competitiveness because this openness enables platform independence, scalable deployment, easier debugging, and universal connectivity, the same basic reasons developers give for implementing any standards-based technology.

And, whether it is Java or any other standards-based solution, the reasoning that open standards are critical to the new industrial economy is quite sound. Companies that can exploit pervasive connectivity over the cloud and public networks will certainly have the edge in cost reduction, innovation and quality control, and much else. And Dragos and others are already issuing detection and mitigation tools that can help contain such breaches to help achieve such benefits. But most who have been following the current breach agree that the perimeter has already been violated, that invading code may have already morphed into less detectable forms, and that industry may be dealing with consequences for many months.

Bedrock perspective

Bedrock Automation does not use the Java Log4j library or any Java code, but we see this as a Stuxnet-level wake-up call to the need for implementing controls that have cyber security built in. With that, you can rest assured that your crown jewels are secure and cannot be manipulated by intruders, while you continue playing whack-a-mole at the perimeter.

For greenfield installations and expansions, starting with intrinsically secure automation is pretty much a no-brainer. For brownfield operations, it is still possible to use intrinsically secure controls as proxies in transitioning legacy controls to an intrinsically secure environment. For more details and an example of a plant that is doing just that, see our white paper: Seamless Migration to Zero Trust OT Cyber Security.

CISA Director Jen Easterly supports the notion of building cyber security into industrial automation hardware and software. In her December 11 statement on the Log4j vulnerability she said it:

“… underscores the urgency of building software securely from the start and more widespread use of Software Bill of Materials (SBOM), both of which were directed by President Biden in his Executive Order issued in May 2021.  An SBOM would provide end-users with the transparency they require to know if their products rely on vulnerable software libraries.”