There are truisms that span history. One truism is that a single mistake can lead to disaster, and to some extent the series of vulnerabilities affecting the organizations that use Apache Log4j.
So, to kick off our historical analogy let’s start with the famous Trojan Horse incident from Greek mythology. Looking at this event through a modern cybersecurity lens what we see is a failure to validate input, i.e., look inside the giant wooden horse at the front gate, which led to a resounding defeat for the Greek city of Troy. This error is comparable to the SQL injection and cross-site scripting attacks we see today. Or consider the battle of Thermopylae Pass where the Greeks lost because the Persians discovered a back door, a secret path through the mountains.
In a way, we can think of these historical cases as single points of failure: a small part of a system broke down, resulting in an entire security system from working properly.
Everyone in the cybersecurity community is now familiar with the Apache Log4j vulnerability. Perhaps you are among many security practitioners who experienced sleepless nights while working to identify and mitigate the problem. If you did, I take my hat off to you as I know how tiring and stressful it is dealing with such a situation.
When it came to remediation, the immediate issues of concern were:
- Widespread use of this particular logging library in hundreds of applications.
- No automated or quick identification method was used.
- In some cases, an easy fix was not available via upgrade, patch, or workaround.
However, even as you were waiting for the investigation and analysis of the exploit to be completed there were several actions to be taken:
- Update anti-malware, IDS/IPS and other detection systems to the latest signatures.
- Review application logs for unrecognised activity which may be a sign of exploitation.
- Block known malicious IP addresses at the perimeter
- Add WAF rules to block malicious inbound requests and outbound responses.
Avoiding a Single Point of Failure
Once all the standard cyber defence actions are implemented and vulnerable systems protected, it’s time to examine what the Log4j attack has taught us.
For that, I’d suggest we expand upon our concept of the single point of failure and look at the concept of multiple points of identical failure. So even though the Log4j vulnerabilities can be viewed as single points of failure, the problem is much broader.
As many vendors deploy Log4j in hundreds of applications, it can be exploited from many different directions. Unfortunately, it then becomes a giant game of online whack-a-mole but a game where all the moles pop up simultaneously and the immediate reaction is an unsustainable increase in hammers.
Avoiding a Log4j Problem
Now that we look back on it, this situation was likely inevitable. Software development is a fast-paced activity where reinventing the wheel loses time and money. To counter this, vendors will create new products using existing open source and commercial components such as Log4j. To best identify these elements, you’ll need a software bill of materials (SBOM) which lists all the components used within that software.
A comprehensive SBOM list can be very useful, allowing an organization to identify and compare common code across numerous applications.
This information will tell you whether you’re overly reliant on a single or a very few components, enabling you to recognize the same potential single point of failure appearing in multiple places.
Furthermore, by knowing which products are using vulnerable code, you’ll be able to track which vendors are releasing patches or updates, allowing you to narrow down your remaining vulnerabilities and prioritize your remediation activities.
These actions naturally link into your supply chain assurance processes as a software vendor SBOM is likely to reduce the risk exposure faced by your organization. However, this activity will always be a work in progress as not all vendors will publish an SBOM. And for those that do there is a resource cost in amalgamating and analyzing the results for the consumer, especially as the pace of change increases; multiple points of a single failure, are likely to become more prevalent in future.
New attack vectors require a greater degree of defence in depth: Trustwave’s Managed Detection and Response should be your first line of defence, ensuring you’ll have access to the latest threat intelligence; our Managed Security Services will give you the expertise and resources to respond and Trustwave’s Consulting and Professional Services will provide vendor assurance and cyber strategy support and advice.
