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? These questions highlight one of the biggest challenges in cyber-security— how organizations should Respond to Cybersecurity incidents?
log4j is an open-source tool that java developers use to record events that happen in their programs.
Log entries are extremely handy because 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.
Contents
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.
If you want more details on the specific issue check out the article “What is Log4J Vulnerability?”
How Organizations Should Respond to Cybersecurity Incidents?
Organizations should always address cybersecurity incidents as soon as possible. They usually respond to cyberattacks via an incident response process.
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 organizations declare an incident. An incident response process has to successfully address the issue with frequent and clear updates. Most teams fail when it comes to this communication aspect.
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, 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.
Let’s assume you have an internal wiki page. You should link everything about the incident from it. If there’s a public statement required about the incident link to it informing customers about the status of your service.
The goal is that if anyone has a question about the issue, they can find the answer 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 all posts are 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.
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 prepare your team for the next big security issue.
