Latest on critical Apache Log4j vulnerability   Read More >

Lacework Cloud Care

Whether you’re a Lacework customer or not, we’re here to help with our free Cloud Care, a Log4j rescue program. Get access to:

Home > Blog > Responding to Cybersecurity Issues Like Log4j…and the Minor Ones too

Responding to Cybersecurity Issues Like Log4j…and the Minor Ones too

Responding to security incidents is hard. It’s even more difficult when the people doing the work don’t understand what to expect.
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:

  1. Constant, clear communication
  2. Actively defend your environment
  3. 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.