A vulnerability in Log4j, a popular software tool used by a majority of the internet, is giving attackers the ability to run their own code on whichever system they are targeting. While we have yet to see the full detrimental effects of this vulnerability, it is likely attackers will exploit it for years to come, with attacks presenting themselves in the form of ransomware or other types of cyberattacks.

Additionally, millions of applications use Log4j. As such, if one piece of software used by many applications has a vulnerability, then all applications using that software are at risk. Given the global impact of Log4j, many applications we use on a regular basis are affected, including iCloud, Minecraft, and Cloudflare.

In response to this, Forrester analysts outline the dangers of the Log4j vulnerability and steps security teams should take to protect themselves from attackers as a result.

Forrester VP and Principal Analyst Jeff Pollard:

“For CISOs, Log4j hits the products and services the company uses, builds, and sells. When anything touches those aspects of a company at once, the board will ask questions. Don’t wait for them to come to you and react. Instead equip them with the information they need proactively. That includes a primer on why Log4j matters including: 

  1. How widespread it is.
  2. Actions taken so far.
  3. Actions underway.
  4. Planned actions.
  5. Any obstacles you foresee and what is needed to address them.

“Provide context to the board on these items in three ways: The status of your company; the status of your customers; and the status of your partners. This demonstrates how your approach to security incorporates the ecosystem in which your company operates and prioritizes potential impact to the business overall, not just impact on the security program.”

Forrester Analyst Allie Mellen:

“This vulnerability is so dangerous because of its massive scale; millions of applications use Log4j. Applications on the Internet are a complex system of interconnectedness, which makes it difficult to know what applications might be affected, even your own. Even if your software doesn’t use Log4j directly, you may use someone else’s software that does and not know it.

“This vulnerability will be used for months if not years to attack enterprises, which is why security teams must strike while the iron is hot. Patch any home-grown software that uses Log4j and coordinate with all vendors to make sure they aren’t affected or get patched in a timely manner. Give your security operations center (SOC) the situational awareness it needs to know which applications and assets are affected so it can respond to every single alert that comes in from one of those systems.

“So far, we have seen this vulnerability exploited by attackers looking to deploy cryptominers or set up botnets. This is just the tip of the iceberg — you can be sure attackers are building more complex attack chains to exploit this vulnerability further with attacks like ransomware and information stealers.

“There’s a ton for security teams to do and it’s all cross-functional. To respond to this vulnerability, we recommend security teams divide and conquer in three buckets: prevention and detection, vendor risk management, and communication: 

  • Engage IT and DevOps to identify all home-grown applications affected by this vulnerability and build a plan to patch those systems.  
  • Engage IT and your business applications team to reach out to vendors to find out if they were affected by this vulnerability, and if so, what their patching schedule looks like. IT and security must work together to develop their own patching and testing schedule to make sure any updates don’t affect business continuity. 
  • Communicate to any customers the status of any externally facing applications to ensure they know what systems might be affected and which aren’t. Communicate your strategy to your organization and to the board. Communication from the CISO directly is critical to engage the rest of the organization and continue to build leadership.

“There is a recent announcement by the FTC that organizations must address the Log4j vulnerability to avoid legal action. They use the Equifax settlement as an example in the announcement. Barring a massive, public breach of a large company via exploiting this vulnerability, enforcing this warning will be a complex task. However, it is another aspect of the potential impact of an exploit of this vulnerability, and that should give businesses pause. It is crucial to ensure the software used by your organization is patched against this vulnerability for more reasons than one. We have not seen the FTC proactively warning companies that they should be patching against a specific vulnerability or risk legal action in the event of a breach … until now. This action by the federal government raises the stakes for organizations and pushes them to prioritize improving their enterprise security or face legal action that could be a business-ending event.”

Forrester Senior Analyst Alla Valente:

“More details are sure to emerge in the coming weeks but from what we know now one thing is clear: risk management of open-source software has not kept pace with the open-source usage boom among public and private sectors. Without a risk management strategy, firms don’t have the budget or the resources they need, and, in hindsight, that they should have to effectively deal with Log4j.”

Forrester Principal Analyst Sandy Carielli:

“From a DevSecOps standpoint, limiting risk from Log4j and future vulnerabilities means knowing what is in your software and having the automation in place to easily upgrade. To understand and control what software you have in your products, you need to integrate your development pipeline with tooling that: Reports on vulnerable libraries in your software; provides guidance on how to remediate these issues; and sets policies to block and alert when you try to add vulnerable or high-risk libraries to your project.

“In the case of Log4J, a well-integrated software composition analysis (SCA) tool should find all vulnerable instances of Log4j, prioritize them based on how your product calls the component, recommend the upgrade to the fixed version, provide the automation to make that upgrade as seamless as possible — and do all of that in the developer’s native environment. Many SCA solutions are extending into broader supply chain issues recommending upgrades when components are stale, out of date, or poorly maintained.

“On the protection front, web application firewall (WAF) vendors are rapidly pushing out new rules to help detect and block attempted Log4j exploits. Accept and activate these new rules quickly — automatically if possible. If you have deployed Runtime Application Self Protection (RASP) on any of your applications, understand how that solution may already be detecting and blocking code execution.” 

Further information can be found here (One, Two) for reference.

To arrange an interview with any of these Forrester analysts, please reach out to press@forrester.com.