Summary

The root cause of the most damaging cloud breaches is not attacker sophistication. It is architecture. Marriott, SolarWinds, and Salesloft/Drift all followed the same five step kill chain, and every step was structurally permitted by the victim’s environment. Traditional security tools are detection instruments that fail here because they are deployed into environments never built for prevention. The fix: enforce security policy at the infrastructure layer before misconfigurations ever reach production.

Marriott had over 383 million guest records accessed across four years. SolarWinds infected 18,000 organizations through a single trusted update. Salesloft/Drift exposed more than 700 companies in ten days. None of these breaches required a single novel exploit. They required a cloud architecture built to detect threats rather than prevent the conditions that create them.

Of those Marriott records, approximately 5.25 million contained full sensitive data. Marriott revised its initial estimates downward after forensic analysis, which itself illustrates how long these breaches go unexamined.

Part I: Three Breaches, One Architecture Failure

The most damaging cloud breaches are not caused by exploits that outpace defenders. They are caused by attackers gaining legitimate entry and operating entirely within the target’s own trusted architecture, and cloud breach prevention starts by making that entry structurally impossible.

Marriott (2014 to 2018)

Stolen employee credentials enabled four years of undetected lateral movement to the central reservation database. The architecture had no mechanism to contain a credential compromise once it occurred. Every step was simply permitted.

SolarWinds (2020)

While the initial compromise was a supply chain attack, the true devastation of SolarWinds was a cloud identity failure. After infiltrating on premises networks via a trusted software update, attackers exploited overly permissive architectural trust relationships to forge SAML tokens, a technique known as Golden SAML. This allowed them to move seamlessly into Microsoft 365 and Azure cloud environments without needing to breach the cloud directly. They simply used the environment’s own unconstrained identity architecture to walk right in.

“SolarWinds did not exploit a vulnerability. It exploited a trust assumption. Trust assumptions, unlike known vulnerabilities, do not get patched. They get enforced or they do not. That is an architectural problem.”

-Joshua Behar

Salesloft / Drift (August 2025)

Stolen OAuth tokens gave an attacker the same identity access as a legitimate integration. Over ten days, CRM data was exported across more than 700 Salesforce organizations. No vulnerability was exploited. The architecture simply had no mechanism to distinguish a compromised token from a trusted one.

“When I brief security leaders on Salesloft/Drift, I ask: how many integrations in your environment have identity access scopes that are assumed rather than enforced by policy? For most organizations, that number is uncomfortably high.”

-Joshua Behar

Part II: Why Detection Tools Cannot Stop This

Security monitoring tools are essential and belong in every mature stack. But they share one design constraint: they identify problems after those problems already exist in your environment. In all three breaches, attackers operated entirely within what monitoring systems considered normal. There was nothing to detect.

• Endpoint and workload protection: detects malicious software. It cannot prevent excessive network or identity access grants, or distinguish legitimate use from compromised use when behavior is identical.

• Log correlation and alerting: surfaces suspicious event sequences. It cannot prevent the permissive configurations that allow those sequences, or flag activity that mirrors legitimate behavior.

• Cloud configuration scanning: finds misconfigurations after deployment. Every problem it finds is already live in production.

• Integrated cloud security platforms: combine the above into a unified view but remain reactive: they tell you what went wrong after it reached production.

Detection came four years too late for Marriott, nearly a year too late for SolarWinds, and weeks too late for Salesloft/Drift. The tools were present. None of it changed the outcome.

“In every post breach conversation I have had with security teams, the story is the same: the tools were working and none of it stopped what happened. That is not a failure of the tools. It is a failure of the architecture those tools were asked to defend.”

- Joshua Behar

‍

‍

‍

Part III: Examples of How Aryon Breaks the Kill Chain

Effective cloud breach prevention requires intervening before the infrastructure is actually built. Once a misconfigured network rule or identity policy reaches a live environment, security becomes a footrace between your detection alerts and an attacker’s automation. To break the kill chain, security policies must be enforced at the deployment layer, blocking risky configurations before they ever go live.

This is the exact architectural gap Aryon Security was built to close. Rather than acting as another passive alarm system, Aryon operates as an active, preventative gatekeeper. Aryon’s policy library contains hundreds of enforcement controls across network access, identity, and lateral movement layers. The examples below illustrate how this deployment stage prevention works in practice. In an Aryon secured environment, the misconfiguration is not flagged. It is structurally prevented from existing in the first place.

“We built Aryon to operate at the deployment layer. The moment a team tries to create an overly permissioned role or expose a management interface, Aryon blocks it. Not flags it. Blocks it. Because by the time you are flagging it, it is already a live risk.”

- Ron Arbel, Cofounder and CEO, Aryon Security

I. Closing Network Access: The Perimeter

The simplest breaches begin with a network door left open. Aryon ensures those doors are never built.

• Blocking exposed administrative network access: Internet facing administrative interfaces configured without network access restrictions are blocked before deployment. An entry point that never exists in production cannot be used as one.

• Preventing publicly accessible data storage: Cloud storage resources configured without strict network access controls are blocked before deployment. This includes the common developer shortcut of opening storage to anonymous network access for a quick task. In practice, that one hour window rarely closes.

II. Enforce Strong Authentication

