It’s a long time since the Log4j vulnerability became public why are we still talking about it? Hasn’t anyone fixed this already? Why won’t this just go away? Those are completely understandable questions and they actually highlight one of the biggest challenges in cyber-security understanding how the Organizations should Respond to Cybersecurity incidents?
Let’s shine a light on that right, Now log4j the project currently causing all the hubbub is an open-source tool that java developers use to record events that happen in their programs.
Things like events or log entries are extremely handy, they help teams understand if the system is working correctly and if something did go wrong they can help provide important data to fix it.
- 1 What is Log4J Vulnerability?
- 2 How Organizations Should Respond to Cybersecurity Incidents?
- 3 Final Remarks on How Organizations Should Respond to Cybersecurity Incidents
What is Log4J Vulnerability?
In early December the log4j project reported a security vulnerability with a severity score of 10 out of 10. This vulnerability allows an attacker to send commands to your application that log4j will process essentially allowing the attacker to run their code on your system.
If you want more details on the specific issue check out the article “What is Log4J Vulnerability?”
How Organizations Should Respond to Cybersecurity Incidents?
What you need to know right now is that this issue and the subsequent ones reported by the project are important enough that they should be addressed immediately.
An organization reacts to these types of issues through an incident response process this workflow is most commonly associated with cyber-attacks but it’s also used in situations like this where there’s a major security challenge.
So what does this process entail? Well, let’s skip the formal definitions and structures because every organization does things a little bit differently.
Balance Between Business and Security
However, we can understand this at a high level where things are pretty much the same. The goal of this process is to strike a balance between keeping the business up and running while reducing the risk posed by the incident.
Things get rolling when an incident has been declared this is when something that might have been a problem has been confirmed to, in fact, be a problem so in the case of log4j it would have been.
When the vulnerability was disclosed publicly and you verified that you had products running that were affected by it, this gets the process rolling if an incident response process is going to be successful.
It has to nail the communications part frequent clear updates are required for all involved and a lot of people will be involved this is where most teams fail.
There are two things that need to be made clear for everyone involved. The first there will be frequent updates and the second is that things will change with each update.
Use Single and Reliable Information Source
The best strategy here is to have a single source of truth for your incident this could be a wiki page or a shared document a slack channel or whatever your organization uses to share information.
But remember that in some incidents your normal tools might not be accessible so make sure you have an alternate available.
Just in a case now for our purposes let’s assume it’s an internal wiki page everything about the incident should go on or be linked from this page. If there’s a public statement required about the incident link to it from here informing customers about the status of your service, link to that post from this page.
The goal is that if anyone has a question about the issue or the current status they can find the answer or the right person to speak to on this page.
Issue Regular Updates
So you should also include a timeline of updates from the various operation teams and working groups even if those updates are no new information understanding that work is going on and the status of those efforts is invaluable.
There’s enough to do without having to chase people down to try to find out the latest information everything goes on the page well almost everything.
Remember how I mentioned this page is the single source of truth you need to make sure that what’s posted there is in fact accurate.
That means citing, sources, validating those sources, and verifying the findings there will be speculation and theories about various aspects of the incident.
That’s okay it’s actually good those need to be explored and worked through a good update to the page is something like exploring idea x because of evidence a b and c and then an update later about whether or not it worked out and why.
It needs to be crystal clear as to what information has been vetted and under what circumstances because those circumstances are going to change as more information comes in.
Back to the log4j example after the initial report at least two more vulnerabilities have been reported that should also be addressed in short order that means the systems that were updated early in the process and marked as clear may have to be updated again.
This is normal except it plans for it with the page up and the expectations for communication set two activities kick-off and they run side by side.
You’re going to have to defend your systems at the same time as trying to fix them.
Defending and Understandings Your System
Defending your systems against these types of issues is hard, one of the reasons the initial log4j vulnerability was scored so highly was because attackers were already using it in the wild to get into your networks by the time it was disclosed.
That has continued and the cybercriminals are learning more about the issue they’re actually changing how they attack early.
The attacks were straightforward but as time went on they grew more complex as attackers try to avoid detection and try to avoid being blocked by security controls to defend your systems you have to understand where the vulnerability is.
The importance of the systems affected and what security controls you have in place means visibility is critical. You need to be able to not only see your environment but understand how it’s interconnected.
That visibility will help you prioritize your efforts and as much as I’d love to say that you can achieve the protection you can’t, no system is perfect with an understanding of your systems and their importance.
Though you can prioritize your monitoring and protection efforts to make sure that you’re getting the most value from them.
One of the most effective ways to do that is by looking for abnormal behaviors in your environment when cyber-criminals gain a foothold one of their first steps is to explore and see what else they can access.
That activity stands out compared to normal behaviors being able to spot that it’s absolutely critical. It’ll let you respond and have a chance to stop things before an attacker gains access to your data.
This part of the response process is a continuous activity with major issues like log4j.
The volume of attempts will keep any team busy but you also have to make sure that you find the time to have the other part of the response process moving along and making headway defending your systems is really about buying yourself time to fix the actual problem that attackers are taking advantage of.
This means that teams need to be finding and fixing the vulnerability itself with our log4j example that’s actually particularly challenging its software that other software uses.
The easiest part is finding the vulnerability in systems that you’ve developed searching your source code or infrastructure templates can help locate all instances of java applications and log4j things get trickier with off-the-shelf software.
Here you need to be looking manually while staying in touch with the vendor to make sure that you’re aware of any specific issues.
Unfortunately, each system is going to have its own procedure and the timeline for fixing the issue some will be a simple patch but others could require a restart and that will impact the availability of various services.
The good news is that this is not particularly complicated it’s just a lot of manual effort trying to map it all out and a lot of extra hours to get the work done.
Final Remarks on How Organizations Should Respond to Cybersecurity Incidents
Welcome to the glamorous world of cybersecurity at a high-level incident response is really simple to understand. These key points will clearly state How Organizations should Respond to Cybersecurity Incidents.
There are definitely challenges in its implementation but it boils down to a few key areas
Constant Communication, defending your systems to buy you time to fix the issue itself. Now, this sounds simple, isn’t it?
Security is one of many competing priorities in an organization and as the situation changes your priorities will change.
This is why communications are absolutely critical, you can’t plan out every move ahead of time but by understanding the flow of an incident response process you can help your teams be better prepared for the next big security issue.