The first thing we need to understand is where exactly the cloud provider’s responsibilities end, and yours, as a customer, begin. These responsibilities can further vary depending on the type of cloud service tier ( IaaS, PaaS, or SaaS) you are using. We discussed all three tiers in detail in Chapter 2, Choosing the Right Cloud Service. For example, when running your applications in EC2, patching thesecurity vulnerabilities or upgrading the AMIs is your responsibility. But the same is not true if your code is deployed on Lambda, in which case the security of the underlying compute infrastructure sits with AWS. The cloud provider is responsible for the security of the cloud, and the customer is responsible for security in the cloud. To explain this further, if a hypervisor vulnerability allows another AWS user to gain unauthorized access to your EC2 instance, then this is a lapse of AWS’ security. On the other hand, misconfigured security groups allowing unrestricted SSH access to an EC2 instance in AWS are the customer’s fault. I would recommend going through the AWS shared responsibility resource to dig deeper into the details: https://aws.amazon.com/compliance/shared-responsibility-model/.

For software applications, the risks are more or less the same if you are running your workload on-premises or in the cloud. However, something that does change is the processes and solutions to address those risks. AWS offers several services that can help you secure the network, data, and identity and access management. Considering our example of an internet-facing web application, you could transfer your risks of managing a self-hosted load balancer to AWS Elastic Load Balancer with web application firewall integrations. Extracting the frontend API logic from the code base and migrating to API Gateway transfers your risks to the cloud provider, and modernizing a traditional static website and hosting it on CloudFront with no servers to manage eliminates your risks. So, it’s important to understand what exactly needs to be secured.

Once the responsibilities have been clarified, the second problem teams run into is how to manage their risks.

Identifying and prioritizing the risks

Software teams often begin by securing parts of the application architecture that they are most familiar with. This can sometimes hide other risks, potentially with a higher probability of occurrence. A good way to understand (or raise Awareness, as defined in the AEA framework) your risk exposures is to begin with a threat modeling process.

Threat modeling is an assessment that outlines the risks that currently deployed resources are exposed to, and what their priorities are based on respective criticalities. With the evolution of application architecture, these risks will also keep on changing, and so should the mitigations. Threat modeling

is sometimes seen as a one-time activity that’s conducted in the later stages of the software delivery process, before a go-live. This should be avoided as per DevSecOps methodologies, which promote the idea of building security practices right into the development life cycle. So, it makes a lot of sense to involve security team members during the design phase of the application so that the risks are surfaced as soon as possible. In the early stages of development, it is also less costly for the developers to fix an architectural approach that has security implications.

For an internet-facing web application, here are some examples of potential risks:

• Distributed Denial of Service (DDoS) attacks

• A user breaching the multi-tenant boundaries of the application to extract data belonging to other users

• SQL injection and cross-site scripting attacks

A threat modeling exercise in this case should consider the probability of each of these risks’ occurrence and suggest steps for mitigation. Organizations with mature DevSecOps practices further ensure that their threat modeling process is a recurring activity. This ensures that a goodsecurity posture is verified not only during the first production release, but constantly evaluated, and optimized, against new risks and exposures.

Tip

OWASP Top 10 is a good resource for understanding different types of web application security issues your applications could run into. As part of your threat modeling activities, you can consider evaluating your workloads against these risks as a starting point: https://owasp. org/www-project-top-ten/.

Not all risks stem from the proprietary code written by software developers. A large number of the vulnerabilities come from the dependencies and open source libraries consumed by these projects. The 2022 State of Open Source Security report from Snyk and Linux Foundation states the following:

“The average application development project has 49 vulnerabilities and 80 direct dependencies, and the time it takes to fix vulnerabilities in open source projects has steadily increased, more than doubling from 49 days in 2018 to 110 days in 2021.”

Even though these numbers reflect the state of open source projects, they speak a lot about the need for continuously scanning any untrusted code and surfacing the vulnerabilities as soon as possible. Let’s discuss some test strategies you could consider.