In the age of on-premises data centers and early cloud adoption, the roles of application developers, infrastructure operators, and security have largely fallen into disrepair. In the cloud, this division of labor increases time to market for innovation reduces productivity, and leads to unnecessary risk.

In a data center environment, developers create software applications, IT teams create the infrastructure needed to run those applications, and security teams are responsible for ensuring the security of those applications. applications and infrastructure. Developers must build software within the confines of the underlying infrastructure and operating system, and security processes dictate the speed of each. When security discovers a vulnerability in production, the remediation process typically involves all parties involved and substantial rework.

By freeing teams from the physical constraints of the data center, the cloud is bringing the biggest change to the IT industry in decades. But it took years for companies to start unlocking the true potential of the cloud as a platform to build and run apps, rather than use it as a platform to host third-party applications. three or migrated from the data center. When the cloud is simply used as a “remote data center”, the classic division of labor is retained and much of the cloud’s potential is untapped.

But moving to the cloud as a platform to build and run applications has profound security implications. From a cloud customer perspective, platforms like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud are 100% software-based, and developers now program the creation and management of cloud infrastructure. their cloud as part of their applications. This means that developers design their cloud architecture and define security-critical configurations, then continually modify them.

An opportunity for organizations

This shift represents a huge opportunity for organizations operating in highly competitive industries, as cloud and application teams can innovate much faster than they can in one. data center. But this poses a serious challenge for teams that need to secure increasingly complex and highly dynamic cloud environments.

The only effective way to approach cloud security today is to provide developers with building and operating in the cloud tools that help them do it securely. Failure to do so makes security a limiting factor in how quickly teams can move into the cloud and the success of the digital transformation.

To understand what it means to hold developers accountable for cloud security, we need to define what it means to be a developer. It’s a broad umbrella that covers a variety of roles, including:

• Application developers build in the cloud and leverage cloud-native services as an embedded component of their applications. In this model, the boundary between application and infrastructure is arbitrary and blurs or even disappears altogether.
• Cloud engineers (i.e., developers) use infrastructure as code (IaC) to programmatically set up, deploy, and manage the cloud infrastructure environment and provision the infrastructure. It’s for cloud developer apps.
• Cloud security engineers use policy as code (PAC) to express security and compliance policy in language that other applications can use to automate security claims and sell messages this PAC institute for teams across the organization.

Regardless of their job description, developers are in control of the cloud infrastructure themselves, because the cloud is completely software-defined. When they build apps in the cloud, they also build the application infrastructure using IaC, and the developers own the process.

Security and compliance policy as code

This means that the role of the security team has evolved into that of a domain expert who imparts knowledge and rules to developers to ensure that they are working in a secure environment. whole. Instead of expressing these rules in human language for others to understand and interpret, they use Pac, which checks other runtime and code environments for unexpected conditions. Pac allows all cloud stakeholders to operate securely without ambiguity or disagreement about the rules and how to apply them at both ends of the software development lifecycle (SDLC).

Organizations that are already well versed in cloud security are advocating adopting the DevSecOps model and empowering developers to ensure application security after deployment. IDC predicts that an increasing number of developers (more than 43 million by 2025) will hold themselves accountable for the continued performance and security of their code while the code is running.

For a long time, applications have been involved in an SDLC that includes the build, test, deploy, and monitor phases. The “left shift” movement in application security has provided a significant return on investment in speed, productivity, and security because it is easier to fix issues earlier in the life cycle day, faster, and safer. With the adoption of IaC, the cloud infrastructure now has its own SDLC, which means that cloud security can and should also be addressed in the pre-implementation stages. The number one concern about cloud security is misconfiguration, but it’s important to realize that misconfiguration is anything in your cloud environment that isn’t effective at stopping hackers. We are best aware of the unique resource misconfigurations that are often highlighted in the media about cloud breaches, such as leaving a malicious port open or allowing public access to a service. object storage. But misconfiguration also involves misconfiguration of the entire environment and architectural vulnerabilities that give attackers the right to detect, move, and extract data.

Every major cloud breach involves exploiting these design flaws in a cloud environment or affecting the control plane. The control plane is the cloud operating and configuration API surface. For example, you can use the control plane to create containers, modify network routes, and access data in databases or database snapshots. (Access to snapshots is more common for hackers than breaking into production databases directly.) In other words, the API control plane is the set of APIs used to configure and operate the cloud.

APIs drive cloud computing. They eliminate the need for a fixed IT architecture in a centralized data center. The API also means that attackers don’t have to respect the arbitrary boundaries that companies erect around systems and data warehouses in their on-premises data centers. While identifying and addressing misconfigurations is a priority, it is important to understand that misconfigurations are only one way to an end for attackers: compromise on the control plane. This has played a central role in all major cloud breaches to date.

Empowering developers to secure 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:

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

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