A critical flaw in the open-source Apache logging library Log4j leaves some of the world’s most popular services and applications vulnerable to attack. As a result, many of the most prominent tech organizations on the planet, including IBM, Google Cloud, Cisco, Amazon Web Services and Microsoft, are impacted and scrambling to fix issues. The implications are enormous and may not be fully known for years. Hundreds of millions of devices around the world are affected. Threat actors swoop in to work the vulnerability to their advantage.
No, it’s not part of the synopsis for a new Netflix original thriller (unfortunately). It’s true. At the end of 2021, the Log4j/Log4Shell vulnerability was discovered. If that sounds like Greek to you, you’re not alone. The headline is that it is one of the most considerable vulnerabilities in Internet history. And that’s not casual hyperbole; that’s a widely shared opinion among cybersecurity professionals.
What is Log4Shell/Log4j?
Log4j is a widely used tool that logs error messages in apps. It is used extensively in many applications and services (from massive platforms to small-scale services). This is part of what makes this a substantial problem, as Log4j is present in many places. It’s likely present in many tools your business uses daily.
To put it in other terms, the Log4j vulnerability can give the robber your alarm code and the keys to your door.
Log4j is the item in which the vulnerability has been discovered, and Log4Shell is the vulnerability.
What can threat actors do with the Log4Shell vulnerability?
A scary list of things. The Log4Shell issue allows threat actors to steal system credentials, run computers and devices remotely, execute ransomware attacks, dive deep within compromised networks, install cryptominers and pilfer data. Alarmingly, a smartly crafted piece of code is all the hackers need to exploit the vulnerability. This code can be presented in a wide variety of simple ways (such as an account username).
The fallout will be substantial, and in many ways, we can’t yet predict just how bad it will be. All we know is that it will be bad. The open-source Apache logging library Log4j is simply used in too many things for it not to be.
What can be done?
The simple answer is to patch everything (patches and updates are often issued for security reasons, so please do your updates)! But there’s a way bigger picture at play here, and it feeds into the heart of what we do as an organization.
It’s fair to say most people think of ‘security’ as tools like anti-virus and firewalls. We need to shift from this thinking collectively. To be sure, those items are essential, but they’re one tiny piece of the pie. It’s like thinking you’re ready to go skiing because you bought some gloves. “Nice gloves Bob, but where are your pants?” There’s a lot more needed.
Security frameworks like ISO 27001, CIS, NIST Cybersecurity framework, etc.) deserve more attention. These are international standards that lay out how information security should be managed. It sounds complicated, but in short, these tools help organizations keep track of and secure the information assets that they use. In addition, an organization’s setup can be audited against the international standard (this is part of the work that we do).
Keeping that in mind and thinking about Log4Shell, the security frameworks help in response to things like this new and significant vulnerability. For a start, the frameworks help organizations manage their IT environments and understand which assets they use. This asset inventory is huge in the face of something like Log4Shell, as you can see what you use and what may be affected. Think of it this way; how would a company know which assets might need to be checked for the Log4j vulnerability without a well-maintained IT asset inventory?
That’s only part of the process, though. Once you have the list of assets, you need to check all those assets for the vulnerability. At SeekingFire, we can do that with our vulnerability scanning service. Those who don’t use a vulnerability scanning service would need to do it manually. Either way, if you find assets that have a vulnerability, what then? At SeekingFire, that’s where our formal approach to patching (called “vulnerability management”) comes in. For those IT assets that don’t yet have a patch, that’s where our risk assessment and risk treatment through alternative mitigating controls can be helpful.
As you can see, the frameworks give us a guide to work against, and rather than fishing in the dark; we’re able to work to solve identified issues. They also enable the work to be tracked and reported to senior management to show the company’s risk.
Of course, having key performance indicators for these processes (vulnerability management, risk assessment, etc.) already in place comes in super handy when something like Log4Shell comes along. If you don’t have those things already in place, the next best thing is to reach out to us today. An ounce of prevention is worth a pound of cure!
At SeekingFire Consulting Inc., we offer a wide range of cybersecurity and cyber resilience support and services. From security assessments to audits to vulnerability scans and Security Incident Response Plans, we can help you, and your organization respond to Log4Shell. We serve clients across Western Canada and offer free consultations to all prospective clients. If you would like to learn more, please reach out.
Disclaimer
While we have made every effort to present accurate, unbiased and helpful information in this article, please note that it reflects the author’s opinion and is written for the purposes of general knowledge, information and discussion. This article is not intended as legal advice, nor should it be considered as advice specific to your individual data security situation. If you would like to discuss your cybersecurity needs in specific detail, please get in touch with us.
