Scaling Cloud Security with Policy as Code
How can enterprise scale cloud security with policy as code?
The cloud presents significant new challenges for security teams. Josh Stella, VP and chief architect at Snyk, discusses how enterprises could use policy as code to scale and improve cloud security in an environment riddled with threat actors and dynamic tech evolution.
The threat surface is radically different with the cloud, and hackers have adapted their tactics accordingly. Before taking steps like implementing new security products or establishing new security policies and processes, it’s critical to understand your organization’s unique cloud environment and the threats against it.
A New Security Threat Landscape
Before the advent of cloud computing, when the on-premises data center was king, there was a clear separation of roles and responsibilities in enterprise IT: Developers built software applications, infrastructure teams provisioned the physical infrastructure to run those applications, and the security team was responsible for certifying everything was secure and that it stayed that way.
That old model was time-consuming and costly, requiring a complicated budget process, a large team, and months to build and secure a complex network. It also inevitably led to a lot of friction when security deemed it necessary to constrain developers’ work and users’ behavior, delaying deployments in order to validate security and frequently interrupting the software development cycle to perform security checks.
The cloud obviates many such tedious processes, but it comes with a trade-off: a new security paradigm where the responsibility for protecting the environment in which developers work no longer rests solely on the security team’s shoulders. And that’s a good thing.
Developers control the cloud computing environment itself because cloud infrastructure is software-defined and on-demand. Building the cloud infrastructure at the same time they are building the applications enables developers to work autonomously and within their own time frame.
Software developers and cloud engineers are using infrastructure as code (IaC) to construct and modify the cloud environments they work in, including setting security-critical resource configurations. They use their cloud providers’ application programming interfaces (APIs) to make, update and destroy virtual machine instances, virtual networks, and data stores. Every single time they make a change, they increase the risk of inadvertently creating a misconfiguration that bad actors can exploit.
The common thread that runs through all major cloud breaches is that the attackers were successful in their efforts to compromise the cloud provider’s control plane, which is the API surface developers use to configure and operate in their cloud environments. Gaining access to the resource API keys enables attackers to operate against the control plane.
Cloud breaches result from attackers exploiting design flaws; cloud security requires gaining and applying knowledge on how to mitigate those flaws effectively.
See More: Keep Your Cloud Secure: A Fitness Routine for Your Cloud Environment
Attackers Are a Step Ahead
Here’s a breakdown of a typical successful cloud attack: An attacker with a laptop uses automation tools to scan the internet looking for vulnerabilities to exploit, which may be cloud misconfigurations, app vulnerabilities, or API keys left unsecured. What they get back is essentially a “shopping list” of targets to choose from. Previously, an attacker would choose their target and then search relentlessly for vulnerabilities to exploit. In the cloud, the existence of a vulnerability can put a target on their back.
And traditional security tools don’t fully cover the cloud because cloud exploits don’t typically traverse traditional networks that security teams can watch with conventional intrusion detection and network monitoring tools.
Security often focuses solely on identifying resource misconfigurations that attackers can exploit to gain entry into an environment, which means they need to get it right 100% of the time — when attackers only need to get lucky once. Teams must ask, “What happens when they slip through and get exploited?” Because rest assured, they will.
Security’s Changing Role
It’s not feasible to eliminate 100% of the misconfigurations in an enterprise cloud environment. While cloud security teams have made remediating misconfigurations a priority, it’s important to understand they’re not the only avenue attackers can travel to compromise the control.
Forward-thinking enterprises embrace the DevSecOps model and empower developers to ensure the security of applications and infrastructure pre-deployment. The first step any security team should take along those lines is to arm them with policy as code (PaC). As the name suggests, it enables developers to use programming languages to create security and compliance rules that allow applications to automatically confirm configurations are correct throughout the software development life cycle (SDLC).
A Cloud Security Imperative
Additionally, PaC eliminates ambiguity and disagreements on translation and interpretation — aligning all stakeholders under a single source of truth on cloud security policy and helping everyone move faster and more securely. Security teams can “vend” their knowledge to the rest of the organization and ensure policies are consistently applied, enforced and reported on.
Benefits of Open Source PaC
PaC allows both the security vendor and the customer to craft whatever is needed over time, just like any other code-writing process. Open source PaC options are available to address today’s cloud security use cases and can be integrated with existing toolchains and security products.
Security solutions vendors love locking you into their proprietary ecosystems, and they do that by requiring that every line of code you write uses their proprietary languages for PaC (although it’s usually not true PaC). That means even if you grow unhappy with them, you’re unlikely to leave because all your work has been in a language incompatible with other vendors’ solutions.
Embrace the opposite philosophy. Write code that has value to you, not to your vendors. Your PaC should be an asset that you own, not a boat anchor that chains you to a vendor. This is where turning to an open source platform is invaluable.
Developers are in the best (and often only) position to secure their code before deployment, maintain its secure integrity while running, and better understand the specific places to provide fixes back in the code. But they’re also human beings prone to mistakes, operating in a world of constant experimentation and failure. PaC greatly reduces the risk of human error by automating the process of constantly searching for and catching mistakes before they become dangerous.
Have you benefited from open source policy as code, or were there specific challenges involved? Tell us all about it on Facebook, Twitter, and LinkedIn.
MORE ON CLOUD:
Image Source: Shutterstock
