As we head into 2022 with Delta and Omicron on our minds and cautious hopes that this will be the year we finally put this disruptive pandemic in our rearview mirror, the impact of the log4j vulnerability continues to be felt across the technology and cybersecurity world.
(If you don’t know anything about log4j, you might want watch this short explainer video first.)
For nonprofits of all sizes, but especially smaller nonprofits (meaning under 100 staff), log4j exposed a weakness that has always been there, but could loom larger as vulnerabilities like log4j continue to emerge. And bear with me here, because I’m going to drop two eye-glazing words on you: enumeration and remediation.
Let’s use the (quite apropos) acronym ER to refer to these two terms. I like ER because it makes most Americans immediately think of “emergency room” (and, perhaps even better, makes Americans of a certain age think of the television series E/R’s George Clooney).
Emergency Room is appropriate because when there is a critical vulnerability disclosure such as log4j, technology personnel need to respond immediately by doing two (2) triage-like actions as thoroughly and rapidly as they can. And these two things are enumeration and remediation.
Think of it like this – let’s say someone threatened to throw a cream pie in the face of any of my colleagues who display the color blue.
Vulnerability – displaying the color blue
Threat – cream pie to the face.
Here’s a picture of my colleagues:
Enumeration would involve going through my staff and seeing who displays any blue. I would immediately see that I have two people with blue showing, one with a blue shirt and one with blue hair.
Remediation would involve having those staff people prevent any blue from showing. I’ll have the person in the blue shirt change to a red shirt and have the person with blue hair change it to red.
Voila! No one gets a cream pie in the face.
How ER applies to log4j and other vulnerability disclosures
The log4j vulnerability was first publicly disclosed on Thursday, December 9th, 2021 and, within hours, attackers were actively scanning the Internet for systems with the log4j vulnerability present and launching attacks against systems discovered to have the vulnerability.
For you to be able to defend your organization against attackers in these kinds of scenarios, you first need to know if you have any systems that are vulnerable to this exploit (e.g. anyone showing the color blue from the example above).
You have to have some way of searching through your systems and software and knowing if you have any devices or software that might be vulnerable and, if so, what they are and how exposed they may be. The process of identifying systems that have vulnerabilities and how exploitable they are is the essence of enumeration.
Enumeration
A typical nonprofit of, let’s say thirty-five (35) staff may have a couple of servers, a firewall (or two), some wireless access points, a few printers, and thirty-five (35) or so laptops and desktops (typically one per staff person). This nonprofit would also have dozens of software applications such as Microsoft Office, Windows and Mac OS operating systems, Adobe Reader, Quickbooks, and so on.
The Cybersecurity & Infrastructure Security Agency (CISA) provides many resources for responding to log4j, with an entire GitHub repository for guidance. This includes a list of all known vendors and software with vulnerabilities.
Even if our typical thirty-five person nonprofit has the best of intentions and goes to the CISA repository looking to take action, they are quickly going to find themselves facing a number of challenges:
- They have no current inventory of all these systems
- They have no person(s) with clear responsibility for leading the process
- There is limited or zero ability to automate this process
- It is extremely difficult for the decision-makers to make appropriate decisions about resource allocation:
- How urgent is it to do this?
- How much risk is there?
- How likely is it that my organization will be targeted?
That is part one of the ER challenge. How would your organization perform enumeration in a scenario like this? Would it even be possible?
Remediation
Part two of the ER challenge is remediation. Once you have enumerated your vulnerabilities (going back to our cream pie example, the two people displaying the color blue), you need to remediate. This typically means eliminating the vulnerabilities by either patching (running updates that fix the vulnerabilities) or making system changes that render the vulnerability unexploitable.
If your enumeration process reveals many vulnerabilities, you will need to prioritize your remediation efforts. Let’s say, for example, that you discovered a vulnerability in one of your servers and also in software applications running on 10 out of your 35 workstations. How do you decide what to remediate first?
In this instance, an Internet-facing server (such as a web server or database server) with the log4j vulnerability present is probably the most critical, since all it would take for an attacker to exploit it is to find it themselves (through their scans of the Internet) and then send it a single packet of data.
The workstations would not typically be Internet-facing (meaning they would not accept unsolicited input from the Internet), and therefore would be less vulnerable, since some kind of user action would be required for an attacker to exploit the log4j vulnerability on those workstations. Note that you will still want to remediate these vulnerabilities, because they can be exploited by getting a user to click on a malicious link, such as through a phishing email. Note that further remediation could include training your staff on how phishing emails work and educating them on how to identify potentially malicious email messages.
The Crux of the Challenge
At this point, unless you’re an IT professional or just incredibly curious about this sort of thing, your eyes have most likely glazed over. Alternately, you might be experiencing minor heart palpitations (if so, my apologies!).
And that’s the issue, in a nutshell. Most nonprofits are in no way prepared to respond effectively to these kinds of major vulnerability disclosures.
What to Do
If your organization does not have in-house capabilities that allow you to keep a current and accurate inventory of your systems and perform some reasonable version of the ER process we’ve described here, think about whether your organization is comfortable accepting that risk or if you’d like to do better. If you would like to be better prepared, consider working with a third-party technology provider (such as RoundTable) that has tools and expertise to respond appropriately to present and future threats.
Also, having an automated digital asset management system (not simply a spreadsheet you update manually) is not only incredibly helpful for day-to-day IT needs, but is increasingly a critical tool in your cybersecurity defense arsenal, without which, you’re left to either guess & hope or do a lot of manual work to perform enumeration and remediation when needed.
If you would like to talk with someone at RoundTable about how we could help your organization with improving your cybersecurity or any other aspect of your technology management, please reach out.
No comment yet, add your voice below!