Zero Trust in Real Time

Executive Summary

 Cybersecurity has always been designed with a under a lock-and-key, moat around the castle mentality. However, in today’s fluid and supply-chain driven risk mitigation realm, the focus on perimeter defenses only ensure that external malicious actors are kept at bay. Unfortunately, these malicious actors are sometimes provided golden keys that land them directly inside the castle without having to fight a single knight or archer. That's where we find ourselves today, and with the current Apache Log4j vulnerability & Log4Shell Exploitation, zero-trust in real-time!

This document provides details discussed in Cybersecurity Journey to Zero Trust: Episode 3, namely Zero Trust Setup, Zero-Trust Reality, and Zero Trust Resilience.


Source Credit: AdvIntel

The Background

Apache’s Log4j, widely used, open-source logging library utility exists in the action of the Java Naming and Directory Interface (JNDI), which takes to resolve variables embedded within numerous cloud and enterprise apps including numerous popular cloud-hosted services of the likes of Minecraft, iCloud, Cloudflare and Twitter, to track software activity. affecting Apache’s Log4j library. CISA and its partners, through the Joint Cyber Defense Collaborative, are responding to active, widespread exploitation of a critical remote code execution (RCE), and the original vulnerability (CVE-2021-44228) in Apache’s Log4j software library, versions 2.0-beta9 to 2.14.1, known as "Log4Shell." Log4versions (Updated December 28, 2021), organizations are urged to upgrade to Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6), and review and monitor the Apache Log4j Security Vulnerabilities webpage for updates and mitigation guidance for all version up to and below 2.17.0. 

"A weakness in the computational logic (e.g., code) found in SW / HW components that, when exploited, results in a negative impact to CIA-triad e.g., confidentiality, integrity, or availability. Mitigation of the vulnerabilities in this context typically involves coding changes but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety)."

The deep ubiquity and integration between these hosting services, servers, and the Apache tool makes the extent of the damage likely to affect hundreds of millions of devices.  In addition to the original vulnerability which leverages Command & Control to distribute malware or exfiltrate data, there was also the risk of a Denial of Service (DoS) attack vector for affected servers/services as well. That was documented in a separate but tangible CVE-2021-45046, that began as a base CVSS Score of 7.5 but was quickly escalated and re-ranked to a 9.0; shortly thereafter, the Apache Software Foundation's log4j project disclosed two newer vulnerabilities identified by CVE-2021-45105 (5.9) & CVE-2021-44832 (6.6) as well. Although they've expressed and commented their belief that these new flaws seem to be a more non-critical DoS-only or lookups, as was the 2nd vulnerability that was a challenging RCE sequence, the latter have all been designated to have a much tighter scope for use as an attack vector than the previous two vulnerabilities. 

However, in comments made shortly after the Zero-Day release, CISA expected all kinds of attackers to exploit the vulnerability, from cryptominers to ransomware and nation-state actors/groups. CISA’s director told industry leaders Monday that along with the vulnerability and scope, among other factors, makes the ranking among vulnerabilities as:

"One of the most serious I've seen in my career, if not the most serious. At the time, there was no evidence of an active of supply-chain attack…"

That changed quickly! On the weekend of the 18th, security researcher ‘1ZRR4H’ identified the first Log4J worm. It is a self-propagating Mirai bot. During that initial notification, CISA did concede that it was going to take a “sustained effort” for organizations to become secure, with diligence needed even after applying patches from Apache, vendors, and service providers. There’s no single action that fixes this issue. It’s a mistake to think anyone is going to be done with this in a week or two.” And prior to the New Year Break, a never-before-seen China-based targeted intrusion adversary labeled as 'Aquatic Panda' was observed leveraging those previous flaws in the Apache Log4j logging library as an access vector to perform various post-exploitation operations, including recon and credential harvesting on targeted 'Educational Institution' systems.  Although thwarted, this is likely the tip of the iceberg as more toolkits and easily accessible summaries of exploit tooling become available on the Dark web and so on.  

Cybersecurity Information Sharing Act (CISA) - Apache Log4j Vulnerability Guidance

Figure: CISA Log4j Guidance Infographic

Reflective of this dialogue and through actualization of the current expanding scope and spiraling escalation of these vulnerabilities, CISA and its partners, through the ‘Joint Cyber Defense Collaborative’ in response, also created a rare, specific webpage (see summary above), to track updates for Apache’s Log4j vulnerability and an updated resource to provide guidance and will actively maintain a community-sourced GitHub repository of publicly available tools, including a scanner and vendor-supplied advisories regarding the Log4j vulnerability. CISA will continually update both of those webpages and the GitHub repository. They’ve also included an updated government-wide Emergency Directive (ED 22-02) directing federal agencies to mitigate the Apache Log4j vulnerability.

Zero Trust Setup

