Log4j was inevitable: taming complexity is the answer

Resolving the Log4j vulnerability has consumed tech teams this week. Publicly disclosed by the Apache Software foundation on 9th December, this could be the greatest vulnerability ever seen, affecting practically every organisation on the planet. Log4j is one of the most popular packages for Java, which is itself one of the most popular coding languages and there are an estimated 3 billion devices that run Java. Most, if not all, applications will be required to perform some kind of logging, and there's a good chance that, if written in Java, they’re using Log4j to do so. 

In addition, the Log4j vulnerability is considered highly dangerous as it is easy to exploit: an attack can be launched by simply typing a string of code into a chat window.  Once exploited, malicious actors have the ability to take over servers, applications and devices, and to infiltrate enterprise networks. Microsoft have already confirmed a new Ransomware family — Khonsari — has been deployed against its systems.

This vulnerability, which is being widely exploited by a growing set of threat actors, presents an urgent challenge

- Jen Easterly, CISA Director.

We’ve ensured that our software product (Cloudsoft AMP) is fully secured and updated, and are continuing to work with our customers to identify and update additional vulnerabilities in their own systems unrelated to AMP.

And these systems are hugely complex; now an initial fix has been issued, the difficult, longer-term work to identify all vulnerabilities begins, in addition to the even more difficult task of identifying where dependencies between applications create problems. This exposes the blackhole between those managing enterprise infrastructure and those running and managing applications for their department. You might think ‘your stuff’ is fixed, but an unknown dependency could throw that into doubt. 

IT supply chains, remote working environments and enterprise IT architectures are all significant points of weakness requiring a Herculean task of examination and remediation.

- Jonathan Care  senior research director at Gartner 

Whilst working closely with one of our enterprise customers this week, who are using Cloudsoft AMP to orchestrate hundreds of applications within a larger estate, an unexpected and important observation came to light. Our client found that the process of fixing Log4j vulnerabilities had exposed where applications lacked good automation. The automation capabilities and composable approach of AMP meant that, once the update had been added to AMP’s library of policies, they had been able to quickly update and secure affected applications and their dependencies. Many of the applications that are not managed by AMP require a manual effort to identify them as a risk and to update them to be secure. 

This quick time to resolution had another upshot — the avoidance of downtime. Whilst it’s perfectly reasonable to prioritise security over availability in such a critical situation, an even better outcome is to be confident that your systems can be both secure and available, even during an incident. By quickly applying approved updates, customers were able to avoid taking systems offline for long periods of time and in some cases, with either blue/green or rolling upgrades, no downtime at all. 

The Log4j crisis has demonstrated that the more complex systems get, the more vulnerable systems become. And when things do go wrong, as they inevitably will, orchestrating workloads centrally in a composable way will ensure you never have to choose between security and downtime. The importance of an application-centric view of compliance and the role of blueprints and patterns for management is becoming more and more self-evident.

Log4j is unlikely to be a once-in-a-decade event. As tech complexity continues to spiral, these problems will continue to happen, with more and more frequency as interdependencies become more complex. It won’t be enough to increase contributions — code, reviews, and funding — to open source communities (although if that increases as a result it will be a silver lining!). What will be key however, is the ability for stakeholders to understand the layers and the connections between their systems. The role of automation and application-oriented models is crucial to navigating these complex waters.