An estimated 30% of all Log4j instances remain vulnerable within the enterprise as of March 18th, 2022. Watch this ungated webinar to learn:
- What risk this poses to your organization
- How to perform the exploit so we can understand it
- How to patch it the long way and the short way
Why are we still discussing Log4j? Isn’t this just ambulance chasing?
No. We’re discussing Log4j because it’s still relevant and can lead to risk not only for yourself, but for your customers too. And we don’t want that to happen to either of you.
Tune in to learn how the LDAP exploit in Log4j is performed (CVE-2021-44228), 2 potential fixes for it, and how you can leverage the power of Security-as-Code to remediate Log4shell in minutes without risking breaking your applications.
Three top takeaways:
Takeaway 1: Factor in engineering resources when determining your risk profile
Your risk isn’t isolated to the $161 per record you stand to lose upon a data breach. To get a real look at the risk this critical vulnerability poses we first have to do some simple, albeit painful, math.
According to NTT, the average time it takes for security teams to remediate critical vulnerabilities has risen to 205 days. Given the fact that there’s a new CVE just over every 4 hours it’s not a question of if you’ll experience an exploit, but when.
In order to remediate a critical CVE your engineering team will have to drop whatever they’re working on and dedicate their time towards fixing the problem – in this case Log4shell.
If we assume that the average salary for an engineer at your company is $120,000/year, that boils down to $461/day. By extrapolating $461 across 205 days, we come out to $94,611 per engineer ON TOP of the $161 per record breached, just to fix this vulnerability.
Realistically at your organization there are more than 1 engineer working on this problem, so mileage may vary.
Takeaway 2: The recommended fixes are difficult and… risky
The difficulty of remediating vulnerable versions of Log4j are summed up perfectly by Open Source Security here, but we’ll do our best to summarize:
Your apps may contain vulnerable versions of Log4j only because you depend on a dependency that depends on Log4j. If that sounds like dependency Inception you’re not far off. And it becomes more difficult to manage when you’re unable to update a dependency because that dependency depends on another library that also uses a vulnerable version of Log4j.
It’s not unusual to see a dependency tree in a production application that looks like this:
app-1.0.1 -> message-bus-1.4.3 -> state-machine-2.7.0 -> log4j-2.14.0
To quote Open Source Security:
This is why there will be products that don’t see updates for weeks or months. If log4j is somewhere deep in their dependency mines, they could be waiting for a lot of updates to happen.
The options you have until then are more bandaids than solutions:
- set the JVM option
log4j2.formatMsgNoLookups=true - remove the
JndiLookupclass from the classpath
Both of which can break applications.
Takeaway 3: Security-as-Code is the only confident way to secure Log4shell without tons of engineering hours
Ultimately if you’re going about security traditionally you can either spend engineering hours to remediate Log4j in your applications or risk breaking your application.
But with Security-as-Code you can define the desired state of security behavior for your apps once and and autonomously apply that to any new code written or changed.
In the video we told the story about the prospect that came to us quoting hundreds of hours to fix Log4j within their applications only to completely resolve Log4shell in their apps in literally 3 minutes using the Security-as-Code platform ARMR. You then saw how we applied the patch both declaratively and through the Web Portal for instantaneous remediation.
The reason this works is ARMR autonomously remediates vulnerabilities in executing code at runtime as defined in the Policy Config file without developer involvement, code changes or downtime. No other technology, product, or vendor can or does fix vulnerable code at runtime.
🎁 BONUS!
As promised here are the POC files. To get access to the Waratek ARMR agent and experience the simplicity of Security-as-Code, get in touch here.
