In 1984, the International Organization for Standardization published something that would fundamentally reshape how we think about computer networking: the OSI model. At the time, the networking world was chaos—proprietary protocols, incompatible systems, and no common framework for different vendors to communicate. The OSI model brought order to this complexity by establishing seven standardized layers, creating the foundation for the interconnected world we know today.
Forty years later, cybersecurity finds itself in a similar moment of chaos. We've built sophisticated defenses, deployed cutting-edge tools, and invested billions in security infrastructure. Yet breaches like MGM Resorts, where a simple phone call led to a $100 million operational shutdown, or the recent leak of 16 billion credentials, reveal a fundamental truth: our security foundation is cracking.
It's time to return to first principles.
Security's Trio: The Foundation We Forgot
Just as the OSI model recognized that networking required structured layers, effective security has always rested on three fundamental pillars:
Identity: Who is accessing the system?
Endpoints: What devices or applications are involved?
Network: How are they communicating?
This trio isn't new—it's been the backbone of security architecture since the beginning. Identity systems authenticate users. Endpoint protection secures devices and applications. Network controls govern how everything connects and communicates.
This model worked in the data center era because the network layer was simple: there was inside (trusted) and outside (untrusted), with clear boundaries and chokepoints. We built our security castle on this foundation, and through the early 2000s, it largely held.
But by 2010, the foundation was showing cracks. Early cloud adopters were demonstrating that the perimeter was beginning to dissolve, users and devices were becoming increasingly mobile, and enterprise data was flowing well beyond corporate firewalls—into SaaS apps, personal devices, and third-party ecosystems.
When John Kindervag introduced Zero Trust at Forrester that year, he was responding to this emerging reality. The "castle-and-moat" model assumed everything inside the network perimeter was trustworthy—a dangerous assumption that cloud adoption was exacerbating. Zero Trust's core principle of "never trust, always verify" was revolutionary because it demanded verification at every layer of the trio, just as the traditional perimeter was starting to crumble.
Then came widespread cloud adoption.
The Great Unraveling: When Foundations Shift
The mass migration to cloud didn't just change where we put our applications—it fundamentally altered the nature of the network itself. Consider what happened:
The Internet Became the Enterprise Network: What was once carefully controlled internal communication—database queries, API calls, service-to-service traffic—now routinely traverses the same public infrastructure we once considered hostile territory.
The Perimeter Exploded: Instead of a few heavily fortified data centers, we now have thousands of Virtual Private Clouds, Kubernetes clusters, serverless functions, and API endpoints. Each represents a micro-perimeter requiring defense, but most lack any dedicated security controls.
In this new reality, two of our three security pillars adapted well to Zero Trust principles:
Identity evolved brilliantly: Single sign-on, multi-factor authentication, and identity providers like Okta embodied Zero Trust's "verify explicitly" principle, creating sophisticated, cloud-native identity controls.
Endpoints got smarter: Endpoint Detection and Response (EDR), Cloud Native Application Protection Platforms (CNAPP), and container security tools embraced "assume breach" thinking, bringing Zero Trust protection into the cloud era.
But the network pillar crumbled. We lost the clear boundaries that made network security possible. Worse, we pretended we hadn't—continuing to operate with implicit trust between workloads even as we implemented Zero Trust everywhere else.
When Two Out of Three Isn't Enough: The MGM Disaster
The 2023 MGM Resorts breach provides a perfect case study of what happens when security's foundational trio is incomplete. In September 2023, attackers from the cybercrime group Scattered Spider executed a devastatingly simple attack: a ten-minute phone call to MGM's IT help desk, impersonating an employee to obtain administrative credentials for the company's cloud environment.
Using these stolen credentials, the attackers pivoted from MGM's cloud identity systems to their on-premise VMware infrastructure, where they deployed ransomware across over 100 hypervisors. The result was a complete operational shutdown lasting nearly ten days, with hotel reservations, digital room keys, slot machines, and payment systems all offline. The financial damage exceeded $100 million, and the reputational impact continues today.
What makes this breach particularly instructive is how it reveals the failure of each security pillar. Let's examine how each pillar performed:
Identity (Partial Success): MGM had sophisticated identity controls—Okta for identity management, proper administrative accounts, and enterprise-grade authentication systems. The problem wasn't the absence of identity controls; it was that a simple social engineering attack bypassed them. A ten-minute phone call to the help desk was all it took for attackers to obtain valid administrative credentials.
Endpoints (Complete Success): There's no evidence that MGM's endpoint security failed. The attack didn't rely on malware, compromised devices, or vulnerable applications. From an endpoint perspective, the attack used legitimate tools and valid credentials throughout.
Network (Catastrophic Failure): This is where the attack succeeded and caused devastating damage. Using stolen cloud administrative credentials, attackers pivoted seamlessly from MGM's cloud identity environment to their on-premise VMware infrastructure. There was no network-level policy preventing this cross-environment communication. Once inside the hypervisor management network, they moved laterally to encrypt over 100 ESXi hosts, bringing down hotel reservations, slot machines, and payment systems across Las Vegas.
The lesson is stark: identity and endpoint security, no matter how sophisticated, cannot compensate for a collapsed network pillar.
The Invisible Highway: Understanding Modern Network Risk
The MGM attack succeeded because it exploited something that traditional security architectures struggle to address: the implicit trust relationships between different parts of their hybrid infrastructure. Consider the pathways that enabled the disaster:
Cloud identity services → On-premise infrastructure management
Compromised cloud credentials were automatically trusted by on-premise systems, allowing attackers to pivot between environments without any network-level verification
Infrastructure management → Individual virtual machines
Control of management systems gave attackers access to all underlying workloads due to insufficient segmentation between administrative and production layers
Virtual machine → Virtual machine (lateral movement)
Attackers moved freely between systems due to flat network design and lack of workload-to-workload access controls
Internal data repositories → External command and control
Internal systems could communicate freely with external destinations, enabling data exfiltration through implicit trust of outbound traffic
Each of these connections traversed what should have been controlled network boundaries, but in practice operated on implicit trust. The attackers weren't using exotic exploits or zero-day vulnerabilities—they were simply moving through unmonitored, uncontrolled communication pathways that security teams had lost visibility into or assumed were trusted.
This is the new attack surface: not the classic "north-south" traffic entering and leaving the network, but the "east-west" traffic flowing between workloads, services, and infrastructure components. It's a massive, largely undefended highway that exists everywhere organizations have embraced cloud and hybrid architectures.
Given this reality, security professionals might reasonably wonder: if we've implemented Zero Trust across our organization, how can such a massive, undefended attack surface still exist?
The Zero Trust Paradox: Why "Never Trust, Always Verify" Stopped at the Network
The answer is that most Zero Trust implementations are incomplete. While organizations have successfully applied Zero Trust principles to user access (identity) and application security (endpoints), they've largely left the network layer—specifically workload-to-workload communication—operating on the old model of implicit trust.
This isn't an oversight; it's an architectural challenge. Zero Trust's "never trust, always verify" principle is easy to implement when you have clear interaction points—a user logging in, an application starting up. But how do you verify trust between thousands of ephemeral containers, microservices calling APIs, or cloud services replicating data? This is a landscape where the sand is constantly shifting. Cloud environments were intentionally built for speed and agility—empowering developers to spin up infrastructure on demand, prioritizing innovation first and security second.
Swimming Against the Current: Why Network Security Struggles in the Cloud
The challenge of applying Zero Trust to workload communication becomes clear when you examine how enterprise network security actually works today. Most approaches, while valuable and necessary, weren't designed for the cloud's fundamental nature. The cloud was built for distribution—to break down boundaries, enable seamless scaling, and connect services across regions and providers. Traditional security controls, however, were designed for the opposite: creating boundaries, maintaining static perimeters, and controlling access through chokepoints.
This creates a fundamental tension. We're essentially trying to swim against the current of how cloud infrastructure naturally wants to operate.
Legacy Approaches in Cloud Environments: Organizations took their data center networking playbook—VLANs, firewall rules, network zones—and tried to recreate it in the cloud. These controls remain important for basic segmentation and access control, but they create complex webs of static rules that become unmaintainable as cloud environments scale and change dynamically.
Cloud Provider Native Controls: Security teams leverage AWS Security Groups, Azure Network Security Groups, and GCP firewall rules—tools that are powerful and essential within their respective environments. But they operate in silos, each with different models, rule syntaxes, and capabilities. They're excellent for securing resources within a single cloud, but fall short when you need consistent policy across AWS, Azure, and your on-premise data center.
Third-Party Cloud Security Tools: Organizations deploy additional layers like CASBs, cloud firewalls, and service mesh platforms to fill the gaps left by legacy and native approaches. While these tools provide important capabilities, they often require complex deployments (like routing traffic through external services) and add management overhead, making them challenging to implement at scale across dynamic cloud environments.
The challenge isn't that these approaches are wrong—they're necessary components of a complete security strategy. The problem is deeper: they're all trying to impose static, boundary-based thinking on infrastructure that operates on entirely different principles:
Workloads are ephemeral: Containers spin up and down by the thousands. Serverless functions exist for milliseconds. IP addresses are constantly changing.
Boundaries are fluid: An enterprise workload may span multiple regions. Kubernetes pods can communicate within and across clusters, to IaaS environments, or even across clouds. The edge is everywhere and nowhere.
Communication patterns are dynamic: Microservices discover each other through service meshes. APIs call other APIs in complex chains. Data flows follow application logic, not network topology.
The MGM attack succeeded precisely because these cloud-native communication patterns fell into the gaps between our network security controls. The pivot from cloud identity to on-premise infrastructure? That crossed multiple security domains, each with different tools and policies. The lateral movement between hypervisors? That happened within what traditional network security considered a "trusted zone."
Enter the Cloud Native Security Fabric: Zero Trust for Workloads
This is why the industry needs a fundamentally new approach—not another point solution, but the missing piece of Zero Trust architecture.
Cloud Native Security Fabric (CNSF) represents Zero Trust for the spaces between workloads. While traditional Zero Trust focused on "who" (identity) and "what" (endpoints), CNSF completes the model by addressing "how"—the communication pathways that connect everything together.
CNSF embeds the core Zero Trust principles directly into the cloud fabric:
Verify explicitly: Every workload-to-workload connection can be authenticated and authorized based on workload identity—whether it's a traditional IaaS virtual machine, a Kubernetes pod leveraging cloud-native constructs like tags and namespaces, or containerized applications communicating across different tech stacks. This identity-based approach works consistently across all clouds and environments, moving beyond simple network location to understand what each workload actually is and what it's authorized to do.
Least privilege access: Connections can be denied by default through microsegmentation that can be applied at the host level using native construct orchestration, or more broadly through cloud-aware groupings that automatically adapt to dynamic environment changes. This approach ensures that workloads can only communicate with explicitly authorized resources, whether those policies are enforced through container orchestration platforms, cloud provider constructs, or intelligent groupings that understand the ephemeral nature of cloud workloads.
Assume breach: Lateral movement can be prevented through continuous verification and dynamic micro-segmentation that treats every connection attempt as potentially hostile, regardless of the source's previous authentication status. When a breach occurs, the blast radius is automatically contained because each workload operates in its own security boundary, preventing attackers from moving freely across the environment. Real-time policy enforcement ensures that even compromised credentials or workloads cannot access unauthorized resources or pivot to other parts of the infrastructure.
Think of it as the difference between building security controls for each road versus embedding Zero Trust intelligence into the transportation fabric itself. CNSF doesn't just secure individual pathways—it creates a policy-driven, identity-aware network layer that can enforce trust decisions in real-time, everywhere workloads communicate.
Rewinding the Tape: MGM with Complete Zero Trust
What would have happened if MGM had a complete Zero Trust implementation—including the missing network pillar? Let's replay the attack:
The social engineering still succeeds. The attackers still obtain valid administrative credentials for MGM's cloud environment. But now, when they attempt to pivot from the cloud identity plane to the on-premise infrastructure management network, something different happens.
A Cloud Native Security Fabric (CNSF) sits in the data path, enforcing Zero Trust policy in real-time. When the connection attempt occurs, the fabric evaluates it against a "never trust, always verify" policy: "Only specific, authorized infrastructure management tools, operating from designated secure network segments, may communicate with ESXi management interfaces."
The connection attempt—despite using valid credentials—doesn't match any allow rule. The fabric blocks it instantly, logs the attempt, and alerts security teams to the anomalous activity. Zero Trust works as designed: the attack stops at the network layer.
Even if attackers somehow compromised a single hypervisor through a different vector, the CNSF's Zero Trust micro-segmentation policies would prevent the ransomware from spreading. Each hypervisor would be isolated, unable to communicate directly with others on management ports. The breach becomes a contained, single-host incident instead of a systemic disaster.
The difference is architectural as well as technical. CNSF provides what MGM's Zero Trust implementation lacked: real-time, policy-driven trust enforcement in the spaces between workloads.
CNSF: Completing Zero Trust for the Cloud Era
Cloud Native Security Fabric represents the modern evolution of Zero Trust's network pillar. Just as identity moved from Active Directory to cloud-native identity providers, and endpoint protection evolved from antivirus to EDR with Zero Trust principles, network security must evolve from perimeter-based controls to fabric-embedded enforcement.
CNSF operates on fundamentally different principles than legacy network security:
Embedded, Not Bolted On: Instead of sitting at network chokepoints, CNSF is woven directly into the cloud infrastructure fabric, providing in-line Zero Trust policy enforcement everywhere workloads communicate.
Identity-Aware: Policies are based on workload identity and intent, not static IP addresses or network locations. Zero Trust controls move dynamically with ephemeral cloud workloads.
Zero Trust by Default: All communication can be denied unless explicitly allowed by policy. There's no concept of "trusted internal" traffic—every connection must be verified.
Real-Time Enforcement: Policies execute as connections are attempted, not after threats are detected. True prevention, not just detection.
Developer Transparent: Zero Trust security is embedded without requiring application code changes or imposing new workflows on development teams.
This isn't just another security tool—it's the missing foundational layer that completes Zero Trust for the cloud era.
The Path Forward: Completing Zero Trust
When Forrester introduced Zero Trust in 2010, it was a response to the failure of perimeter-based security. Today, we face a similar moment: Zero Trust implementations are failing not because the principles are wrong, but because they're incomplete.
The evidence from breaches like MGM is clear: sophisticated identity and endpoint controls aren't sufficient when the network layer—the communication fabric between workloads—still operates on implicit trust.
CNSF provides the architectural evolution Zero Trust needs—not another point solution, but the missing foundational layer that completes "never trust, always verify" for the cloud era. It treats workload-to-workload communication with the same Zero Trust rigor we've brought to user access and application security.
The choice facing security leaders isn't whether to embrace this evolution—the breaches prove it's necessary. The choice is whether to complete Zero Trust proactively, before the next crisis, or reactively, in its aftermath. The cloud won't wait. Neither will the adversaries who thrive in the unprotected spaces we've left behind.
The foundation of security hasn't changed: identity, endpoints, and network. But the cloud has fundamentally altered how that foundation must be implemented. CNSF completes Zero Trust, providing the network pillar our defenses have been missing.
Schedule a demo to learn how Aviatrix’s Cloud Native Security Fabric can protect your network’s foundation.