This section explores how quickly the need for a Zero Trust Architecture can be exposed.


  • The Common Vulnerabilities & Exposures (CVE) rating for this is a ’10.0’ out of 10 <and> what started as a 3.7 ramped up to a 9.0 within a week for the secondary CVE respectively and now a 3rd rated at 7.5.
  • Continued potential for additional follow-on CVE’s related to the original vulnerability (e.g. 2nd, 3rd and 4th CVE's related to Log4j).
  • Not only does this provide a level of numeric scale to the severity of this issue, but also the speed in which this can change dynamically, the criticality of the problem facing the overall community at large.


  • Apache’s service is very broadly used in a variety of consumer and enterprise services, websites, and applications including numerous popular cloud-hosted services of the likes of Apple’s iCloud, Minecraft, Cloudflare and Twitter—as well as, in operational technology (OT) products—to log security and performance information:
  • An unauthenticated remote actor could exploit this vulnerability to take control of an affected system and provide them a C2 e.g., malware / phishing campaigns or simply exfiltration e.g., $ or info.
  • The 2nd & 3rd flaws were found in the same logging utility, both that could potentially crash websites & serve as a DoS to those and other hosted services.


  • Scale to find what apps have vulnerable versions of Log4j.
  • Discover which apps have the vulnerability.
  • Halt attacks against it today, don’t wait for a patch or WAF signature updates, and lastly:
  • Future proof your code and protect against the zero-day vuls as they come to pass.

Zero-Trust Reality: The next battlefield


Source Credit: Black Hat USA


  • Breadth & Depth; unknown, undocumented, and unseen? This had been in making for years.
  • How long must you play on a given battlefield?! This issue will be around for some time, as are other vulnerabilities and their malicious variants and actors developing against them ex. Mirai / SolarWinds / Spectre-Meltdown.

Land & Expand

  • Where’s the beachhead?!  How do you stop an attack that is already inside your walls, within your fabric of operations and doesn’t need sophisticated threat actor involvement?
  • How quickly is the next Cyber / supply chain or infrastructure attack going to take this time? 


  • In the initial hours, CISA and others tracking this had not identified any ‘active campaigns.
  • Within days, several campaigns have already been detected in the wild e.g., several were putting ransomware and remote-access-Trojans on Windows machines with Java installed.
  • Malicious actors will continue to sequence the vulnerability as detailed via MITRE’s cyber threat actor’s tactics and techniques. 


Figure: MITRE’s cyber threat actor T&Ts

Zero Trust Resilience

How does the protection work and mitigates and takes aim at future-proofing against the next incarnation?

  • Zero Trust Tenets & Log4Shell - Zero Trust assumption is that the exploiter is already inside the perimeter; a supply chain exploit can go after this vulnerability from the inside, gaining RCE in the logging asset, with its privilege.
  • Granular Isolation (e.g. microservice, container, app) - Limit the compromised behavior, to only intended, tested, least privilege & least capability actions.
  • Continuous Enforcement on ‘every transaction’ - Exploit will need to mirror the allowed actions of the component only, without any access to the policy, guessing right at every move, for every hop.
  • Inline & Realtime Verification - Any anomalous action outside of those intentions would be blocked that would be blocked by continuous enforcement and verification, at a point outside of the component failure domain.
  • Universal Coverage & End-to-End Coverage - All subjects and objects are identified and access restricted, so many mal behaviors will be disallowed.
  • Exploitation App Workloads/Services Limitation - Similarly, unlike the many exploits with specific mitigations that are being frantically discussed right now.


Figure: Tenets from NIST SP 800-207

This is the value of built-in resilience … as a complement to the rest of security! The aim and goal should be preserving security resiliency during times of zero-day notification, through exploitation activities and the advancements or updated versions of attacks from the vector by deploying these Zero Trust framework based on NIST’s 7 tenets, strategies, and tools of Zero Trust!

Summary and Additional Resources

This document provided details discussed in Cybersecurity Journey to Zero Trust: Episode 3, namely Zero Trust Setup, Zero-Trust Reality, and Zero Trust Resilience.

Additional Resources

For further Zero-Trust assets on Tech Zone, see:


The following updates were made to this guide:


Description of Changes


  • Initial publication.

About the Author

Andrew Osborn is serving in a role at VMware as a dedicated ‘Staff Technical Marketing Architect’ for all things End-User Computing (EUC) compliance / regulatory. He has over 20 years’ experience in the IT Industry, including the last 8 years within Public Sector, with roles spanning Cybersecurity, Networking, Enterprise Ops, Mobility & Telco solutions, encompassing numerous technologies and architectures. Andrew received an MIS degree from University of Oklahoma with certs from ISC2 CISSP & GIAC GSLC and is based out of San Antonio, TX. He'll be contributing to VMware’s Tech Zone to provide more tailored messaging for Federal, State, Local & Education (SLED) solutions from VMware EUC.


Your feedback is valuable.

To comment on this paper, contact VMware End-User-Computing Technical Marketing at


Associated Content

home-carousel-icon From the action bar MORE button.

Filter Tags

Document WhitePaper Intermediate Zero Trust Public Sector