This chapter covers the Cloud Security Architecture Review, a critical process for evaluating and improving the security posture of cloud environments. For the SC-200 exam, understanding how to assess and recommend changes to cloud architectures is essential, as it appears in approximately 10-15% of questions related to cloud security (Objective 3.2). You will learn the key components of a security architecture review, including identity and access management, network segmentation, data protection, logging, and monitoring, and how to apply them to Microsoft Azure and hybrid environments. Mastery of this topic will help you identify misconfigurations, propose remediation, and align with compliance frameworks like the Microsoft Cloud Security Benchmark.
Jump to a section
Imagine a bank with multiple vaults, each containing different types of assets (cash, bonds, safety deposit boxes). The bank conducts a Security Architecture Review to ensure that the vaults, alarms, access controls, and surveillance systems are designed correctly to protect against threats. The review examines the physical layout: where vaults are placed relative to entry points, how alarms are zoned, who has keys, and how access logs are audited. It identifies weaknesses like a vault door that opens inward (making it harder to block), a camera blind spot covering the main entrance, or an alarm that can be silenced from an unsecured panel. The review recommends changes: rekeying locks, adding motion sensors, reinforcing walls, and implementing dual-control access for the most valuable vault. Similarly, a Cloud Security Architecture Review evaluates the design of cloud infrastructure—network segmentation, identity controls, encryption, logging, and monitoring—to find gaps and ensure the architecture meets security requirements before deployment. Just as the bank review is proactive, preventing theft rather than reacting after a loss, the cloud review aims to catch misconfigurations and design flaws early, reducing attack surface and ensuring compliance.
What is a Cloud Security Architecture Review?
A Cloud Security Architecture Review is a systematic evaluation of the design and configuration of cloud resources to identify security risks, misconfigurations, and compliance gaps. It is not a penetration test or vulnerability scan; it examines the architecture itself—how components are connected, how access is controlled, how data flows, and how monitoring is set up. The goal is to ensure the architecture aligns with security best practices, organizational policies, and regulatory requirements. For SC-200, this review is often performed using tools like Microsoft Defender for Cloud, Azure Policy, and Microsoft Sentinel, and it focuses on the Microsoft Cloud Security Benchmark (MCSB) as the baseline.
Why It Exists
Cloud environments are complex, with hundreds of services, network configurations, identity providers, and data storage options. Misconfigurations are the leading cause of cloud breaches (e.g., open storage containers, overly permissive IAM roles, unencrypted data). A security architecture review catches these issues before they are exploited. It also helps organizations meet compliance standards (e.g., PCI DSS, HIPAA, ISO 27001) by providing evidence of secure design. For the SOC analyst, understanding the architecture helps in incident response—knowing where logs come from, how traffic flows, and what controls are in place.
How It Works Internally
A cloud security architecture review follows a structured process: 1. Scope Definition: Identify the cloud environment (Azure subscriptions, management groups, resource groups) and the components to review (compute, network, identity, data, monitoring). 2. Data Collection: Gather configuration data using tools like Azure Resource Graph, Azure Policy, and Defender for Cloud recommendations. For example, querying all storage accounts with public network access enabled. 3. Baseline Comparison: Compare the current configuration against a security baseline, such as the MCSB or CIS benchmarks. Each control is checked: e.g., “Storage accounts should restrict network access” (MCSB control NS-2). 4. Risk Assessment: For each deviation, assess the risk level (High, Medium, Low) based on exploitability, impact, and likelihood. For instance, a storage account with public access and no encryption is high risk. 5. Recommendations: Propose remediation actions, such as enabling firewall rules, enforcing encryption, or implementing just-in-time access. 6. Reporting: Document findings in a report with severity, affected resources, and remediation steps. Use tools like Azure Workbooks to visualize findings.
Key Components, Values, Defaults, and Timers
Microsoft Cloud Security Benchmark (MCSB): The primary baseline for Azure. It includes control domains: Network Security (NS), Identity Management (IM), Privileged Access (PA), Data Protection (DP), Asset Management (AM), Logging and Threat Detection (LT), and others.
Defender for Cloud: Provides secure score (0-100%) based on compliance with recommendations. Each recommendation has a severity and a potential score increase if remediated.
Azure Policy: Enforces rules using policy definitions (e.g., “Allowed locations”). Policies can be assigned at management group, subscription, or resource group scope. Effects include Audit, Deny, DeployIfNotExists, etc.
Azure Resource Graph: Kusto Query Language (KQL) queries to explore resources. Example: where type =~ 'microsoft.storage/storageaccounts' and properties.networkAcls.defaultAction == 'Allow'.
Logging and Monitoring: Review must include diagnostic settings—are logs sent to Log Analytics workspace? Are they retained for at least 90 days (common requirement)? Is Sentinel enabled?
Network Segmentation: Check for network security groups (NSGs), Azure Firewall, virtual network peering, and private endpoints. Default NSG rules allow inbound from VNet and load balancer, deny all other inbound; allow outbound to internet.
Identity: Review Azure AD roles, conditional access policies, managed identities, and service principals. Check for unused roles, excessive permissions, and lack of MFA.
Data Protection: Encryption at rest (Azure Storage Service Encryption, Azure Disk Encryption), encryption in transit (TLS 1.2+), and key management (Azure Key Vault, customer-managed keys).
Timers: Review frequency—quarterly or after major changes. Some controls have time-based requirements: e.g., “Accounts with owner permissions on subscriptions should be MFA-enabled within 30 days of creation” (MCSB IM-3).
Configuration and Verification Commands
Azure CLI: az security task list to list security recommendations. az policy assignment list to view policies.
PowerShell: Get-AzSecurityAssessment for security assessments. Get-AzPolicyState for policy compliance.
KQL in Azure Resource Graph:
SecurityResources
| where type == 'microsoft.security/assessments'
| where properties.displayName contains 'storage account'
| project resourceId, properties.status.codeSentinel: Use KQL to query logs for suspicious activities, e.g., failed logins from unusual locations.
Interactions with Related Technologies
Defender for Cloud integrates with Azure Policy to enforce recommendations automatically. For example, if a storage account is non-compliant, a policy can deny creation or deploy a fix.
Azure Sentinel uses logs from diagnostic settings to detect threats; a review ensures all critical resources (e.g., Azure AD, Azure Activity Log) are sending logs to Sentinel.
Azure Blueprints can package policies, RBAC roles, and resource templates to enforce architecture standards across subscriptions.
Microsoft 365 Defender extends review to SaaS applications—checking for risky user behavior, compromised identities, and misconfigured apps.
Exam Focus
For SC-200, know that the review is proactive, not reactive. The exam tests your ability to use Defender for Cloud recommendations to identify misconfigurations. Key terms: secure score, MCSB, regulatory compliance dashboard, Azure Policy effects (Audit, Deny, DeployIfNotExists). Be able to interpret a compliance report and recommend changes. Common scenarios: storage accounts with public access, unencrypted disks, missing NSGs, unused user accounts, lack of MFA.
Define Scope and Objectives
Determine the boundaries of the review: which Azure subscriptions, management groups, and resource groups are included. Identify the key workloads (e.g., production vs. dev). Document business and compliance requirements (e.g., PCI DSS, HIPAA). Establish the baseline—typically the Microsoft Cloud Security Benchmark (MCSB) or CIS Azure Foundations Benchmark. For SC-200, focus on MCSB controls. This step ensures the review is targeted and relevant. Without clear scope, the review may miss critical areas or become too broad.
Collect Configuration Data
Use Azure Resource Graph, Azure Policy compliance data, and Defender for Cloud recommendations to gather current state. For example, run a KQL query to list all storage accounts with public network access enabled. Collect identity information from Azure AD (users, roles, sign-in logs). Network configuration from virtual networks, NSGs, and Azure Firewall. Also gather diagnostic settings—are all resources sending logs to a Log Analytics workspace? Use tools like Azure Resource Graph Explorer or PowerShell. Data collection is automated but must be verified for completeness.
Assess Against Security Baseline
Compare collected data against MCSB controls. For each control, determine if the resource is compliant. For example, MCSB control NS-2: “Storage accounts should restrict network access.” Check if the storage account’s firewall is enabled and default action is Deny. Use Defender for Cloud’s regulatory compliance dashboard to see pass/fail status. Note the severity: high if public access is allowed, medium if only certain IPs are allowed but not using private endpoint. Document each deviation with the specific control ID and resource.
Analyze Risks and Prioritize
For each non-compliant finding, assess the risk level. Consider: is the resource internet-facing? Does it contain sensitive data? Is there compensating control? For example, a storage account with public access but with a SAS token that expires in 1 hour is lower risk than one with anonymous access. Use the Common Vulnerability Scoring System (CVSS) or similar to assign scores. Prioritize high-risk findings for immediate remediation. For SC-200, know that Defender for Cloud’s secure score improvement actions are prioritized by risk.
Document and Recommend Remediation
Create a report summarizing findings, including resource ID, control ID, current state, risk level, and recommended action. For example: “StorageAccount1 (subscription: xxx) – MCSB NS-2 – Public network access enabled – High risk – Remediation: Enable firewall and set default action to Deny, or use private endpoint.” Provide step-by-step remediation using Azure Portal, CLI, or PowerShell. Also recommend policy enforcement to prevent future misconfigurations. Finally, present the report to stakeholders and track remediation in a ticketing system.
Scenario 1: Financial Services Company A large bank migrating to Azure must comply with PCI DSS. The security team conducts a Cloud Security Architecture Review of their new payment processing environment. They discover that several storage accounts containing transaction logs have public network access enabled (firewall default action = Allow) and no encryption at rest. The review recommends enabling Azure Storage firewall, setting default action to Deny, and using customer-managed keys (CMK) in Azure Key Vault. Additionally, they find that diagnostic settings for the storage accounts are not sending logs to a Log Analytics workspace, violating PCI DSS logging requirements. After remediation, the bank’s secure score improves by 15 points, and they pass their PCI audit. The review also identifies that virtual machines are using unmanaged disks with no encryption, leading to a recommendation to migrate to managed disks with Azure Disk Encryption.
Scenario 2: Healthcare SaaS Provider A healthcare SaaS company uses Azure to host patient records (HIPAA covered). Their annual security review reveals that Azure AD conditional access policies are not enforced for all users—some legacy service accounts bypass MFA. The review recommends creating a conditional access policy requiring MFA for all users, including service accounts where possible (using certificate-based authentication). They also find that the Azure SQL databases have auditing disabled, which is required for HIPAA. The review recommends enabling auditing and sending logs to a Log Analytics workspace monitored by Sentinel. The company also discovers that network security groups (NSGs) on subnets are missing explicit deny rules for inbound traffic from the internet, relying only on default deny. They add NSG rules to block all inbound except from specific IP ranges. The review process takes two weeks and results in a 20% reduction in attack surface.
Common Pitfalls - Scope creep: Reviewing too many resources without prioritization leads to analysis paralysis. Focus on critical assets first. - Ignoring identity: Many reviews focus on network and storage but neglect Azure AD roles and permissions. Over-privileged accounts are a top risk. - Not testing remediation: After applying changes, verify that the fix works and doesn’t break functionality. For example, enabling a storage firewall may block legitimate applications. - Lack of automation: Manual reviews are error-prone and slow. Use Azure Policy and Defender for Cloud to continuously monitor compliance.
What SC-200 Tests on This Topic The SC-200 exam (Objective 3.2) expects you to understand the process and tools for conducting a cloud security architecture review. Specifically: - Use Defender for Cloud to identify misconfigurations: Know how to interpret secure score, recommendations, and regulatory compliance dashboard. - Azure Policy and MCSB: Understand policy effects (Audit, Deny, DeployIfNotExists) and how they enforce compliance. Be able to map a finding to an MCSB control (e.g., NS-2, IM-3). - Logging and monitoring: Know that all critical resources should have diagnostic settings enabled and logs sent to a Log Analytics workspace or Sentinel. - Identity and access: Recognize excessive permissions, lack of MFA, and unused accounts as risks. - Network security: Identify open ports, missing NSGs, and public endpoints.
Common Wrong Answers and Why Candidates Choose Them 1. Choosing ‘penetration test’ over ‘architecture review’: Candidates confuse active testing with passive review. The architecture review does not exploit vulnerabilities; it checks design. 2. Selecting ‘Azure Security Center’ (old name) instead of ‘Defender for Cloud’: The exam uses the current name. Azure Security Center was renamed; always use ‘Defender for Cloud’. 3. Believing that a high secure score means no issues: The secure score is based on implemented recommendations, but it doesn’t cover all risks (e.g., misconfigured policies not yet assessed). 4. Thinking that Azure Policy can only deny, not audit: Policy can audit (log non-compliance) without blocking, which is useful for testing.
Specific Numbers and Terms - Secure score range: 0% to 100%. - MCSB control domains: NS, IM, PA, DP, AM, LT, etc. - Default NSG rules: AllowVNetInBound, AllowAzureLoadBalancerInBound, DenyAllInbound; AllowInternetOutBound. - Diagnostic settings retention: default 30 days, but compliance often requires 90+ days. - Azure Policy effects: Audit, Deny, DeployIfNotExists, AuditIfNotExists, Append, Modify, Disabled.
Edge Cases and Exceptions - Management groups: Policies applied at management group level affect all child subscriptions. A review must check inheritance. - Service endpoints vs. private endpoints: Service endpoints are less secure (still use public IP). The exam prefers private endpoints for sensitive data. - Azure AD roles: Global Administrator is too permissive; use Privileged Identity Management (PIM) for just-in-time access. - Key Vault firewall: Even with firewall enabled, Azure services can still access if ‘Allow trusted Microsoft services’ is checked. This is a common misconfiguration.
How to Eliminate Wrong Answers - If a question asks about proactive security assessment, eliminate any answer involving exploitation or scanning. - If a question mentions compliance, look for answers referencing MCSB or regulatory compliance dashboard. - For remediation, prefer answers that use Azure Policy to enforce (Deny or DeployIfNotExists) rather than manual fixes. - Remember that the review is continuous; choose answers that mention ongoing monitoring or periodic reviews.
A cloud security architecture review is a proactive evaluation of design and configuration against a baseline like the Microsoft Cloud Security Benchmark (MCSB).
Use Defender for Cloud to get a secure score (0-100%) and identify misconfigurations prioritized by risk.
Azure Policy enforces compliance through effects: Audit, Deny, DeployIfNotExists, etc.
Key areas to review: network segmentation (NSGs, firewalls), identity (MFA, roles), data protection (encryption, key management), and logging (diagnostic settings, Sentinel).
Default NSG rules allow inbound from VNet and load balancer, deny all other inbound; allow outbound to internet.
Diagnostic settings should be enabled for all critical resources with logs sent to a Log Analytics workspace for at least 90 days.
Common misconfigurations: public storage accounts, unencrypted disks, missing MFA, over-privileged roles, and disabled logging.
The review process includes scope definition, data collection, baseline comparison, risk analysis, and remediation recommendation.
For SC-200, know how to interpret Defender for Cloud recommendations and map them to MCSB controls.
Automate reviews using Azure Resource Graph, Azure Policy, and Defender for Cloud continuous assessment.
These come up on the exam all the time. Here's how to tell them apart.
Defender for Cloud
Provides a unified view of security posture with secure score.
Offers regulatory compliance dashboards (e.g., MCSB, CIS).
Includes threat detection and just-in-time VM access.
Automatically assesses resources against built-in recommendations.
Integrates with Microsoft Sentinel for incident response.
Azure Policy
Enforces organizational rules at resource creation/update.
Uses policy definitions and initiatives to manage compliance.
Effects include Audit, Deny, DeployIfNotExists, etc.
Can be assigned at management group, subscription, or resource group scope.
Focuses on governance and automation, not threat detection.
Mistake
A cloud security architecture review is the same as a vulnerability scan.
Correct
A vulnerability scan actively probes for known vulnerabilities (e.g., missing patches). An architecture review examines the design and configuration of resources against a baseline (e.g., MCSB) to find misconfigurations and compliance gaps. It does not exploit systems.
Mistake
If the secure score is 100%, the environment is fully secure.
Correct
Secure score measures implementation of Defender for Cloud recommendations, but it does not cover all risks (e.g., custom applications, zero-day exploits, or misconfigured policies not yet assessed). A 100% score means all tracked recommendations are applied, but other security controls may be missing.
Mistake
Azure Policy can only enforce by denying non-compliant resources.
Correct
Azure Policy has multiple effects: Audit (logs non-compliance without blocking), Deny (blocks creation/modification), DeployIfNotExists (remediates automatically), and more. Audit is useful for initial discovery without disruption.
Mistake
You need to manually check each resource during a review.
Correct
Reviews leverage automated tools like Defender for Cloud, Azure Resource Graph, and Azure Policy to collect data across thousands of resources. Manual checks are only needed for edge cases or custom configurations.
Mistake
Network security groups are sufficient to protect all inbound traffic.
Correct
NSGs provide basic stateful filtering but cannot protect against application-layer attacks. For comprehensive protection, use Azure Firewall or a Web Application Firewall (WAF) in front of web applications.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A cloud security architecture review evaluates the design and configuration of cloud resources against a security baseline (e.g., MCSB) to identify misconfigurations and compliance gaps. It is non-intrusive and does not attempt to exploit vulnerabilities. A penetration test actively simulates attacks to find exploitable weaknesses, often using tools like Metasploit. The review is proactive and preventative, while a pen test is reactive and validates defenses. For SC-200, know that the review is part of continuous compliance, not a one-time offensive test.
Navigate to Defender for Cloud in the Azure Portal. The 'Recommendations' blade lists all non-compliant resources with severity and potential score increase. The 'Regulatory Compliance' blade shows compliance with MCSB or other standards. Use the 'Inventory' blade to explore resources. You can also use Azure Resource Graph with KQL to query specific configurations. For example, to find storage accounts with public access: `SecurityResources | where type == 'microsoft.security/assessments' | where properties.displayName contains 'Storage account should restrict network access'`. The secure score gives an overall posture.
Top misconfigurations include: (1) Storage accounts with public network access enabled (default action = Allow). (2) Virtual machines using unmanaged disks without encryption. (3) Azure AD users without MFA, especially privileged roles. (4) Network security groups missing explicit deny rules for inbound traffic, relying only on default deny. (5) Diagnostic settings not enabled for critical resources like Azure Activity Log, Azure AD, or key vaults. (6) Overly permissive RBAC roles, e.g., Global Administrator assigned to many users. Remediate by enabling firewalls, enforcing encryption, requiring MFA, and enabling logging.
MCSB is a set of security best practices for Azure, organized into control domains: Network Security (NS), Identity Management (IM), Privileged Access (PA), Data Protection (DP), Asset Management (AM), Logging and Threat Detection (LT), and others. In a review, you compare your environment against MCSB controls using Defender for Cloud's regulatory compliance dashboard. Each control has a pass/fail status. For example, control NS-2 requires storage accounts to restrict network access. The review documents which controls fail and recommends remediation. MCSB is the primary baseline for SC-200.
Best practice is to perform a formal review quarterly or after any significant change (e.g., new subscription, major deployment). However, continuous monitoring via Defender for Cloud and Azure Policy provides real-time assessment. For SC-200, understand that automated tools enable continuous compliance, but manual reviews are still needed for custom configurations and to validate automated findings. Regulatory requirements may mandate specific intervals (e.g., annually for PCI DSS).
Yes, using the DeployIfNotExists effect, Azure Policy can automatically deploy remediation (e.g., enable diagnostics, enforce encryption) when a non-compliant resource is created or updated. For existing resources, remediation tasks can be triggered manually or on a schedule. However, not all misconfigurations can be auto-remediated (e.g., removing public access may require manual approval). Policy effects like Audit and Deny help enforce compliance without automatic fixes.
Sentinel is not directly used for the review itself, but the review ensures that all critical resources are sending logs to a Log Analytics workspace that feeds Sentinel. The review checks diagnostic settings, data retention (at least 90 days), and whether Sentinel is ingesting logs from Azure AD, Azure Activity, and other sources. A well-architected logging pipeline is essential for threat detection. Sentinel can also be used to query logs for historical anomalies during the review.
You've just covered Cloud Security Architecture Review — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?