This chapter covers threat modeling for Azure solutions, a critical skill for the AZ-305 exam. Threat modeling is the process of identifying, analyzing, and mitigating security threats to your Azure architecture. Approximately 10-15% of exam questions touch on security design, including threat modeling concepts like STRIDE and Microsoft Threat Modeling Tool. Mastering this topic ensures you can design secure solutions that meet compliance requirements and resist attacks.
Jump to a section
Threat modeling is like an architect designing a bank vault. Before pouring concrete, the architect studies the vault's purpose (store cash), identifies assets (cash, safety deposit boxes), and maps entry points (door, ventilation, service ducts). They then think like a thief: 'How would I break in? Could I pick the lock? Drill through the wall? Bribe a guard?' For each threat, they design a countermeasure: a multi-ton door, reinforced concrete, motion sensors, dual-control locks. The blueprint is reviewed by a security team who add more layers: timed locks, camera placement, alarm response. After construction, the vault is tested—penetration testers try to break in. If they succeed, the design is updated. Threat modeling in Azure follows the same process: identify what you're protecting (data, identities), map how attackers could reach it (network, application, social engineering), and design controls (firewalls, encryption, RBAC). The threat model is a living document, updated as the system changes. Without it, you're building a vault without knowing where the weak spots are.
What is Threat Modeling and Why Does It Exist?
Threat modeling is a structured approach to identifying potential security threats to a system and defining countermeasures to prevent or mitigate them. It originated from software security and is now a standard practice in cloud architecture. The goal is to find vulnerabilities early in the design phase, when fixes are cheaper and easier, rather than after deployment. In Azure, threat modeling helps you comply with frameworks like NIST, ISO 27001, and Azure Security Benchmark. The AZ-305 exam expects you to apply threat modeling principles to design secure Azure solutions.
The STRIDE Model
STRIDE is a mnemonic for six threat categories developed by Microsoft: - Spoofing: Impersonating a user or system (e.g., fake login page). - Tampering: Modifying data or code (e.g., altering a database record). - Repudiation: Denying an action without proof (e.g., claiming you didn't send a message). - Information Disclosure: Exposing data to unauthorized parties (e.g., SQL injection leaks customer data). - Denial of Service: Disrupting service availability (e.g., DDoS attack). - Elevation of Privilege: Gaining higher access than intended (e.g., exploiting a bug to become admin).
Each threat maps to a security property: Authentication, Integrity, Non-repudiation, Confidentiality, Availability, and Authorization. When threat modeling, you analyze each component of your Azure solution against these six categories.
Microsoft Threat Modeling Tool
The Microsoft Threat Modeling Tool (TMT) is a free tool that helps you create threat models for Azure solutions. It uses a data flow diagram (DFD) approach. You draw your system architecture (processes, data stores, data flows, external entities) and the tool automatically generates threats based on STRIDE. The tool includes a template for Azure services, providing pre-defined threats for components like Azure SQL Database, Storage Accounts, and Virtual Machines.
Key steps in TMT: 1. Create a DFD: Drag and drop components like Azure Web App, Azure SQL Database, Azure Storage, etc. 2. Define trust boundaries: Draw lines between different trust zones (e.g., on-premises vs. Azure, internet vs. VNet). 3. Generate threats: Click 'Generate Threats' to see a list of potential threats per component. 4. Review and mitigate: For each threat, assign a priority (High, Medium, Low) and define countermeasures.
STRIDE per Azure Component
Let's apply STRIDE to common Azure services:
Azure Storage Account
Spoofing: An attacker could use a stolen SAS token to access data.
Tampering: Data in transit could be modified if not using HTTPS.
Repudiation: Without logging, a user could deny uploading a blob.
Information Disclosure: A misconfigured container (public access) leaks data.
Denial of Service: A massive upload could exhaust storage performance.
Elevation of Privilege: An attacker with read-only SAS could escalate to write via a bug.
Azure SQL Database
Spoofing: SQL injection could impersonate a user.
Tampering: SQL injection modifies query results.
Repudiation: Without audit logging, actions cannot be traced.
Information Disclosure: SQL injection leaks data.
Denial of Service: A long-running query could block others.
Elevation of Privilege: SQL injection could grant admin rights.
Azure Virtual Machines
Spoofing: RDP brute force could compromise credentials.
Tampering: Malware modifies system files.
Repudiation: Without logging, an admin could deny changes.
Information Disclosure: Open ports expose services.
Denial of Service: Network DDoS targets VM IP.
Elevation of Privilege: Exploit in guest OS grants root.
The Threat Modeling Process
The standard process has five steps: 1. Define security requirements: What are you protecting? (e.g., PII, financial data). Align with compliance like GDPR, HIPAA. 2. Create an architecture diagram: Use a DFD showing data flows, trust boundaries, and components. 3. Identify threats: Use STRIDE per component. Also consider attack trees and common vulnerabilities (OWASP Top 10). 4. Mitigate threats: For each threat, design a control. Example: For SQL injection, use parameterized queries and a Web Application Firewall (WAF). 5. Validate: Test mitigations through penetration testing and code review.
Threat Modeling in Azure DevOps
Azure DevOps integrates threat modeling through the 'Threat Modeling' extension. You can automatically generate threats from your ARM templates or Terraform scripts. This shifts left security into CI/CD. The tool checks for common misconfigurations like open ports, unencrypted data, and missing authentication.
Common Mitigations in Azure
For each STRIDE category, Azure provides specific services:
Spoofing: Azure AD with Multi-Factor Authentication (MFA), Managed Identities.
Tampering: Azure Storage encryption (SSE, client-side), Azure SQL Transparent Data Encryption (TDE).
Repudiation: Azure Monitor Logs, Azure SQL Auditing, Azure Storage Analytics Logs.
Information Disclosure: Azure Firewall, Network Security Groups (NSGs), Private Endpoints, Azure Information Protection.
Denial of Service: Azure DDoS Protection Standard, Azure Front Door, Azure Application Gateway WAF.
Elevation of Privilege: Azure RBAC, Privileged Identity Management (PIM), Just-In-Time (JIT) VM access.
Attack Trees and Threat Modeling
An attack tree is a graphical representation of attack vectors. The root is the attacker's goal (e.g., 'Steal customer data'). Branches are ways to achieve it (e.g., 'SQL injection', 'Phishing admin credentials', 'Exploit open storage'). Threat modeling often uses attack trees to brainstorm threats. In Azure, you can map attack trees to your architecture. For example, to steal data from Azure SQL:
Exploit SQL injection in web app
Steal admin password via phishing
Access from a compromised VM in the same VNet
Use a misconfigured firewall rule
Each leaf becomes a threat to mitigate.
Trust Boundaries
Trust boundaries are points where data moves from one trust level to another. Examples:
Internet to Azure (low trust to high trust)
On-premises to Azure (via VPN/ExpressRoute)
VNet to VNet (peering)
VNet to PaaS service (Service Endpoint vs Private Endpoint)
At each trust boundary, threats like spoofing and tampering are likely. For instance, data crossing the internet to Azure could be intercepted (information disclosure) or modified (tampering). Mitigations include TLS, VPN, and Azure Firewall.
Threat Modeling for Containers and Kubernetes
Azure Kubernetes Service (AKS) adds complexity. Threats include:
Spoofing: A compromised container image impersonates a legitimate service.
Tampering: An attacker modifies a running container's filesystem.
Repudiation: Without audit, actions inside a pod cannot be traced.
Information Disclosure: A container with access to host network leaks data.
Denial of Service: A pod consumes all cluster resources.
Elevation of Privilege: A container escapes to the host node.
Mitigations: Use Azure Container Registry with vulnerability scanning, apply pod security policies, enable Azure Policy for AKS, and use Azure AD for RBAC.
Threat Modeling for Serverless (Azure Functions, Logic Apps)
Serverless components have unique threats:
Spoofing: An attacker could invoke a function without proper authentication.
Tampering: Input data could be modified before reaching the function.
Repudiation: Without logging, function invocations are untraceable.
Information Disclosure: Function logs may contain sensitive data.
Denial of Service: A burst of invocations could exhaust consumption plan resources.
Elevation of Privilege: A function with high permissions could be exploited.
Mitigations: Use Azure AD authentication, enable Application Insights, set function access keys, and use managed identities.
Threat Modeling for Identity and Access
Identity is a key attack surface. Threats:
Spoofing: Attacker steals user credentials.
Tampering: Attacker modifies group membership.
Repudiation: User denies performing an action.
Information Disclosure: Attacker reads user attributes from Azure AD.
Denial of Service: Locking accounts via repeated failed logins.
Elevation of Privilege: Attacker gains Global Admin via privilege escalation.
Mitigations: Azure AD Identity Protection, Conditional Access, PIM, and Access Reviews.
The Role of Threat Modeling in AZ-305
The AZ-305 exam tests your ability to design secure solutions. You will be given a scenario (e.g., 'A company is moving a web app to Azure. They need to protect customer PII.') and asked to recommend security controls. Threat modeling helps you systematically identify what threats exist and what mitigations are appropriate. Common exam questions ask: 'Which STRIDE category is addressed by X?' or 'What is the next step in threat modeling after creating a DFD?' You must know the order: requirements, DFD, identify threats, mitigate, validate.
Advanced Threat Modeling with Microsoft Security Development Lifecycle (SDL)
Microsoft's SDL includes threat modeling as a mandatory phase. The SDL process adds documentation and training. For AZ-305, you should know that SDL is a broader software security framework that includes threat modeling, but the exam focuses on the threat modeling part.
Tools and Resources
Microsoft Threat Modeling Tool: Free, downloadable from Microsoft.
OWASP Threat Dragon: Open-source alternative.
Azure Security Center: Provides security recommendations based on your architecture, but not a full threat model.
Azure Blueprints: Pre-built templates that include security controls.
Common Pitfalls
Not including all trust boundaries: Data flows between Azure services also have trust boundaries (e.g., between App Service and SQL Database via VNet).
Ignoring human factors: Social engineering is a spoofing threat.
Not updating the threat model: When you add a new component, re-run the threat model.
Over-relying on the tool: The tool generates generic threats; you must tailor them to your system.
Summary of Key Numbers and Defaults
STRIDE has 6 categories.
Microsoft Threat Modeling Tool uses DFDs.
Trust boundaries are where data crosses from one trust level to another.
The five steps: Requirements, DFD, Identify, Mitigate, Validate.
Common exam scenario: 'A company is designing a new application. What should they do first?' Answer: Define security requirements.
How Threat Modeling Interacts with Other Azure Services
Azure Policy: Enforce threat model mitigations (e.g., require encryption).
Azure Blueprints: Package threat model requirements into deployable artifacts.
Azure DevOps: Integrate threat modeling into CI/CD pipeline.
Azure Monitor: Detect threats in real-time (e.g., anomalous access).
By mastering threat modeling, you can design Azure solutions that are secure by default, meeting both business needs and compliance requirements.
Define Security Requirements
Start by identifying what you need to protect. This includes data classification (e.g., public, internal, confidential, restricted), compliance requirements (GDPR, HIPAA, PCI DSS), and business goals. For example, if you are storing PII, you need encryption at rest and in transit, access controls, and audit logging. Document these requirements in a security requirements document. This step sets the scope for the entire threat model. Without clear requirements, you may miss critical threats or over-engineer controls. On the exam, this is the first step in the threat modeling process.
Create Architecture Diagram (DFD)
Draw a data flow diagram (DFD) of your Azure solution. Include all components: VMs, databases, storage accounts, web apps, APIs, load balancers, and external entities (users, on-premises systems). Show data flows between components with arrows. Mark trust boundaries (e.g., a dashed line around the VNet). Use the Microsoft Threat Modeling Tool to create the DFD. The tool provides templates for Azure services. Ensure you include all data flows, including outbound to the internet. A missing flow could hide a threat.
Identify Threats Using STRIDE
For each component and data flow, apply the STRIDE model. List potential threats. For example, for an Azure SQL Database accessed from a web app: Spoofing (SQL injection), Tampering (SQL injection), Repudiation (no audit), Information Disclosure (SQL injection), Denial of Service (resource exhaustion), Elevation of Privilege (SQL injection). The Threat Modeling Tool can auto-generate threats, but you should review and add missing ones. Consider attack trees for complex scenarios. Document each threat with a unique ID.
Prioritize and Mitigate Threats
Assign a risk level (High, Medium, Low) to each threat based on likelihood and impact. High-risk threats must be mitigated. Design countermeasures using Azure services. For SQL injection: use parameterized queries, WAF, and stored procedures. For spoofing: enable MFA. For information disclosure: use encryption. Document the mitigation and the Azure service that implements it. For each mitigation, verify it does not introduce new threats (e.g., a firewall might block legitimate traffic).
Validate Mitigations
Test that mitigations work as intended. This can include penetration testing, code review, and configuration review. Use Azure Security Center to validate compliance with security policies. Run the Threat Modeling Tool again to see if threats are addressed. Update the threat model if new threats are discovered. Validation is an ongoing process; when you change the architecture, repeat steps 2-5. On the exam, validation is the final step in the threat modeling process.
Scenario 1: E-Commerce Platform Migration to Azure
A retail company is migrating its e-commerce platform to Azure. The platform handles customer PII (names, addresses, credit card numbers) and is subject to PCI DSS. The architecture includes Azure App Service for the web frontend, Azure SQL Database for orders, Azure Storage for product images, and Azure Redis Cache for session state. The threat modeling process begins with defining security requirements: encrypt credit card data at rest and in transit, implement strong authentication, log all access to PII, and protect against DDoS. The DFD shows data flows: users connect to App Service over HTTPS, App Service queries SQL Database, and App Service reads/writes to Storage. Trust boundaries: Internet to Azure, App Service to SQL Database, App Service to Storage. STRIDE analysis reveals high-risk threats: SQL injection in the web app (could leak credit card data), misconfigured storage container (public access to images), and session hijacking via Redis. Mitigations: Use Azure WAF on Application Gateway to block SQL injection, enable Azure Storage firewall and private endpoints, use Azure Cache for Redis with authentication and TLS, and enable Azure SQL Advanced Threat Protection. The threat model is reviewed quarterly and updated when new features are added. A common misconfiguration is forgetting to restrict storage access to only the App Service, leading to data exposure. In production, the company uses Azure Policy to enforce encryption and logging across all resources.
Scenario 2: Healthcare SaaS Application on Azure
A healthcare SaaS provider builds a patient portal on Azure, handling PHI (Protected Health Information) subject to HIPAA. The architecture uses Azure Kubernetes Service (AKS) for microservices, Azure Cosmos DB for patient records, Azure Functions for background processing, and Azure API Management (APIM) for API gateway. Threat modeling identifies threats: unauthorized access to Cosmos DB via a compromised microservice, data leakage through Function logs, and privilege escalation via AKS container escape. Mitigations: Use Azure AD managed identities for service-to-service authentication, enable Cosmos DB firewall with virtual network integration, use Azure Policy to restrict AKS container capabilities, enable Application Insights with data masking, and use APIM with OAuth2 and rate limiting. A common issue is that developers forget to disable local authentication on Cosmos DB, leaving it open to attacks. The threat model also includes physical security: the Azure datacenters are SOC 2 compliant. The company conducts annual penetration tests and uses Azure Security Center to monitor for misconfigurations. When a new microservice is added, the threat model is updated to include its data flows.
Scenario 3: Financial Services Data Lake
A bank builds a data lake in Azure for analytics, using Azure Data Lake Storage Gen2, Azure Databricks, and Azure Synapse Analytics. The data includes transaction records and customer profiles. Compliance with SOX and GDPR is required. Threat modeling reveals threats: unauthorized access to Data Lake via a leaked storage account key, data tampering during ETL, and repudiation of data modifications. Mitigations: Use Azure AD authentication for Data Lake (disable storage account keys), enable Azure SQL Auditing for Synapse, use Azure Purview for data lineage and classification, and implement Azure Policy to require encryption. A common misconfiguration is leaving Data Lake accessible from the internet; the correct approach is to use private endpoints and firewall rules. The threat model also addresses insider threats: use PIM for just-in-time access to sensitive data. The model is updated when new data sources are added. In production, the bank uses Azure Monitor to alert on anomalous access patterns.
What the AZ-305 Tests on Threat Modeling
The AZ-305 exam focuses on threat modeling as part of the 'Design Identity, Governance, and Monitoring Solutions' domain (objective 1.2). Specifically, you must be able to:
Identify which STRIDE category a given threat falls into.
Recommend appropriate Azure services to mitigate a threat.
Understand the threat modeling process steps in order.
Apply threat modeling to a given scenario (e.g., a web app with a database).
Common exam question formats: - 'Your company is designing a new application. What is the first step in threat modeling?' Answer: Define security requirements. - 'Which threat category does SQL injection belong to?' Answer: Tampering and Information Disclosure (it can both modify and leak data). - 'You need to mitigate spoofing threats for a web app. What should you use?' Answer: Azure AD with MFA.
Common Wrong Answers and Why Candidates Choose Them
Confusing STRIDE categories: Candidates often mix up Spoofing and Elevation of Privilege. Spoofing is about pretending to be someone else; Elevation of Privilege is about gaining higher permissions than assigned. For example, a user accessing another user's data via a broken access control is Elevation of Privilege, not Spoofing.
Choosing the wrong mitigation: For a denial of service threat, candidates might choose Azure Firewall instead of Azure DDoS Protection. Firewall filters traffic but does not absorb DDoS attacks; DDoS Protection does.
Incorrect order of steps: Candidates might put 'Identify Threats' before 'Create Architecture Diagram'. You must have a diagram to identify threats.
Overlooking trust boundaries: A question might describe a data flow from a web app to a database, but candidates forget that the database is inside a VNet, so the trust boundary is between the web app and the database. The correct mitigation is a private endpoint or VNet integration.
Specific Numbers and Terms on the Exam
STRIDE acronym and each letter's meaning.
The five steps: Requirements, DFD, Identify, Mitigate, Validate.
Microsoft Threat Modeling Tool uses DFDs.
Trust boundaries are critical.
For each STRIDE category, know the primary Azure mitigation service: Spoofing -> Azure AD MFA, Tampering -> Encryption, Repudiation -> Audit logs, Information Disclosure -> Firewall/Private Endpoints, Denial of Service -> DDoS Protection, Elevation of Privilege -> RBAC/PIM.
Edge Cases and Exceptions
Multiple STRIDE categories for one threat: SQL injection is both Tampering and Information Disclosure. The exam may ask for the primary category, but be prepared for multiple.
Threat modeling for PaaS vs IaaS: PaaS services have shared responsibility; the provider secures the OS, but you must secure application and data. The exam may test that you still need to threat model PaaS components.
Zero Trust: Threat modeling aligns with Zero Trust principles (assume breach). You may need to recommend micro-segmentation and continuous verification.
How to Eliminate Wrong Answers
If a question asks for a mitigation for a specific STRIDE category, eliminate any answer that addresses a different category. For example, for Spoofing, eliminate options about encryption (that's for tampering/information disclosure).
For process steps, eliminate any option that lists 'Create DFD' before 'Define requirements'.
For scenario-based questions, look for the trust boundary. If the data flow crosses the internet, the threat is higher, and mitigation should include encryption and firewall.
If an answer suggests a service that does not exist in Azure (e.g., 'Azure Threat Detection Tool' — the real tool is Microsoft Threat Modeling Tool), it is wrong.
Threat modeling is a structured process with five steps: Define security requirements, Create DFD, Identify threats (STRIDE), Mitigate, Validate.
STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
The Microsoft Threat Modeling Tool uses data flow diagrams and auto-generates threats based on STRIDE.
Trust boundaries are critical points where data crosses between different trust levels (e.g., internet to Azure, VNet to VNet).
For each STRIDE category, know the primary Azure mitigation: MFA (Spoofing), Encryption (Tampering), Audit Logs (Repudiation), Firewall (Info Disclosure), DDoS Protection (DoS), RBAC/PIM (Elevation).
SQL injection is both Tampering and Information Disclosure—a common exam trap.
Threat models must be updated when the architecture changes or new vulnerabilities are discovered.
On the exam, the first step is always 'Define security requirements'.
Azure Security Center provides ongoing security recommendations but is not a replacement for threat modeling.
For serverless and containers, apply the same STRIDE analysis; they have unique threats like container escape and function key compromise.
These come up on the exam all the time. Here's how to tell them apart.
Microsoft Threat Modeling Tool
Integrates with Visual Studio and Azure DevOps.
Uses STRIDE by default.
Provides Azure-specific templates.
Generates threat reports in Word/Excel.
Free and maintained by Microsoft.
OWASP Threat Dragon
Open-source and cross-platform.
Supports STRIDE, LINDDUN, and custom categories.
Can import from draw.io and other tools.
Generates reports in PDF and JSON.
Community-driven updates.
Mistake
Threat modeling is only for developers, not architects.
Correct
Threat modeling is a core responsibility of solution architects. Architects design the system, so they must identify threats early. The AZ-305 exam tests threat modeling from an architect's perspective, focusing on system-level threats and Azure mitigations.
Mistake
The Microsoft Threat Modeling Tool automatically fixes threats.
Correct
The tool only generates a list of potential threats. It does not implement mitigations. You must manually design and apply controls using Azure services. The tool is an aid, not a solution.
Mistake
Once a threat model is created, it doesn't need updating.
Correct
Threat models must be living documents. As you add new components, change configurations, or discover new vulnerabilities, you must update the model. The exam emphasizes continuous improvement.
Mistake
STRIDE categories are mutually exclusive.
Correct
A single vulnerability can fall into multiple STRIDE categories. For example, SQL injection is both Tampering (modifying data) and Information Disclosure (leaking data). You must consider all relevant categories.
Mistake
Trust boundaries only exist between on-premises and cloud.
Correct
Trust boundaries exist wherever data moves between different trust levels, including between Azure services. For example, a web app and a database in the same VNet still have a trust boundary if the database is accessed over the network.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The first step is to define security requirements. This includes identifying what data you need to protect (e.g., PII, financial data), compliance requirements (GDPR, HIPAA), and business goals. Without clear requirements, you cannot effectively identify threats or design mitigations. On the exam, if a question asks for the first step, always choose 'Define security requirements' over 'Create a data flow diagram' or 'Identify threats'.
Spoofing threats involve impersonation. In Azure, the primary mitigation is strong authentication using Azure Active Directory with Multi-Factor Authentication (MFA). For service-to-service communication, use Managed Identities to avoid storing credentials. For web apps, enforce Azure AD authentication. Additionally, use Conditional Access policies to block suspicious sign-ins. For example, if a user logs in from an unusual location, require MFA.
Spoofing is when an attacker pretends to be someone else (e.g., using stolen credentials). Elevation of Privilege is when an attacker gains higher permissions than they are authorized to have (e.g., a regular user becomes an admin). Spoofing is about identity; elevation is about authorization. A common exam question: 'An attacker uses SQL injection to read data from another user's account.' This is Elevation of Privilege (accessing data they shouldn't), not Spoofing.
For network-level DDoS attacks, use Azure DDoS Protection Standard. It provides automatic mitigation for Azure resources. For application-layer DoS (e.g., HTTP flood), use Azure Web Application Firewall (WAF) on Application Gateway or Front Door. For resource exhaustion (e.g., a VM consuming all CPU), use Azure Autoscale and load balancing. The exam may ask for the service that specifically handles DDoS; that is Azure DDoS Protection.
Yes. Although Microsoft secures the underlying infrastructure, you are responsible for data, access, and application-level threats. For Azure SQL Database, threats include SQL injection, weak authentication, and data exfiltration. Your threat model should include these and recommend mitigations like Azure AD authentication, firewall rules, and Advanced Threat Protection.
A trust boundary is a point where data moves from one trust level to another. For example, from the internet to your Azure VNet, or from a web app to a database. At these boundaries, threats like spoofing and tampering are likely. In a threat model, you draw trust boundaries on your DFD to help identify where threats can occur. The exam may ask you to identify trust boundaries in a given architecture.
Update your threat model whenever the architecture changes (e.g., adding a new service, changing data flows) or when new vulnerabilities are discovered. Also review it periodically (e.g., quarterly) as part of a security review. The exam emphasizes that threat modeling is an ongoing process, not a one-time activity.
You've just covered Threat Modelling for Azure Solutions — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?