Why developers hold the key to cloud security

SnykSec - Nov 14 '22 - - Dev Community

In the days of on-prem data centers and early cloud adoption, the roles of application developers, infrastructure operations, and security were largely siloed. In the cloud, this division of labor increases the time-to-market for innovation, reduces productivity, and invites unnecessary risk.

The security disruption from data center to cloud

In a data center environment, developers build software applications, IT teams build the infrastructure to run those applications, and security teams ensure that applications and infrastructure are secure. Developers must build software within the constraints of the underlying infrastructure and operating systems, and security processes dictate how fast everyone can go. When security discovers a vulnerability in production, the remediation process typically involves all stakeholders — and considerable rework.

By freeing teams of the physical constraints of the data center, the cloud is causing the biggest shift that’s happened to the IT industry in decades. But it’s taken years for organizations to start unlocking the true potential of the cloud as a platform for building and running applications, as opposed to using it as a platform for hosting third-party applications or those migrated from a data center. When the cloud is used simply as a “remote data center,” the classic division of labor is carried over, and much of the potential of the cloud goes unrealized.

The shift to using the cloud as a platform for building and running applications is disrupting security in profound ways. From the perspective of the cloud customer, platforms like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud are 100% software, and developers are now programming the creation and management of their cloud infrastructure as an integral part of their applications. That means developers are designing their cloud architecture and setting security-critical configurations — and then changing them constantly.

This creates a massive opportunity for organizations operating in highly competitive industries, because application and cloud teams can innovate much faster than they could in a data center. But it presents a serious challenge for those teams that need to ensure the security of increasingly complex and highly dynamic cloud environments.

Empowering developers must be a top priority

The only effective way to approach cloud security today is by empowering the developers building and operating in the cloud with tools that help them proceed securely. Failing to do so makes security the rate-limiting factor for how fast teams can go in the cloud and how successful digital transformation can be.

In order to understand how to empower developers on cloud security, we need to define what we mean by developer. It’s a broad term that covers several different roles, including:

  • Application developers who are building in the cloud and leveraging native cloud services as integral components of the application. In this model, the boundary between application and infrastructure is arbitrary and blurring, if not disappearing altogether.
  • Cloud engineers (i.e., DevOps) who are using infrastructure as code (IaC) to program the configuration, deployment and management of cloud infrastructure environments and deliver that infrastructure to application developers.
  • Cloud security engineers who use policy as code (PaC) to express security and compliance policies in a language that other applications can use to validate security automatically and vend these PaC libraries to teams throughout the organization.

No matter their job descriptions, developers control the cloud computing infrastructure itself because the cloud is fully software-defined. When they build applications in the cloud, they’re also building the infrastructure for the applications using IaC, and they own that process.

This means the security team’s role has evolved to that of the domain experts who impart knowledge and rules to the developers to ensure a secure development environment. Rather than expressing those rules in a human language for others to understand and interpret, they use PaC, which checks other code and running environments for unwanted conditions. PaC empowers all cloud stakeholders to operate securely without ambiguity or disagreement about rules and how to apply them at both ends of the software development life cycle (SDLC).

Organizations that get cloud security right champion the DevSecOps model and enable developers to ensure the security of applications post-deployment.IDC predicts an increasing number of developers (who will equal over 43 million by 2025) will find themselves fully responsible for the ongoing performance and security of their code once it’s running.

Cloud misconfigurations are vulnerabilities

For quite some time, applications have involved a software development life cycle that includes creation, test, deployment and monitoring phases. The movement to shift left on application security has generated significant ROI in terms of speed, productivity and security because it’s easier, faster and safer to fix issues earlier in the SDLC. With the adoption of IaC, cloud infrastructure now has its own SDLC, which means cloud security can, and should, also be addressed in pre-deployment phases.

The primary concern with cloud security is misconfiguration, but it’s important to recognize that a misconfiguration can be anything in your cloud environment that is ineffective at stopping malicious actors. We’re most familiar with the single-resource misconfigurations that are often highlighted in news coverage of cloud breaches, such as leaving a dangerous port open or enabling public access to an object storage service. But they misconfigurations can also involve the entire environment — the architectural vulnerabilities that give attackers the power of discovery, movement, and data extraction.

Every major cloud breach involves exploits of these design flaws in cloud environments — or control plane compromise. 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 databases or snapshots of databases (and snapshots are more popular among attackers than live production databases). In other words, the API control plane is the collection of APIs used to configure and operate the cloud.

APIs drive cloud computing. They eliminate the requirement for a fixed IT architecture in a centralized data center. This means attackers don’t have to honor the arbitrary boundaries enterprises erect around the systems and data stores in their on-premises data centers. While identifying and remediating misconfigurations is a priority, it’s essential to understand that misconfigurations are just one means to the ultimate end for attackers: control plane compromise, which has played a central role in every significant cloud breach to date.

5 steps for supporting secure development in the cloud

Empowering developers to find and fix cloud misconfigurations when developing IaC is critical, but it’s equally important to give them the tools they need to design cloud architecture that’s inherently secure against today’s control plane compromise attacks.

There are five steps any organization can take to effectively empower developers to operate securely in the cloud:

1. Understand your cloud environment and SDLC

Security teams should embed engineers with application and DevOps teams to understand everything that’s running, how it’s configured, how it’s developed and deployed, and changes when they happen. You should know what applications are associated with cloud resources, along with any data and how it’s used. Think like an attacker to identify control plane compromise risks.

2. Prioritize secure design and prevent misconfiguration

Once a control plane compromise attack is underway, it’s usually too late to stop it. Effective cloud security requires preventing the conditions that make these attacks possible. Bake security into the entire cloud SDLC to catch misconfigurations before they’re deployed, and focus on designing inherently secure environment architectures.

3. Empower developers with tools that guide them on security

Developers move fast, and any security tooling needs to work the way they work if we want adoption without reducing velocity. Cloud security tooling should provide developers with useful, actionable feedback on security issues and how to remediate them quickly.

4. Adopt policy as code for cloud security

PaC helps security teams scale their effort with the resources they have by empowering all cloud stakeholders to operate securely without any ambiguity or disagreement on what the rules are and how they should be applied. It aligns all teams under a single source of truth for policy, eliminates human error in interpreting and applying policy, and enables security automation (evaluation, enforcement, etc.) at every stage of the SDLC.

5. Focus on measurement and process improvement

Cloud security is less about intrusion detection and monitoring networks for nefarious activity and more about preventing exploits from happening. Successful cloud teams continuously score the risk of their environment as well as the productivity of developers and security teams, which should improve as manual, error-prone tasks are automated.

Cloud security starts with developers

Developers are in the best (and often only) position to secure their code before deployment, maintain its integrity in production, and understand where to provide fixes. But they’re also human beings prone to mistakes, operating in a world of constant experimentation and failure. Automation built on PaC removes the risk of human error by automating the process of searching for and catching mistakes before deployment.

Organizations that embrace a developer-first approach to cloud security will innovate faster and more securely than their competitors.

Empower your developers

See how Snyk Cloud can help your developers manage cloud security.

Try it for free

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .