| Description & Rationale | ControlSeverity | Automated | Fix Script |
|---|---|---|---|
| Minimize the number of admins/owners Each additional person in the Owner/Contributor role increases the attack surface for the entire subscription. The number of members in these roles should be kept to as low as possible. | Medium | Yes | No |
| Justify all identities that are granted with admin/owner access on your subscription. Accounts that are a member of these groups without a legitimate business reason increase the risk for your subscription. By carefully reviewing and removing accounts that shouldn't be there in the first place, you can avoid attacks if those accounts are compromised. | Medium | Yes | No |
| Mandatory central accounts must be present on the subscription Certain central accounts are expected to be present in all subscriptions to support enterprise wide functions (e.g., security scanning, cost optimization, etc.). Certain other accounts may also be required depending on special functionality enabled in a subscription (e.g., Express Route network management). The script checks for presence of such 'mandatory' and 'scenario-specific' accounts. If these are not present per the current baseline, there may be security/functionality impact for your subscription. | High | Yes | Yes |
| Deprecated/stale accounts must not be present on the subscription Deprecated accounts are ones that were once deployed to your subscription for some trial/pilot initiative (or some other purpose). These are not required any more and are a standing risk if present in any role on the subscription. | Critical | Yes | Yes |
| Do not grant permissions to external accounts (i.e., accounts outside the native directory for the subscription) Non-AD accounts (such as xyz@hotmail.com, pqr@outlook.com, etc.) present at any scope within a subscription subject your cloud assets to undue risk. These accounts are not managed to the same standards as enterprise tenant identities. They don't have multi-factor authentication enabled. Etc. | High | Yes | No |
| Service accounts cannot support MFA and should not be used for subscription activity Service accounts are typically not multi-factor authentication capable. Quite often, teams who own these accounts don't exercise due care (e.g., someone may login interactively on servers using a service account exposing their credentials to attacks such as pass-the-hash, phishing, etc.) As a result, using service accounts in any privileged role in a subscription exposes the subscription to 'credential theft'-related attack vectors. (In effect, the subscription becomes accessible after just one factor (password) is compromised...this defeats the whole purpose of imposing the MFA requirement for cloud subscriptions.) | High | No | No |
| There should not be more than 2 classic administrators The v1 (ASM-based) version of Azure resource access model did not have much in terms of RBAC granularity. As a result, everyone who needed any access on a subscription or its resources had to be added to the Co-administrator role. These individuals are referred to as 'classic' administrators. In the v2 (ARM-based) model, this is not required at all and even the count of 2 classic admins currently permitted is for backward compatibility. (Some Azure services are still migrating onto the ARM-based model so creating/operating on them needs 'classic' admin privilege.) | High | Yes | No |
| Use of management certificates is not permitted. Just like classic admins, management certificates were used in the v1 model for script/tool based automation on Azure subscriptions. These management certificates are risky because the (private) key management hygiene tends to be lax. These certificates have no role to play in the current ARM-based model and should be immediately cleaned up if found on a subscription. (VS-deployment certificates from v1 timeframe are a good example of these.) | High | Yes | No |
| Azure Security Center (ASC) must be correctly configured on the subscription The Security Center feature in Azure helps with important central settings for the subscription such as configuring a security point of contact. It also supports key policy settings (e.g., is patching configured for VMs?, is threat detection enabled for SQL?, etc.) and alerts about resources which are not compliant to those policy settings. Correctly configuring ASC is critical as it gives a baseline layer of protection for the subscription and commonly used resource types. | High | Yes | Yes |
| Pending Azure Security Center (ASC) alerts must be resolved Based on the policies that are enabled in the subscription, Azure Security Center raises alerts (which are typically indicative of resources that ASC suspects might be under attack or needing immediate attention). It is important that these alerts/actions are resolved promptly in order to eliminate the exposure to attacks. | High | Yes | No |
| Service Principal Names (SPNs) should not be Owners or Contributors on the subscription Just like AD-based service accounts, SPNs have a single credential and most scenarios that use them cannot support multi-factor authentication. As a result, adding SPNs to a subscription in 'Owners' or 'Contributors' roles is risky. | Medium | Yes | No |
| Critical application resources should be protected using a resource lock A resource lock protects a resource from getting accidentally deleted. With proper RBAC configuration, it is possible to setup critical resources in a subscription in such a way that people can perform most operations on them but cannot delete them. resource locks can help ensure that important data is not lost by accidental/malicious deletion of such resources (thus ensuring that availability is not impacted). | Medium | Yes | No |
| ARM policies should be used to audit or deny certain activities in the subscription that can impact security The AzSK subscription security setup configures a set of ARM policies which result in audit log entries upon actions that violate the policies. (For instance, an audit event is generated if someone creates a v1 resource in a subscription.) These policies help by raising visibility to potentially insecure actions. | Medium | Yes | Yes |
| Alerts must be configured for critical actions on subscription and resources The AzSK subscription security setup configures Insights-based alerts for sensitive operations in the subscription. These alerts notify the configured security point of contact about various sensitive activities on the subscription and its resources (for instance, adding a new member to subscription 'Owners' group or deleting a firewall setting or creating a new web app deployment, etc.) | High | Yes | Yes |
| Do not use custom-defined RBAC roles Custom RBAC role definitions are usually tricky to get right. A lot of threat modeling goes in when the product team works on and defines the various 'out-of-box' roles ('Owners', 'Contributors', etc.). As much as possible, teams should use these roles for their RBAC needs. Using custom roles is treated as an exception and requires a rigorous review. | Medium | Yes | No |
| Do not use any classic resources on a subscription You should use new ARM/v2 resources as the ARM model provides several security enhancements such as: stronger access control (RBAC), better auditing, ARM-based deployment/governance, access to managed identities, access to key vault for secrets, AAD-based authentication, support for tags and resource groups for easier security management, etc. | Medium | Yes | No |
| Do not use any classic virtual machines on your subscription. You should use new Az resources as the ARM model provides several security enhancements such as: stronger access control (RBAC), better auditing, ARM-based deployment/governance, access to managed identities, access to key vault for secrets, AAD-based authentication, support for tags and resource groups for easier security management, etc. | High | Yes | No |
| Verify the list of public IP addresses on your subscription Public IPs provide direct access over the internet exposing a cloud resource to all type of attacks over the public network. Hence use of public IPs should be carefully scrutinized/reviewed. | High | Yes | No |
| Enable PIM (Privileged Identity Management) for granting privileged access to subscription level roles. PIM (Privileged Identity Management) allows to manage, control, and monitor access on your subscription which helps to mitigate the risk of excessive, unnecessary or misused access rights.By using PIM, one can ensure that least required access is granted for just enough duration of time thereby eliminating risks from persistent privileged role memberships. | High | Yes | No |
| Enable PIM (Privileged Identity Management) for granting privileged access to resource group level roles. PIM (Privileged Identity Management) allows to manage, control, and monitor access on your resource group which helps to mitigate the risk of excessive, unnecessary or misused access rights.By using PIM, one can ensure that least required access is granted for just enough duration of time thereby eliminating risks from persistent privileged role memberships. Note: This control gets executed only during CA scan. | High | Yes | No |
| Mandatory tags must be set per your organization policy. Certain tags are expected to be present in all resources to support enterprise wide functions (e.g., security visibility based on environment, security scanning, cost optimization, etc.). The script checks for presence of such 'mandatory' and 'scenario-specific' tags. | High | Yes | No |
| Standard tier must be enabled for Azure Security Center. ASC standard tier enables advanced threat detection capabilities, which uses built-in behavioral analytics and machine learning to identify attacks and zero-day exploits, access and application controls to reduce exposure to network attacks and malware, and more. | High | Yes | No |
| Ensure any credentials approaching expiry are rotated soon. Periodic credential rotation is a good security hygiene practice as, over time, it minimizes the likelihood of data loss/compromise which can arise from key theft/brute forcing/recovery attacks. Credential expiry can also impact availability of existing apps. | High | Yes | No |
| Control ID, Description & Rationale | +ControlSeverity | +Automated | +Fix Script | +
|---|---|---|---|
| Azure_Subscription_AuthZ_Limit_Admin_Owner_Count Minimize the number of admins/owners Each additional person in the Owner/Contributor role + increases the attack surface for the entire subscription. The number of members in these roles should be + kept to as low as possible. |
+ Medium | +Yes | +No | +
| Azure_Subscription_AuthZ_Justify_Admins_Owners Justify all identities that are granted with admin/owner access on your + subscription. Accounts that are a member of these groups without a legitimate business + reason increase the risk for your subscription. By carefully reviewing and removing accounts that + shouldn't be there in the first place, you can avoid attacks if those accounts are compromised. |
+ Medium | +Yes | +No | +
| Azure_Subscription_AuthZ_Add_Required_Central_Accounts Mandatory central accounts must be present on the subscription Certain central accounts are + expected to be present in all subscriptions to support enterprise wide functions (e.g., security + scanning, cost optimization, etc.). Certain other accounts may also be required depending on special + functionality enabled in a subscription (e.g., Express Route network management). The script checks for + presence of such 'mandatory' and 'scenario-specific' accounts. If these are not present per the current + baseline, there may be security/functionality impact for your subscription. |
+ High | +Yes | +Yes | +
| Azure_Subscription_AuthZ_Remove_Deprecated_Accounts Deprecated/stale accounts must not be present on the subscription Deprecated accounts are + ones that were once deployed to your subscription for some trial/pilot initiative (or some other + purpose). These are not required any more and are a standing risk if present in any role on the + subscription. |
+ Critical | +Yes | +Yes | +
| Azure_Subscription_AuthZ_Dont_Use_NonAD_Identities Do not grant permissions to external accounts (i.e., accounts outside the native directory for the + subscription) Non-AD accounts (such as xyz@hotmail.com, pqr@outlook.com, etc.) present at + any scope within a subscription subject your cloud assets to undue risk. These accounts are not managed + to the same standards as enterprise tenant identities. They don't have multi-factor authentication + enabled. Etc. |
+ High | +Yes | +No | +
| Azure_Subscription_AuthZ_Dont_Use_SVC_Accounts_No_MFA Service accounts cannot support MFA and should not be used for subscription activity Service + accounts are typically not multi-factor authentication capable. Quite often, teams who own these + accounts don't exercise due care (e.g., someone may login interactively on servers using a service + account exposing their credentials to attacks such as pass-the-hash, phishing, etc.) As a result, using + service accounts in any privileged role in a subscription exposes the subscription to 'credential + theft'-related attack vectors. (In effect, the subscription becomes accessible after just one factor + (password) is compromised...this defeats the whole purpose of imposing the MFA requirement for cloud + subscriptions.) |
+ High | +No | +No | +
| Azure_Subscription_AuthZ_Limit_ClassicAdmin_Count There should not be more than 2 classic administrators The v1 (ASM-based) version of Azure + resource access model did not have much in terms of RBAC granularity. As a result, everyone who needed + any access on a subscription or its resources had to be added to the Co-administrator role. These + individuals are referred to as 'classic' administrators. In the v2 (ARM-based) model, this is not + required at all and even the count of 2 classic admins currently permitted is for backward + compatibility. (Some Azure services are still migrating onto the ARM-based model so creating/operating + on them needs 'classic' admin privilege.) |
+ High | +Yes | +No | +
| Azure_Subscription_AuthZ_Remove_Management_Certs Use of management certificates is not permitted. Just like classic admins, management + certificates were used in the v1 model for script/tool based automation on Azure subscriptions. These + management certificates are risky because the (private) key management hygiene tends to be lax. These + certificates have no role to play in the current ARM-based model and should be immediately cleaned up if + found on a subscription. (VS-deployment certificates from v1 timeframe are a good example of these.) + |
+ High | +Yes | +No | +
| Azure_Subscription_Config_Azure_Security_Center Azure Security Center (ASC) must be correctly configured on the subscription The Security + Center feature in Azure helps with important central settings for the subscription such as configuring a + security point of contact. It also supports key policy settings (e.g., is patching configured for VMs?, + is threat detection enabled for SQL?, etc.) and alerts about resources which are not compliant to those + policy settings. Correctly configuring ASC is critical as it gives a baseline layer of protection for + the subscription and commonly used resource types. |
+ High | +Yes | +Yes | +
| Azure_Subscription_Audit_Resolve_Azure_Security_Center_Alerts Pending Azure Security Center (ASC) alerts must be resolved Based on the policies that are + enabled in the subscription, Azure Security Center raises alerts (which are typically indicative of + resources that ASC suspects might be under attack or needing immediate attention). It is important that + these alerts/actions are resolved promptly in order to eliminate the exposure to attacks. |
+ High | +Yes | +No | +
| Azure_Subscription_AuthZ_Dont_Add_SPNs_as_Owner Service Principal Names (SPNs) should not be Owners or Contributors on the subscription Just + like AD-based service accounts, SPNs have a single credential and most scenarios that use them cannot + support multi-factor authentication. As a result, adding SPNs to a subscription in 'Owners' or + 'Contributors' roles is risky. |
+ Medium | +Yes | +No | +
| Azure_Subscription_SI_Lock_Critical_Resources Critical application resources should be protected using a resource lock A resource lock + protects a resource from getting accidentally deleted. With proper RBAC configuration, it is possible to + setup critical resources in a subscription in such a way that people can perform most operations on them + but cannot delete them. resource locks can help ensure that important data is not lost by + accidental/malicious deletion of such resources (thus ensuring that availability is not impacted). |
+ Medium | +Yes | +No | +
| Azure_Subscription_Config_ARM_Policy ARM policies should be used to audit or deny certain activities in the subscription that can impact + security The AzSK subscription security setup configures a set of ARM policies which result + in audit log entries upon actions that violate the policies. (For instance, an audit event is generated + if someone creates a v1 resource in a subscription.) These policies help by raising visibility to + potentially insecure actions. |
+ Medium | +Yes | +Yes | +
| Azure_Subscription_Audit_Configure_Critical_Alerts Alerts must be configured for critical actions on subscription and resources The AzSK + subscription security setup configures Insights-based alerts for sensitive operations in the + subscription. These alerts notify the configured security point of contact about various sensitive + activities on the subscription and its resources (for instance, adding a new member to subscription + 'Owners' group or deleting a firewall setting or creating a new web app deployment, etc.) |
+ High | +Yes | +Yes | +
| Azure_Subscription_AuthZ_Custom_RBAC_Roles Do not use custom-defined RBAC roles Custom RBAC role definitions are usually tricky to get + right. A lot of threat modeling goes in when the product team works on and defines the various + 'out-of-box' roles ('Owners', 'Contributors', etc.). As much as possible, teams should use these roles + for their RBAC needs. Using custom roles is treated as an exception and requires a rigorous review. |
+ Medium | +Yes | +No | +
| Azure_Subscription_SI_Classic_Resources Do not use any classic resources on a subscription You should use new ARM/v2 resources as + the ARM model provides several security enhancements such as: stronger access control (RBAC), better + auditing, ARM-based deployment/governance, access to managed identities, access to key vault for + secrets, AAD-based authentication, support for tags and resource groups for easier security management, + etc. |
+ Medium | +Yes | +No | +
| Azure_Subscription_SI_Dont_Use_Classic_VMs Do not use any classic virtual machines on your subscription. You should use new Az + resources as the ARM model provides several security enhancements such as: stronger access control + (RBAC), better auditing, ARM-based deployment/governance, access to managed identities, access to key + vault for secrets, AAD-based authentication, support for tags and resource groups for easier security + management, etc. |
+ High | +Yes | +No | +
| Azure_Subscription_NetSec_Justify_PublicIPs Verify the list of public IP addresses on your subscription Public IPs provide direct access + over the internet exposing a cloud resource to all type of attacks over the public network. Hence use of + public IPs should be carefully scrutinized/reviewed. |
+ High | +Yes | +No | +
| Azure_Subscription_AuthZ_Dont_Grant_Persistent_Access Enable PIM (Privileged Identity Management) for granting privileged access to subscription level + roles. PIM (Privileged Identity Management) allows to manage, control, and monitor access + on your subscription which helps to mitigate the risk of excessive, unnecessary or misused access + rights.By using PIM, one can ensure that least required access is granted for just enough duration of + time thereby eliminating risks from persistent privileged role memberships. |
+ High | +Yes | +No | +
| Azure_Subscription_AuthZ_Dont_Grant_Persistent_Access_RG Enable PIM (Privileged Identity Management) for granting privileged access to resource group level + roles. PIM (Privileged Identity Management) allows to manage, control, and monitor access + on your resource group which helps to mitigate the risk of excessive, unnecessary or misused access + rights.By using PIM, one can ensure that least required access is granted for just enough duration of + time thereby eliminating risks from persistent privileged role memberships. Note: This control + gets executed only during CA scan. |
+ High | +Yes | +No | +
| Azure_Subscription_Config_Add_Required_Tags Mandatory tags must be set per your organization policy. Certain tags are expected to be + present in all resources to support enterprise wide functions (e.g., security visibility based on + environment, security scanning, cost optimization, etc.). The script checks for presence of such + 'mandatory' and 'scenario-specific' tags. |
+ High | +Yes | +No | +
| Azure_Subscription_Config_ASC_Tier Standard tier must be enabled for Azure Security Center. ASC standard tier enables advanced + threat detection capabilities, which uses built-in behavioral analytics and machine learning to identify + attacks and zero-day exploits, access and application controls to reduce exposure to network attacks and + malware, and more. |
+ High | +Yes | +No | +
| Azure_Subscription_Check_Credential_Rotation Ensure any credentials approaching expiry are rotated soon. Periodic credential rotation is + a good security hygiene practice as, over time, it minimizes the likelihood of data loss/compromise + which can arise from key theft/brute forcing/recovery attacks. Credential expiry can also impact + availability of existing apps. |
+ High | +Yes | +No | +