Cyber Security
 | 4 min read

Lessons from Log4J: What is a zero-day vulnerability and how do you manage it?

By  Hilary Walton,
 11 April 2022

When the Log4J vulnerability emerged in late 2021, it’s fair to say it shook up the global information security establishment. After all, the open-source utility for Java is used universally in software of all kinds.

If that sounds bad, there’s more: it was a zero-day vulnerability, lain dormant for years. It popped up just before Christmas, already being used for malicious activity.

What exactly is a zero-day vulnerability?

A zero-day vulnerability refers to any flaw in software security hackers take advantage of before developers become aware of its existence, and there’s no patch or mitigation.
The urgency around mitigating a zero-day vulnerability stems from the fact your business could already be under threat from an opportunistic cybercriminal, without anyone having noticed.

In and of itself, Log4J is innocuous, nothing more than a utility recording events and messages occurring as software runs so administrators can keep an eye on what’s happening in their systems. It’s also core to Java, which is widely used in software of every kind.

That’s why Log4J shot into the public eye when a zero-day weakness named Log4Shell was identified. Log4Shell allows ‘bad actors’ to load and execute malicious code using Log4J. The ubiquity of Log4J meant a problem of epic proportions for those responsible for systems security.

Mitigating the risk

Once identified, the Log4J vulnerability became a top priority to remedy. Due to its widespread usage, most businesses had a massive list of potential risks. The first step in tackling this issue was to set up a triage process, so teams could focus on software or applications presenting the most risk.

Unfortunately, third party software using Log4J required a patch from the vendor, and many vendors have yet to provide a security update for impacted applications.
In the absence of third-party security patches, businesses needed additional layers of mitigation to protect organisations at the edge until a more permanent solution could be found.

For example, Log4Shell communication was dependent on an outbound connection. By changing default settings of applications to disallow outbound connections, and in some cases disconnecting certain assets from the internet, we could buy time to examine and resolve a suspected compromised device or application.

Similarly, adopting third party tools to help mitigate the risk also helped protect systems.
Within hours of learning of the exploit, RedShield, a web application shielding solution, developed shields with the ability to stop attackers with WAF (Web Application Firewall) signatures, detecting malicious actors and providing assurance by discovering the assets susceptible to the problem.

This provided extra protection for web applications, particularly where a patch or upgrade was unavailable, or was difficult to administer.

Zero-day playbook

One of the key learnings from Log4J was that a methodical approach was needed, due to the urgency of the threat and the wide scope of potentially impacted applications. Scrambling is hard in a crisis. Having a plan makes it far easier to manage this type of scenario.

This is where a zero-day playbook comes in handy. A playbook can help your organisation prepare and plan to deal with this type of vulnerability. It provides you with a roadmap so your organisations can resolve or at least mitigate the issue as fast as possible.

Your playbook needs to cover several areas including risk assessment, communication and decision making, and should include mitigation strategies and tools. Once you’ve developed a playbook, it’s also essential that you practice it.

Walking through the steps will verify that your plan is effective and will build confidence in your team to be able to execute it during a real incident.

Here’s our top recommendations and tips for building a zero-day playbook;

• Ensure your plan outlines who will form your incident response team, including subject matter experts, technical leads, key operational executives, and communication staff. Set roles and responsibilities in advance, so everyone knows who is taking care of what aspect of the response.
• If you don’t have capability within your team, consider who you could turn to in a crisis (ie. a specialist cyber security consultancy or managed service provider).
• Managing the risk requires a solid understanding of the technology systems critical to core business which might be exposed. A vulnerability scan is a good place to start. You can’t manage what you can’t see (or measure).
• Communication and coordination drive an effective response when facing a large and complex problem. Make sure you establish a process for technical teams working on the issue to provide appropriate updates to the executive and communications teams.
• Likewise, be prepared to make updates to your key stakeholders, customers, and partners. During Log4J, many businesses required assurances from their supply chains that they were aware of the issue and were taking appropriate steps to eliminate the problem. Preparing templates and channels for reaching your stakeholders in advance will help you get key communications out in a timely fashion.
• Consider tools to contain and eliminate threats. For example, RedShield can help alleviate some of the demands on your technical teams racing to patch and mitigate vulnerable applications.

Ongoing focus

Despite disappearing from the headlines, Log4J is still a major threat to many organisations. Some third-party vendors have yet to provide patches or software updates to vulnerable applications and analysts from our Cyber Defence Operations and our partners at RedShield are still seeing activity from bad actors looking to exploit the vulnerability.

Ongoing monitoring and management are crucial for staying on top of this vulnerability. Our advice is to avoid being complacent and moving on to business as usual – the longtail of Log4J is still a threat to all of our businesses, and our supply chains.

Likewise, the next zero-day exploit is potentially just around the corner. While Log4J was a rather extreme example, there’s plenty of risk your business could be impacted by future vulnerabilities. Keep ahead of the threat by building and rehearsing your zero-day playbook so you can be confident in your response should the worst happen.