Threat modeling cloud applications in AWS, Azure, and GCP

In a cloud-first world, platforms like Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP) provide organizations with unprecedented flexibility and scalability. However, this expanded flexibility can also open the door to a wider range of security threats.

So, how can you anticipate these threats?

In this blog post, we’ll explore the importance of threat modeling in cloud environments, discuss how it helps drive application security across teams, and show how tools like ThreatCanvas can streamline this process.

What is threat modeling?

Threat modeling aims to proactively identify vulnerabilities, allowing teams to anticipate potential risks before they reach production. In cloud environments, where configurations and dependencies can be constantly changing and updating, this proactive approach becomes even more critical.

Traditional threat modeling is usually performed by security teams or designated security experts within development teams and often relies on manual processes. This is a time-consuming process, and it can oftentimes struggle to keep pace with the dynamic nature of cloud environments.

It aims to proactively identify and assess potential vulnerabilities in a given context and give developers and security experts the guidance needed to address them. By understanding the potential threats and their impacts before they are in production, organizations can get ahead with the right mitigation techniques.

Why use threat modeling?

As applications and environments grow more varied and cloud-based deployments become the norm, identifying potential threats becomes increasingly complex.

This means a more structured approach is required to find and remediate threats. With threat modeling, teams can model an application, environment, or feature and plan how to address potential threats before they have the chance to arise.

Ideally, threat models should be created before committing any code and during the design stages at the start of any new project. They should also be revisited regularly—especially when your cloud infrastructure or application features evolve beyond the original design.

Threats within AWS, Azure, and GCP

In AWS, services such as AWS Lambda, S3, and RDS need more attention paid to them to ensure permissions are configured correctly and encryption is being used. Identify and Access Management (IAM) roles need to be tightly controlled lest there be unintentional data breaches from unauthorized access.

Misconfigured S3 buckets on AWS have been the cause of data breaches before, and it’s easy to overlook this if there is no plan in place to address it beforehand.

Likewise, Azure offers Azure Kubernetes Service (AKS), Azure Functions, and Cosmos DB, which all have their own security issues to take into consideration. For organizations using Azure Active Directory for their user and identity management, attention will need to be paid to the levels of access and assigned roles to each person.

GCP gives teams a range of tools to build in the cloud, but like AWS and Azure, they come with their own set of risks. Some of these are Functions and Cloud Run for enabling serverless architectures, where limiting who can trigger these is a priority.

Much like AWS Elastic Kubernetes Service (EKS) or Azure’s AKS, GCP has its own Google Kubernetes Engine, which will require strict network rules, management permissions, and locked-down containers. On top of that, GCPs’ roles are defined within the IAM and should be scrutinized so that no one person gets more power than they should for their role.

Threat modeling within the AWS, Azure, and GCP Well-Architected Framework

The AWS’s Well-Architected Framework best practices, specifically within the Security Pillar SEC01-BP07, highlight threat modeling as a best practice.

Perform threat modeling to identify and maintain an up-to-date register of potential threats and associated mitigations for your workload.

Level of risk exposed if this best practice is not established: High

AWS makes efforts to inform users about their shared responsibility model across the AWS ecosystem, highlighting the importance of organizations securing their applications and data within the AWS cloud.

Likewise, Azure’s Well-Architected Framework emphasizes similar points concerning integrating threat modeling into your processes to proactively identify potential risks and plan mitigations early. As Microsoft states, threat modeling allows teams to:

• Detect security weaknesses: Use monitoring tools to detect threats before they are introduced into production environments.
• Build security into the application design: Implement security controls and mitigations from the start, reducing the cost and complexity of fixes.
• Adapt security practices: Keep up with evolving threats and changes in the application or infrastructure.

Microsoft also highlights the importance of threat modeling for cloud-native services such as containers, serverless computing, and microservices, where security concerns can be more specific.

GCP, though not as formally structured as AWS’s or Azure’s Well-Architected Framework, emphasizes best practices for managing risks for cloud applications in their Architecture Framework document under security. Key practices include:

• Identify risks to your organization: Perform risk assessments and use tools for conducting threat modeling to identify potential gaps.
• Implement suitable controls: After identifying threats and risks, add controls to mitigate them.
• Shift security left: Use automation for deployments to scan and detect any insecure misconfigurations during build pipelines.

The importance of threat modeling in AWS, Azure, and GCP

When deploying applications in the cloud, a main concern is ensuring that your system is resilient to external threats and internal vulnerabilities. Traditional application threat modeling involves identifying potential attack vectors and weaknesses in the system architecture, but when these applications run on cloud platforms, the complexity increases.

Cloud-native services like serverless computing, containers, and managed databases introduce some security challenges unique to the cloud environment. While offering speed and flexibility, they can also expand the attack surface and require careful attention to security configurations.

For example, serverless computing can lead to risks like misconfigured permissions, which may grant functions unnecessary access to sensitive data, or API vulnerabilities such as SQL injection or cross-site scripting (XSS), or Denial of Service (DoS) from a lack of rate-limiting.

Similarly, containers can pose threats if they are misconfigured (e.g., running with root privileges) or container breakout vulnerabilities that allow attackers to escape and access the host system. Managed databases may also introduce risks through insecure default settings or poorly managed access controls.

Threat modeling helps teams identify these risks early, addressing potential misconfigurations and vulnerabilities before they can be exploited. It enables teams to mitigate real-world cloud risks, ensuring their cloud architecture is secure and compliant with shared responsibility models in AWS, Azure, and GCP.

Threat modeling in the cloud helps you:

• Identify assets and their dependencies in a cloud environment.
• Assess and prioritize risks associated with cloud-native services.
• Understand how different components (e.g., virtual machines, containers, storage) communicate and where security gaps may lie.

---

Threat models driving application security across teams

Security is often seen as the responsibility of just one team or that one team should oversee it. However, it’s a shared goal across development, operations, and security teams.

Threat models can foster cross-functional collaboration by providing a common language for risk, enabling teams to visualize potential threats and communicate necessary security controls.

For example, DevSecOps teams can use threat models to ensure Infrastructure as Code (IaC) is properly secured before deployment. Similarly, developers can refer to threat models to ensure their code is secure and suitable controls and mitigations are in place against the risks identified, from SQL injections to insecure API calls.

By making threat modeling a part of your cloud development workflow, teams can:

• Break down barriers between development and security, fostering collaboration.
• Implement security controls consistently across cloud resources.
• Continuously monitor and adapt security measures as applications scale.

Take control of cloud security with ThreatCanvas and SecureFlag

The cloud offers unparalleled opportunities for innovation, but only if security is built into every step of the development process.

With ThreatCanvas, your teams can create threat models within the contexts of AWS, Azure, or GCP within seconds.

Teams can automate the complete threat modeling process using IaC templates, architectural diagrams, or typing a description of the application and then share the resulting models across teams.

By using ThreatCanvas to model and address threats in your cloud applications, you ensure that your security measures are as dynamic and scalable as the cloud itself.

Start your journey to more secure cloud applications today. Sign up for ThreatCanvas Lite for free or get in touch with the SecureFlag team to learn more about our secure coding virtual Labs to empower your team to secure your cloud environment from the ground up.