Five Steps to a Secure Cloud Architecture

Cloud computing cyberattacks don’t play out like the scenes from Hollywood thrillers. No one is slowly lowering Tom Cruise into a preselected target’s secure data center equipped with ultrasensitive noise, temperature and motion detectors so he can steal a specific file.

The real-life script is much more pedestrian. Attackers sit at their laptops and deploy automation technologies to scan the internet looking for vulnerabilities to exploit. They choose which target to exploit, “go shopping” for sensitive data like personally identifiable information (PII), and extract it in minutes, often from object storage services or database snapshots. 

Sounds simple and easy to defend, yet according to the 2021 edition of the annual Verizon Data Breach Investigations Report (DBIR), “external cloud assets were more common than on-premises assets in both incidents and breaches.”

Attackers don’t traverse traditional networks that security teams can monitor with conventional intrusion detection and prevention solutions and processes. Enterprises are trying to thwart today’s attackers with yesterday’s security technologies and don’t have a complete understanding of the cloud threat landscape.

Too often, the focus is on identifying resource misconfigurations that attackers can exploit to gain entry into an environment and analyzing log events to identify suspicious activity “indicators of compromise” (IOC). These could be changes in IAM configurations to escalate privileges, turning off encryption to access data, or logging to cover one’s tracks. All are necessary activities for any cloud security effort. But misconfigurations represent only one of the paths a hacker can take to achieve control plane compromise, which has played a central role in every significant cloud breach.

Devoting so much time and energy to finding and eliminating single resource misconfigurations won’t provide the answer to the question, “What happens when they slip through and get exploited?” Because rest assured, they will.

No enterprise cloud environment is free of misconfigurations. Cloud security teams often find and remediate dozens — or hundreds — every day. Focusing solely on identifying IOCs is even riskier; cloud breaches can happen in a matter of minutes before teams have a chance to respond, even with the best monitoring, analysis and alerting tools.

A New Threat Landscape

Developers and engineers use code to build their cloud infrastructure, making and changing their infrastructure decisions, including security-critical configurations, in real time as they work. They use the application programming interfaces (APIs) to make or destroy servers and make or access storage. Every change creates the risk of a misconfiguration left open to attack.

The control plane is the API surface that configures and operates the cloud. For example, you can use the control plane to build a container, modify a network route, and gain access to data in databases or snapshots of databases (which are more popular among hackers than breaking into live production databases). In other words, the API control plane is the collection of APIs used to configure and operate the cloud.

Application programming interfaces — the software “middlemen” that allow different applications to interact with each other — drive cloud computing. They eliminate the requirement for a fixed IT architecture in a centralized data center. It also means attackers don’t have to honor the arbitrary boundaries enterprises erect around the systems and data stores in their on-premises data centers. A cloud attack could begin with an app vulnerability that network intrusion detection tools will never identify.

Protect the Control Plane

There are five steps any organization can take to design its cloud environments to be inherently secure against control plane compromise attacks:

1. Minimize control plane compromise risk. Broaden the definition of “cloud misconfiguration” beyond single resource misconfigurations to include architectural misconfigurations — those that involve multiple resources and how they relate to each other.
   
   For existing cloud environments, assess the blast radius of any potential penetration event by analyzing resource access policies and identity and access management (IAM) configurations to identify overly permissive settings that attackers can exploit for discovery, movement and data extraction. When you find them — and trust me, you will find them — work with your developers and DevOps teams to eliminate these architectural misconfigurations without breaking the applications. That may require some rework to address these vulnerabilities in existing environments, so it’s better to address architectural security in the design and development phases.
2. Adopt policy as code for cloud infrastructure. Policy as code (PaC), such as Open Policy Agent, the open source standard the Cloud Native Computing Foundation sponsors, is a means of expressing policy in a language that machines can understand.
   
   In a software-defined world, security’s role is that of the domain expert who imparts knowledge to the people building stuff — the developers — to ensure they’re working in a secure environment. Remember, it’s the developers who build applications in the cloud and the infrastructure for the applications. It’s all done with code, so the developers, not the security team, own the process. PaC enables developers to express security and compliance rules in a programming language that an application can use to check the correctness of configurations and identify unwanted conditions or things that should not be.
   
   Empowering all cloud stakeholders to operate securely without any ambiguity or disagreement on what the rules are and how they should be applied serves to align all teams under a single source of truth for policy, eliminates human error in interpreting and applying policy, and powers security automation (evaluation, enforcement, etc.) at every stage of the software development life cycle (SDLC).
3. Empower developers to build secure cloud environments. Gone are the days when IT teams would provision physical infrastructure and provide it to developers. Today, developers and DevOps engineers use infrastructure as code (IaC) to express the infrastructure they want and provide it automatically.
   
   While this is great for efficient cloud ops, it increases the risk of propagating vulnerabilities at scale. However, IaC adoption gives us an opportunity we didn’t have before: the ability to check infrastructure security pre-deployment. With PaC, we can provide developers with tools to check security as they develop it and guide them toward designing inherently secure environments that minimize control plane compromise threats.
4. Use guardrails to prevent misconfiguration. No matter how successful you are at “extending” cloud security left with IaC checks and more secure design, misconfigurations can still slip through, and post-deployment mutation of cloud resources is a constant risk.
   
   You should build automated security checks into your continuous integration and continuous delivery (CI/CD) pipeline to automatically catch misconfiguration during the deployment process and fail a build automatically if it fails security checks. For less sensitive deployments, alert teams to violations so they can investigate and remediate if necessary. Because post-deployment change to cloud resources is pervasive, maintaining continuous monitoring to detect drift is critical. Ensure that what’s running reflects the IaC templates that created it, and check for dangerous misconfiguration events and orphaned resources that can contain vulnerabilities. In all of these use cases, your adoption of PaC will continue paying dividends.
5. Build cloud security architecture expertise. The increasing rate of enterprise cloud adoption requires security professionals to shift their focus away from traditional security approaches such as threat detection and monitoring network traffic to understand how control plane compromise attacks work and how to use secure architecture design effectively to prevent them.

The ultimate goal for securing cloud environments is to render any successful initial attack penetration event moot before it occurs. After all, who cares if an attacker gains access to a resource in an enterprise’s cloud environment if there’s nothing they can gain from it?

Charge your security team with learning how cloud applications work to help ensure cloud infrastructure supports the applications without introducing unnecessary risks. They also need to know how to leverage PaC to check environments for deeper multi-resource vulnerabilities and help guide developers to design and build inherently secure environments.