Log4Shell Response for Community Financial Institutions

This post is intended to help community financial institutions appropriately prioritize their response efforts to the Log4Shell vulnerability. If you’ve been watching your threat intel feeds (or even just the news) over the past week, you are well aware of this vulnerability.

Security experts are calling Log4Shell one of the top 3 vulnerabilities in the past decade. Why? Because of the widespread use and how easy it is to successfully attack the affected systems.

It stems from the Java Log4j library that many systems use for logging. Recently it was discovered that, if supplied the right (or wrong) string of characters, those systems could be forced to download and run malicious code.

Before we all panic, there are a few things to consider. This isn’t like the SolarWinds attack, where the code had already been installed on the affected systems. For this one, attackers must be able to access the system to successfully execute the attack. This means that they need to be in your network (and if so, you have a ton of problems anyway), or the system must be externally facing.

The good news for the banking industry is that we don’t typically host our own externally facing systems. The bad news is that we continue to partner with more and more service providers and vendors that DO have external facing systems.

In times like these, it’s important to prioritize our responses so we can make the most of our limited resources. This is my suggested approach to do so:

1. Address your external facing systems first.
   1. Does it use Log4j? If so;
   2. Upgrade to the latest version (Apache Log4j 2.16.0) - you may have to work with a software vendor to do this.
   3. If you can’t upgrade, block traffic to untrusted servers (via whitelist if possible).
   4. Look for indicators of compromise on this system - I suggest you get help from trained forensics specialists.
2. Contact critical vendors with external-facing systems.
   1. Some examples: internet banking, insurance platforms, new accounts sites, CRMs, file sharing sites, etc.
   2. Verify that they followed the steps 1a-1d from above.
3. Once external systems have been secured, address internal-facing systems using similar steps to 1a-1d above.

For many financial institutions, the first step is to jump directly to #2 and begin the process of working with vendors to determine their exposure and if an appropriate response has been taken. Make sure you take care of that before beginning the quest of addressing internal systems.

As always, retain your documentation and other evidence of your response. It’s also good in high-profile incidents like this to communicate to your board where you stand and if further actions are necessary.

Lastly, the FDIC sent out an email this week pointing folks to the CISA website for the latest information, that site can be found here: https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

If you’d like to see a sample threat analysis on Log4Shell (that we do for our customers regularly), email me at chris@bedelsecurity.com and I’ll send you a full copy.

If managing the ever-changing threat landscape (including vulnerabilities like Log4Shell) seems to be a task that’s getting out of control, it might be time for outside perspective from an expert. We’ll give you feedback on incident response processes and responsibilities as well as other areas of your infosec program. If you’d like to know more, check out our CISO Assessment.