Why Developers Hold the Key to Cloud Security
Josh Stella, vice president and chief architect at Snyk, the leader in developer security, explains why the responsibility for cloud security rests with developers and DevOps teams, not IT security.
In the days of the on-premise data center 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.
In a data center environment, developers build software applications, IT teams build the infrastructure needed to run those applications, and security teams are responsible for ensuring 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 bringing the biggest shift in 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 the 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.
Recommended AI News: Leavened Announces New ConfigAI Feature
But 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 shift represents 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.
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 what it means to empower developers on cloud security, we need to define what we mean by developer. It’s a broad umbrella that covers several different roles, including:
- Application developers that are building in the cloud and are 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 instead using IaC, and developers own that process.
That means the security team’s role has evolved to become that of the domain expert who imparts knowledge and rules to the developers to ensure they work in a secure environment. Rather than express those 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 on the rules and how to apply them at both ends of the software development life cycle (SDLC).
Organizations that get cloud security right champion the embrace of the DevSecOps model and enable developers to ensure the security of applications post-deployment. IDC predicts an increasing number of developers (who will number over 43 million by 2025) will find themselves fully responsible for the ongoing performance and security of their code once it’s running.
For quite some time, applications have involved a software development life cycle, which 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 is anything in your cloud environment that proves ineffective at stopping a hacker. 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 also involve misconfiguration of 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 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.
Recommended AI News: MobileFuse Achieves Carbon Negative Status, Commits to Ongoing Reductions
APIs 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. 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.
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:
- 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 a hacker to identify control plane compromise risks.
- Prioritize secure design and prevent misconfiguration. Once a control plane compromise attack is underway, it’s generally 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 get deployed, and focus on designing inherently secure environment architectures.
- Empower developers with tools that guide them on security. Developers are moving fast, and any security tooling needs to work the way they work if we expect adoption without impacting velocity. Cloud security tooling should provide developers with useful, actionable feedback on security issues and how to remediate them quickly so they can move on with their work.
- 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 serves to align 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.
- Focus on measurement and process improvement. Cloud security is less about intrusion detection and monitoring networks for nefarious activity, and more about improving the processes of cloud security to prevent 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.
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. Automation built on PaC removes the risk of human error by automating the process of constantly searching for and catching mistakes before they get deployed.
[To share your insights with us, please write to email@example.com]