We all know that ApacheLog4j emphasized the importance of upgrading from the bolted-on infrastructure architectures of WANs, VPNs, firewalls, etc to secure by design architectures.

However, ApacheLog4j also demonstrated that most Zero Trust solutions are not the answer, because they secure one component, rather than providing total, systems-level, secure by design architecture across everything.  Let’s take a look.

Businesses which use NetFoundry for full Zero Trust weren’t forced to scramble to react to ApacheLog4j 2 because their secure by design architectures meant that NetFoundry prevented ApacheLog4j 2 from grasping its first breath of air.  As a quick recap, here’s how ApacheLog4j 2 comes to life – how it first breathes:

  1. An attacker executes an HTTP request against a target system (e.g. a web server with ApacheLog4j)
  2. The targeted system then generates a log using Log4j 2
  3. The log causes the JNDI API to connect to an attacker controlled site and execute the payload

Because NetFoundry is the only true Zero Trust platform (the only platform to enable businesses to close all network connections for all apps and use cases, and only permit identified, authenticated, authorized, least privileged access connections to be made), the attacker couldn’t reach ApacheLog4j to begin with (minimize the attack surface) via external networks (the common attack point).  Even if ApacheLog4j was reached in a different manner, the business was still protected because their NetFoundry platform meant ApacheLog4j it was prevented from connecting to the attacker controlled site (minimize the blast radius), essentially suffocating it.

This meant NetFoundry customers were protected and had time to patch their servers, rather than scrambling into crisis mode.  Maybe more importantly, when the next vulnerability surfaces…they are still protected.  NetFoundry customers prevent against the unknown vulnerabilities of the future by proactively eliminating the number one attack vector – the network.

While the Zero Trust world (which has now expanded to ironically include firewall and SD-WAN vendors) has quickly pointed out that this is yet another example of why orgs need to replace WANs, VPNs and open firewalls with Zero Trust, please be careful.  99% of the world’s “Zero Trust” solutions would not have helped in this case because they solely focus on the connection between a user and a modern web app.

That limitation resulted in that web server using ApacheLog4j still being vulnerable – the server is not made unreachable to the networks by the “zero trust” solution – for example, at the very least, there are remote management connections, connections to third-party APIs and microservices, connections to databases, etc.

The NetFoundry Zero Trust platform it the opposite, rather than only protect the connection between a user and an app server, actually enable businesses to detach all apps, APIs, servers, database calls, etc. from the networks.  The whole system is secure – by design – rather than the approach of trying to secure each part with different bespoke solutions.  This is part of what Gartner labeled as CASCE (naming NetFoundry as one of the top 10 CASCE providers).

You can dive into the detail in this Zero Trust whitepaper to learn how to secure all your assets from network attacks, proactively and by design.

Discuss On: