Mastering the Shared Responsibility Model

It’s no secret that cloud-native application development is growing exponentially, with Agile development, IaaS and PaaS from providers like Amazon, Microsoft and Google, enabling innovation at a pace that is challenging for security to keep up with. 

A global pandemic and the resulting remote work mandates have only accelerated this movement. And with this change in distributed work and agile application development comes greater security considerations—and a higher degree of risk to the business. Security in the cloud is a shared responsibility, but too many organizations find it difficult to fully understand their role in the security of their applications. There are many elements of securing cloud-native applications that cannot be delegated. They require careful attention as part of a risk-based application security program that extends from design to development throughout their application development life cycle.

With the appropriate visibility, risk-based thinking and automation, cloud-native applications have the ability to be more secure than ever, while enabling faster development and delivery at the same time. But to get to this point, organizations need to understand their responsibilities. 

Cloud infrastructure security and compliance are necessities for ensuring how applications and data are deployed and operated in the cloud. But what about what is in those applications? Applications are made up of lines of application/infrastructure code and open source libraries built by developers, DevOps, product managers, security champions and other roles. 

How do we know the components that make up the application are effectively secured? It is too late and not enough to solely rely on a secure cloud posture. Reducing risk early in the development lifecycle will dramatically reduce costs and business risk. Some sources have assessed the cost impact of fixing a risk in early production to be four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase.

Modern applications are delivered through sophisticated “plumbing” of secure cloud infrastructure to our device interfaces. Just as we require clean and safe water to transit the physical plumbing into our homes, we need our applications to remain secure and high-quality as they transit cloud services.

The IaaS/PaaS Shared Responsibility Model

The best way to think about security in this cloud-native world is by using a shared responsibility model, with IaaS customers only responsible for certain elements of the security of an application that lies on top of the infrastructure. 

In the traditional shared responsibility model, IaaS vendors are responsible for the configuration, management and security of infrastructure elements such as networking, databases and compute engines, in addition to physical security, redundancy and more. But each of their customers is responsible for the security and privacy of everything on top of that, from design to code to deployment.

The Traditional IaaS/PaaS Shared Responsibility Model

The Customer Side of the Shared Responsibility Model

What’s missing from this model are software design, code risk and CI/CD security and integrity—and these areas are the most difficult, time-consuming and require a well-thought-out and comprehensive application security program.

With new approaches to application security, organizations can better understand the risk of their cloud-native applications and automate a significant amount of risk remediation activities at the design or coding phases before deploying to the cloud. This requires taking a broad but contextual view of AppSec across the entire SDLC—and the modern nature of attacks requires a complete view of the SDLC to understand where the most impactful business risk lies.

Organizations must evaluate the full picture of their risk—from design to code to cloud:

1. Visibility—Understanding your risk starts with visibility into your security and compliance risks with a real-time inventory of assets, application and infrastructure code behavior, developer knowledge, third-party security alerts, sensitive data and business impact.
2. Secure by Design—You need to make sure that security is addressed at the design stage—before any code has been written or committed.
3. Change Management—Organizations need to focus on the risks that matter early in the development process and based on business impact. Material changes to the applications and infrastructure should be carefully evaluated while other changes can be approved more quickly or ignored, thereby accelerating product delivery.
4. CI/CD Security and Integrity—As an ever-running, highly-trusted and sensitive process, CI/CD is often overlooked. Many attacks in the recent past exploited this Achilles’ heel of the development cycle by embedding attackers’ code within native code commits or other automatic CI/CD processes. Organizations should ensure CI/CD operations are secure with integrity and security checks in place.
5. App & Infra Risks Together—To properly secure your applications, you must correlate the risks of your applications and infrastructure in one platform.
6. Automation—Automation must also be employed to limit mistakes caused by human error, ensure consistency in enforcement of policies and increase the speed of the DevSecOps process. Organizations must carefully manage this process, because automation can also introduce a new category of issues, such as race conditions, untimely triggering, incomplete state validation for edge cases, etc.

Infrastructure-as-Code (IaC)

The human element of risk has changed with IaaS and PaaS due to the power that cloud administrators now have. Instead of purchasing, configuring and deploying servers over a period of months, an admin can spin up a Kubernetes cluster or an S3 storage bucket, load customer data and expose it to the Internet with relevant identity and access management (IAM) policies in record time via infrastructure-as-code (IaC) using GitOps instead of ClickOps.

The rise of IaC has enabled us to view, evaluate and respond to infrastructure changes in the same way we would any application code change. Organizations must apply the same governance rules and automation to review changes in infrastructure before they reach production, along with real-time analysis of cloud misconfiguration. 

The main challenge is context! All IaC tools in the market today are looking at security misconfiguration as a single dimension (for example, an S3 bucket missing encryption; a cloud database missing SSL for incoming connections, etc.) and this creates a lot of noisy alerts. The risks of cloud infrastructure and the applications that run on top of it are inherently connected—it is harder to connect the dots and understand the true risk of changes than it is to accept alerts at face value!

When securing your applications in the cloud, don’t rely on traditional tools and processes. Today’s technologies enable new approaches that help you understand and remediate risk in entirely new ways and make cloud-native applications more secure than ever.