The immediate focus on Log4j (and the Log4Shell exploit) was on the IT side of the business. However, the IoT side can be even worse. It has been highlighted repeatedly challenges in securing operational technology networks and the expanding attack surface that the growing number of IoT devices enables.

Consider how many embedded systems use Java and are not easily discovered and patched via remote management tools. Those cases mean dispatching teams worldwide to react to Log4j – to physically go patch devices – and remain vulnerable in the interim.

Before Log4j, leaders like TOOQ announced they had secured their IoT analytics app with NetFoundry, and leaders like Capgemini and Arm announced this autonomous vehicle zero trust security blueprint with NetFoundry. The TOOQ IoT solution uses Nvidia Jetson devices, and the Arm/Capgemini/NetFoundry solution uses AWS Greengrass. AWS Greengrass is written in Java and uses Log4j – it was therefore vulnerable to log4shell exploit. Fortunately, any solution which proactively secured their applications was not vulnerable to Log4shell being exploited from the network – using the same opensource components as Tooq and the Arm/Capgemini/NetFoundry blueprint. Putting this together into one picture:

In that picture, we can quickly see how businesses who proactively secure their environments with NetFoundry are protected from the Log4j issues inside AWS Greengrass, and any future vulnerability, for example, in other software on the Nvidia Jetson devices. Jetson and AWS Greengrass are both terrific IoT solutions. Adding the OpenZiti endpoint (via SDK, container or VM) helps their IoT solutions be secure by ensuring they can’t be reached from the networks. You can dive into the detail in this Zero Trust whitepaper to learn how to secure all your assets from network attacks proactively, making the next Log4j into a non-event for your business, including securing your AWS Greengrass environments.

For those not yet familiar, Log4j disrupted businesses to an unprecedented extent. The CVE is severity of 10 (the highest possible severity). Any device running Java exposed to networks is potentially at risk because an estimated 90% of Java software uses Log4j.[1]

Yet, Log4j was a non-event for businesses that leveraged NetFoundry to secure their IT and IoT environments, including solutions leveraging AWS Greengrass and Nvidia Jetson. Was Log4j neutered because NetFoundry runs magical AI-enhanced algorithms which detected the vulnerability in quasi-real-time and were able to patch thousands of systems in quasi-real-time magically? No. Businesses use NetFoundry to secure their environments from all network-initiated attacks proactively – these businesses proactively make their environments unreachable from the networks. This is particularly powerful in IoT environments where compute resources are constrained. Thus, the traditional approach of inspecting every packet to detect the vulnerabilities (let alone using AI-enhanced algorithms) is restricted by the availability of resources and prohibitive costs if they are.

 

[1] Read more on Demystifying the magic of Zero Trust with my daughter and opensource

Discuss On: