How to Best Threat Model Cloud-Native Applications
Organizations of all sizes are accelerating their move to the cloud. The benefits of instant upward or downward scalability are obvious. As is the avoidance of purchasing, expanding, and maintaining physical infrastructure such as servers, storage, and network devices. In most organizations, moving to the cloud is not limited to a single Cloud Service Provider (CSP). According to a recent report by Flexera, 92 percent of organizations use multiple cloud providers, with an average of 2.6 public and 2.7 private clouds .
Many organizations take a cloud-native approach to new applications. According to the Cloud Native Computing Foundation, cloud-native applications are characterized by “…[c]ontainers, service meshes, microservices, immutable infrastructure, and declarative APIs ...” This is different from the applications we used to build for on-premises deployments with a fixed footprint infrastructure. Rather than a single monolithic application encompassing all logic and operational functionality, cloud-native applications are composed of dozens or hundreds of discrete or ephemeral components that can be instantiated, updated, or redeployed independently. This makes enhancements, maintenance, and scaling simpler by allowing developers to focus on individual services that are updated and deployed frequently, using the right technology stack that is independent of other services.
Cloud-Native Applications Have Different Security Challenges
Threat modeling is a critical part of the security life cycle when building any application. Threat modeling anticipates how design flaws and implementation weaknesses could enter the application, then specifies mitigation controls to be implemented during the development process. This allows organizations to avoid the addition of exploitable weaknesses during the development process, rather than using scanners to test for security after code is built or deployed. When threat modeling cloud-native applications, teams must consider additional security challenges.
Shared responsibility for security
One should not simply redeploy an existing on-premises application to a new CSP – or between two different CSPs. In the cloud’s shared responsibility model, each cloud vendor can offer different levels of management and security controls. In a SaaS environment, the vendor may provide a custom database schema. In an IaaS or PaaS environment, tools, frameworks, operating systems, and other environments may not be easily replicated. The shared responsibility model can be different for each application and covers the infrastructure, metastructure, infostructure, and applistructure layers of the environment.
Dynamic attack surfaces
The attack surface of cloud applications can change frequently. In a microservices architecture we can scale up or down any service or data store as needed—automatically in many cases. Each time we do so, the attack surface of the application dynamically changes, which leads to the possibility of new threats. Similarly, new attack vectors can appear as we instantiate service level accounts across those microservices. For this reason, key rotations and Identity and Access Management (IAM) become increasingly important in the cloud.
Identifying and maintaining risk mitigations
With the many variations of shared services between CSPs, and a constantly changing attack surface, determining and enforcing effective mitigation controls can be difficult. Controls that once provided adequate protection after an initial threat model may leave critical weaknesses exposed as an application evolves.
Security Considerations When Threat Modeling Cloud-Native Applications
It is critical to understand the security requirements, applicable regulatory standards, and architecture-based threats to the application. Once these are identified through a threat model, controls to mitigate risk can be enumerated for each and assigned for implementation. For cloud-native applications these include:
API vulnerabilities
Each component and microservice communicates with other components through its Application Programming Interface (API). Like any other piece of software, APIs can include errors that affect security.
- Unauthorized call – All calls to the API should be checked to ensure that unauthorized users or systems are not permitted to access the API.
- Information leakage - Sensitive information is passed through APIs, including system credentials, sensitive user information, credit card numbers, and data that could aid an attacker.
- Denial of service - Any API call consumes resources. A malicious actor could flood the API with calls to consume server resources and prevent other calls to the API from being processed.
Insecure data transfers
Data in transit between users and systems should always be encrypted to prevent attackers from intercepting or monitoring plaintext data transmission.
- Managing cryptographic keys at both cloud and ground level – Managingcloud-to-cloud interactions is well understood. Organizations also need to manage and synchronize keys between cloud and ground (on-premises users).
Shared IAM
Cloud deployments require teams to consider risks from multi-tenancy and the third party managed infrastructure, making IAM controls critical.
- Credential sharing for RBAC – Role-Based Access Control (RBAC) restricts system access to authorized users. Teams need to watch for unauthorized sharing of credentials between users.
- Maintaining least privilege – Ensure that user and system privileges are maintained at the minimum level required to perform a task for each role.
Application vulnerabilities
Secure coding practices are critical in any environment. Design flaws and coding errors must be considered, as well as the use of open source components with known vulnerabilities.
- OWASP Top 10 – The Open Web Application Security Project (OWASP) publishes a list of the most critical security risks to web applications. Teams should, at a minimum, employ methods to test for these vulnerabilities.
Misconfigured services
Misconfigurations in systems and services can also result in breaches. A recent study found misconfigured cloud storage services in 93 percent of cloud deployments.
- Default security groups - Default security groups dictate rules that allow all outbound traffic, deny all inbound traffic, and allow all traffic between cloud resources in the group. Default settings should not be changed to permit unauthorized access.
- Data exfiltration from publicly available datastores – Misconfigurations of cloud data stores can permit unauthenticated or unauthorized access to stores and data.
Required Cloud Threat Modeling Capabilities
The steps taken when threat modeling cloud applications are like those for on-premises systems; however, the deployment environment and responsibilities for implementing risk mitigation controls differ. Threat modeling cloud applications must include:
- Asset classification – The first step in a cloud threat model is to inventory all information and assets, then classify them for criticality and acceptable levels of business risk.
- Threat identification – The majority of exploitable weaknesses to an application are inherent to the technical stack of the application, including programming languages, frameworks, services, and deployment environment.
- Vulnerability identification – Vulnerabilities can include unpatched systems, configuration errors, hard-coded credentials, and open source or third-party components and cloud services with known vulnerabilities.
- Threat and vulnerability classification – All threats and vulnerabilities should be risk-ranked against the likelihood of exploitation, consequences of exploitation, and the organization's appetite for risk.
- Risk assessment – Once threats, vulnerabilities and other potential weaknesses are identified and classified, an overall risk status can be determined. This is drawn from an organization’s predefined and agreed-upon security and compliance policies and enables you to take a strategic approach to mitigating application risk.
Where Are We Headed?
Expect the cloud risk landscape to evolve. A couple of trends we believe will help organizations include:
Policy-driven security models – Traditional threat modeling is based on manually mapping an application’s data flow, diagramming trust boundaries, and prescribing mitigations for implementation by development teams. Manual methods don’t scale and are a poor fit with today's rapid development requirements, business expectations, and continually changing attack surface and threat landscape.
A policy-driven security model provides a baseline context for every software build, which can be measured against policies to determine if developers are compliant. Tying policies to business risks offers several advantages, such as integrating security risk assessments into product delivery pipelines. This ensures high levels of security and reduces costly rework activities later in the cycle — a consequence of viewing security as an afterthought.
Translate policies into actionable guidance – Policies for secure coding and configurations are necessary but guidance documents can be difficult for DevSecOps teams to interpret for implementation. Translating policies into consistent, effective, and actionable tasks delivered directly to parties responsible for implementation ensures that policies are understandable and simplifies validating those controls are in place.
Account for new vulnerabilities and threats – The threat space is not static; new threats and attack vectors are discovered each year. Likewise, researchers identify new vulnerabilities daily. In 2021, over 20,000 new vulnerabilities in software were disclosed in the National Vulnerability Database (NVD).
Attack categorization – Providing a common language and categorization for attack methods helps security professionals understand vectors and defenses. Weaknesses in hardware and software are already characterized in MITRE’s Common Weakness Enumeration (CWE). MITRE’s ATT&CK project provides similar characterization on “cyber adversary behavior and taxonomy for adversarial actions” including tactics, techniques, and procedures (TTP).
Protection at the asset level – Network-centric security is difficult in a hybrid cloud environment. Instead, expect to see a great focus on application and data security. This protects sensitive information where it resides: within applications.
Cloud Threat Modeling and SD Elements
SD Elements supports many security frameworks and standards, including the Cloud Security Association’s Cloud Controls Matrix (CCM). The CCM provides over 130 security controls across 16 domains, including application and API security, audit assurance, encryption and key management, and data security and information life cycle management.It provides teams with the ability to accelerate time to market while ensuring that threats and appropriate security controls are identified and applied consistently.