Labyrinths and Footguns: Cybersecurity in the Age of the Cloud
Chris Clements, VP of Solutions Consulting
“It’s important to realize that not only does the cloud not solve all your old cybersecurity problems, it can introduce its own new ones.”
Key Takeaways
- Moving to the cloud does not eliminate cybersecurity risk. It shifts the attack surface, introducing new security challenges alongside the benefits of scalability and flexibility.
- Identity and access management mistakes are the most common cloud security failures. Over-privileged IAM roles, exposed credentials, and weak access controls often create more risk than advanced external attacks.
- Cloud-native security tools can strengthen defenses when implemented correctly. Infrastructure as Code, centralized telemetry, and container immutability can improve resilience, but insecure pipelines and compromised images can quickly spread vulnerabilities.
- Understanding the shared responsibility model is essential. Cloud providers secure the underlying infrastructure, but organizations remain responsible for their data, configurations, identities, and connected applications.
The Cloud is Not Magic
Cloud services, whether PaaS, IaaS, or SaaS, are the backbones of most organizations.
Most core business operations, like communication (M365, Google Workspace), CRMs such as Salesforce and HubSpot, and accounting packages like QuickBooks Online, are delivered as SaaS. Most customer-facing products live in providers like AWS, Azure, or GCP. These platforms deliver real value, but come with their own cloud security risks and configuration challenges.
With the cloud, it is important to realize that what you have really done is trade attack surfaces, not shrink them.
The Origins of Centralized Computing
In the beginning, there was the cloud.
Well, technically we called them mainframes at the time, and there was usually just one, and it was definitely on prem.
Alright fine, it’s not such a great metaphor, but the point is that most of the responsibility for computing was centralized on a single platform with endpoints that did very little to no processing work. This simplified the number of access and other security controls that were necessary to think about.
But lord were those things expensive.
The Explosion of the Endpoint Attack Surface
The advent of microcomputers decentralized computing with cheap end user devices capable of doing meaningful work supported by multiple purpose-based server class systems. Instead of everyone riding passively on the same train, now everyone has their own car they pilot themselves.
While this democratized computing for more organizations and users, it also exploded the cybersecurity attack surface. Every endpoint became a potential vector for attack, especially as devices became portable with laptops and then smartphones.
If everyone is now speeding around in their own car, anyone can cause a catastrophic pileup. Especially because none of the users were required to get a license to drive their new computers.
To address this added complexity and risk, we implemented technologies such as firewalls to restrict access to systems that didn’t need to serve data to the internet, intrusion detection and prevention systems to spot and stop threats in the network traffic we did need, along with many other security controls.
But this complexity also created a management burden. Now organizations need helpdesk teams to manage endpoints, server administrators to maintain servers, network teams to connect everything together, and eventually security teams to fight with everyone else and tell them no (mostly a joke… mostly).
Cloud 2.0: Return of Centralization
All the infrastructure and personnel needed to run an average organization’s IT became both expensive and slow to change. Teams, collaborating and sometimes fighting with each other, introduced delays and frictions as each brought their own territorial concerns and priorities. These factors also had the effect of making IT slow to scale.
Enter “the cloud.”
Software as a Service (SaaS) providers, such as Microsoft365, made infrastructure that previously required hefty upfront investment and added personnel accessible to anyone with a browser and a credit card. Platform and Infrastructure as a Service (PaaS and IaaS), such as AWS, offered to provide entire data center IaaS through a single web console or API call. Using IaaS, startups like Airbnb and Slack, were able to not only move at light speed from idea to product, but also from a few users to internet scale practically overnight by taking a cloud-native approach to operations.
While their cloud bill no doubt ended up being costly, this allowed them to accomplish something that previously would have taken large up-front infrastructure and personnel investment.
Traditional and other established companies seeing success of these startups often rushed to follow suit, sometimes whether or not it actually made sense for their business, but I digress…
Cloud Security Risks: Labyrinths and Footguns
I promise this all has something to do with cybersecurity.
You might be a shiny new startup born natively in the cloud, or an established enterprise dragging your legacy on-prem infrastructure into a provider’s data center via a “lift and shift.” Either way it’s important to realize that not only does the cloud not solve all your old cybersecurity problems, it can introduce its own new ones.
Take the lift-and-shift approach, for example. Recreating your physical networks and servers virtually does grant you massive resiliency against availability issues like bandwidth exhaustion and hardware failures.
That dead power supply is now Andy Jassy’s problem instead of yours.
But the traditional headaches remain. You still completely own the configuration, access control, authorization, and yes, you still have to patch the things.
Cloud-Native Security Advantages and New Risks
However, when organizations do move past simply renting virtual servers and embrace true cloud-native capabilities, there are some real defensive upgrades. Infrastructure as Code (IaC) allows security teams to deploy hardened, globally consistent security baselines via code rather than hoping a junior admin checked the right box on a physical firewall appliance.
The cloud also brings centralized telemetry, granting access to the kind of machine-learning-driven threat intelligence that only a hyperscaler can provide.
It even changes incident response. Instead of painstakingly patching and cleaning a compromised server, immutability allows you to simply kill the infected container and automatically spin up a fresh, secure image.
But these same capabilities introduce their own attack surfaces.
IaC pipelines from tools, like Terraform, CloudFormation, and Pulumi, are now critical security targets for attackers. A misconfigured module committed to a shared repository, or a compromised CI/CD pipeline with cloud deployment credentials can push insecure configurations to production at a scale and speed that would make a human blush. And centralized telemetry is only useful if someone is actually watching it. The sheer volume of cloud logs makes alert fatigue a genuine operational hazard, not merely a theoretical one.
Container immutability will only save you if the base image you’re spinning up is itself clean. A compromised image sitting in your registry means you’re not recovering from an incident; you’re starting it all over.
These are not arguments against going cloud-native. Rather, they are arguments for treating your DevOps toolchain with the same security rigor you apply to your production systems.
The Shared Responsibility Model
For organizations taking the cloud-native approach with pure SaaS and PaaS for business operations, it’s easy to think that you’ve solved your security problems by outsourcing the management of the backend systems to a third-party cloud provider.
But the reality is that whoever manages your operations and data, you are still responsible for protecting it.
Cloud services operate on a shared responsibility model, and it’s incumbent upon those responsible for their organization’s data and operations to understand where the providers’ responsibility ends and theirs begins.
Identity is the New Perimeter
With cloud, identity is the new perimeter.
The biggest threat isn’t a zero-day exploit against a hypervisor. It’s an overly permissive Identity and Access Management (IAM) role. In a traditional on-premises environment, a compromised set of credentials typically gives an attacker access to whatever systems that user could reach on the network.
In a cloud environment, a single over-privileged IAM role or service account can grant read access to every S3 bucket in your account, the ability to create new admin users, access to secrets stored in your secrets manager, and the power to spin up infrastructure in any region on earth.
Credential compromise, whether through phishing, leaked API keys committed to a public GitHub repo, or exposed instance metadata endpoints, is consistently among the top initial access vectors in our cloud breach investigations.
Shadow IT and the Classic Cloud Footgun
Furthermore, because provisioning requires nothing more than a browser and a credit card, developers can spin up massive shadow IT infrastructure entirely outside the security team’s purview.
A developer standing up a test environment in a personal AWS account, or a business unit purchasing a SaaS tool without going through IT, represents real organizational risk as those environments lack the same security controls as the company tenant.
Then there’s the classic cloud footgun: the public S3 bucket.
The provider secures the underlying storage hardware, but if you misconfigure the bucket to expose your customer database to the public internet, well cowpoke, that one’s on you.
Platform Complexity and Changing Defaults
Cloud platforms themselves have their own quirks and proclivities, especially around cybersecurity. They often change quickly and with little or no notice for you to adapt to. Many platforms experienced a roaring development cycle as their use exploded, leading to conflicting features and configurations, dangerous default settings, and above all, massive complexity.
I challenge anyone to be able to clearly explain the nuance of all the possible AWS security settings, configurations, and defaults to a new cloud user in an afternoon.
And that’s not even trying to map those onto other cloud platforms, like Azure or GCP.
The Hidden Risk of SaaS Integrations
The other attack surface most organizations don’t think about until it bites them is the sprawling ecosystem of third-party SaaS integrations. Every app your users connect to Microsoft 365, Salesforce, or Google Workspace gets an OAuth token with a persistent foothold in your environment. These tokens usually have more permissions than they actually need and often have no expiration date.
That developer productivity tool someone connected in 2021 and stopped using six months later? Yeah, it probably still has live read access to your email.
Multiply that by a few hundred users making their own integration decisions over several years and you have an attack surface nobody consciously built, and nobody is watching. The security posture of every one of those vendors, and every dependency in their stack, is now your problem whether you agreed to that arrangement or not.
Auditing your authorized OAuth applications, killing stale tokens, and enforcing a policy about what can connect to your core SaaS platforms without IT sign-off are not exactly exotic security practices.
This is table stakes that most organizations skip.
Attackers who’ve run out of easier doors to knock on have absolutely figured this out.
Navigating the Cloud Security Labyrinth
We didn’t retreat back to the heavily guarded, passive safety of the mainframe when the decentralized PC-era got messy. And we aren’t retreating from the cloud now. The benefits it offers are simply too valuable to the business.
But just as we had to invent the network firewall and endpoint detection to survive the microcomputing wild west, we have to completely rewire our security mindset to survive the cloud. The cloud can be a labyrinth of overlapping services, constantly shifting features, and terrifyingly complex IAM policies.
But the map to navigate it exists.
It starts with actually reading your provider’s Shared Responsibility Model instead of treating it like an iTunes Terms of Service agreement (which I honestly still have not read). It requires accepting that it’s more likely your own misconfigurations than elite nation-state hackers that are your biggest threat.
If you bring a physical firewall mindset to an API fight, you’re going to shoot yourself in the foot.
Learn the labyrinth, map your shared responsibilities, and for the love of God, check your default settings.
Need Help Navigating the Labyrinth?
The cloud’s labyrinth can be navigated, but only if organizations understand where the real risks live. If you need help mapping those risks and securing your environment, Let’s talk.