Many articles explain how to fix the Log4j flaw and mention the saga of security updates provided by Apache.

When an adversary is able to exploit this vulnerability (or another), they can install malicious code, exfiltrate sensitive data, and even delete backup copies.

Therefore, the question then is, how are you going to recover, in how long, and with what kind of data freshness?

Backstory

On December 10, 2021, Apache released a security bulletin highlighting a critical vulnerability leading to a remote code execution related to Log4j, a widely deployed open source JAVA logging tool.

The vulnerability identified as CVE-2021-44228 is extremely critical, with a CVSS score of 10, the highest level of severity possible.

It has been determined that the first security update Log4j 2.15.0 was itself vulnerable in certain configurations. Log4j version 2.16.0 followed to correct this latest vulnerability, identified as CVE-2021-45046.

And finally, Apache made version 2.17.0 available this Friday, December 17, which fixes a denial of service vulnerability identified as CVE-2021- 45105 (CVSS score of 7.5), making it the third flaw in Log 4j2. to be discovered after CVE-2021-45046 and CVE-2021-44228.

Challenges

The risks are such that the governments of Quebec and Canada have taken several hundred sites offline to validate the presence of Log4j and make the required corrections.

And more generally, the majority of companies offering or using web solutions are directly affected.

In other words, the number of affected organizations is excessively high.

However, it should not be forgotten that this vulnerability indirectly affects user data and personal information held by organizations of all types.

Steps to take

The following steps should be put in place:

Identify the applications using the Log4j service

This involves scanning all servers for the Log4j2 file, and checking if it is a vulnerable version.

Update applications

Log4j version 2.17.0 has been released and is available for download.

But the fact remains that before being out of the woods, you must overcome 2 challenges namely:

• You could be attacked before you have made all the updates, especially when vendors are slow to release security patches for their applications using Log4j.
• If a hacker uploads malicious code to your servers, you need to have a suitable recovery strategy.

Set up a recovery strategy

Your recovery capacity is essentially a function of 3 factors:

The guarantee of having a complete and integral backup copy

You should use best practices especially those associated with the 3-2-1-1-0 recommendation.

The freshness of your data

Modern data protection solutions, such as those from Datto, allow you to take copies every 5 minutes.

Return to production time

Whether locally or in the Datto Cloud in the event of a site disaster, you are able to ensure business continuity.

Conclusion

We know it well. This is neither the first nor the last major flaw to occur.

And while prevention is better than cure, sooner or later you are in danger of being struck, if only because your reaction speed is often slower than the attack speed of hackers.

It's time to prepare your infrastructure for the next threats with a managed business continuity solution.