| IM-1 |
nan |
Centralize identity and authentication while ensuring isolation |
Parent |
Protect users' identities |
A Microsoft Entra administrator should be provisioned for PostgreSQL servers |
Use a centralized identity and authentication system to govern your organization's identities and authentications for cloud and non-cloud resources. While centralizing the identity and authentication, you should also ensure you segregate and isolate identities based on enterprise-wide strategy. The goal is to ensure that production environments are managed using credentials and identities that are separate from those used for day-to-day access. The segregate and isolate identities based on enterprise-wide strategy may include: Enforce Least Privilege Access for IdentitiesSegregate Administrative and Non-Administrative IdentitiesIsolate Identities Across EnvironmentsImplement Workload Identity SegregationEnforce Identity Boundary Separation Across Tenants |
Unauthorized Access:Decentralized or local authentication systems often lead to inconsistent security policies, weak password practices, or unmonitored accounts, allowing attackers to exploit misconfigured or outdated credentials to gain access to sensitive resources (e.g., via brute force or stolen credentials).Credential Theft and Reuse:Fragmented identity systems increase the risk of credentials being stored insecurely (e.g., in plaintext or weak hashes) or reused across systems, enabling attackers to harvest credentials from one compromised system and use them elsewhere (e.g., via phishing or credential dumping).Inconsistent Access Control:Without centralized governance, disparate systems may have varying access policies, leading to over-privileged accounts or orphaned accounts that attackers can exploit to escalate privileges or access unauthorized resources.Lack of Visibility and Monitoring:Decentralized authentication lacks unified logging and monitoring, making it difficult to detect suspicious activities, such as unauthorized login attempts or anomalous user behavior, increasing the risk of undetected breaches. |
Initial Access (TA0001): Exploitation of weak or decentralized authentication mechanisms, such as local accounts with default credentials or outdated protocols, enabling attackers to gain unauthorized entry (e.g., T1078 - Valid Accounts). |
Scenario:A financial services organization needs centralized identity management with strict isolation between production, development, and partner environments to comply with regulations and prevent lateral movement. Implementation Steps: Deploy Microsoft Entra ID as centralized identity provider:Create primary tenant (contoso.onmicrosoft.com) for corporate identityConfigureMicrosoft Entra Connect Syncto synchronize on-premises AD usersEnable Entra ID Protection for risk-based policies and Conditional Access requiring MFA for adminsConfigure SSO for SaaS apps (Salesforce, ServiceNow, GitHub)Deploy managed identities for Azure resources, eliminate local authentication on Azure SQL/StorageEnable passwordless authentication withFIDO2 keysand Windows HelloDesign management group hierarchy for isolation: Tenant Root Group |
Must have |
AC-2, AC-3, AC-4, AC-6, SC-2, SC-7 |
1.4.2, 7.2.1, 7.2.2, 8.2.1 |
6.7, 12.5, 16.1 |
PR.AA-1, PR.AC-1, PR.AC-7 |
A.5.15, A.5.16, A.8.2 |
CC6.1, CC6.2, CC6.6 |
|
|
|
|
|
An Azure Active Directory administrator should be provisioned for SQL servers |
|
|
|
├── Corporate Production (finance-prod-sub, hr-prod-sub) |
|
|
|
|
|
|
|
|
|
|
|
|
App Service apps should have local authentication methods disabled for FTP deployments |
|
|
Credential Access (TA0006): Theft of credentials from fragmented identity systems, exploiting insecure storage (e.g., plaintext passwords in local systems) or weak authentication methods, facilitating credential dumping or reuse (e.g., T1003 - OS Credential Dumping). |
├── Corporate Non-Production (dev-sub, test-sub) |
|
|
|
|
|
|
|
|
|
|
|
|
App Service apps should have local authentication methods disabled for SCM site deployments |
|
|
|
├── Partner Integration (partner-sub) |
|
|
|
|
|
|
|
|
|
|
|
|
Application Insights components should block non-Azure Active Directory based ingestion. |
|
|
Privilege Escalation (TA0004): Leveraging inconsistent access controls in non-centralized systems to exploit over-privileged or orphaned accounts, allowing attackers to elevate access to sensitive resources (e.g., T1078 - Valid Accounts). |
└── Customer-Facing Tenant (customer-prod-sub, customer-staging-sub) Implement identity segregation:Production identities:Dedicated admin accounts with PAWs, no dev/test accessDevelopment identities:Standard accounts with elevated permissions in dev onlyPartner identities:Microsoft Entra B2Bwith time-limited accessCustomer identities:Separate tenant usingMicrosoft Entra External IDEnforce subscription-level isolation:Assign Azure RBAC at subscription scope (prod-admin-group: Owner on finance-prod-sub only)Apply Conditional Access requiring compliant devices for production accessConfigureAzure Policyat management group level for security baselinesEnable separate Log Analytics workspaces per environmentImplement security controls:Use subscription boundaries to isolate billing, resources, and permissionsDeployAzure Firewallto restrict inter-environment trafficEnableDefender for Cloudfor unified security monitoringStream Entra ID audit logs to Azure Monitor, alert on cross-environment access attemptsConduct quarterly access reviews usingEntra ID Governance |
|
|
|
|
|
|
|
|
|
|
|
|
Azure AI Services resources should have key access disabled (disable local authentication) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure Kubernetes Service Clusters should enable Microsoft Entra ID integration |
|
|
Defense Evasion (TA0005): Bypassing detection due to lack of centralized monitoring, enabling attackers to perform unauthorized actions without triggering alerts (e.g., T1562 - Impair Defenses). |
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure Machine Learning Computes should have local authentication methods disabled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure SQL Database should have Microsoft Entra-only authentication enabled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure SQL Database should have Microsoft Entra-only authentication enabled during creation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure SQL Managed Instance should have Microsoft Entra-only authentication enabled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure SQL Managed Instances should have Microsoft Entra-only authentication enabled during creation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Configure Azure AI Services resources to disable local key access (disable local authentication) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Container registries should have local admin account disabled. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cosmos DB database accounts should have local authentication methods disabled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Service Fabric clusters should only use Azure Active Directory for client authentication |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Storage accounts should prevent shared key access |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Storage accounts should prevent shared key access (excluding storage accounts created by Databricks) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Synapse Workspaces should have Microsoft Entra-only authentication enabled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Synapse Workspaces should use only Microsoft Entra identities for authentication during workspace creation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VPN gateways should use only Azure Active Directory (Azure AD) authentication for point-to-site users |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: Azure PostgreSQL flexible server should have Microsoft Entra Only Authentication enabled |
|
|
|
|
|
|
|
|
|
|
|
| IM-1 |
IM-1.1 |
Centralize identity and authentication |
Child |
Protect users' identities |
A Microsoft Entra administrator should be provisioned for PostgreSQL servers |
Use a centralized identity and authentication system to govern your organization's identities and authentications for cloud and non-cloud resources. While centralizing the identity and authentication, you should also ensure you segregate and isolate identities based on enterprise-wide strategy. The goal is to ensure that production environments are managed using credentials and identities that are separate from those used for day-to-day access. The segregate and isolate identities based on enterprise-wide strategy may include: Enforce Least Privilege Access for IdentitiesSegregate Administrative and Non-Administrative IdentitiesIsolate Identities Across EnvironmentsImplement Workload Identity SegregationEnforce Identity Boundary Separation Across Tenants |
nan |
nan |
Centralized identity management eliminates the security risks of fragmented authentication systems by providing consistent policy enforcement, unified monitoring, and streamlined access control across all resources. Modern cloud environments require a single authoritative identity source that supports strong authentication methods, conditional access policies, and comprehensive audit logging. Organizations adopting centralized identity systems reduce credential sprawl, improve security posture visibility, and simplify compliance while maintaining flexibility for hybrid and multi-cloud architectures. Implement centralized identity management using the following approach: Cloud identity platform adoption:Microsoft Entra ID is amultitenant, cloud-based identity and access management service that centralizes authentication, authorization, and governance for Microsoft and non-Microsoft environments that support Entra ID.StandardizeMicrosoft Entra ID to manage identities across all resources.Manage cloud resource identities:Use managed identities and workload identity federation for Microsoft cloud resources including Azure Storage, Azure Virtual Machines (Linux and Windows), Azure Key Vault, PaaS, and SaaS applications to eliminate secrets and ensure isolation.Centralize organizational resource authentication:Leverage single sign-on (SSO) and Conditional Access for organizational resources such as applications hosted on Azure, third-party applications on corporate networks, and th |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
|
|
|
|
|
An Azure Active Directory administrator should be provisioned for SQL servers |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
App Service apps should have local authentication methods disabled for FTP deployments |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
App Service apps should have local authentication methods disabled for SCM site deployments |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Application Insights components should block non-Azure Active Directory based ingestion. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure AI Services resources should have key access disabled (disable local authentication) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure Kubernetes Service Clusters should enable Microsoft Entra ID integration |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure Machine Learning Computes should have local authentication methods disabled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure SQL Database should have Microsoft Entra-only authentication enabled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure SQL Database should have Microsoft Entra-only authentication enabled during creation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure SQL Managed Instance should have Microsoft Entra-only authentication enabled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure SQL Managed Instances should have Microsoft Entra-only authentication enabled during creation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Configure Azure AI Services resources to disable local key access (disable local authentication) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Container registries should have local admin account disabled. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cosmos DB database accounts should have local authentication methods disabled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Service Fabric clusters should only use Azure Active Directory for client authentication |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Storage accounts should prevent shared key access |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Storage accounts should prevent shared key access (excluding storage accounts created by Databricks) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Synapse Workspaces should have Microsoft Entra-only authentication enabled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Synapse Workspaces should use only Microsoft Entra identities for authentication during workspace creation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VPN gateways should use only Azure Active Directory (Azure AD) authentication for point-to-site users |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: Azure PostgreSQL flexible server should have Microsoft Entra Only Authentication enabled |
|
|
|
|
|
|
|
|
|
|
|
| IM-2 |
nan |
Protect identity and authentication systems |
Parent |
Protect users' identities |
Users must authenticate with multi-factor authentication to create or update resources |
Secure your identity and authentication system as a high priority in your organization's cloud security practice. Common security controls include: Restrict privileged roles and accountsRequire strong authentications for all privileged accessMonitor and audit high risk activities |
Credential-Based Attacks: Unfederated authentication, legacy protocols (e.g., POP3, IMAP), and insecure OAuth 2.0 consent flows create exploitable access points, allowing attackers to compromise credentials or tokens (e.g., via brute force, phishing, or OAuth consent abuse) to infiltrate systems.Privilege Elevation: Over-provisioned RBAC roles, persistent privileged access, and excessive global admin assignments enable unauthorized permission gains, exploited by attackers through account takeover or privilege attribute certificate (PAC) misuse to escalate access.Resource Boundary Violations: Inconsistent subscription governance and lack of environment segregation permit cross-resource access, exploited by attackers via lateral movement (e.g., exploiting misconfigured service principals) to breach dev, test, or prod boundaries.Cross-Tenant Identity Misuse: Weak cross-tenant authentication and unverified federated identities expose multi-tenant environments, exploited by attackers through token replay or unauthorized identity federation to access external tenants.Access Persistence: Inadequate identity lifecycle management and unmonitored access reviews result in stale or excessive p |
Initial Access (TA0001): Exploitation of unfederated identity protocols or misconfigured OAuth 2.0 application consents, enabling adversaries to gain unauthorized entry (e.g., T1078 - Valid Accounts). |
Scenario:A financial services organization needs to improve identity security posture across 5,000 users and 200+ applications using continuous monitoring and risk-based protection. Implementation Steps: Establish baseline withIdentity Secure Score:Access Identity Secure Score dashboard in Microsoft Entra ID (current score: 62/100)Review prioritized recommendations: Reduce global admins (8→3), enforce MFA for privileged accounts, disable legacy authentication, restrict application consentSet target score: 85/100 within 90 daysDeployMicrosoft Entra ID Protectionfor automated risk detection:Enable risk-based policies: Require password change for high-risk users, require MFA for medium/high-risk sign-insConfigure alerts for leaked credentials, anomalous activity, privilege escalation attemptsIntegrate with Microsoft 365 Defender for correlated threat intelligenceImplement continuous monitoring:Establish weekly Secure Score reviews and daily risk detection monitoringConfigure automated remediation: Auto-block high-risk IPs, trigger password reset for compromised credentials, revoke sessions for anomalous behaviorConduct quarterly access reviews to remove stale privileged assignments Outcomes: The organization significantly improved its identity security posture through continuous monitoring and risk-based protection. The Identity Secure Score increased substantially within the target timeframe, while global administrator accounts were reduced to align with least-privilege best practices. MFA coverage reached full deployment for all privileged accounts, and legacy authentication protocols were disabled, dramatically reducing the attack surface. |
Must have |
AC-2, AC-3, IA-2, IA-4, IA-5, IA-8, SI-4 |
7.2.1, 8.2.1, 8.3.1, 8.3.2, 10.2.1 |
5.4, 6.3, 6.5, 8.2 |
PR.AA-1, PR.AC-1, DE.CM-1 |
A.5.15, A.5.16, A.5.17, A.8.5 |
CC6.1, CC6.2, CC6.6, CC7.2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Credential Access (TA0006): Theft of authentication tokens or service principal secrets from insecure identity configurations, exploiting weak storage or legacy authentication methods, facilitating credential compromise (e.g., T1110 - Brute Force). |
Automated risk detection and response capabilities shortened response times significantly, while credential-based attacks were completely eliminated through proactive monitoring and automated remediation. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Privilege Escalation (TA0004): Leveraging over-privileged RBAC assignments or misconfigured privilege attribute certificates (PAC) in identity systems, allowing adversaries to elevate access to sensitive resources (e.g., T1134 - Access Token Manipulation). |
Reference: New Identity Secure Score recommendations in General AvailabilityMonitoring & Assessing Risk with Microsoft Entra ID Protection |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Lateral Movement (TA0008): Exploitation of non-segregated subscriptions or cross-tenant identity misconfigurations, enabling adversaries to traverse environment or tenant boundaries (e.g., T1578 - Modify Cloud Compute Infrastructure). |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Persistence (TA0003): Manipulation of unmonitored identity lifecycles or orphaned service principals, allowing adversaries to maintain prolonged access through stale credentials (e.g., T1098 - Account Manipulation). |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Defense Evasion (TA0005): Exploitation of unmonitored identity activities or Kerberos ticket manipulation, enabling adversaries to conceal malicious actions like anomalous token usage (e.g., T1550 - Use Alternate Authentication Material). |
|
|
|
|
|
|
|
|
| IM-2 |
IM-2.1 |
Assess your identity secure score |
Child |
Protect users' identities |
Users must authenticate with multi-factor authentication to create or update resources |
Secure your identity and authentication system as a high priority in your organization's cloud security practice. Common security controls include: Restrict privileged roles and accountsRequire strong authentications for all privileged accessMonitor and audit high risk activities |
nan |
nan |
Identity security posture requires continuous assessment and improvement through measurable metrics that identify configuration gaps and security weaknesses. The Identity Secure Score provides actionable recommendations for strengthening authentication controls, reducing privileged access exposure, and implementing modern security features that prevent credential-based attacks. Organizations regularly reviewing their secure score identify high-impact improvements, prioritize remediation efforts, and demonstrate security maturity to stakeholders while maintaining compliance with industry frameworks. Assess and improve your identity security posture through the following practices: Evaluate Identity Secure Score:UseIdentity Secure Scoreto assess your identity security posture and address configuration gaps, evaluating administrative role assignments, MFA enforcement, legacy authentication status, and consent policies.Assign limited administrative roles:Enforce least privilege by assigning limited administrative roles and designating 2-4 global administrators for redundancy while avoiding over-provisioning.Enable identity protection policies:Enable user and sign-in risk policies via Microsoft Entra ID Protection and block legacy authentication protocols to prevent insecure access.Enforce multifactor authentication:Require MFA for all users supporting passwordless methods (e.g., FIDO2, Windows Hello) and mandate MFA for administrative roles to secure privileged access.Enable self |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
| IM-3 |
nan |
Manage application identities securely and automatically |
Parent |
Protect applications and secrets |
App Service app slots should use managed identity |
Use managed application identities instead of creating human accounts for applications to access resources and execute code. Managed application identities provide benefits such as reducing the exposure of credentials. Automate the rotation of credentials to ensure the security of the identities. |
Exposure of Hard-Coded Credentials in Code or Configurations: Static credentials (e.g., API keys, client secrets) embedded in source code, build artifacts, or configuration files (e.g., .env, YAML) are exposed via misconfigured SCM repositories (e.g., public Git repos) or CI/CD pipelines, enabling adversaries to authenticate to cloud APIs via HTTP POST requests to token endpoints.Credential Theft via Phishing or Interception: Adversaries capture long-lived credentials or API keys through spearphishing campaigns (e.g., OAuth consent phishing) or MitM attacks intercepting unencrypted HTTP/HTTPS traffic, exploiting weak TLS configurations to acquire tokens for cloud service authentication.Unauthorized Access from Weak or Reused Credentials: Insecurely configured credentials (e.g., low-entropy passwords, reused API keys) are vulnerable to brute-force enumeration (e.g., password spraying via REST API calls) or credential stuffing attacks leveraging breached datasets, granting access to cloud management APIs.Persistent Access via Rogue or Orphaned Accounts: Adversaries create unauthorized accounts or exploit unrevoked credentials from decommissioned resources, embedding static keys in cl |
Initial Access (TA0001): exploiting hard-coded credentials or compromised user accounts embedded in cloud application code or configuration files, leveraging phishing (T1566.001) to steal passwords or exploiting misconfigured public-facing APIs (T1190) to authenticate via OAuth 2.0 or API key-based endpoints. |
Scenario:A healthcare organization with 50+ applications requires secure authentication for HIPAA compliance, eliminating credentials from code and configuration files. Implementation Steps: Deploymanaged identitiesfor Azure services:Enable system-assigned identities for 30 App Services accessing SharePoint and Azure SQLConfigure user-assigned identities for 15 Azure Functions accessing Key Vault and Service BusDeploy managed identities on VMs for background processing jobsRefactor application code with Azure.Identity SDK (DefaultAzureCredential)Configureservice principalsfor legacy systems:Create 5 service principals with certificate-based authentication (X.509 from organizational PKI)Store certificates in Azure Key Vault with automatic rotationAssign least-privilege RBAC roles scoped to specific resource groupsFor CI/CD pipelines: Use client secrets with 6-month expiration and automated rotationImplement monitoring and governance:Deploy Azure Policy to audit resources without managed identitiesConfigure Defender for Cloud to detect credential exposureEstablish quarterly access reviews for service principal permissionsMonitor sign-in logs for anomalous service principal activity Outcomes: The organization successfully migrated the vast majority of applications to managed identities, eliminating the need for credential management in modern cloud-native services. |
Must have |
AC-2, AC-3, IA-2, IA-4, IA-5, IA-9, SC-12, SC-13 |
8.2.1, 8.2.2, 8.3.1, 8.5.1 |
6.7, 12.5, 16.1, 16.9 |
PR.AA-1, PR.AC-1, PR.DS-1 |
A.5.15, A.8.3, A.8.5 |
CC6.1, CC6.2 |
|
|
|
|
|
App Service apps should use managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Automation Account should have Managed Identity |
|
|
Credential Access (TA0006): targeting exposed credentials in source code repositories or unsecured storage (T1003), using brute-force attacks on weak user passwords (T1110.001) or intercepting API keys and session tokens (T1539) during cloud service authentication flows. |
Legacy systems that couldn't adopt managed identities were secured using certificate-based service principals with automatic rotation capabilities. |
|
|
|
|
|
|
|
|
|
|
|
|
Azure Data Factory linked services should use system-assigned managed identity authentication when it is supported |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure Machine Learning workspaces should use user-assigned managed identity |
|
|
Persistence (TA0003): maintaining access by creating rogue user accounts (T1136.003) or modifying cloud application configurations to embed persistent credentials (T1098.001), ensuring repeated authentication to cloud resources without detection. |
All hardcoded credentials were removed from application code and configuration files, achieving complete automation of credential rotation for service principals. |
|
|
|
|
|
|
|
|
|
|
|
|
Cognitive Services accounts should use a managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Communication service resource should use a managed identity |
|
|
Privilege Escalation (TA0004): Compromised user accounts or exposed API keys with excessive permissions are exploited to gain administrative access, abusing misconfigured role-based access controls (T1548.004) to manipulate cloud resources or management APIs. |
This comprehensive transformation eliminated all compliance audit findings related to credential management that had previously been identified. |
|
|
|
|
|
|
|
|
|
|
|
|
Function apps should use managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Managed Identity should be enabled for Container Apps |
|
|
Defense Evasion (TA0005): Attackers evade detection by forging stolen API keys or session tokens (T1606.002) to mimic legitimate cloud traffic or disabling audit logging (T1562.001), masquerading as authorized users (T1036) to avoid monitoring. |
Reference: Granting Azure Resources Access to SharePoint Online Sites Using Managed IdentityWorking with Azure Service Principal Accounts |
|
|
|
|
|
|
|
|
|
|
|
|
Stream Analytics job should use managed identity to authenticate endpoints |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity |
|
|
Collection (TA0009): harvesting hard-coded credentials, API keys, or user session data from compromised cloud instances or storage (T1213.002), targeting configuration fi |
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: A managed identity should be enabled on your machines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: Managed Identity Federated Credentials from Azure Kubernetes should be from trusted sources |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: Managed Identity Federated Credentials from GitHub should be from trusted repository owners |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: Managed Identity Federated Credentials should be from allowed issuer types |
|
|
|
|
|
|
|
|
|
|
|
| IM-3 |
IM-3.1 |
Use managed identity in supported Azure resources |
Child |
Protect applications and secrets |
App Service app slots should use managed identity |
Use managed application identities instead of creating human accounts for applications to access resources and execute code. Managed application identities provide benefits such as reducing the exposure of credentials. Automate the rotation of credentials to ensure the security of the identities. |
nan |
nan |
Managed identities eliminate credential exposure by providing Azure resources with automatically managed identities for authenticating to services supporting Microsoft Entra ID authentication. These platform-managed credentials are fully rotated and protected without requiring hard-coded secrets in source code or configuration files, reducing attack surface and operational overhead. Organizations adopting managed identities prevent credential theft, simplify secret management, and maintain security compliance while enabling seamless service-to-service authentication across Azure resources. Implement managed identities using the following steps: Choose and enable managed identity:Decide between system-assigned (tied to a single resource, auto-deleted with resource) or user-assigned (standalone, reusable across multiple resources) based on your use case. Enable the managed identity during resource creation (e.g., enable a system-assigned identity for an Azure App Service to access Key Vault).Assign least-privilege permissions:Use Azure Role-Based Access Control (RBAC) to grant the managed identity specific roles (e.g., Key Vault Secrets User or Storage Blob Data Reader) for target Azure services.Integrate authentication in application code:Use Azure SDKs (e.g., Azure.Identity in .NET, azure-identity in Python) with DefaultAzureCredential to authenticate to services like Key Vault, SQL Database, or Storage without embedding credentials. For example, in C#, use var credential = n |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
|
|
|
|
|
App Service apps should use managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Automation Account should have Managed Identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure Data Factory linked services should use system-assigned managed identity authentication when it is supported |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure Machine Learning workspaces should use user-assigned managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cognitive Services accounts should use a managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Communication service resource should use a managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Function apps should use managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Managed Identity should be enabled for Container Apps |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stream Analytics job should use managed identity to authenticate endpoints |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: A managed identity should be enabled on your machines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: Managed Identity Federated Credentials from Azure Kubernetes should be from trusted sources |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: Managed Identity Federated Credentials from GitHub should be from trusted repository owners |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: Managed Identity Federated Credentials should be from allowed issuer types |
|
|
|
|
|
|
|
|
|
|
|
| IM-3 |
IM-3.2 |
Use service principals where managed identities are not applicable |
Child |
Protect applications and secrets |
App Service app slots should use managed identity |
Use managed application identities instead of creating human accounts for applications to access resources and execute code. Managed application identities provide benefits such as reducing the exposure of credentials. Automate the rotation of credentials to ensure the security of the identities. |
nan |
nan |
Service principals provide secure authentication for services and applications that cannot use managed identities, implementing credential-based access with enhanced security controls. Organizations should prioritize certificate credentials over client secrets to reduce exposure risk, while maintaining strict permission boundaries through least-privilege RBAC assignments. Properly configured service principals enable secure automation and integration scenarios while minimizing credential theft risks through secret rotation policies and secure vault storage. Implement service principals using the following approach: Create service principal in Microsoft Entra ID:Use Microsoft Entra ID to create a service principal for services that do not support managed identities, ensuring it represents your application or service (e.g., register an app for a legacy service needing access to Azure Storage).Configure restricted permissions:Assign least-privilege permissions to the service principal using Azure Role-Based Access Control (RBAC) at the resource level (e.g., Storage Blob Data Contributor for a specific storage account).Use certificate-based credentials:Prefer certificate credentials over client secrets for enhanced security. Generate a self-signed or CA-issued certificate and upload it to the service principal in Entra ID.Fallback to client secrets if necessary:If certificates are not feasible, create a client secret in Entra ID with a defined expiration (e.g., 1 year). Securely |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
|
|
|
|
|
App Service apps should use managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Automation Account should have Managed Identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure Data Factory linked services should use system-assigned managed identity authentication when it is supported |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure Machine Learning workspaces should use user-assigned managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cognitive Services accounts should use a managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Communication service resource should use a managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Function apps should use managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Managed Identity should be enabled for Container Apps |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stream Analytics job should use managed identity to authenticate endpoints |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: A managed identity should be enabled on your machines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: Managed Identity Federated Credentials from Azure Kubernetes should be from trusted sources |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: Managed Identity Federated Credentials from GitHub should be from trusted repository owners |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Preview]: Managed Identity Federated Credentials should be from allowed issuer types |
|
|
|
|
|
|
|
|
|
|
|
| IM-4 |
nan |
Authenticate server and services |
Parent |
Protect applications and secrets |
API Management calls to API backends should be authenticated |
Authenticate remote servers and services from your client side to ensure you are connecting to trusted server and services. The most common server authentication protocol is Transport Layer Security (TLS), where the client-side (often a browser or client device) verifies the server by verifying the server's certificate was issued by a trusted certificate authority. Note: Mutual authentication can be used when both the server and the client authenticate one another. |
Unauthorized Access: Attackers exploit missing or flawed authentication to impersonate services or clients, accessing APIs, storage, or compute resources. |
Initial Access (TA0001): Attackers exploit weak authentication in service-to-service or client-to-service flows, using stolen client credentials (T1078.004) or phishing for user tokens (T1566.002) to infiltrate environments. For example, a misconfigured OAuth 2.0 app registration allows unauthorized API access (T1133) via forged tokens, granting entry to storage or compute resources. |
Scenario:A payment processing company must secure API communications between mobile applications, backend services, and payment gateways to meet PCI-DSS compliance. |
Must have |
IA-9, SC-8, SC-13, SC-23 |
4.2.1, 6.2.4, 8.2.1 |
3.10, 9.2, 13.3 |
PR.DS-2, PR.DS-5 |
A.5.14, A.8.24 |
CC6.6, CC6.7 |
|
|
|
|
|
API Management calls to API backends should not bypass certificate thumbprint or name validation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
API endpoints in Azure API Management should be authenticated |
|
This enables data exfiltration, payload injection, or system takeover. |
Credential Access (TA0006): Adversaries target exposed client secrets, certificates, or JWTs in code repositories, logs, or unsecured vaults (T1552.001). Techniques include scraping service principal credentials from CI/CD pipelines (T1552.004) or intercepting refresh tokens during client authentication (T1539), enabling persistent access to protected APIs. |
They need to prevent man-in-the-middle attacks with mutual authentication. Implementation Steps: EnforceTLS 1.2+ for all services:Configure minimum TLS version (1.2+) across all Azure App Services and API ManagementDeploy trusted SSL/TLS certificates from DigiCert for all custom domainsEnable HTTPS-only mode to redirect HTTP requestsConfigure Azure SQL Database with "Encrypt=True" and "TrustServerCertificate=False"Implement mutual TLS (mTLS) for critical APIs:Enable client certificate authentication in App Service configurationUpload trusted client certificate CA to App ServiceConfigure API Management to validate client certificates (thumbprint, expiration, issuer)Issue unique client certificates for each partner/mobile app versionStore certificates in Azure Key Vault with appropriate access controlsCertificate lifecycle management:Enable automatic certificate rotation for Azure-managed certificatesSet up alerts for certificates expiring within 60 daysImplementOCSP (Online Certificate Status Protocol)checkingConfigure quarterly certificate revocation testingClient application certificate validation:Implementcertificate pinningfor mobile banking apps (iOS/Android)Validate server certificate chain in application codeStore client certificates in device secure enclave/keychain Outcomes: The organization achieved complete encryption of all API communications using modern TLS standards, with mutual TLS implemented for high-value API endpoints requiring enhanced security. Man-in-the-middle attacks were completely eliminated post-implementation, while certificate management issues causing service outages were resolved through automation. Full PCI-DSS compliance was achieved across all requirements, with automated certificate lifecycle management ensuring continuous security without operational overhead. |
|
|
|
|
|
|
|
|
|
|
|
|
Azure SQL Database should be running TLS version 1.2 or newer |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For example, an unauthenticated service-to-service request could extract sensitive blobs from Azure Storage, while a client bypassing validation might manipulate backend APIs directly.Credential Theft or Leakage: Hardcoded or exposed credentials (e.g., client secrets, tokens) in code, configs, or logs are harvested by attackers, granting persistent resource access. |
Collection (TA0009): Attackers harvest authentication artifacts like access tokens or session data from compromised resources (T1213.002). This includes extracting hardcoded secrets from application configs (T1552.001) or capturing in-transit tokens via MITM on unsecured service-to-service calls (T1040), fueling further attacks. |
Reference: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A stolen AAD app secret could allow indefinite impersonation of a trusted service, accessing all scoped endpoints until revoked. |
Privilege Escalation (TA0004): Compromised service principals or user accounts with excessive role-based permissions are abused to gain elevated access (T1078.004). Attackers exploit misconfigured app permissions (T1548.004) to modify resource configurations or assign admin roles, escalating control over systems or tenants. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Weak secret rotation or unencrypted storage amplifies exposure.Man-in-the-Middle (MITM) Attacks: Adversaries intercept unsecured communications, stealing tokens or altering requests. |
Defense Evasion (TA0005): Attackers forge stolen tokens (T1606.002) to mimic legitimate traffic or m |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Without mutual authentication, attackers can spoof identities, compromising data integrity. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For instance, an unencrypted service-to-service call might leak JWTs, enabling forged API requests. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Weak TLS ciphers or missing certificate validation heightens vulnerability.Privilege Escalation: Overl |
|
|
|
|
|
|
|
|
|
| IM-4 |
IM-4.1 |
Authenticate server and services |
Child |
Protect applications and secrets |
API Management calls to API backends should be authenticated |
Authenticate remote servers and services from your client side to ensure you are connecting to trusted server and services. The most common server authentication protocol is Transport Layer Security (TLS), where the client-side (often a browser or client device) verifies the server by verifying the server's certificate was issued by a trusted certificate authority. Note: Mutual authentication can be used when both the server and the client authenticate one another. |
nan |
nan |
Server and service authentication establishes trust relationships between distributed components, preventing man-in-the-middle attacks and service impersonation threats. Transport Layer Security (TLS) provides the standard mechanism for server authentication where clients verify server certificates issued by trusted certificate authorities before establishing secure communications. Organizations enforcing TLS authentication across all service communications protect data in transit, prevent credential interception, and maintain secure service-to-service interactions essential for zero-trust architectures. Implement server and service authentication through the following practices: Enable TLS authentication for all services:Many Azure services support TLS authentication by default. For services that don't support TLS authentication by default or support disabling TLS, ensure it is always enabled to support server/client authentication.Verify certificate trust in client applications:Your client application should be designed to verify server/client identity by verifying the server's certificate was issued by a trusted certificate authority during the handshake stage.Implement mutual TLS where applicable:Services such as API Management and API Gateway support TLS mutual authentication for enhanced security where both server and client authenticate one another. |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
|
|
|
|
|
API Management calls to API backends should not bypass certificate thumbprint or name validation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
API endpoints in Azure API Management should be authenticated |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure SQL Database should be running TLS version 1.2 or newer |
|
|
|
|
|
|
|
|
|
|
|
| IM-5 |
nan |
Use single sign-on (SSO) for application access |
Parent |
Protect users' identities |
No Azure Policy available |
Implement single sign-on (SSO) to streamline user authentication across cloud services, SaaS applications, and on-premises environments, enhancing user experience and security. SSO allows users to log in once via a trusted identity provider and access all authorized resources without repeated logins. This reduces password fatigue, minimizes credential sprawl, and mitigates risks like phishing, brute-force attacks, and exposed credentials by enforcing centralized MFA, consistent TLS, and unified monitoring, ensuring secure and efficient access management. |
Exposure of Application-Specific Credentials in Code or Configurations: Plaintext credentials (e.g., API keys, passwords) embedded in source code or configuration files (e.g., .env, JSON) are exposed via misconfigured repositories or CI/CD pipelines, enabling adversaries to authenticate to cloud or on-premises services via API endpoints.Credential Theft via Phishing Across Multiple Login Interfaces: Adversaries capture credentials through spear-phishing (e.g., fake app-specific login pages) or intercept unencrypted traffic to varied login endpoints, exploiting inconsistent TLS configurations to acquire credentials for multiple systems.Unauthorized Access from Weak or Reused Credentials: Low-entropy or reused credentials across disparate apps are vulnerable to brute-force attacks (e.g., password spraying via app login APIs) or credential stuffing, granting access to cloud services, SaaS, or on-premises resources.Persistent Access via Untracked Application Accounts: Adversaries exploit unmanaged accounts in individual app databases, embedding credentials in configurations to maintain access through repeated authentication to siloed systems without centralized revocation.Detection Eva |
Credential Access (TA0006) -Phishing: Spearphishing Link (T1566.001): Fake login pages mimic app endpoints to capture credentials, exploiting inconsistent TLS in non-SSO systems. Credential Access (TA0006) -Unsecured Credentials: Credentials in Files (T1552.001): Plaintext API keys or passwords in misconfigured Git repos or CI/CD artifacts are extracted. Initial Access (TA0001) - Valid Accounts (T1078): Stolen credentials authenticate to Azure, SaaS, or on-premises apps, bypassing MFA in non-SSO setups. Persistence (TA0003)- Account Manipulation (T1098): Unmanaged app accounts or embedded credentials ensure repeated access without revocation. Defense Evasion (TA0005)- Masquerading (T1036): Stolen credentials mimic legitimate API traffic to evade detection in siloed systems. |
Scenario:A global manufacturing company with 12,000 employees, 500 partners, and 50,000 customers needs to consolidate authentication across 75 applications, eliminate password fatigue, and reduce help desk tickets while improving security. Implementation Steps: Configure SAML SSOfor enterprise applications:Inventory 75 applications: 45 SaaS apps (Salesforce, ServiceNow), 20 on-premises apps, 10 custom Azure appsConfigure SAML 2.0 integration for Salesforce (map Entra ID attributes, enableJIT provisioning)Set up OpenID Connect for custom Azure Web Apps using Microsoft.Identity.Web SDKDeploy Azure AD Application Proxy for 20 on-premises legacy apps withKerberos Constrained DelegationConfigure external identities for partners (B2B):Invite 500 partner users via B2B collaboration for project management toolsEnable federated SSO for partners to use their own organizational credentialsImplement access packages with time-bound project access (auto-expiration)Establish cross-tenant trust with 5 major partners usingcross-tenant access settingsDeploy Azure AD B2C for customers:Set up B2C tenant for 50,000 customers accessing support portalsConfigure social identity providers (Microsoft, Google, Facebook)Protect customer APIs using OAuth 2.0 with B2C-issued tokensBrand authentication pages with company logoImplement conditional access and governance:Configure risk-based policies (high-risk users require password change + MFA, block legacy auth)EnableSCIM-based user provisioningfor Salesforce, ServiceNow, WorkdayImplement HR-driven lifecycle: Auto-provision within 4 hours, auto-revoke within 1 hourEstablish quarterly access reviews for partners and annual certification for sensitive apps Outcomes: The organization successfully enabled SSO across a large application portfolio serving employees, partners, and customers, dramatically improving both security and user experience. |
Must have |
IA-2, IA-4, IA-8, AC-2 |
8.2.1, 8.2.2, 8.3.1 |
6.3, 6.5, 12.5 |
PR.AA-1, PR.AC-1 |
A.5.15, A.5.16 |
CC6.1, CC6.2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Password reset tickets decreased significantly, while users gained substantial productivity through elimination of repeated login prompts. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Phishing susceptibility dropped sharply due to fewer credential exposure points. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Partner onboarding time was dramatically reduced through automated access packages, and customer satisfaction increased notably through seamless social login integration. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Most significantly, security incidents related to weak passwords were completely eliminated. |
|
|
|
|
|
|
|
| IM-5 |
IM-5.1 |
Use single sign-on (SSO) for application access |
Child |
Protect users' identities |
No Azure Policy available |
Implement single sign-on (SSO) to streamline user authentication across cloud services, SaaS applications, and on-premises environments, enhancing user experience and security. SSO allows users to log in once via a trusted identity provider and access all authorized resources without repeated logins. This reduces password fatigue, minimizes credential sprawl, and mitigates risks like phishing, brute-force attacks, and exposed credentials by enforcing centralized MFA, consistent TLS, and unified monitoring, ensuring secure and efficient access management. |
nan |
nan |
Single sign-on eliminates password fatigue and credential sprawl by enabling users to authenticate once and access all authorized resources without repeated logins. SSO through a centralized identity provider enforces consistent security policies including multi-factor authentication, conditional access, and unified audit logging across all applications. Organizations implementing SSO reduce phishing vulnerability, simplify user experience, and maintain comprehensive visibility into access patterns while supporting diverse user populations including employees, partners, and customers. Implement SSO across your environment using the following approach: Plan SSO implementation:Identify applications (cloud, on-premises, customer-facing) and Azure resources requiring SSO. Categorize users as enterprise (employees), external trusted (partners), or public (customers). Decide protocols (e.g., OpenID Connect, SAML 2.0, OAuth 2.0) based on app compatibility.Configure SSO in Microsoft Entra ID:Leverage Microsoft Entra ID to streamline access to customer-facing workload applications throughsingle sign-on (SSO), eliminating the need for duplicate user accounts. Register applications in the Entra App Registration module and configure SSO settings using SAML metadata or OIDC client IDs/secrets as needed. Assign Azure RBAC roles (e.g., Contributor) for management plane access.Enable SSO for enterprise users:Sync on-premises Active Directory with Entra ID using Entra Connect enabling seamles |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
| IM-6 |
nan |
Use strong authentication controls |
Parent |
Protect users' identities |
Authentication to Linux machines should require SSH keys |
Enforce strong and phishing-resistant authentication controls (strong passwordless authentication or multi-factor authentication) with your centralized identity and authentication management system for all access to resources. Authentication based on password credentials alone is considered legacy, as it is insecure and does not stand up to popular attack methods. When deploying strong authentication, configure administrators and privileged users first, to ensure the highest level of the strong authentication method, quickly followed by rolling out the appropriate strong authentication policy to all users. Note: If legacy password-based authentication is required for legacy applications and scenarios, ensure password security best practices such as complexity requirements, are followed. |
Credential Compromise via Phishing or Interception: Attackers capture credentials through phishing or network sniffing, exploiting OAuth phishing or session hijacking to access applications and resources.Weak or Reused Credentials: Predictable or reused passwords enable brute-force attacks or credential stuffing from breached databases.Credential Exposure in Code or Configurations: Hard-coded credentials in source code or configuration files are exposed via misconfigurations or insider errors.Unauthorized Access from Compromised Accounts: Compromised accounts provide attackers broad access to applications and resources due to insufficient behavioral monitoring.Account Proliferation and Orphaned Accounts: Duplicate or abandoned accounts (e.g., for former employees) are exploited by attackers or misused.Inconsistent Security Policies Across Applications: Varying security controls (e.g., lack of MFA) across apps create exploitable vulnerabilities.Man-in-the-Middle (MitM) Attacks: Attackers intercept authentication sessions to steal credentials or tokens.Insider Threats from Over-Privileged Accounts: Excessive permissions allow intentional or accidental misuse by employees or partners. |
Credential Access (TA0006): extracting plaintext credentials (e.g., API keys, passwords) embedded in source code or configuration files (e.g., .env, JSON) from misconfigured repositories or CI/CD pipelines, using harvested credentials to authenticate to cloud or on-premises service APIs. |
Scenario:A technology company with 8,000 employees needs to eliminate password-based attacks and improve user experience by deploying phishing-resistant passwordless authentication. Implementation Steps: Enable authentication methods in Microsoft Entra ID:Navigate to Microsoft Entra admin center > Protection > Authentication methodsEnable Windows Hello for Business for all users (default Windows 10/11 device authentication)Enable Passkeys (FIDO2) with attestation enforcement set toYes(ensures only verified security keys from FIDO Alliance MDS)Enable Passkeys in Microsoft Authenticator (preview) with attestation enforcementEnable Certificate-Based Authentication (CBA) and configure trusted certificate authoritiesConfigure fallback MFA methods: Microsoft Authenticator push notifications, OATH tokens (avoid SMS/voice for privileged users)Define authentication strength policies:Create custom authentication strength "Admin Phishing-Resistant" requiring: FIDO2 security key OR Windows Hello for Business OR Platform SSO OR Certificate-based authentication (multifactor)Use built-in "Passwordless MFA strength" for standard users (includes Windows Hello, FIDO2, Authenticator passkeys, CBA)Use built-in "Multifactor authentication strength" as fallback for legacy application accessDeploy phishing-resistant authentication for privileged users (150 admins):Purchase FIDO2 security keys with USB-A/C and NFC support (YubiKey 5 Series) for cross-platform compatibilityDistribute keys to all administrators and guide them through registration in Microsoft Entra Security Info pageConfigure Windows Hello for Business on 100 Windows PAWs using TPM 2.0 withPIN complexity requirementsCreate Conditional Access policy targeting admin roles (Global Admin, Security Admin, etc.): Require "Admin Phishing-Resistant" authentication strength for all Azure portal and admin app accessResult: 100% of admin sign-ins use hardware-backed phishing-resistant methods, attestation prevents rogue device registrationRoll out passwordless authentication for end users (7,850 users):Windows users (6,500):Deploy Windows Hello for Business via Intune using TPM 2.0 or biometric sensors (fingerprint, facial recognition)Mobile users (1,200):Enablepasskeys in Microsoft Authenticator(preview) for iOS/AndroidiOS: Device-bound passkeys using Secure Enclave with FaceID/TouchIDAndroid: Device-bound passkeys using Secure Element or Trusted Execution Environment (TEE) with biometric authenticationEnable attestation via |
Must have |
AC-2, AC-3, IA-2, IA-5, IA-8, IA-11 |
7.2.1, 8.2.1, 8.3.1, 8.3.2, 8.4.2 |
6.3, 6.4, 6.5 |
PR.AA-1, PR.AC-1 |
A.5.15, A.5.17, A.5.18 |
CC6.1, CC6.2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Initial Access (TA0001): capturing credentials via spear-phishing (e.g., fake app-specific login pages, T1566.001) or intercept unencrypted traffic to disparate login endpoints, exploiting inconsistent TLS configurations to acquire credentials for multiple systems. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Initial Access (TA0001): exploiting weak or reused credentials across uncoordinated apps, leveraging brute-force attacks (e.g., password spraying via app login APIs, T1110.001) or credential stuffing to gain unauthorized access to cloud services, SaaS, or on-premises resources. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Persistence (TA0003): maintaining access by exploiting unmanaged accounts in individual app databases, embedding credentials in configurations (T1098.001) to repeatedly authenticate to siloed systems without centralized revocation. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Defense Evasion (TA0005): using stolen credentials to generate API or app requests mimicking legitimate traffic across disparate systems, evading detection (T1036) due to fragmented audit logging or lack of centralized telemetry. |
|
|
|
|
|
|
|
|
| IM-6 |
IM-6.1 |
Use strong authentication controls |
Child |
Protect users' identities |
Authentication to Linux machines should require SSH keys |
Enforce strong and phishing-resistant authentication controls (strong passwordless authentication or multi-factor authentication) with your centralized identity and authentication management system for all access to resources. Authentication based on password credentials alone is considered legacy, as it is insecure and does not stand up to popular attack methods. When deploying strong authentication, configure administrators and privileged users first, to ensure the highest level of the strong authentication method, quickly followed by rolling out the appropriate strong authentication policy to all users. Note: If legacy password-based authentication is required for legacy applications and scenarios, ensure password security best practices such as complexity requirements, are followed. |
nan |
nan |
Strong authentication prevents credential-based attacks by eliminating reliance on passwords alone, which remain vulnerable to phishing, brute force, and breach databases. Modern authentication methods including passwordless options (biometrics, security keys, certificate-based authentication) and multi-factor authentication dramatically reduce account compromise risks while improving user experience. Organizations deploying strong authentication should prioritize administrators and privileged users first to protect high-value accounts, then systematically extend coverage to all users while maintaining support for legacy scenarios requiring passwords through enhanced security policies. Implement strong authentication controls using the following methods: Deploy passwordless authentication:Use passwordless authentication as your default method with four available options: Windows Hello for Business, Microsoft Authenticator app phone sign-in, passkeys(FIDO2), and certificate-based authentication. Microsoft Entra ID supports passwordless authentication natively. In addition, customers can use on-premises authentication methods such as smart cards.Enforce multi-factor authentication:EnableAzure MFAwhich can be enforced on all users, select users, or at the per-user level based on sign-in conditions and risk factors. Follow Microsoft Defender for Cloud identity and access management recommendations for your MFA setup.Maintain password security for legacy scenarios:If legacy passwo |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
| IM-7 |
nan |
Restrict resource access based on conditions |
Parent |
Secure access |
No Azure Policy available |
Explicitly validate trusted signals to allow or deny user access to resources, as part of a zero-trust access model. Signals to validate should include strong authentication of user account, behavioral analytics of user account, device trustworthiness, user or group membership, locations and so on. |
Privilege Escalation from Over-Privileged Credentials or Accounts: Adversaries exploit shared credentials or user accounts with excessively broad permissions (e.g., blanket admin access) to invoke high-privilege cloud API operations, such as resource creation, deletion, or policy modification, via HTTP requests to management endpoints (e.g., REST APIs).Unauthorized Access via Stolen Broad-Scope Credentials: Adversaries use stolen credentials from poorly managed access systems, acquired through spearphishing or misconfigured public-facing endpoints, to authenticate to cloud services via API keys or passwords that lack granular, resource-specific restrictions.Persistent Access through Unmanaged or Excessive Accounts: Adversaries create or modify unmanaged accounts with broad permissions, embedding static credentials in cloud configurations (e.g., IaC templates) to maintain persistent access through repeated API authentications without centralized permission revocation.Detection Evasion with Broadly Scoped Credential Usage: Adversaries leverage broadly scoped credentials to generate API requests that mimic legitimate cloud traffic, evading detection due to the absence of role-specific |
Privilege Escalation (TA0004): exploiting over-privileged shared credentials or user accounts with broad access scopes, abusing permissive access controls to invoke high-privilege cloud API operations (e.g., resource creation, policy modification) across services. |
Scenario:A healthcare organization with 3,500 employees needs zero-trust access controls for 150 Azure resources and 45 applications while ensuring HIPAA compliance. UnderstandingRole-Based Access Control (RBAC) fundamentalsis essential. Implementation Steps: EstablishRBAC baseline:Define role hierarchy: Global Admin (3), Security Admin (8), Application Admin (25), Standard Users (3,464)Create custom Azure roles for healthcare scenarios (PHI Data Reader, Clinical Application Admin, Audit Reviewer)Assign roles at appropriate scopes (subscription-level for infrastructure, resource group-level for applications)Enroll 4,200 devices in Microsoft Intune for compliance trackingDeploy 8 conditional access policies:Policy 1 - MFA Baseline:All users, all cloud apps require MFA (sign-in frequency: 8 hours)Policy 2 - Privileged Role Protection:Admins require MFA + compliant device + approved client app (4-hour sessions)Policy 3 - Azure Management:Require MFA + compliant device + hybrid Azure AD joined for portal.azure.com accessPolicy 4 - Legacy Auth Block:Block POP3, IMAP, SMTP AUTH (15 temporary exceptions with 6-month sunset plan)Policy 5 - Trusted Location:Require MFA for PHI access from untrusted locations; block Tor/anonymous proxiesPolicy 6 - Risk-Based Control:Require MFA + password change for medium/high sign-in risk (Entra ID Protection integration)Policy 7 - Managed Device:Require compliant or hybrid Azure AD joined devices for SharePoint/Azure Web AppsPolicy 8 - App-Specific Sessions:30-minute sessions for financial systems, block download/copy/paste for PHIEnablecontinuous access evaluation (CAE):Immediate token revocation when user disabled, password changed, or moved to high-risk locationTokens revoked within 15 minutes for critical eventsMonitoring and optimization:Review Conditional Access insights weekly (policy impact, user experience metrics)Manage 45 exceptions (break-glass accounts, legacy systems) with quarterly reviewsMonthly policy review meetings with stakeholders |
Must have |
AC-2, AC-3, AC-6, AC-16 |
7.2.1, 7.2.2, 7.2.3 |
3.3, 6.4, 6.8, 13.5 |
PR.AC-1, PR.AC-4, PR.AA-1 |
A.5.15, A.5.18, A.8.2, A.8.3 |
CC6.1, CC6.3, CC6.6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Initial Access (TA0001): leveraging stolen credentials from coarsely managed access systems, using spear-phishing or misconfigured public-facing endpoints to authenticate via API keys or passwords lacking granular restrictions. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Persistence (TA0003): maintaining access by creating or modifying unmanaged accounts with excessive permissions, embedding credentials in cloud configurations to repeatedly authenticate without role-based revocation. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Defense Evasion (TA0005): using broadly scoped credentials to mimic legitimate cloud API traffic (T1036), evading detection due to lack of role-specific audit trails or monitoring, bypassing coarse access logging mechanisms. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Collection (TA0009): harvesting sensitive data or credentials from cloud resources with overly permissive access extracting API keys or user data from storage or instances due to absent role-based access boundaries. |
|
|
|
|
|
|
|
|
| IM-7 |
IM-7.1 |
Restrict resource access based on conditions |
Child |
Secure access |
No Azure Policy available |
Explicitly validate trusted signals to allow or deny user access to resources, as part of a zero-trust access model. Signals to validate should include strong authentication of user account, behavioral analytics of user account, device trustworthiness, user or group membership, locations and so on. |
nan |
nan |
Conditional access policies enable zero-trust security by dynamically evaluating multiple signals before granting resource access, moving beyond static permissions to context-aware access control. Organizations implement conditional access to enforce adaptive security requirements such as requiring MFA for administrative actions, blocking legacy authentication protocols, or mandating compliant devices for sensitive applications. These policies provide granular control over authentication sessions while balancing security requirements with user productivity, ensuring appropriate protection levels based on real-time risk assessment. Implement conditional access controls using the following approach: Deploy Microsoft Entra Conditional Access:Use Microsoft Entra Conditional Access for granular access controls based on user-defined conditions, such as requiring user logins from certain IP ranges (or devices) to use MFA. Microsoft Entra Conditional Access allows you to enforce access controls on your organization's apps based on certain conditions.Define applicable conditions and criteria:Consider the following common use cases when defining applicable conditions and criteria for Microsoft Entra Conditional Access in your workload: Require MFA for administrative roles:Require multi-factor authentication for users with administrative roles.Require MFA for management tasks:Require multi-factor authentication for Azure management tasks.Block legacy authentication protocols:Block sign- |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
| IM-8 |
nan |
Restrict the exposure of credentials and secrets |
Parent |
Protect applications and secrets |
API Management secret named values should be stored in Azure Key Vault |
Ensure that application developers securely handle credentials and secrets: Avoid embedding the credentials and secrets into the code and configuration filesUse key vault or a secure key store service to store the credentials and secretsScan for credentials in source code. Note: This is often governed and enforced through a secure software development lifecycle (SDLC) and DevOps security process. |
Unauthorized Access: Exposed credentials (e.g., API keys, passwords) in plaintext, code repositories, or logs can be exploited by attackers to gain access to sensitive systems or data. |
Initial Access (TA0001): Exploitation of exposed credentials, such as API keys or service principal tokens in public repositories or misconfigured storage, enabling attackers to gain unauthorized entry to cloud resources (e.g., T1078 - Valid Accounts). |
Scenario:A fintech startup with developers across multiple teams experiences a security incident when an API key committed to a public GitHub repository exposes customer data, resulting in regulatory fines. |
Must have |
IA-5, SI-4, RA-5, SC-12, SC-13, SC-28 |
3.5.1, 6.3.2, 8.2.1, 8.3.2 |
16.9, 16.10, 16.12 |
DE.CM-8, PR.DS-1, PR.AC-1 |
A.5.15, A.8.3, A.8.24 |
CC6.1, CC6.6, CC7.2 |
|
|
|
|
|
Machines should have secret findings resolved |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For instance, a leaked Azure service principal key could allow an attacker to access storage accounts or virtual machines.Privilege Escalation: Compromised secrets, such as over-privileged service account tokens, enable attackers to elevate their access within the cloud environment, potentially gaining control over entire subscriptions or critical resources (e.g., using a stolen Key Vault secret to access administrative functions).Data Breach: Exposed database connection strings or storage account keys can lead to unauthorized data extraction, exposing sensitive information like customer records or intellectual property, often via public-facing misconfigurations (e.g., an open Azure Blob container).Lateral Movement: Stolen credentials allow attackers to pivot across cloud resources, exploiting trust relationships or shared secrets to access additional systems, such as moving from a compromised VM to a Kubernetes cluster using a reused token. |
Privilege Escalation (TA0004): Use of stolen, over-privileged secrets to elevate access, allowing attackers to control additional resources or subscriptions (e.g., T1078 - Valid Accounts). |
They need comprehensive secret detection and protection to prevent future credential leaks. Phase 1: Secret detection - prevent credential leaks (IM-8.1) Implement CredScan in secure application lifecycle:Integrate CredScan into Azure DevOps pipelines to scan for common secret patternsConfigure pipeline to fail if high-severity secrets detected, blocking production deploymentsInitial scan identifies exposed secrets across repositories (Storage keys, SQL connection strings, API keys, JWT signing secrets)GitHub Advanced Security secret scanning:Enable GitHub Advanced Security for all repositoriesConfigure native secret scanning to detect common token types and custom patternsEnablepush protectionto block commits containing secrets before push completesSet up alerts to trigger incident response workflowMicrosoft Defender for Cloud agentless scanning:Enable Defender for Cloud for Azure VMs, storage accounts, and container registriesConfigure agentless secrets scanning for configuration files, container images, and blob storageSet up automated alerts for secrets found in running VMs, storage accounts, and container imagesHistorical repository scanning (remediation):Use tools like Gitleaks or TruffleHog to scan entire Git history for exposed secretsIdentify credentials exposed across commits over timeImplement remediation: Rotate all identified credentials, remove secrets from Git history, educate developers Phase 2: Secret protection - centralized vault and rotation (IM-8.2) Azure Key Vault deployment:Create 3 Key Vaults by environment (Production, Staging, Development)Migrate secrets: database connection strings, third-party API keys, Azure service credentials, OAuth secrets, encryption keysUpdate microservices to retrieve secrets using Azure SDKs (Azure.Security.KeyVault.Secrets for .NET,@azure/keyvault-secretsfor Node.js, azure-keyvault-secrets for Python)Remove all hardcoded secrets from code, configuration files, and CI/CD pipelinesAutomated secret rotation:Enable automatic rotation for Azure Storage keys, SQL passwords, and service principal secretsImplement custom rotation for third-party API keys and database credentialsConfigure Key Vault RBAC with least-privilege access for applications and operatorsEnable audit logging and alerts for anomalous acc |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Collection (TA0009): Harvesting sensitive data by leveraging exposed database connection strings or storage keys, leading to unauthorized data extraction from cloud resources (e.g., T1530 - Data from Cloud Storage). |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Lateral Movement (TA0008): Pivoting across cloud resources using compromised credentials, such as reused tokens or service accounts, to access interconnected systems or virtual networks (e.g., T1021 - Remote Services). |
|
|
|
|
|
|
|
|
| IM-8 |
IM-8.1 |
Detect live secrets and credentials |
Child |
Protect applications and secrets |
API Management secret named values should be stored in Azure Key Vault |
Ensure that application developers securely handle credentials and secrets: Avoid embedding the credentials and secrets into the code and configuration filesUse key vault or a secure key store service to store the credentials and secretsScan for credentials in source code. Note: This is often governed and enforced through a secure software development lifecycle (SDLC) and DevOps security process. |
nan |
nan |
Proactive secret detection prevents credential exposure by identifying live secrets embedded in source code, configuration files, communication tools, and archived materials before attackers discover them. Organizations implementing continuous secret scanning across development pipelines, infrastructure deployments, and storage systems detect and remediate exposed credentials including API keys, connection strings, and authentication tokens. Automated detection integrated into CI/CD workflows enables rapid response to credential leaks, reducing the window of exposure and preventing unauthorized access to cloud resources and services. Implement secret detection through the following practices: Enable Azure DevOps secret scanning:If you use Azure DevOps for code management, implementAzure DevOps Credential Scannerto identify credentials within code repositories.Enable GitHub secret scanning:For GitHub repositories, use thenative secret scanning featureto identify credentials or other forms of secrets within code.Deploy agentless secrets scanning:Enable Microsoft Defender for Cloud for agentless secrets scanning on VMs, storage, and multi-cloud instances to detect secrets like connection strings in configuration files and source code repositories. |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
|
|
|
|
|
Machines should have secret findings resolved |
|
|
|
|
|
|
|
|
|
|
|
| IM-8 |
IM-8.2 |
Protect secrets and credentials |
Child |
Protect applications and secrets |
API Management secret named values should be stored in Azure Key Vault |
Ensure that application developers securely handle credentials and secrets: Avoid embedding the credentials and secrets into the code and configuration filesUse key vault or a secure key store service to store the credentials and secretsScan for credentials in source code. Note: This is often governed and enforced through a secure software development lifecycle (SDLC) and DevOps security process. |
nan |
nan |
Secure secrets management protects authentication credentials through centralized vaults, automatic rotation, and access controls preventing credential theft and unauthorized service access. Azure Key Vault provides enterprise-grade secret storage with built-in rotation capabilities for supported services, hardware security module (HSM) backing, and comprehensive audit logging. Organizations storing secrets in Key Vault accessed via managed identities eliminate hard-coded credentials, implement automatic rotation policies, and maintain compliance with security frameworks while enabling secure service-to-service authentication across cloud and hybrid environments. Protect secrets and credentials using the following practices: Store secrets in Azure Key Vault:When managed identity is not an option, ensure secrets and credentials are stored in secure locations such as Azure Key Vault instead of embedding them into code and configuration files.Implement automatic secret rotation:Azure Key Vault provides automatic rotation for supported services. For secrets that cannot be automatically rotated, ensure they are manually rotated periodically and purged when no longer in use.Access Key Vault via managed identities:Clients such as Azure Functions, Azure Apps services, and VMs can use managed identities to access Azure Key Vault securely without storing additional credentials. |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
|
|
|
|
|
Machines should have secret findings resolved |
|
|
|
|
|
|
|
|
|
|
|