Stolen credentials and tokens are only dangerous when the environment grants them unconstrained identity access. Aryon removes that power at the source.

• Requiring authentication on all public facing services: Public facing services provisioned without mandatory identity authentication are blocked. An unauthenticated service is structurally an open door. Aryon ensures it is never installed.

• Eliminating credentials embedded in infrastructure: Deployments that attempt to embed credentials directly into infrastructure configurations are blocked. A credential that cannot be embedded cannot be leaked or harvested.

• Blocking weak and default passwords: Infrastructure configurations that allow weak or default passwords are automatically blocked at deployment. What stops a junior DevOps engineer from spinning up a virtual machine open to the internet with a weak password? In an Aryon secured environment, policy does, automatically, before it goes live.

• Enforcing the use of short-lived credentials: Aryon enforces policies that prevent the use of long-term credentials for human users. Without long-term credentials, there is nothing persistent to leak. Even if a short-term key is exposed, it expires before it can be exploited.

III. Handling Vulnerabilities

Unpatched systems and unprotected web surfaces are reliable footholds. Aryon closes these windows at the infrastructure layer before they can be exploited.

• Enforcing WAF coverage on web facing resources: Aryon ensures all web facing resources are protected by a Web Application Firewall at provisioning time, preventing exploitation of known vulnerabilities before an attacker can probe them.

• Enforcing security patch requirements: Aryon enforces mandatory security updates on infrastructure components, blocking deployments that run unpatched versions with known vulnerabilities. This structurally closes the window that one day exploits depend on.

IV. Blocking Lateral Movement

Lateral movement is only possible when the architecture permits free traversal between systems. Aryon enforces the boundaries that contain a compromise to where it starts.

• Enforcing network boundaries between systems: Infrastructure that allows unrestricted network communication between environments is blocked. A compromised network access point is contained to the zone it belongs in and cannot reach what it cannot connect to.

• Preventing unauthorized environment crossings: Trust relationships that would allow network or identity access to cross from one environment into another are blocked. The Marriott attackers moved freely for four years because no such boundary existed. In an Aryon secured environment, that crossing is never permitted.

• Blocking overly broad identity access grants: Identities or integrations provisioned with identity access rights that exceed their operational function are blocked. Broad access grants are architectural debt that attackers cash in the moment they gain any foothold.

‍

These examples represent a fraction of Aryon’s enforcement capability. Aryon’s policy library spans hundreds of controls across network access, identity management, lateral movement prevention, and persistence blocking, continuously expanded as new threat patterns emerge. All of this operates with no agents, no changes to existing development workflows, and zero risk to the stability of your existing production environment.

Part IV: The Prevention Readiness Test

Answer these questions honestly before your next security architecture review. They reveal more about your actual risk posture than any compliance audit.

1. Can an overly permissioned account reach production without a policy block? If yes, it is a live risk from the moment it is created.

2. Do your human users rely on long-term credentials that can be leaked? If yes, you carry a structural liability that detection cannot resolve. Aryon enforces short-lived credentials so there is nothing persistent to steal. Even if a short-term key is exposed, it is already expired before the leak can be acted on.

3. Can an integration token be granted broader identity access than its purpose requires? If yes, you carry the same structural vulnerability as Salesloft/Drift.

4. What prevents a junior DevOps engineer from spinning up a virtual machine open to the internet with a weak password? If the answer is nothing automatic, that machine is one credential away from becoming an entry point.

5. What stops a developer from opening a storage resource to anonymous network access for just one hour to solve a quick problem? In practice, that one hour rarely ends. If there is no enforcement layer blocking it at deployment, the window stays open.

If these questions expose gaps in your architecture, that is exactly where to start. Not with another monitoring tool, but with enforcement. Aryon was built to make these conditions structurally impossible. If cloud breach prevention is a priority for your organization, talk to us.

Conclusion: The Attacker’s First Step Should Be Their Last

Marriott, SolarWinds, and Salesloft / Drift make the case for cloud breach prevention more clearly than any framework document ever could. They are tales of trust assumptions never validated, permissions broader than necessary, and monitoring tools deployed into environments never designed for prevention.

The most revealing question in cloud security today is not how fast you can detect and respond. It is this: what is stopping the misconfiguration from appearing in the first place?

“If you cannot confidently answer those questions, your environment is built for remediation, not prevention. Start with the architecture. The tools will follow.”

- Joshua Behar

“Every control Aryon enforces is a link in the breach chain that can never be completed. If the misconfiguration cannot exist, the breach cannot start. Prevention is not a layer you add to your security stack. It is the foundation everything else is built on.”

- Ron Arbel, Cofounder and CEO, Aryon Security

About the Authors

Joshua Behar

Cybersecurity executive and SaaS growth consultant specializing in Cloud Security, AI driven technology, and Enterprise Sales Strategy. Former CEO of Ericom Security (acquired by Ericsson’s Cradlepoint). Joshua works with cybersecurity startups to shorten sales cycles and build go to market strategies grounded in technical credibility.

Ron Arbel

Forbes 30 Under 30 recipient and Cofounder and CEO of Aryon Security. Former COO at Cyberilium, where he drove the growth that led to the acquisition of Cyberilium’s flagship product by CYE in 2023. Cofounder of the Matzov Entrepreneurship Forum.

‍