Responding to Cybersecurity Issues Like Log4j…and the Minor Ones too
Editor’s Note: Log4j is an unfolding situation that we are closely monitoring. We will be updating our blog on a regular basis so check back for updates.
Responding to security incidents is hard. It’s even more difficult when the people doing the work don’t understand what to expect.
The fundamental challenge is that the incident response process is a dynamic one. Without crystal clear communications, frustrations grow quickly.
The Strategy
Your organization’s incident response process will be slightly different than any others. The actions taken will depend on the team structure, the technologies in play, and your overall risk appetite.
CISA has some excellent playbooks available if you’d like to see a complete process in full detail.
What is common across all incident response processes is the high level strategy. Simple put:
- Constant, clear communication
- Actively defend your environment
- Find and fix the core issue
Simple to list, difficult to implement successfully.
Communications
Shining a light on what’s happening is critical to a successful response process. If we use the recent log4j issue as an example, there was an initial vulnerability reported which started the response process for most teams.
Within the next week, two more major issues were discovered with log4j that also needed to be addressed. With each discovery work needed to be redone. What defenders were looking for in their networks changed.
That’s hard to adjust to.
The only way forward is through constant, clear communications. Start with a single place for all information about the issue.
This can be a wiki page, a shared documentation, whatever works for your teams.
Everything. Goes. On. The. Page.
Then, make sure that you vet the information on the page. Flag technical issues that haven’t been verified yet. Cite sources. List the constraints.
Clarity is key. The reason?
Back to the log4j example, early in the process, setting on the LOG4J_FORMAT_MSG_NO_LOOKUPS environment to true was thought to prevent any exploitation of the initial vulnerability (CVE-2021-44228).
It turns out that this is only a partial mitigation. Because the affected code is still in the library, other exploits were proven to be able to take advantage of that vulnerability. That meant the environment variable went from stopping any attacks to simply reducing the likelihood of an attack succeeding.
That’s a crucial difference that you need to be aware of. That’s why you need all of that contextual information on the centralized incident page!
Defending
When an incident is declared, those examinations might now include everything rated higher than a medium severity.
What you’re looking for and what other mitigations you want to put in place is completely dependent on the situation. The control needs to match the issue.
Regardless of the type of issue, you’re going to need visibility into your environment and the context to properly prioritize your response.
If you’re a Lacework customer, this blog post and the support documentation will help you understand how to approach the log4j issue using our platform.
Finding & Fixing
While you’re monitoring and defending your network, you also want to be identifying the systems affected by the issues. Once you have an inventory of impacted systems, you need to prioritize the work.
Then, it’s a “simple” matter of working through the list either applying a mitigation (essentially a temporary fix) or a patch to fix the problem.
You may have to do this more than once.
One of the challenges with vulnerabilities in particular, is that when attention is drawn to a specific project or product, more vulnerabilities get discovered. It’s a natural effect of having more security researchers and cybercriminals suddenly gain interest in a codebase.
The good news is that initial inventory and prioritization activity will give you a reusable map that makes subsequent sweeps a little bit faster. It’s a small consolation, but a week+ into an issue like log4j and you’ll take what you can get.
Rinse & Repeat
Incident & vulnerability response is a simple concept. It’s the implementation that’s challenging. Every environment and organization is different and the response process needs to meet that business’ needs.
The key principles don’t change though. You need crystal clear communications that help keep everyone on the same page while you’re simultaneously defending your systems and fixing the issue itself.
It’s not glamorous work but it’s necessary for the continued success of your business. Understanding the three key principles can help keep everyone on the same page while working together to get your business back on track.
Copyright 2021 Lacework Inc. All rights reserved.