Modern cyberattacks are a little like plane crashes. There’s rarely one single factor that causes the disaster—rather, it’s the result of a chain of problems or failures. In the last century of commercial aviation, there have been so many technologies, protocols, and checks built into the airplanes and various maintenance and operational processes that it takes a cascade of multiple factors, often both technical issues and human mistakes, to cause an accident.
Cybersecurity hasn’t been around for quite as long as that, but defense-in-depth strategies—i.e., using multiple layers of security controls and technologies so that if any one of those measures fails, there are others in place to mitigate or contain the damage—have evolved into expansive technology stacks.
Despite all these varied protections, breaches still happen, including incursions that steal massive volumes of data and cost organizations millions in lost revenue, mitigation actions such as paying for credit monitoring services for their customers, and fines. In fact, these large-scale attacks seem to be increasing in scope and frequency. Why? There are two primary reasons:
Cybercriminal sophistication: Attackers are no longer just script kiddies playing around or lone wolves looking for a quick buck. Today’s hackers are highly organized groups that operate like legitimate businesses with specialized “departments” and significant resources—some are even state-sponsored—and are willing to play a long game for an enormous payout.
Perimeter-less environments: Enterprise computing environments no longer have clear inside-outside distinctions that allow you to build a protective “wall.” Sensitive data, connections, and processes, once secured within a digital fortress, now use public cloud infrastructures. Traditional security controls are still valuable, but they don’t cover the new attack surfaces that are now open: the unmonitored, implicitly trusted communication pathways between every cloud workload.
So, what does this mean for defense-in-depth? Clearly, bolting another security solution onto the edge of the network is not the answer. Instead, we need to embed a new foundational security layer within the cloud runtime that can inspect, segment, and secure communication between every cloud workload no matter where it resides—in a public cloud, in a private data center, or at the edge—and deliver real-time, policy-driven enforcement.
This layer, a Cloud Native Security Fabric (CNSF), operates directly in the data path of workload-to-workload communications. It’s dynamic and distributed, with security policies and segmentation tied to workload identities, not static IP addresses, so controls move with ephemeral workloads as they are created, scaled, and destroyed. And it uses the zero trust approach of denying all traffic by default unless explicitly allowed by a policy, with enforcement happening as connections are attempted rather than after a threat has been detected.
To understand how a CNSF works in practice, and how it differs from other cybersecurity controls, it’s useful to dissect a well-known breach and detail how a CNSF would have intervened at each failure point for a drastically different outcome.
The failures leading to the MGM breach—and how a CNSF could have contained the impact
The September 2023 cyberattack against hospitality, sports, and entertainment giant MGM Resorts International started with a simple phishing expedition and ended with 10 days of massive operational disruptions, an estimated loss of $100 million in core profits, and a $45 million outlay in class action settlement costs.
It’s important to note that this exercise isn’t about shaming the victim. Nor should it be inferred that MGM had poor cybersecurity controls in place—on the contrary, this incident is a stark warning that every business, even those with the most robust best-practice tools and processes, can be at risk.
Here’s how the Scattered Spider hacking group, also known as UNC3944, exploited a chain of weaknesses to penetrate MGM’s cybersecurity defenses.
Failure #1: Human carelessness compromises one user’s credentials
The attackers, using information from LinkedIn to impersonate an employee, called MGM’s IT help desk to claim they’d been locked out of their account. They manipulated the help desk staffer into providing that user’s login credentials.
A CNSF doesn’t protect against social engineering. But it can ensure that the impact of stolen credentials is narrowly contained.
Failure #2: Implicit trust enables the attackers to pivot
Using the stolen credentials, Scattered Spider was able to gain admin-level privileges to MGM’s central identity and access management control plane, Okta, and Microsoft Azure tenant environments. Because the attackers had legitimate—albeit stolen—credentials, the systems implicitly trusted them. Because there was no independent security control monitoring or segmenting the pathway between the cloud identity tool and other systems, the attackers were able to use their privileged position to move laterally into MGM’s VMware ESXi environment.
The CNSF intervention: Block lateral movement with identity-based micro-segmentation. With a CNSF, it’s not enough to have privileged credentials. A CNSF can enforce a strict zero trust policy that only specific, authorized infrastructure management tools operating from a designated secure network segment can communicate with the virtualization management interface. The attackers are attempting to connect from a general administrative user context within the cloud, which wouldn’t match any “allow” rule even though the user is authenticated, and the fabric would block the path, log the attempt, and alert security teams.
Failure #3: East-west propagation expands the blast radius of the ransomware
Now that Scatter Spider had access to the virtualization management interface, they were joined by ransomware-as-a-service partner ALPHV, also known as BlackCat, for the next phase of the operation. They deployed ransomware to around 100 hypervisors that power a wide range of functions across the business. Crippling these hypervisors crippled operations throughout the entire organization.
The CNSF intervention: Prevent ransomware spread. Even if the attackers managed to compromise the first hypervisor with their ransomware, that host would start scanning the local network to find other ESXi hosts to infect. A CNSF’s micro-segmentation policies would ensure that each hypervisor resides in its own isolated segment. Furthermore, it would know that the hypervisors have no legitimate reason to communicate directly with each other on management ports, so it would block the ransomware’s attempts to spread, containing the infection to a single host.
Failure #4: Unfiltered egress allows data to be exfiltrated
At the same time that the attackers were seizing control of the ESXi hypervisors, they were also exfiltrating around 6 terabytes of sensitive customer data from MGM’s systems. They accomplished this by moving the data from internal database services to a staging server and then out to an external command-and-control destination.
The CNSF intervention: Prevent data exfiltration. A CNSF sits inline with all traffic to provide robust egress filtering via policies that specify precisely which workloads can communicate with the public internet and to which destinations. An attempt to transfer terabytes of data from a protected database segment to an unknown external IP address would violate the least-privilege egress policy, and the CNSF would block the flow.
A very different outcome
A CNSF could have dramatically reduced the fallout of the MGM breach, limiting it to one set of stolen credentials, and one compromised ESXi hypervisor. Of course, foiling the hackers at one turn would likely cause them to shift gears and look for a different vulnerability to exploit to achieve their ultimate objective. Because the attempts would violate policy of what is explicitly allowed, the CNSF would prevent those connections as well.
CNSF is the next frontier in cloud security
Traditional approaches have focused on detecting “bad.” This provides a solid starting point for security. The challenge is that risks and vulnerabilities are constantly changing, making the efforts to keep pace with malware signatures and anomalous behavior patterns a never-ending game of speed Whac-A-Mole. Now we need to progress to enforcing “good,” and that’s exactly what Aviatrix has developed its CNSF to do.
CNSF enforces a positive security model based on declared intent. It doesn’t need to know who is attempting a connection, it only needs to know if that communication path is allowed by policy. By embedding security directly into the network fabric of the cloud itself, the Aviatrix CNSF provides the architectural approach needed to address the gaps that traditional defense-in-depth layers can’t cover in perimeter-less cloud environments.
Learn more about CNSF:
Read about how the Aviatrix CNSF can stop breaches like the EchoLeak zero-click vulnerability or the Play ransomware attack.
Read about how the Aviatrix CNSF can severely limit the blast radius of supply chain attacks like the MOVEit zero-day breach.
Download our white paper to explore how the Aviatrix CNSF embeds protection within a cloud architecture.
