Five steps to a secure cloud architecture

Policy as code is central to establishing and maintaining secure cloud architecture by enabling security teams to impart their knowledge across the organization in a common, machine-readable language.

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. What they get is a virtual "shopping list" of targets to choose from, and once in a cloud environment, they leverage architectural weaknesses to find 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 against, yet according to the just-released 2022 edition of the annual Verizon Data Breach Investigations Report (DBIR), "The rise of the misconfiguration error began in 2018 and was largely driven by cloud data store implementations that were stood up without appropriate access controls… Despite the efforts of the major cloud providers to make the default configurations more secure (which we applaud), these errors persist."

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 cloud attackers with yesterday’s data center 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 identity and access management (IAM) configurations to escalate privileges, turning off encryption to access data, or logging to cover one’s tracks. These are necessary activities for any cloud security effort, but ultimately they’re not enough to keep cloud data secure. Misconfigurations represent only one of the paths a hacker can take to gain entry to a cloud environment and compromise the API control plane, which happens in nearly 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 access to the control plane?" Because be assured, sooner or later, 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 to stop attacks in progress 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, you can only count on quickly discovering you were hacked.

A New Threat Landscape

Developers and engineers are increasingly using infrastructure as code (IaC) that operates against the cloud provider’s application programming interfaces (APIs) to build and modify their cloud infrastructure, including security-critical configurations, in real time as they work. Change in the cloud is a constant, and every change brings risk of a misconfiguration vulnerability that attackers can exploit quickly using automated detection.

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 a more popular target for 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.

Minimizing the potential blast radius of any successful cloud penetration event means protecting against control plane compromise in architectural design of the environment.

Five Steps to a Secure Cloud Architecture

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. It’s time to broaden your 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 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 and Cloud Native Computing Foundation project, 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. Not with rulebooks or checklists, but with code. 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 teams 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 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. Everyone can move faster and more securely.

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 runtime 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.

In order to do this, organizations need cloud security engineers and architects who can work closely with developers and DevOps teams to understand cloud use cases and help establish secure design principles in the development process.

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.

Image credit: jirsak / depositphotos.com

Josh Stella is chief architect at Snyk and a technical authority on cloud security. Josh brings 25 years of IT and security expertise as founding chief technology officer at Fugue, principal solutions architect at Amazon Web Services, and advisor to the U.S. intelligence community. Josh’s personal mission is to help organizations understand how cloud configuration is the new attack surface and how companies need to move from a defensive to a preventive posture to secure their cloud infrastructure. He wrote the first book on “Immutable Infrastructure” (published by O’Reilly), holds numerous cloud security technology patents, and hosts an educational Cloud Security Masterclass series. Connect with Josh on LinkedIn and via Fugue at www.fugue.co.