The Truth About The Log4J Security Issue
It's far from being the only one.
Here's what you need to do.
There is a crazy amount of attention towards the Log4J vulnerability. Even non-technical people I know are aware of what “a Log4J” is! As an architect/developer this event also impacts me in multiple ways.
After reading this article, you’ll be fully prepared against vulnerabilities, while understanding even their darkest secrets!
Note: If you’ve missed the news, Log4J, a widely used software package for Java, contains a critical security vulnerability, impacting the majority of Java applications.
Impacts of Log4J
The security vulnerability impacts many people:
- Project managers: need to plan in time for fixing the vulnerability
- Release managers: need to plan in the urgent hot-fix releases
- Architects: need to find which applications are impacted + a solution for them
- Developers: need to implement the hot-fix with time pressure
- Others: become more aware of global software security risks
All that, while often dealing with tightly packed calendars.
How did it happen?
Log4J is an open-source package. Anybody can contribute code, and anybody can use it. This means that unintentional bugs or security issues can crop in.
What about open-source?
Does that mean we should stop using open-source? Not at all! Why would proprietary software be more secure? Less people review and test proprietary software.
“But proprietary software’s code is hidden, so it is harder to find vulnerabilities!” That’s true, but we should aim for security by design, not security through obscurity. That’s a famous saying in the world of security, also called Kerckhoffs’s principle!
We should aim for security by design, not security through obscurity.
Security by design can’t be hacked, even if attackers understand the internals. If an attacker gets hold of the implementation with security through obscurity — the software is irreversibly compromised.
What was the real issue?
All in all, I strongly advocate the use of open-source software! The real issue is that once the vulnerability is revealed, attackers know there is a big chance of it to work. This is called zero-day vulnerabilities in the security world.
Having vulnerabilities by itself is not entirely avoidable. What we can improve, is our response time!
By responding quickly to such issues, we can avoid attacks. This means:
- The software should be fixed quickly
- Consumers of the software should have an easy way to apply the fix
- Consumers need to apply the fix quickly
- Consumers need to be aware of the vulnerability
But aren’t we already doing so? Not always. Let’s dig deeper.
Consumers should have an easy fix
It should be easy to apply the fix. In most cases, it’s just a version upgrade, riiight..?
Sure it could be. When is the last time you upgraded that package though? Are you on the latest major version? It’s easy to keep on coding and ignoring that the package you’re using is 5 years old. It.. still.. runs….
Consumers need to be aware of the vulnerability
Regarding awareness, nobody could miss the log4j vulnerability since it was in every news outlet. However, what about that small niche software package you installed 2 years ago? Don’t you think you might have missed the upgrade?
What can you do?
Here’s a small shortlist of what you can do to prepare against such attacks! Just don’t tell me you want to replace
1. Keep your dependencies up-to-date
Nobody likes outdated and dusty software applications, and especially in the event of a security vulnerability.
Help me out, and estimate the work needed for the following items:
- Upgrading Log4J from v2.14.1 to v2.17.0
- Upgrading Log4J from v1.2 to v2.17.0
Obviously the former will be easier and faster. In case you have custom implementations along with an old version, the upgrade can become considerable work. Multiply it by the amount of applications in your company, and the work keeps adding on!
That’s why I want to stress the importance of regularly keeping your packages up-to-date. You’ll avoid smaller security vulnerabilities, while also making it easier to upgrade in case of big zero-days. It helps everybody.
2. Prioritise your devs code maintenance work
Understand that upgrading packages and keeping the applications safe is worth the budget and needs to be prioritized accordingly! Let your devs keep the codebase alive and up-to-date. In return, they’ll keep you safe.
Log4J isn’t the only one
It’s the well-known recent zero-day, sure, but there are many more vulnerabilities that must be known by a group of people, while not being publicly known. I’m thinking about hacker groups, secret agencies, and maybe even governments as well for all we know.
Yep, there could be somebody spying on your phone’s microphone right now using a yet unknown exploit.
What else can I do?
You could run security audits on your application’s dependencies. For example, Node’s npm has a command for it:
npm audit which gives you a report of all the possible vulnerabilities from your dependencies and how you can fix them.
Other dependency managers have their own ways to do this, so be sure to plan in a deep dive into their documentation for this!
A call for action from me to you — have a look at your codebases and go upgrade your dependencies now! Motivate your colleagues to keep your code alive! Your users and customers will thank you.