This is not a post on what Log4j is, or what controls you need to put in place. There are too many articles about that already. If that’s what you’re looking for, please read this great post from our Founder, Chairman, and CTO, Casey Ellis.
Today’s post is about what front line security and technology teams should be mindful of in the coming weeks/months, particularly those that are reeling from or have been impacted by the Log4j vulnerability in its various shapes or forms. Some things to consider for battling it:
Be in Red-Alert Mode (for many weeks):
- Log4j was the entry in. You must now look for abnormalities/anomalies elsewhere in your organization that might have taken a different form. SOC teams need to be in “DEFCON 1” alert mode until you have high confidence that you have a clean bill of health.
Use Deep Assurance Tools and Ensure that Trusted Images and Continuous Testing Practices are in Place, such as:
- Software composition analysis tools, asset inventory tools, Log4j scanners, and other continuous testing practices need to be pointed internally (while continuing to validate externally) to pick up ALL known Log4j libraries and dependencies. Leave no known and outdated Log4j library unturned. Unfortunately, there’s probably a long tail of many more product vendor patches, just around the corner. Your mid- to long-term strategy should focus on fixing the problem at its source to stem any further re-introductions of this vulnerability into your organization. Organizations need to be sure they are using trusted and up-to-date images to fix the build pipeline rather than patching production constantly.
Watch Out for Upcoming Third-Party Supply Attacks
- It’s a given that in the next few weeks news will likely surface that third-party organizations you rely on have or will be impacted by threat actors (TAs) who used Log4j as their initial access into your organization / supply chain. Heightened monitoring and canvassing of your suppliers (and what they have and will be doing) is imperative to form an understanding of potential upcoming exposure areas. Start assessing them now.
Evolve your Controls with the Times
- TA TTPs (tactics, techniques, and procedures) have evolved in the last week and will continue to morph. Therefore so should your WAF and ingress/egress rules. Don’t drop the ball here – constantly monitor, adapt like a chameleon, and proactively update.
Be on Guard for Log4j-born Malware, Worms and Ransomware
- Log4j is an absolute ripsnorter. It has five dangerous “characteristics of an exploit” where previous well known worms only need two to be considered “wild” and impactful. As a result, we will certainly see funding from cyber criminal groups and Initial Access Brokers (IABs) that will transform this vulnerability into ransomware and worm-able variants.
Increase Management (and Regulatory – if applicable) Oversight:
- Manage internal stakeholders’ expectations with proactive updates and concrete treatment plans. Internal, constant, and simplistic updates on Log4j to stakeholders are always important.
- If you’re a regulated entity and submitted breach reports, expect a fair degree of upcoming supervision. Plan for this in advance, with your teams and support functions such as Compliance and Risk.
Review Investment Slates and Reprioritize:
- Depending on the impact of Log4j on your organization and where (or if) you have failed at any stage to detect, respond, or contain Log4j exploits, take a process, controls and ‘defense in depth’ approach to the event and learn from it. Put a plan in place for future events like this if you have not already done so. We’re approaching the end of the year when most large- and medium-sized organizations are finalizing next year’s investments, so it’s a great opportunity to reprioritize accordingly based on lessons learned from the Log4j incident. You don’t want to be tripped up over and over by the same control failure occurring later down the track, so being properly funded is imperative.
See our full list of Log4j/Log4Shell resources here.
