All over the globe, teams are scrambling right now to triage the impact of the recently announced Log4j vulnerability on their services and applications.
Rather than reinvent the wheel, here’s a snippet from an informative Cloudflare blog post that puts CVE-2021-44228 in context:
This vulnerability allows an attacker to execute code on a remote server; a so-called Remote Code Execution (RCE). Because of the widespread use of Java and Log4j this is likely one of the most serious vulnerabilities on the Internet since both Heartbleed and ShellShock.
In short, it’s a doozy. Any organization on the planet operating software needs to be aware of this potential exploit and take steps to mitigate their exposure (mitigate how? make sure you’re aware of the second, related CVE). Fortunately, there’s no Java running at OpsLevel.
Where am I vulnerable?
But before any mitigation can occur, organizations need to know where to mitigate and who’s best placed to do that work. In short, they need a service catalog.
Without an up-to-date service catalog, even basic questions like “Which services in our architecture use Java” could be manual, tedious, and time-consuming to answer. And with a vulnerability as serious as this one speed is vital.
Not to mention accuracy. Overlooking just one service could be problematic…close only counts in horseshoes and hand grenades. Why rely on a spreadsheet manually compiled under time pressure?
Remove the guesswork with a service catalog
With OpsLevel’s service ownership platform, instead of frantically compiling an adhoc impact assessment, you can know in real-time exactly which services are impacted the next time a serious exploit is announced.
For each impacted service, you’ll know exactly which team owns it and is responsible for remediation of the issue. Plus, with our Service Maturity dashboards and reporting, you’ll have a ready-made project plan for driving and tracking mitigation progress.
How do we do it?
A quick search of your catalog can surface any service using Java. But with our visibility into the repos behind your services, we can do even better. Using a repo file check we can do things like investigate if a project’s Maven pom.xml files contains a safe version of Log4j. The regex used in the check would be:
2\.([1-9][6-9]|\d{3,})\.\d+<\/log4j2.version>
Depending on your Java framework, you may need to build a slightly different repo check. In addition to the repo file check method shown above (which requires specifying a file to look in), you can also use a repo search check to search across an entire repository to determine whether any of them contain (or do not contain) specific text.
Looking Ahead
There’s no doubt that vulnerabilities like this one–and the chaotic week that ensued–will occur again in the future. And the nature of security is that bad actors will always be at least one small step ahead of defenders. So one of the best–and simplest–things to do is be prepared ahead of time.
When the next all-hands-on-deck CVE is announced, having an accurate, exhaustive inventory of your services (including all their metadata: owners, frameworks, dependencies, configurations, etc.) will make your team’s response less chaotic and more efficient. If you’re ready to formalize that inventory and build your service catalog, request your custom OpsLevel demo today.
The specifics of the Log4j vulnerability and how to best mitigate it may evolve over time. Please consult more actively updated sources like the Apache foundation for the latest guidance.