CIS Microsoft Azure Foundations Benchmark v3.0.0

Level 1

2 Identity

2.1 Security Defaults (Per-User MFA)

[IMPORTANT - Please read the section overview: If your organization pays for Microsoft Entra ID licensing (included in Microsoft 365 E3, E5, or F5, and EM&S E3 or E5 licenses) and CAN use Conditional Access, ignore the recommendations in this section and proceed to the Conditional Access section.]Security defaults in Microsoft Entra ID make it easier to be secure and help protect your organization. Security defaults contain preconfigured security settings for common attacks.Security defaults is available to everyone. The goal is to ensure that all organizations have a basic level of security enabled at no extra cost. You may turn on security defaults in the Azure portal.

If your tenant was created on or after October 22, 2019, security defaults may already be enabled in your tenant.

Audit from Azure PortalTo ensure security defaults is enabled in your directory:1. From Azure Home select the Portal Menu.2. Browse to Microsoft Entra ID > Properties.3. Select Manage security defaults.4. Under Security defaults, verify that Enabled (recommended) is selected.

This recommendation should be implemented initially and then may be overridden by other service/product specific CIS Benchmarks. Administrators should also be aware that certain configurations in Microsoft Entra ID may impact other Microsoft services such as Microsoft 365.

Manual

Security defaults provide secure default settings that we manage on behalf of organizations to keep customers safe until they are ready to manage their own identity security settings.For example, doing the following:- Requiring all users and admins to register for MFA.- Challenging users with MFA - when necessary, based on factors such as location, device, role, and task. - Disabling authentication from legacy authentication clients, which can’t do MFA.

Remediate from Azure PortalTo enable security defaults in your directory:1. From Azure Home select the Portal Menu.1. Browse to Microsoft Entra ID > Properties.1. Select Manage security defaults.1. Under Security defaults, select Enabled (recommended).1. Select Save.

This recommendation differs from the Microsoft 365 Benchmark. This is because the potential impact associated with disabling Security Defaults is dependent upon the security settings implemented in the environment. It is recommended that organizations disabling Security Defaults implement appropriate security settings to replace the settings configured by Security Defaults.

Level 1

2 Identity

2.1 Security Defaults (Per-User MFA)

[IMPORTANT - Please read the section overview: If your organization pays for Microsoft Entra ID licensing (included in Microsoft 365 E3, E5, or F5, and EM&S E3 or E5 licenses) and CAN use Conditional Access, ignore the recommendations in this section and proceed to the Conditional Access section.]Enable multi-factor authentication for all roles, groups, and users that have write access or permissions to Azure resources. These include custom created objects or built-in roles such as;- Service Co-Administrators- Subscription Owners- Contributors

By default, multi-factor authentication is disabled for all users.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select the Microsoft Entra ID blade1. Under Manage, click Roles and administrators1. Take note of all users with the role Service Co-Administrators, Owners or Contributors1. Return to the Overview1. Under Manage, click Users1. Click on the Per-User MFA button in the top row menu1. Ensure that Status is Enabled for all noted usersAudit from REST APIFor Every Subscription, For Every Tenant Step 1: Identify Users with Administrative Access 1. List All Users Using Microsoft Graph API: GET https://graph.microsoft.com/v1.0/users Capture id and corresponding userPrincipalName ('$uid', '$userPrincipalName') 2. List all Role Definitions Using Azure management API: https://management.azure.com/subscriptions/:subscriptionId/providers/Microsoft.Authorization/roleDefinitions?api-version=2017-05-01 Capture Role Definition IDs/Name ('$name') and role names ('$properties/roleName') where 'properties/roleName' contains (Owner or *contributor or admin ) 3. List All Role Assignments (Mappings $A.uid to $B.name) Using Azure Management API: GET https://management.azure.com/subscriptions/:subscriptionId/providers/Microsoft.Authorization/roleassignments?api-version=2017-10-01-previewFind all administrative roles ($B.name) in 'Properties/roleDefinitionId' mapped with user ids ($A.id) in 'Properties/principalId' where 'Properties/principalType' == 'User' 4. Now Match ($CProperties/principalId) with $A.uid and get $A.userPrincipalName save this as D.userPrincipalNameStep 2: Run Graph PowerShell command: get-mguser -All | where {$_.StrongAuthenticationMethods.Count -eq 0} | Select-Object -Property UserPrincipalNameIf the output contains any of the $D.userPrincipalName, then this recommendation is non-compliant.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: e3e008c3-56b9-4133-8fd7-d3347377402a - Name: 'Accounts with owner permissions on Azure resources should be MFA enabled'- Policy ID: 931e118d-50a1-4457-a5e4-78550e086c52 - Name: 'Accounts with write permissions on Azure resources should be MFA enabled'

Users would require two forms of authentication before any access is granted. Additional administrative time will be required for managing dual forms of authentication when enabling multi-factor authentication.

Manual

Multi-factor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted. Multi-factor authentication provides additional assurance that the individual attempting to gain access is who they claim to be. With multi-factor authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID blade1. Under Manage, click Roles and administrators1. Take note of all users with the role Service Co-Administrators, Owners or Contributors1. Return to the Overview1. Under Manage, click Users1. Click on the Per-User MFA button in the top row menu1. Check the box next to each noted user1. Click Enable MFA1. Click EnableOther Options within Azure PortalFollow Microsoft Azure documentation and enable multi-factor authentication in your environment.https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-azure-mfaEnabling and configuring MFA with conditional access policy is a multi-step process. Here are some additional resources on the process within Entra ID to enable multi-factor authentication for users within your subscriptions with conditional access policy.https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-admin-mfahttps://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-getstarted#enable-multi-factor-authentication-with-conditional-accesshttps://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-mfasettings

Level 2

2 Identity

2.1 Security Defaults (Per-User MFA)

[IMPORTANT - Please read the section overview: If your organization pays for Microsoft Entra ID licensing (included in Microsoft 365 E3, E5, or F5, and EM&S E3 or E5 licenses) and CAN use Conditional Access, ignore the recommendations in this section and proceed to the Conditional Access section.]Enable multi-factor authentication for all non-privileged users.

By default, multi-factor authentication is disabled for all users.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select the Microsoft Entra ID blade1. Under Manage, click Users1. Click the Per-User MFA button on the top barFor every user listed, ensure that the Status column indicates EnabledAudit from REST APIFor Every Subscription, For Every Tenant Step 1: Identify Users with non-administrative Access 1. List All Users Using Microsoft Graph API: GET https://graph.microsoft.com/v1.0/users Capture id and corresponding userPrincipalName ($uid, $userPrincipalName) 2. List all Role Definitions Using Azure management API: https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.Authorization/roleDefinitions?api-version=2017-05-01 Capture Role Definition IDs/Name ($name) and role names ($properties/roleName) where 'properties/roleName' does NOT contain (Owner or *contributor or admin ) 3. List All Role Assignments (Mappings $A.uid to $B.name) Using Azure Management API: GET https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.Authorization/roleassignments?api-version=2017-10-01-previewFind all non-administrative roles ($B.name) in 'Properties/roleDefinationId' mapped with user ids ($A.id) in 'Properties/principalId' where 'Properties/principalType' == 'User' D> Now Match ($CProperties/principalId) with $A.uid and get $A.userPrincipalName save this as D.userPrincipleNameStep 2: Run Graph PowerShell command: get-mguser -All | where {$_.StrongAuthenticationMethods.Count -eq 0} | Select-Object -Property UserPrincipalNameIf the output contains any of the $D.userPrincipleName, then this recommendation is non-compliant.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 81b3ccb4-e6e8-4e4a-8d05-5df25cd29fd4 - Name: 'Accounts with read permissions on Azure resources should be MFA enabled'

Users would require two forms of authentication before any access is granted. Also, this requires an overhead for managing dual forms of authentication.

Manual

Multi-factor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted. Multi-factor authentication provides additional assurance that the individual attempting to gain access is who they claim to be. With multi-factor authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID blade1. Under Manage, click Users1. Click on the Per-User MFA button in the top row menu1. Check the box next to each user1. Click Enable MFA1. Click EnableOther Options within Azure PortalFollow Microsoft Azure documentation and enable multi-factor authentication in your environment.https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-azure-mfaEnabling and configuring MFA is a multi-step process. Here are some additional resources on the process within Microsoft Entra ID:https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-admin-mfahttps://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-getstarted#enable-multi-factor-authentication-with-conditional-accesshttps://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-mfasettings

Level 1

2 Identity

2.1 Security Defaults (Per-User MFA)

[IMPORTANT - Please read the section overview: If your organization pays for Microsoft Entra ID licensing (included in Microsoft 365 E3, E5, or F5, and EM&S E3 or E5 licenses) and CAN use Conditional Access, ignore the recommendations in this section and proceed to the Conditional Access section.]Do not allow users to remember multi-factor authentication on devices.

By default, Allow users to remember multi-factor authentication on devices they trust is disabled.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, click Users1. Click the Per-user MFA button on the top bar1. Click on Service settings1. Ensure that Allow users to remember multi-factor authentication on devices they trust is not enabled

For every login attempt, the user will be required to perform multi-factor authentication.

Manual

Remembering Multi-Factor Authentication (MFA) for devices and browsers allows users to have the option to bypass MFA for a set number of days after performing a successful sign-in using MFA. This can enhance usability by minimizing the number of times a user may need to perform two-step verification on the same device. However, if an account or device is compromised, remembering MFA for trusted devices may affect security. Hence, it is recommended that users not be allowed to bypass MFA.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, click Users1. Click the Per-user MFA button on the top bar1. Click on Service settings1. Uncheck the box next to Allow users to remember multi-factor authentication on devices they trust1. Click Save

Level 2

2 Identity

2.2 Conditional Access

Microsoft Entra ID Conditional Access allows an organization to configure Named locations and configure whether those locations are trusted or untrusted. These settings provide organizations the means to specify Geographical locations for use in conditional access policies, or define actual IP addresses and IP ranges and whether or not those IP addresses and/or ranges are trusted by the organization.

By default, no locations are configured under the Named locations blade within the Microsoft Entra ID Conditional Access blade.

Audit from Azure Portal1. In the Azure Portal, navigate to Microsoft Entra ID1. Under Manage, click Security1. Under Protect, click Conditional Access1. Under Manage, click Named locationsEnsure there are IP ranges location settings configured and marked as TrustedAudit from PowerShellGet-MgIdentityConditionalAccessNamedLocationIn the output from the above command, for each Named location group, make sure at least one entry contains the IsTrusted parameter with a value of True. Otherwise, if there is no output as a result of the above command or all of the entries contain the IsTrusted parameter with an empty value, a NULL value, or a value of False, the results are out of compliance with this check.

When configuring Named locations, the organization can create locations using Geographical location data or by defining source IP addresses or ranges. Configuring Named locations using a Country location does not provide the organization the ability to mark those locations as trusted, and any Conditional Access policy relying on those Countries location setting will not be able to use the All trusted locations setting within the Conditional Access policy. They instead will have to rely on the Select locations setting. This may add additional resource requirements when configuring and will require thorough organizational testing.In general, Conditional Access policies may completely prevent users from authenticating to Microsoft Entra ID, and thorough testing is recommended. To avoid complete lockout, a 'Break Glass' account with full Global Administrator rights is recommended in the event all other administrators are locked out of authenticating to Microsoft Entra ID. This 'Break Glass' account should be excluded from Conditional Access Policies and should be configured with the longest pass phrase feasible in addition to a FIDO2 security key or certificate kept in a very secure physical location. This account should only be used in the event of an emergency and complete administrator lockout.NOTE: Starting July 2024, Microsoft will begin requiring MFA for All Users - including Break Glass Accounts. By the end of October 2024, this requirement will be enforced. Physical FIDO2 security keys, or a certificate kept on secure removable storage can fulfill this MFA requirement. If opting for a physical device, that device should be kept in a very secure, documented physical location.

Manual

Defining trusted source IP addresses or ranges helps organizations create and enforce Conditional Access policies around those trusted or untrusted IP addresses and ranges. Users authenticating from trusted IP addresses and/or ranges may have less access restrictions or access requirements when compared to users that try to authenticate to Microsoft Entra ID from untrusted locations or untrusted source IP addresses/ranges.

Remediate from Azure Portal1. In the Azure Portal, navigate to Microsoft Entra ID1. Under Manage, click Security1. Under Protect, click Conditional Access1. Under Manage, click Named locations1. Within the Named locations blade, click on IP ranges location1. Enter a name for this location setting in the Name text box1. Click on the + sign1. Add an IP Address Range in CIDR notation inside the text box that appears1. Click on the Add button1. Repeat steps 7 through 9 for each IP Range that needs to be added1. If the information entered are trusted ranges, select the Mark as trusted location check box1. Once finished, click on CreateRemediate from PowerShellCreate a new trusted IP-based Named location policy[System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.IpRange]]$ipRanges = @()$ipRanges.Add('<first IP range in CIDR notation>')$ipRanges.Add('<second IP range in CIDR notation>')$ipRanges.Add('<third IP range in CIDR notation>')New-MgIdentityConditionalAccessNamedLocation -dataType '#microsoft.graph.ipNamedLocation' -DisplayName '<name of IP Named location policy>' -IsTrusted $true -IpRanges $ipRangesSet an existing IP-based Named location policy to trustedUpdate-MgIdentityConditionalAccessNamedLocation -PolicyId '<ID of the policy>' -dataType '#microsoft.graph.ipNamedLocation' -IsTrusted $true

Level 2

2 Identity

2.2 Conditional Access

CAUTION: If these policies are created without first auditing and testing the result, misconfiguration can potentially lock out administrators or create undesired access issues.Conditional Access Policies can be used to block access from geographic locations that are deemed out-of-scope for your organization or application. The scope and variables for this policy should be carefully examined and defined.

This policy does not exist by default.

Audit from Azure Portal1. From Azure Home open the Portal menu in the top left, and select Microsoft Entra ID.1. Scroll down in the menu on the left, and select Security.1. Select on the left side Conditional Access.1. Select Policies.1. Select the policy you wish to audit, then: - Under Assignments > Users, review the users and groups for the personnel the policy will apply to - Under Assignments > Target resources, review the cloud apps or actions for the systems the policy will apply to - Under Conditions > Locations, Review the Include locations for those that should be blocked - Under Conditions > Locations, Review the Exclude locations for those that should be allowed (Note: locations set up in the previous recommendation for Trusted Location should be in the Exclude list.) - Under Access Controls > Grant - Confirm that Block access is selected.Audit from Azure CLIAs of this writing there are no subcommands for Conditional Access Policies within the Azure CLIAudit from PowerShell$conditionalAccessPolicies = Get-MgIdentityConditionalAccessPolicy foreach($policy in $conditionalAccessPolicies) {$policy | Select-Object @{N='Policy ID'; E={$policy.id}}, @{N='Included Locations'; E={$policy.Conditions.Locations.IncludeLocations}}, @{N='Excluded Locations'; E={$policy.Conditions.Locations.ExcludeLocations}}, @{N='BuiltIn GrantControls'; E={$policy.GrantControls.BuiltInControls}}}Make sure there is at least 1 row in the output of the above PowerShell command that contains Block under the BuiltIn GrantControls column and location IDs under the Included Locations and Excluded Locations columns. If not, a policy containing these options has not been created and is considered a finding.

Microsoft Entra ID P1 or P2 is required. Limiting access geographically will deny access to users that are traveling or working remotely in a different part of the world. A point-to-site or site to site tunnel such as a VPN is recommended to address exceptions to geographic access policies.

Manual

Conditional Access, when used as a deny list for the tenant or subscription, is able to prevent ingress or egress of traffic to countries that are outside of the scope of interest (e.g.: customers, suppliers) or jurisdiction of an organization. This is an effective way to prevent unnecessary and long-lasting exposure to international threats such as APTs.

Remediate from Azure PortalPart 1 of 2 - Create the policy and enable it in Report-only mode.1. From Azure Home open the portal menu in the top left, and select Microsoft Entra ID.1. Scroll down in the menu on the left, and select Security.1. Select on the left side Conditional Access.1. Select Policies.1. Click the + New policy button, then:1. Provide a name for the policy. 1. Under Assignments, select Users then: - Under Include, select All users - Under Exclude, check Users and groups and only select emergency access accounts and service accounts (NOTE: Service accounts are excluded here because service accounts are non-interactive and cannot complete MFA)1. Under Assignments, select Target resources then: - Under Include, select All cloud apps - Leave Exclude blank unless you have a well defined exception1. Under Conditions, select Locations then: - Select Include, then add entries for locations for those that should be blocked - Select Exclude, then add entries for those that should be allowed (IMPORTANT: Ensure that all Trusted Locations are in the Exclude list.)1. Under Access Controls, select Grant select Block Access.1. Set Enable policy to Report-only.1. Click Create.Allow some time to pass to ensure the sign-in logs capture relevant conditional access events. These events will need to be reviewed to determine if additional considerations are necessary for your organization (e.g. legitimate locations are being blocked and investigation is needed for exception).NOTE: The policy is not yet 'live,' since Report-only is being used to audit the effect of the policy.Part 2 of 2 - Confirm that the policy is not blocking access that should be granted, then toggle to On.1. With your policy now in report-only mode, return to the Microsoft Entra blade and click on Sign-in logs.1. Review the recent sign-in events - click an event then review the event details (specifically the Report-only tab) to ensure: - The sign-in event you're reviewing occurred after turning on the policy in report-only mode - The policy name from step 6 above is listed in the Policy Name column - The Result column for the new policy shows that the policy was Not applied (indicating the location origin was not blocked)1. If the above conditions are present, navigate back to the policy name in Conditional Access and open it.1. Toggle the policy from Report-only to On.1. Click Save.Remediate from PowerShellFirst, set up the conditions objects values before updating an existing conditional access policy or before creating a new one. You may need to use additional PowerShell cmdlets to retrieve specific IDs such as the Get-MgIdentityConditionalAccessNamedLocation which outputs the Location IDs for use with conditional access policies.$conditions = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessConditionSet$conditions.Applications = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessApplicationCondition$conditions.Applications.IncludeApplications = <'All' | 'Office365' | 'app ID' | @('app ID 1', 'app ID 2', etc...>$conditions.Applications.ExcludeApplications = <'Office365' | 'app ID' | @('app ID 1', 'app ID 2', etc...)>$conditions.Users = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessUserCondition$conditions.Users.IncludeUsers = <'All' | 'None' | 'GuestsOrExternalUsers' | 'Specific User ID' | @('User ID 1', 'User ID 2', etc.)>$conditions.Users.ExcludeUsers = <'GuestsOrExternalUsers' | 'Specific User ID' | @('User ID 1', 'User ID 2', etc.)>$conditions.Users.IncludeGroups = <'group ID' | 'All' | @('Group ID 1', 'Group ID 2', etc...)>$conditions.Users.ExcludeGroups = <'group ID' | @('Group ID 1', 'Group ID 2', etc...)>$conditions.Users.IncludeRoles = <'Role ID' | 'All' | @('Role ID 1', 'Role ID 2', etc...)>$conditions.Users.ExcludeRoles = <'Role ID' | @('Role ID 1', 'Role ID 2', etc...)>$conditions.Locations = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessLocationCondition$conditions.Locations.IncludeLocations = <'Location ID' | @('Location ID 1', 'Location ID 2', etc...) >$conditions.Locations.ExcludeLocations = <'AllTrusted' | 'Location ID' | @('Location ID 1', 'Location ID 2', etc...)>$controls = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControls$controls._Operator = 'OR'$controls.BuiltInControls = 'block'Next, update the existing conditional access policy with the condition set options configured with the previous commands.Update-MgIdentityConditionalAccessPolicy -PolicyId <policy ID> -Conditions $conditions -GrantControls $controlsTo create a new conditional access policy that complies with this best practice, run the following commands after creating the condition set aboveNew-MgIdentityConditionalAccessPolicy -Name 'Policy Name' -State <enabled|disabled> -Conditions $conditions -GrantControls $controls

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with logging in for users until they use an MFA device linked to their accounts. Further testing can also be done via the insights and reporting resource in References which monitors Azure sign ins.

Level 2

2 Identity

2.2 Conditional Access

Conditional Access Policies can be used to prevent the Device code authentication flow. Device code flow should be permitted only for users that regularly perform duties that explicitly require the use of Device Code to authenticate, such as utilizing Azure with PowerShell.

This policy does not exist by default.

Audit from Azure Portal1. From Azure Home open the Portal menu in the top left and select Microsoft Entra ID.1. Scroll down in the menu on the left and select Security.1. Select on the left side Conditional Access.1. Select Policies.1. Select the policy you wish to audit, then: - Under Assignments > Users, review the users and groups for the personnel the policy will apply to - Under Assignments > Target resources, review the cloud apps or actions for the systems the policy will apply to - Under Conditions > Authentication Flows, review the configuration to ensure Device code flow is selected - Under Access Controls > Grant - Confirm that Block access is selected.

Microsoft Entra ID P1 or P2 is required. This policy should be tested using the Report-only mode before implementation. Without a full and careful understanding of the accounts and personnel who require Device code authentication flow, implementing this policy can block authentication for users and devices who rely on Device code flow. For users and devices that rely on device code flow authentication, more secure alternatives should be implemented wherever possible.

Manual

Attackers use Device code flow in phishing attacks and, if successful, results in the attacker gaining access tokens and refresh tokens which are scoped to 'user_impersonation', which can perform any action the user has permission to perform.

Remediate from Azure PortalPart 1 of 2 - Create the policy and enable it in Report-only mode.1. From Azure Home open the portal menu in the top left and select Microsoft Entra ID.1. Scroll down in the menu on the left and select Security.1. Select on the left side Conditional Access.1. Select Policies.1. Click the + New policy button, then:1. Provide a name for the policy. 1. Under Assignments, select Users then: - Under Include, select All users - Under Exclude, check Users and groups and only select emergency access accounts1. Under Assignments, select Target resources then: - Under Include, select All cloud apps - Leave Exclude blank unless you have a well defined exception1. Under Conditions > Authentication Flows, set Configure to Yes then: - Select Device code flow - Select Done1. Under Access Controls > Grant, select Block Access.1. Set Enable policy to Report-only.1. Click Create.Allow some time to pass to ensure the sign-in logs capture relevant conditional access events. These events will need to be reviewed to determine if additional considerations are necessary for your organization (e.g. many legitimate use cases of device code authentication are observed).NOTE: The policy is not yet 'live,' since Report-only is being used to audit the effect of the policy.Part 2 of 2 - Confirm that the policy is not blocking access that should be granted, then toggle to On.1. With your policy now in report-only mode, return to the Microsoft Entra blade and click on Sign-in logs.1. Review the recent sign-in events - click an event then review the event details (specifically the Report-only tab) to ensure: - The sign-in event you're reviewing occurred after turning on the policy in report-only mode - The policy name from step 6 above is listed in the Policy Name column - The Result column for the new policy shows that the policy was Not applied (indicating the device code authentication flow was not blocked)1. If the above conditions are present, navigate back to the policy name in Conditional Access and open it.1. Toggle the policy from Report-only to On.1. Click Save.

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with logging in for users until they use an MFA device linked to their accounts. Further testing can also be done via the insights and reporting resource in References which monitors Azure sign ins.

Level 2

2 Identity

2.2 Conditional Access

For designated users, they will be prompted to use their multi-factor authentication (MFA) process on login.

Starting October 2024, MFA will be required for all accounts by default.

Audit from Azure Portal1. From Azure Home open the Portal Menu in the top left, and select Microsoft Entra ID.1. Select Security.1. Select Conditional Access.1. Select Policies.1. Select the policy you wish to audit.1. Click the blue text under Users.1. View under Include the corresponding users and groups to whom the policy is applied. Be certain the emergency access account is not in the list.1. View under Exclude to determine which Users and groups to whom the policy is not applied.

There is an increased cost, as Conditional Access policies require Microsoft Entra ID P1. Similarly, MFA may require additional overhead to maintain. There is also a potential scenario in which the multi-factor authentication method can be lost, and administrative users are no longer able to log in. For this scenario, there should be an emergency access account. Please see References for creating this.NOTE: Starting July 2024, Microsoft will begin requiring MFA for All Users - including Break Glass Accounts. By the end of October 2024, this requirement will be enforced. Physical FIDO2 security keys, or a certificate kept on secure removable storage can fulfill this MFA requirement. If opting for a physical device, that device should be kept in a very secure, documented physical location.

Manual

Enabling multi-factor authentication is a recommended setting to limit the use of Administrative accounts to authenticated personnel.

Remediate from Azure Portal1. From Azure Home open the Portal Menu in top left, and select Microsoft Entra ID.1. Select Security.1. Select Conditional Access.1. Select Policies.1. Click + New policy.1. Enter a name for the policy.1. Click the blue text under Users.1. Select Select users and groups.1. Select administrative groups this policy should apply to and click Select.1. Under Exclude, check Users and groups.1. Select users this policy not should apply to and click Select.1. Click the blue text under Target resources.1. Select All cloud apps.1. Click the blue text under Grant.1. Under Grant access, check Require multifactor authentication and click Select.1. Set Enable policy to Report-only.1. Click Create.After testing the policy in report-only mode, update the Enable policy setting from Report-only to On.

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with logging in for users until they use an MFA device linked to their accounts. Further testing can also be done via the insights and reporting resource in References which monitors Azure sign ins.

Level 2

2 Identity

2.2 Conditional Access

For designated users, they will be prompted to use their multi-factor authentication (MFA) process on logins.

Starting October 2024, MFA will be required for all accounts by default.

Audit from Azure Portal1. From Azure Home open the Portal Menu in the top left, and select Microsoft Entra ID.1. Scroll down in the menu on the left, and select Security.1. Select on the left side Conditional Access.1. Select Policies.1. Select the policy you wish to audit.1. Click the blue text under Users.1. View under Include the corresponding users and groups to whom the policy is applied.1. View under Exclude to determine which users and groups to whom the policy is not applied.

There is an increased cost, as Conditional Access policies require Microsoft Entra ID P1 or P2. Similarly, this may require additional overhead to maintain if users lose access to their MFA.NOTE: Starting July 2024, Microsoft will begin requiring MFA for All Users - including Break Glass Accounts. By the end of October 2024, this requirement will be enforced. Physical FIDO2 security keys, or a certificate kept on secure removable storage can fulfill this MFA requirement. If opting for a physical device, that device should be kept in a very secure, documented physical location.

Manual

Enabling multi-factor authentication is a recommended setting to limit the potential of accounts being compromised and limiting access to authenticated personnel.

Remediate from Azure Portal1. From Azure Home open Portal menu in the top left, and select Microsoft Entra ID.1. Select Security.1. Select Conditional Access.1. Select Policies.1. Click + New policy.1. Enter a name for the policy.1. Click the blue text under Users.1. Under Include, select All users.1. Under Exclude, check Users and groups.1. Select users this policy should not apply to and click Select.1. Click the blue text under Target resources.1. Select All cloud apps.1. Click the blue text under Grant.1. Under Grant access, check Require multifactor authentication and click Select.1. Set Enable policy to Report-only.1. Click Create.After testing the policy in report-only mode, update the Enable policy setting from Report-only to On.

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with logging in for users until they use an MFA device linked to their accounts. Further testing can also be done via the insights and reporting resource the in References which monitors Azure sign ins.

Level 2

2 Identity

2.2 Conditional Access

Entra ID tracks the behavior of sign-in events. If the Entra ID domain is licensed with P2, the sign-in behavior can be used as a detection mechanism for additional scrutiny during the sign-in event. If this policy is set up, then Risky Sign-in events will prompt users to use multi-factor authentication (MFA) tokens on login for additional verification.

MFA is not enabled by default.

Audit from Azure Portal1. From Azure Home select the Portal Menu in the top left and select Microsoft Entra ID.1. Select Security.1. Select on the left side Conditional Access.1. Select Policies.1. Select the policy you wish to audit.1. Click the blue text under Users.1. View under Include the corresponding users and groups to whom the policy is applied.1. View under Exclude to determine which users and groups to whom the policy is not applied.

Risk Policies for Conditional Access require Microsoft Entra ID P2. Additional overhead to support or maintain these policies may also be required if users lose access to their MFA tokens.

Manual

Enabling multi-factor authentication is a recommended setting to limit the potential of accounts being compromised and limiting access to authenticated personnel. Enabling this policy allows Entra ID's risk-detection mechanisms to force additional scrutiny on the login event, providing a deterrent response to potentially malicious sign-in events, and adding an additional authentication layer as a reaction to potentially malicious behavior.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu in the top left and select Microsoft Entra ID.1. Select Security1. Select Conditional Access.1. Select Policies.1. Click + New policy.1. Enter a name for the policy.1. Click the blue text under Users.1. Under Include, select All users.1. Under Exclude, check Users and groups.1. Select users this policy should not apply to and click Select.1. Click the blue text under Target resources.1. Select All cloud apps.1. Click the blue text under Conditions.1. Select Sign-in risk.1. Update the Configure toggle to Yes.1. Check the sign-in risk level this policy should apply to, e.g. High and Medium.1. Select Done.1. Click the blue text under Grant and check Require multifactor authentication then click the Select button.1. Click the blue text under Session then check Sign-in frequency and select Every time and click the Select button. 1. Set Enable policy to Report-only.1. Click Create.After testing the policy in report-only mode, update the Enable policy setting from Report-only to On.

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with logging in for users until they use an MFA device linked to their accounts. Further testing can also be done via the insights and reporting resource the in References which monitors Azure sign ins.

Level 2

2 Identity

2.2 Conditional Access

This recommendation ensures that users accessing the Windows Azure Service Management API (i.e. Azure Powershell, Azure CLI, Azure Resource Manager API, etc.) are required to use multi-factor authentication (MFA) credentials when accessing resources through the Windows Azure Service Management API.

MFA is not enabled by default for administrative actions.

Audit from Azure Portal1. From the Azure Admin Portal dashboard, open Microsoft Entra ID.1. In the menu on the left of the Entra ID blade, click Security.1. In the menu on the left of the Security blade, click Conditional Access.1. In the menu on the left of the Conditional Access blade, click Policies.1. Click on the name of the policy you wish to audit.1. Click the blue text under Users.1. Under the Include section of Users, ensure that All Users is selected.1. Under the Exclude section of Users, review the Users and Groups that are excluded from the policy (NOTE: this should be limited to break-glass emergency access accounts, non-interactive service accounts, and other carefully considered exceptions).1. On the left side, click the blue text under Target resources.1. Under the Include section of Target Resources, ensure that the Select apps radio button is selected.1. Under Select, ensure that Windows Azure Service Management API is listed.

Conditional Access policies require Microsoft Entra ID P1 or P2 licenses. Similarly, they may require additional overhead to maintain if users lose access to their MFA. Any users or groups which are granted an exception to this policy should be carefully tracked, be granted only minimal necessary privileges, and conditional access exceptions should be regularly reviewed or investigated.

Manual

Administrative access to the Windows Azure Service Management API should be secured with a higher level of scrutiny to authenticating mechanisms. Enabling multi-factor authentication is recommended to reduce the potential for abuse of Administrative actions, and to prevent intruders or compromised admin credentials from changing administrative settings.IMPORTANT: While this recommendation allows exceptions to specific Users or Groups, they should be very carefully tracked and reviewed for necessity on a regular interval through an Access Review process. It is important that this rule be built to include 'All Users' to ensure that all users not specifically excepted will be required to use MFA to access the Azure Service Management API.

Remediate from Azure Portal1. From the Azure Admin Portal dashboard, open Microsoft Entra ID.1. Click Security in the Entra ID blade.1. Click Conditional Access in the Security blade.1. Click Policies in the Conditional Access blade.1. Click + New policy.1. Enter a name for the policy.1. Click the blue text under Users.1. Under Include, select All users.1. Under Exclude, check Users and groups.1. Select users or groups to be exempted from this policy (e.g. break-glass emergency accounts, and non-interactive service accounts) then click the Select button.1. Click the blue text under Target resources.1. Under Include, click the Select apps radio button.1. Click the blue text under Select.1. Check the box next to Windows Azure Service Management APIs then click the Select button.1. Click the blue text under Grant.1. Under Grant access check the box for Require multi-factor authentication then click the Select button.1. Before creating, set Enable policy to Report-only.1. Click Create.After testing the policy in report-only mode, update the Enable policy setting from Report-only to On.

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with administrators changing settings until they use an MFA device linked to their accounts. An emergency access account is recommended for this eventuality if all administrators are locked out. Please see the documentation in the references for further information. Similarly further testing can also be done via the insights and reporting resource in References which monitors Azure sign ins.

Level 2

2 Identity

2.2 Conditional Access

This recommendation ensures that users accessing Microsoft Admin Portals (i.e. Microsoft 365 Admin, Microsoft 365 Defender, Exchange Admin Center, Azure Portal, etc.) are required to use multi-factor authentication (MFA) credentials when logging into an Admin Portal.

MFA is not enabled by default for administrative actions.

Audit from Azure Portal1. From the Azure Admin Portal dashboard, open Microsoft Entra ID.1. In the menu on the left of the Entra ID blade, click Security.1. In the menu on the left of the Security blade, click Conditional Access.1. In the menu on the left of the Conditional Access blade, click Policies.1. Click on the name of the policy you wish to audit.1. Click the blue text under Users.1. Under the Include section of Users, review Users and Groups to ensure that All Users is selected.1. Under the Exclude section of Users, review the Users and Groups that are excluded from the policy (NOTE: this should be limited to break-glass emergency access accounts, non-interactive service accounts, and other carefully considered exceptions).1. On the left side, click the blue text under Target Resources.1. Under the Include section of Target resources, ensure the Select apps radio button is selected.1. Under Select, ensure Microsoft Admin Portals is listed.

Conditional Access policies require Microsoft Entra ID P1 or P2 licenses. Similarly, they may require additional overhead to maintain if users lose access to their MFA. Any users or groups which are granted an exception to this policy should be carefully tracked, be granted only minimal necessary privileges, and conditional access exceptions should be reviewed or investigated.

Manual

Administrative Portals for Microsoft Azure should be secured with a higher level of scrutiny to authenticating mechanisms. Enabling multi-factor authentication is recommended to reduce the potential for abuse of Administrative actions, and to prevent intruders or compromised admin credentials from changing administrative settings.IMPORTANT: While this recommendation allows exceptions to specific Users or Groups, they should be very carefully tracked and reviewed for necessity on a regular interval through an Access Review process. It is important that this rule be built to include 'All Users' to ensure that all users not specifically excepted will be required to use MFA to access Admin Portals.

Remediate from Azure Portal1. From the Azure Admin Portal dashboard, open Microsoft Entra ID.1. Click Security in the Entra ID blade.1. Click Conditional Access in the Security blade.1. Click Policies in the Conditional Access blade.1. Click + New policy.1. Enter a name for the policy.1. Click the blue text under Users.1. Under Include, select All users.1. Under Exclude, check Users and groups.1. Select users or groups to be exempted from this policy (e.g. break-glass emergency accounts, and non-interactive service accounts) then click the Select button.1. Click the blue text under Target resources.1. Under Include, click the Select apps radio button.1. Click the blue text under Select.1. Check the box next to Microsoft Admin Portals then click the Select button.1. Click the blue text under Grant.1. Under Grant access check the box for Require multifactor authentication then click the Select button.1. Before creating, set Enable policy to Report-only.1. Click Create.After testing the policy in report-only mode, update the Enable policy setting from Report-only to On.

These policies should be tested by using the What If tool in the References. Setting these can and will create issues with administrators changing settings until they use an MFA device linked to their accounts. An emergency access account is recommended for this eventuality if all administrators are locked out. Please see the documentation in the references for further information. Similarly further testing can also be done via the insights and reporting resource in References which monitors Azure sign ins.

Level 1

2 Identity

Require administrators or appropriately delegated users to create new tenants.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select User settings1. Ensure that Restrict non-admin users from creating tenants is set to YesAudit from PowerShellImport-Module Microsoft.Graph.Identity.SignIns Connect-MgGraph -Scopes 'Policy.ReadWrite.Authorization' Get-MgPolicyAuthorizationPolicy | Select-Object -ExpandProperty DefaultUserRolePermissions | Format-ListReview the 'DefaultUserRolePermissions' section of the output. Ensure that AllowedToCreateTenants is not 'True'.

Enforcing this setting will ensure that only authorized users are able to create new tenants.

Automated

It is recommended to only allow an administrator to create new tenants. This prevent users from creating new Microsoft Entra ID or Azure AD B2C tenants and ensures that only authorized users are able to do so.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select User settings1. Set Restrict non-admin users from creating tenants to Yes1. Click SaveRemediate from PowerShellImport-Module Microsoft.Graph.Identity.SignIns Connect-MgGraph -Scopes 'Policy.ReadWrite.Authorization' Select-MgProfile -Name beta $params = @{ DefaultUserRolePermissions = @{ AllowedToCreateTenants = $false } } Update-MgPolicyAuthorizationPolicy -AuthorizationPolicyId -BodyParameter $params

Level 1

2 Identity

Microsoft Entra ID has native and extended identity functionality allowing you to invite people from outside your organization to be guest users in your cloud account and sign in with their own work, school, or social identities.

By default no guest users are created.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Click on Add filter1. Select User type1. Select Guest from the Value dropdown1. Click Apply1. Audit the listed guest usersAudit from Azure CLIaz ad user list --query '[?userType=='Guest']'Ensure all users listed are still required and not inactive.Audit from Azure PowerShellGet-AzureADUser |Where-Object {$_.UserType -like 'Guest'} |Select-Object DisplayName, UserPrincipalName, UserType -UniqueAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: e9ac8f8e-ce22-4355-8f04-99b911d6be52 - Name: 'Guest accounts with read permissions on Azure resources should be removed'- Policy ID: 94e1c2ac-cbbe-4cac-a2b5-389c812dee87 - Name: 'Guest accounts with write permissions on Azure resources should be removed'- Policy ID: 339353f6-2387-4a45-abe4-7f529d121046 - Name: 'Guest accounts with owner permissions on Azure resources should be removed'

Before removing guest users, determine their use and scope. Like removing any user, there may be unforeseen consequences to systems if an account is removed without careful consideration.

Manual

Guest users are typically added outside your employee on-boarding/off-boarding process and could potentially be overlooked indefinitely. To prevent this, guest users should be reviewed on a regular basis. During this audit, guest users should also be determined to not have administrative privileges.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Click on Add filter1. Select User type1. Select Guest from the Value dropdown1. Click Apply1. Check the box next to all Guest users that are no longer required or are inactive1. Click Delete1. Click OKRemediate from Azure CLIBefore deleting the user, set it to inactive using the ID from the Audit Procedure to determine if there are any dependent systems.az ad user update --id <exampleaccountid@domain.com> --account-enabled {false}After determining that there are no dependent systems delete the user.Remove-AzureADUser -ObjectId <exampleaccountid@domain.com>Remediate from Azure PowerShellBefore deleting the user, set it to inactive using the ID from the Audit Procedure to determine if there are any dependent systems.Set-AzureADUser -ObjectId '<exampleaccountid@domain.com>' -AccountEnabled falseAfter determining that there are no dependent systems delete the user.PS C:\>Remove-AzureADUser -ObjectId <exampleaccountid@domain.com>

It is good practice to use a dynamic security group to manage guest users.To create the dynamic security group:1. Navigate to the 'Microsoft Entra ID' blade in the Azure Portal2. Select the 'Groups' item3. Create new4. Type of 'dynamic'5. Use the following dynamic selection rule. '(user.userType -eq 'Guest')'6. Once the group has been created, select access reviews option and create a new access review with a period of monthly and send to relevant administrators for review.

Level 1

2 Identity

Ensures that two alternate forms of identification are provided before allowing a password reset.

By default, the Number of methods required to reset is set to '2'.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select Password reset1. Select Authentication methods1. Ensure that Number of methods required to reset is set to 2

There may be administrative overhead, as users who lose access to their secondary authentication methods will need an administrator with permissions to remove it. There will also need to be organization-wide security policies and training to teach administrators to verify the identity of the requesting user so that social engineering cannot render this setting useless.

Manual

A Self-service Password Reset (SSPR) through Azure Multi-factor Authentication (MFA) ensures the user's identity is confirmed using two separate methods of identification. With multiple methods set, an attacker would have to compromise both methods before they could maliciously reset a user's password.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select Password reset1. Select Authentication methods1. Set the Number of methods required to reset to 21. Click Save

Level 1

2 Identity

The account lockout threshold determines how many failed login attempts are permitted prior to placing the account in a locked-out state and initiating a variable lockout duration.

By default, Lockout threshold is set to 10.

Audit from Azure Portal1. From Azure Home select the Portal Menu.1. Select Microsoft Entra ID.1. Under Manage, select Security.1. Under Manage, select Authentication methods.1. Under Manage, select Password protection.1. Ensure that Lockout threshold is set to 10 or fewer.

If account lockout threshold is set too low (less than 3), users may experience frequent lockout events and the resulting security alerts may contribute to alert fatigue.If account lockout threshold is set too high (more than 10), malicious actors can programmatically execute more password attempts in a given period of time.

Manual

Account lockout is a method of protecting against brute-force and password spray attacks. Once the lockout threshold has been exceeded, the account enters a locked-out state which prevents all login attempts for a variable duration. The lockout in combination with a reasonable duration reduces the total number of failed login attempts that a malicious actor can execute in a given period of time.

Remediate from Azure Portal1. From Azure Home select the Portal Menu.1. Select Microsoft Entra ID.1. Under Manage, select Security.1. Under Manage, select Authentication methods.1. Under Manage, select Password protection.1. Set the Lockout threshold to 10 or fewer.1. Click Save.

NOTE: The variable number for failed login attempts allowed before lockout is prescribed by many security and compliance frameworks. The appropriate setting for this variable should be determined by the most restrictive security or compliance framework that your organization follows.

Level 1

2 Identity

The account lockout duration value determines how long an account retains the status of lockout, and therefore how long before a user can continue to attempt to login after passing the lockout threshold.

By default, Lockout duration in seconds is set to 60.

Audit from Azure Portal1. From Azure Home select the Portal Menu.1. Select Microsoft Entra ID.1. Under Manage, select Security.1. Under Manage, select Authentication methods.1. Under Manage, select Password protection.1. Ensure that Lockout duration in seconds is set to 60 or higher.

If account lockout duration is set too low (less than 60 seconds), malicious actors can perform more password spray and brute-force attempts over a given period of time. If the account lockout duration is set too high (more than 300 seconds) users may experience inconvenient delays during lockout.

Manual

Account lockout is a method of protecting against brute-force and password spray attacks. Once the lockout threshold has been exceeded, the account enters a locked-out state which prevents all login attempts for a variable duration. The lockout in combination with a reasonable duration reduces the total number of failed login attempts that a malicious actor can execute in a given period of time.

Remediate from Azure Portal1. From Azure Home select the Portal Menu.1. Select Microsoft Entra ID.1. Under Manage, select Security.1. Under Manage, select Authentication methods.1. Under Manage, select Password protection.1. Set the Lockout duration in seconds to 60 or higher.1. Click Save.

Level 1

2 Identity

Microsoft Azure provides a Global Banned Password policy that applies to Azure administrative and normal user accounts. This is not applied to user accounts that are synced from an on-premise Active Directory unless Microsoft Entra ID Connect is used and you enable EnforceCloudPasswordPolicyForPasswordSyncedUsers.Please see the list in default values on the specifics of this policy. To further password security, it is recommended to further define a custom banned password policy.

By default the custom bad password list is not 'Enabled'.Organizational-specific terms can be added to the custom banned password list, such as the following examples:- Brand names- Product names- Locations, such as company headquarters- Company-specific internal terms- Abbreviations that have specific company meaning- Months and weekdays with your company's local languagesThe default Azure bad password policy is already applied to your resources which applies the following basic requirements:Characters allowed: - Uppercase characters (A - Z)- Lowercase characters (a - z)- Numbers (0 - 9)- Symbols:- @ # $ % ^ & * - _ ! + = [ ] { } | \ : ' , . ? / ` ~ ' ( ) ; < >- blank spaceCharacters not allowed:- Unicode characters- Password length Passwords require- A minimum of eight characters- A maximum of 256 characters**Password complexity:**Passwords require three out of four of the following categories:- Uppercase characters- Lowercase characters- Numbers- SymbolsNote: Password complexity check isn't required for Education tenants.Password not recently used:- When a user changes or resets their password, the new password can't be the same as the current or recently used passwords.- Password isn't banned by Entra ID Password Protection.- The password can't be on the global list of banned passwords for Azure AD Password Protection, or on the customizable list of banned passwords specific to your organization.

Audit from Azure Portal1. From Azure Home select the Portal Menu.1. Select Microsoft Entra ID.1. Under Manage, select Security.1. Under Manage, select Authentication methods.1. Under Manage, select Password protection.1. Ensure Enforce custom list is set to Yes.1. Review the list of words banned from use in passwords.

Increasing needed password complexity might increase overhead on administration of user accounts.Licensing requirement for Global Banned Password List and Custom Banned Password list requires Microsoft Entra ID P1 or P2. On-premises Active Directory Domain Services users that are not synchronized to Microsoft Entra ID also benefit from Microsoft Entra ID Password Protection based on existing licensing for synchronized users.

Manual

Enabling this gives your organization further customization on what secure passwords are allowed. Setting a bad password list enables your organization to fine-tune its password policy further, depending on your needs. Removing easy-to-guess passwords increases the security of access to your Azure resources.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Security.1. Under Manage, select Authentication methods.1. Under Manage, select Password protection.1. Set the Enforce custom list option to Yes.1. Click in the Custom banned password list text box to add a string.1. Click Save.

Level 1

2 Identity

Ensure that the number of days before users are asked to re-confirm their authentication information is not set to 0.

By default, the Number of days before users are asked to re-confirm their authentication information is set to '180 days'.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select Password reset1. Under Manage, select Registration1. Ensure that Number of days before users are asked to re-confirm their authentication informationis not set to0`

Users will be prompted for their multifactor authentication at the duration set here.

Manual

This setting is necessary if you have setup 'Require users to register when signing in option'. If authentication re-confirmation is disabled, registered users will never be prompted to re-confirm their existing authentication information. If the authentication information for a user changes, such as a phone number or email, then the password reset information for that user reverts to the previously registered authentication information.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select Password reset1. Under Manage, select Registration1. Set the Number of days before users are asked to re-confirm their authentication informationto your organization-defined frequency1. ClickSave`

Level 1

2 Identity

Ensure that users are notified on their primary and alternate emails on password resets.

By default, Notify users on password resets? is set to 'Yes'.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select Password reset1. Under Manage, select Notifications1. Ensure that Notify users on password resets? is set to Yes

Users will receive emails alerting them to password changes to both their primary and alternate emails.

Manual

User notification on password reset is a proactive way of confirming password reset activity. It helps the user to recognize unauthorized password reset activities.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select Password reset1. Under Manage, select Notifications1. Set Notify users on password resets? to Yes1. Click Save

Level 1

2 Identity

Ensure that all Global Administrators are notified if any other administrator resets their password.

By default, Notify all admins when other admins reset their password? is set to 'No'.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select Password reset1. Under Manage, select Notifications1. Ensure that Notify all admins when other admins reset their password? is set to Yes

All Global Administrators will receive a notification from Azure every time a password is reset. This is useful for auditing procedures to confirm that there are no out of the ordinary password resets for Administrators. There is additional overhead, however, in the time required for Global Administrators to audit the notifications. This setting is only useful if all Global Administrators pay attention to the notifications and audit each one.

Manual

Administrator accounts are sensitive. Any password reset activity notification, when sent to all Administrators, ensures that all Global Administrators can passively confirm if such a reset is a common pattern within their group. For example, if all Administrators change their password every 30 days, any password reset activity before that may require administrator(s) to evaluate any unusual activity and confirm its origin.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select Password reset1. Under Manage, select Notifications1. Set Notify all admins when other admins reset their password? to Yes1. Click Save

Level 1

2 Identity

Require administrators to provide consent for applications before use.

By default, Users consent for applications is set to Allow user consent for apps.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Enterprise applications1. Under Security, select Consent and permissions1. Under Manage, select User consent settings1. Ensure User consent for applications is set to Do not allow user consentAudit from PowerShellConnect-MgGraph(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Select-Object -ExpandProperty PermissionGrantPoliciesAssignedIf the command returns no values in response, the configuration complies with the recommendation.

Enforcing this setting may create additional requests that administrators need to review.

Manual

If Microsoft Entra ID is running as an identity provider for third-party applications, permissions and consent should be limited to administrators or pre-approved. Malicious applications may attempt to exfiltrate data or abuse privileged user accounts.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Enterprise applications1. Under Security, select Consent and permissions1. Under Manage, select User consent settings1. Set User consent for applications to Do not allow user consent1. Click Save

Level 2

2 Identity

Allow users to provide consent for selected permissions when a request is coming from a verified publisher.

By default, User consent for applications is set to Allow user consent for apps.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Enterprise applications1. Under Security, select Consent and permissions1. Under Manage, select User consent settings1. Under User consent for applications, ensure Allow user consent for apps from verified publishers, for selected permissionsis selected**Audit from PowerShell**```Connect-MgGraph(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Select-Object -ExpandProperty PermissionGrantPoliciesAssigned```The command should return eitherManagePermissionGrantsForSelf.microsoft-user-default-low` or a custom app consent policy id if one is in use.

Enforcing this setting may create additional requests that administrators need to review.

Manual

If Microsoft Entra ID is running as an identity provider for third-party applications, permissions and consent should be limited to administrators or pre-approved. Malicious applications may attempt to exfiltrate data or abuse privileged user accounts.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Enterprise applications1. Under Security, select Consent and permissions1. Under Manage, select User consent settings1. Under User consent for applications, select Allow user consent for apps from verified publishers, for selected permissions1. Click Save`

Level 1

2 Identity

Require administrators or appropriately delegated users to register third-party applications.

By default, Users can register applications is set to 'Yes'.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select User settings1. Ensure that Users can register applications is set to NoAudit from PowerShell(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Format-List AllowedToCreateAppsCommand should return the value of False

Enforcing this setting will create additional requests for approval that will need to be addressed by an administrator. If permissions are delegated, a user may approve a malevolent third party application, potentially giving it access to your data.

Automated

It is recommended to only allow an administrator to register custom-developed applications. This ensures that the application undergoes a formal security review and approval process prior to exposing Microsoft Entra ID data. Certain users like developers or other high-request users may also be delegated permissions to prevent them from waiting on an administrative user. Your organization should review your policies and decide your needs.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select User settings1. Set Users can register applications to No1. Click SaveRemediate from PowerShell$param = @{ AllowedToCreateApps = '$false' } Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions $param

Level 1

2 Identity

Limit guest user permissions.

By default, Guest user access restrictions is set to Guest users have limited access to properties and memberships of directory objects.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select External Identities1. Select External collaboration settings1. Under Guest user access, ensure that Guest user access restrictions is set to Guest user access is restricted to properties and memberships of their own directory objectsAudit from PowerShell1. Enter the following: Connect-MgGraph(Get-MgPolicyAuthorizationPolicy).GuestUserRoleIdWhich will give a result like:Id : authorizationPolicyOdataType :Description : Used to manage authorization related settings across the company.DisplayName : Authorization PolicyEnabledPreviewFeatures : {}GuestUserRoleId : 10dae51f-b6af-4016-8d66-8c2a99b929b3PermissionGrantPolicyIdsAssignedToDefaultUserRole : {user-default-legacy}If the GuestUserRoleID property does not equal 2af84b1e-32c8-42b7-82bc-daa82404023b then it is not set to most restrictive.

This may create additional requests for permissions to access resources that administrators will need to approve.According to https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/users-restrict-guest-permissions#services-currently-not-supportedService without current support might have compatibility issues with the new guest restriction setting.- Forms- Project- Yammer- Planner in SharePoint

Automated

Limiting guest access ensures that guest accounts do not have permission for certain directory tasks, such as enumerating users, groups or other directory resources, and cannot be assigned to administrative roles in your directory. Guest access has three levels of restriction.1. Guest users have the same access as members (most inclusive),2. Guest users have limited access to properties and memberships of directory objects (default value),3. Guest user access is restricted to properties and memberships of their own directory objects (most restrictive).The recommended option is the 3rd, most restrictive: 'Guest user access is restricted to their own directory object'.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select External Identities1. Select External collaboration settings1. Under Guest user access, set Guest user access restrictions to Guest user access is restricted to properties and memberships of their own directory objects1. Click SaveRemediate from PowerShell1. Enter the following to update the policy ID:Update-MgPolicyAuthorizationPolicy -GuestUserRoleId '2af84b1e-32c8-42b7-82bc-daa82404023b'1. Check the GuestUserRoleId again:(Get-MgPolicyAuthorizationPolicy).GuestUserRoleId1. Ensure that the GuestUserRoleId is equal to the earlier entered value of 2af84b1e-32c8-42b7-82bc-daa82404023b.

Level 2

2 Identity

Restrict invitations to users with specific administrative roles only.

By default, Guest invite restrictions is set to Anyone in the organization can invite guest users including guests and non-admins

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select External Identities1. Select External collaboration settings1. Under Guest invite settings, for Guest invite restrictions, ensure that Only users assigned to specific admin roles can invite guest users is selectedNote: This setting has 4 levels of restriction, which include:- Anyone in the organization can invite guest users including guests and non-admins (most inclusive),- Member users and users assigned to specific admin roles can invite guest users including guests with member permissions,- Only users assigned to specific admin roles can invite guest users,- No one in the organization can invite guest users including admins (most restrictive).Audit from PowershellEnter the following:Connect-MgGraph(Get-MgPolicyAuthorizationPolicy).AllowInvitesFromIf the resulting value is adminsAndGuestInviters the configuration complies.

With the option of Only users assigned to specific admin roles can invite guest users selected, users with specific admin roles will be in charge of sending invitations to the external users, requiring additional overhead by them to manage user accounts. This will mean coordinating with other departments as they are onboarding new users.

Automated

Restricting invitations to users with specific administrator roles ensures that only authorized accounts have access to cloud resources. This helps to maintain 'Need to Know' permissions and prevents inadvertent access to data.By default the setting Guest invite restrictions is set to Anyone in the organization can invite guest users including guests and non-admins. This would allow anyone within the organization to invite guests and non-admins to the tenant, posing a security risk.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select External Identities1. Select External collaboration settings1. Under Guest invite settings, set Guest invite restrictions, to Only users assigned to specific admin roles can invite guest users1. Click SaveRemediate from PowershellEnter the following:Connect-MgGraphUpdate-MgPolicyAuthorizationPolicy -AllowInvitesFrom 'adminsAndGuestInviters'

Level 1

2 Identity

Restrict access to the Microsoft Entra ID administration center to administrators only.NOTE: This only affects access to the Entra ID administrator's web portal. This setting does not prohibit privileged users from using other methods such as Rest API or Powershell to obtain sensitive information from Microsoft Entra ID.

By default, Restrict access to Microsoft Entra admin center is set to No

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select User settings1. Under Administration centre, ensure that Restrict access to Microsoft Entra admin center is set to Yes

All administrative tasks will need to be done by Administrators, causing additional overhead in management of users and resources.

Manual

The Microsoft Entra ID administrative center has sensitive data and permission settings. All non-administrators should be prohibited from accessing any Microsoft Entra ID data in the administration center to avoid exposure.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Users1. Under Manage, select User settings1. Under Administration centre, set Restrict access to Microsoft Entra admin center to Yes1. Click Save

Level 2

2 Identity

Restrict access to group web interface in the Access Panel portal.

By default, Restrict user ability to access groups features in the Access Pane is set to No

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Groups1. Under Settings, select General1. Under Self Service Group Management, ensure that Restrict user ability to access groups features in My Groups is set to Yes

Setting to Yes could create administrative overhead by customers seeking certain group memberships that will have to be manually managed by administrators with appropriate permissions.

Manual

Self-service group management enables users to create and manage security groups or Office 365 groups in Microsoft Entra ID. Unless a business requires this day-to-day delegation for some users, self-service group management should be disabled. Any user can access the Access Panel, where they can reset their passwords, view their information, etc. By default, users are also allowed to access the Group feature, which shows groups, members, related resources (SharePoint URL, Group email address, Yammer URL, and Teams URL). By setting this feature to 'Yes', users will no longer have access to the web interface, but still have access to the data using the API. This is useful to prevent non-technical users from enumerating groups-related information, but technical users will still be able to access this information using APIs.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Groups1. Under Settings, select General1. Under Self Service Group Management, set Restrict user ability to access groups features in My Groups to Yes1. Click Save

Level 2

2 Identity

Restrict security group creation to administrators only.

By default, Users can create security groups in Azure portals, API or PowerShell is set to Yes

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Groups1. Under Settings, select General1. Under Security Groups, ensure that Users can create security groups in Azure portals, API or PowerShell is set to No

Enabling this setting could create a number of requests that would need to be managed by an administrator.

Manual

When creating security groups is enabled, all users in the directory are allowed to create new security groups and add members to those groups. Unless a business requires this day-to-day delegation, security group creation should be restricted to administrators only.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Groups1. Under Settings, select General1. Under Security Groups, set Users can create security groups in Azure portals, API or PowerShell to No1. Click Save

Level 2

2 Identity

Restrict security group management to administrators only.

By default, Owners can manage group membership requests in My Groups is set to No.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Groups1. Under Settings, select General1. Under Self Service Group Management, ensure that Owners can manage group membership requests in My Groups is set to No

Group Membership for user accounts will need to be handled by Admins and cause administrative overhead.

Manual

Restricting security group management to administrators only prohibits users from making changes to security groups. This ensures that security groups are appropriately managed and their management is not delegated to non-administrators.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Groups1. Under Settings, select General1. Under Self Service Group Management, set Owners can manage group membership requests in My Groups to No1. Click Save

Level 2

2 Identity

Restrict Microsoft 365 group creation to administrators only.

By default, Users can create Microsoft 365 groups in Azure portals, API or PowerShell is set to Yes.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Groups1. Under Settings, select General1. Under Microsoft 365 Groups, ensure that Users can create Microsoft 365 groups in Azure portals, API or PowerShell is set to No

Enabling this setting could create a number of requests that would need to be managed by an administrator.

Manual

Restricting Microsoft 365 group creation to administrators only ensures that creation of Microsoft 365 groups is controlled by the administrator. Appropriate groups should be created and managed by the administrator and group creation rights should not be delegated to any other user.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Groups1. Under Settings, select General1. Under Microsoft 365 Groups, set Users can create Microsoft 365 groups in Azure portals, API or PowerShell to No1. Click Save

Level 1

2 Identity

NOTE: This recommendation is only relevant if your subscription is using Per-User MFA. If your organization is licensed to use Conditional Access, the preferred method of requiring MFA to join devices to Entra ID is to use a Conditional Access policy (see additional information below for link).Joining or registering devices to Microsoft Entra ID should require multi-factor authentication.

By default, Require Multifactor Authentication to register or join devices with Microsoft Entra is set to No.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Devices1. Under Manage, select Device settings1. Under Microsoft Entra join and registration settings, ensure that Require Multifactor Authentication to register or join devices with Microsoft Entra is set to Yes

A slight impact of additional overhead, as Administrators will now have to approve every access to the domain.

Manual

Multi-factor authentication is recommended when adding devices to Microsoft Entra ID. When set to Yes, users who are adding devices from the internet must first use the second method of authentication before their device is successfully added to the directory. This ensures that rogue devices are not added to the domain using a compromised user account.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Devices1. Under Manage, select Device settings1. Under Microsoft Entra join and registration settings, set Require Multifactor Authentication to register or join devices with Microsoft Entra to Yes1. Click Save

If Conditional Access is available, this recommendation should be bypassed in favor of the Conditional Access implementation of requiring Multifactor Authentication to register or join devices with Microsoft Entra.https://learn.microsoft.com/en-us/entra/identity/conditional-access/how-to-policy-mfa-device-register-join

Level 1

2 Identity

The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access.

By default, no custom owner roles are created.

Audit from Azure Portal1. From Azure Home select the Portal Menu.1. Select Subscriptions.1. Select a subscription.1. Select Access control (IAM).1. Select Roles.1. Click Type and select Custom role from the drop-down menu.1. Select View next to a role.1. Select JSON.1. Check for assignableScopes set to the subscription, and actions set to *.1. Repeat steps 7-9 for each custom role.Audit from Azure CLIList custom roles:az role definition list --custom-role-only TrueCheck for entries with assignableScope of the subscription, and an action of *Audit from PowerShellConnect-AzAccountGet-AzRoleDefinition |Where-Object {($_.IsCustom -eq $true) -and ($_.Actions.contains('*'))}Check the output for AssignableScopes value set to the subscription.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: a451c1ef-c6ca-483d-87ed-f49761e3ffb5 - Name: 'Audit usage of custom RBAC roles'

Subscriptions will need to be handled by Administrators with permissions.

Automated

Custom roles in Azure with administrative access can obfuscate the permissions granted and introduce complexity and blind spots to the management of privileged identities. For less mature security programs without regular identity audits, the creation of Custom roles should be avoided entirely. For more mature security programs with regular identity audits, Custom Roles should be audited for use and assignment, used minimally, and the principle of least privilege should be observed when granting permissions

Remediate from Azure Portal1. From Azure Home select the Portal Menu.1. Select Subscriptions.1. Select a subscription.1. Select Access control (IAM).1. Select Roles.1. Click Type and select Custom role from the drop-down menu.1. Check the box next to each role which grants subscription administrator privileges.1. Select Delete.1. Select Yes.Remediate from Azure CLIList custom roles:az role definition list --custom-role-only TrueCheck for entries with assignableScope of the subscription, and an action of *.To remove a violating role:az role definition delete --name <role name>Note that any role assignments must be removed before a custom role can be deleted.Ensure impact is assessed before deleting a custom role granting subscription administrator privileges.

Level 2

2 Identity

Resource locking is a powerful protection mechanism that can prevent inadvertent modification/deletion of resources within Azure subscriptions/Resource Groups and is a recommended NIST configuration.

Audit from Azure Portal1. In the Azure portal, open a subscription or resource group where you want to view assigned roles.2. Select Access control (IAM)3. Select Roles4. Search for the custom role named <role_name> e.g. from remediation Resource Lock Administrator5. Ensure that the role is assigned to the appropriate users.

By adding this role, specific permissions may be granted for managing just resource locks rather than needing to provide the wide Owner or User Access Administrator role, reducing the risk of the user being able to do unintentional damage.

Manual

Given the resource lock functionality is outside of standard Role Based Access Control(RBAC), it would be prudent to create a resource lock administrator role to prevent inadvertent unlocking of resources.

Remediate from Azure Portal1. In the Azure portal, open a subscription or resource group where you want the custom role to be assigned.1. Select Access control (IAM).1. Click Add.1. Select Add custom role.1. In the Custom role name field enter Resource Lock Administrator.1. In the Description field enter Can Administer Resource Locks.1. For Baseline permissions select Start from scratch1. Select Next.1. In the Permissions tab select Add permissions.1. In the Search for a permission box, type in Microsoft.Authorization/locks to search for permissions.1. Click on the result.1. Check the box next to Permission.1. Select Add.1. Select Review + create.1. Select Create.1. Assign the newly created role to the appropriate user.**Remediate from PowerShell:**Below is a power shell definition for a resource lock administrator role created at an Azure Management group levelImport-Module Az.AccountsConnect-AzAccount$role = Get-AzRoleDefinition 'User Access Administrator'$role.Id = $null$role.Name = 'Resource Lock Administrator'$role.Description = 'Can Administer Resource Locks'$role.Actions.Clear()$role.Actions.Add('Microsoft.Authorization/locks/*')$role.AssignableScopes.Clear()* Scope at the Management group level Management group$role.AssignableScopes.Add('/providers/Microsoft.Management/managementGroups/MG-Name')New-AzRoleDefinition -Role $roleGet-AzureRmRoleDefinition 'Resource Lock Administrator'

Level 2

2 Identity

Users who are set as subscription owners are able to make administrative changes to the subscriptions and move them into and out of Microsoft Entra ID.

By default Subscription leaving Microsoft Entra tenant and Subscription entering Microsoft Entra tenant are set to Allow everyone (default)

Audit from Azure Portal1. From the Azure Portal Home select the portal menu1. Select Subscriptions1. In the Advanced options drop-down menu, select Manage Policies1. Ensure Subscription leaving Microsoft Entra tenant and Subscription entering Microsoft Entra tenant are set to Permit no one

Subscriptions will need to have these settings turned off to be moved.

Manual

Permissions to move subscriptions in and out of a Microsoft Entra tenant must only be given to appropriate administrative personnel. A subscription that is moved into a Microsoft Entra tenant may be within a folder to which other users have elevated permissions. This prevents loss of data or unapproved changes of the objects within by potential bad actors.

Remediate from Azure Portal1. From the Azure Portal Home select the portal menu1. Select Subscriptions1. In the Advanced options drop-down menu, select Manage Policies1. Set Subscription leaving Microsoft Entra tenant and Subscription entering Microsoft Entra tenant to Permit no one1. Click Save changes

Level 1

2 Identity

This recommendation aims to maintain a balance between security and operational efficiency by ensuring that a minimum of 2 and a maximum of 4 users are assigned the Global Administrator role in Microsoft Entra ID. Having at least two Global Administrators ensures redundancy, while limiting the number to four reduces the risk of excessive privileged access.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Roles and administrators1. Under Administrative Roles, select Global Administrator1. Ensure less than 5 users are actively assigned the role.1. Ensure that at least 2 users are actively assigned the role.

Implementing this recommendation may require changes in administrative workflows or the redistribution of roles and responsibilities. Adequate training and awareness should be provided to all Global Administrators.

Manual

The Global Administrator role has extensive privileges across all services in Microsoft Entra ID. The Global Administrator role should never be used in regular daily activities; administrators should have a regular user account for daily activities, and a separate account for administrative responsibilities. Limiting the number of Global Administrators helps mitigate the risk of unauthorized access, reduces the potential impact of human error, and aligns with the principle of least privilege to reduce the attack surface of an Azure tenant. Conversely, having at least two Global Administrators ensures that administrative functions can be performed without interruption in case of unavailability of a single admin.

Remediate from Azure Portal 1. From Azure Home select the Portal Menu1. Select Microsoft Entra ID1. Under Manage, select Roles and administrators1. Under Administrative Roles, select Global AdministratorIf more than 4 users are assigned:1. Remove Global Administrator role for users which do not or no longer require the role.1. Assign Global Administrator role via PIM which can be activated when required.1. Assign more granular roles to users to conduct their duties.If only one user is assigned:1. Provide the Global Administrator role to a trusted user or create a break glass admin account.

Level 1

3 Security

3.1 Microsoft Defender For Cloud

Enable automatic provisioning of the monitoring agent to collect security data.DEPRECATION PLANNED: The Log Analytics Agent is slated for deprecation in August 2024. The Microsoft Defender for Endpoint agent, in tandem with new agentless capabilities will be providing replacement functionality. More detail is available here: https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/microsoft-defender-for-cloud-strategy-and-plan-towards-log/ba-p/3883341.

By default, Automatic provisioning of monitoring agent is set to On.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Defender for Cloud1. Under Management, select Environment Settings1. Select a subscription1. Click on Settings & monitoring1. Ensure that Log Analytics agent is set to OnRepeat the above for any additional subscriptions.Audit from Azure CLIEnsure the output of the below command is On````az account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X GET -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/<subscriptionID>/providers/Microsoft.Security/autoProvisioningSettings?api-version=2017-08-01-preview' | jq '.|.value[] | select(.name=='default')'|jq '.properties.autoProvision'```**Audit from PowerShell**```Connect-AzAccountGet-AzSecurityAutoProvisioningSetting | Select-Object Name, AutoProvision```Ensure output for Id Name AutoProvisionis/subscriptions//providers/Microsoft.Security/autoProvisioningSettings/default default On`Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 475aae12-b88a-4572-8b36-9b712b2b3a17 - Name: 'Auto provisioning of the Log Analytics agent should be enabled on your subscription'

Automated

When Log Analytics agent for Azure VMs is turned on, Microsoft Defender for Cloud provisions the Microsoft Monitoring Agent on all existing supported Azure virtual machines and any new ones that are created. The Microsoft Monitoring Agent scans for various security-related configurations and events such as system updates, OS vulnerabilities, endpoint protection, and provides alerts.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Defender for Cloud1. Under Management, select Environment Settings1. Select a subscription1. Click on Settings & monitoring1. Set the Status of Log Analytics agent to On1. Select a Workspace1. Click Apply1. Click ContinueRepeat the above for any additional subscriptions.Remediate from Azure CLIUse the below command to set Automatic provisioning of monitoring agent to On.az account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X PUT -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/subscriptionID/providers/Microsoft.Security/autoProvisioningSettings/default?api-version=2017-08-01-preview -d@'input.json''Where input.json contains the Request body json data as mentioned below. { 'id': '/subscriptions/<Your_Subscription_Id>/providers/Microsoft.Security/autoProvisioningSettings/default', 'name': 'default', 'type': 'Microsoft.Security/autoProvisioningSettings', 'properties': { 'autoProvision': 'On' }}

'- Excluding any of the entries in input.json may disable the specific setting by default- Microsoft has recently changed APIs to get and Update Automatic Provisioning Setting. This recommendation is updated accordingly.DEPRECATION PLANNED: The Log Analytics Agent is slated for deprecation in August 2024. The Microsoft Defender for Endpoint agent, in tandem with new agentless capabilities will be providing replacement functionality. More detail is available here: https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/microsoft-defender-for-cloud-strategy-and-plan-towards-log/ba-p/3883341.

Level 2

3 Security

3.1 Microsoft Defender For Cloud

This integration setting enables Microsoft Defender for Cloud Apps (formerly 'Microsoft Cloud App Security' or 'MCAS' - see additional info) to communicate with Microsoft Defender for Cloud.

With Cloud App Security license, these alerts are enabled by default.

Audit from Azure Portal1. From Azure Home select the Portal Menu.1. Select Microsoft Defender for Cloud.1. Under Management, select Environment Settings.1. Click on the subscription name.1. Select the Integrations blade.1. Ensure setting Allow Microsoft Defender for Cloud Apps to access my data is selected.Audit from Azure CLIEnsure the output of the below command is `true````az account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X GET -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/<subscription_ID>/providers/Microsoft.Security/settings?api-version=2021-06-01' | jq '.|.value[] | select(.name=='MCAS')'|jq '.properties.enabled'**Audit from PowerShell**Run the following series of commands to audit this configurationGet-AzAccount Set-AzContext -Subscription <subscription ID> Get-AzSecuritySetting | Select-Object name,enabled |where-object {$_.name -eq 'MCAS'} **PowerShell Output - Non-Compliant**Name Enabled---- -------MCAS False**PowerShell Output - Compliant**Name Enabled---- -------MCAS True```

Microsoft Defender for Cloud Apps works with Standard pricing tier Subscription. Choosing the Standard pricing tier of Microsoft Defender for Cloud incurs an additional cost per resource.

Automated

Microsoft Defender for Cloud offers an additional layer of protection by using Azure Resource Manager events, which is considered to be the control plane for Azure. By analyzing the Azure Resource Manager records, Microsoft Defender for Cloud detects unusual or potentially harmful operations in the Azure subscription environment.Several of the preceding analytics are powered by Microsoft Defender for Cloud Apps. To benefit from these analytics, subscription must have a Cloud App Security license. Microsoft Defender for Cloud Apps works only with Standard Tier subscriptions.

Remediate from Azure Portal1. From Azure Home select the Portal Menu.1. Select Microsoft Defender for Cloud.1. Under Management, select Environment Settings.1. Select the subscription.1. Select Integrations.1. Check Allow Microsoft Defender for Cloud Apps to access my data.1. Select Save.Remediate from Azure CLIUse the below command to enable Standard pricing tier for Storage Accountsaz account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X PUT -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/<subscription_ID>/providers/Microsoft.Security/settings/MCAS?api-version=2021-06-01 -d@'input.json''Where input.json contains the Request body json data as mentioned below.{ 'id': '/subscriptions/<Your_Subscription_Id>/providers/Microsoft.Security/settings/MCAS', 'kind': 'DataExportSetting', 'type': 'Microsoft.Security/settings', 'properties': { 'enabled': true }}

NOTE: 'Microsoft Defender for Cloud Apps' ('MDCA') is formerly known as 'Microsoft Cloud App Security' ('MCAS'). There are a number of places (e.g. Azure CLI) where the 'MCAS' acronym is still used within Azure.

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Turning on Microsoft Defender for Servers enables threat detection for Servers, providing threat intelligence, anomaly detection, and behavior analytics in the Microsoft Defender for Cloud.

By default, Microsoft Defender for Servers plan is off.

Audit from Azure Portal1. Go to Microsoft Defender for Cloud1. Under Management, select Environment Settings1. Click on the subscription name1. Select Defender plans in the left pane1. Under Cloud Workload Protection (CWP), locate Server in the Plan column, ensure Status is set to On.Audit from Azure CLIRun the following command:az security pricing show -n VirtualMachines --query pricingTierIf the tenant is licensed and enabled, the output should indicate StandardAudit from PowerShellRun the following command:Get-AzSecurityPricing -Name 'VirtualMachines' |Select-Object Name,PricingTierIf the tenant is licensed and enabled, the -PricingTier parameter will indicate StandardAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 4da35fc9-c9e7-4960-aec9-797fe7d9051d - Name: 'Azure Defender for servers should be enabled'

Turning on Microsoft Defender for Servers in Microsoft Defender for Cloud incurs an additional cost per resource.Two Defender for Servers plans exist:- Plan 1: Subscription only- Plan 2: Subscription and workspace

Automated

Enabling Microsoft Defender for Servers allows for greater defense-in-depth, with threat detection provided by the Microsoft Security Response Center (MSRC).

Remediate from Azure Portal1. Go to Microsoft Defender for Cloud1. Under Management, select Environment Settings1. Click on the subscription name1. Click Defender plans in the left pane1. Under Cloud Workload Protection (CWP), locate Server in the Plan column, set Status to On1. Select SaveRemediate from Azure CLIRun the following command:az security pricing create -n VirtualMachines --tier 'standard'Remediate from PowerShellRun the following command:Set-AzSecurityPricing -Name 'VirtualMachines' -PricingTier 'Standard'

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Enable vulnerability assessment for machines on both Azure and hybrid (Arc enabled) machines.

By default, Automatic provisioning of monitoring agent is set to Off.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Defender for Cloud1. Under Management, select Environment Settings1. Select a subscription1. Click on Settings & monitoring1. Ensure that Vulnerability assessment for machines is set to OnRepeat the above for any additional subscriptions.

Microsoft Defender for Servers plan 2 licensing is required, and configuration of Azure Arc introduces complexity beyond this recommendation.

Manual

Vulnerability assessment for machines scans for various security-related configurations and events such as system updates, OS vulnerabilities, and endpoint protection, then produces alerts on threat and vulnerability findings.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Defender for Cloud1. Under Management, select Environment Settings1. Select a subscription1. Click on Settings & Monitoring1. Set the Status of Vulnerability assessment for machines to On1. Click ContinueRepeat the above for any additional subscriptions.

While this feature is generally available as of publication, it is not yet available for Azure Government tenants.

Level 2

3 Security

3.1 Microsoft Defender For Cloud

The Endpoint protection component enables Microsoft Defender for Endpoint (formerly 'Advanced Threat Protection' or 'ATP' or 'WDATP' - see additional info) to communicate with Microsoft Defender for Cloud.IMPORTANT: When enabling integration between DfE & DfC it needs to be taken into account that this will have some side effects that may be undesirable.1. For server 2019 & above if defender is installed (default for these server SKUs) this will trigger a deployment of the new unified agent and link to any of the extended configuration in the Defender portal.1. If the new unified agent is required for server SKUs of Win 2016 or Linux and lower there is additional integration that needs to be switched on and agents need to be aligned.

By default, Endpoint protection is off.

Audit from Azure Portal1. From Azure Home select the Portal Menu.1. Select Microsoft Defender for Cloud.1. Under Management, select Environment Settings.1. Click on the subscription name.1. Click Settings & monitoring.1. Ensure the Status for Endpoint protection is set to On.Audit from Azure CLIEnsure the output of the below command is `True````az account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X GET -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/<subscriptionID>/providers/Microsoft.Security/settings?api-version=2021-06-01' | jq '.|.value[] | select(.name=='WDATP')'|jq '.properties.enabled'**Audit from PowerShell** Run the following commands to login and audit this check Connect-AzAccount Set-AzContext -Subscription <subscriptionID> Get-AzSecuritySetting | Select-Object name,enabled |where-object {$_.name -eq 'WDATP'} **PowerShell Output - Non-Compliant**Name Enabled---- -------WDATP False**PowerShell Output - Compliant**Name Enabled---- -------WDATP True```

Endpoint protection requires licensing and is included in these plans:- Defender for Servers plan 1- Defender for Servers plan 2

Manual

Microsoft Defender for Endpoint integration brings comprehensive Endpoint Detection and Response (EDR) capabilities within Microsoft Defender for Cloud. This integration helps to spot abnormalities, as well as detect and respond to advanced attacks on endpoints monitored by Microsoft Defender for Cloud.MDE works only with Standard Tier subscriptions.

Remediate from Azure Portal1. From Azure Home select the Portal Menu.1. Go to Microsoft Defender for Cloud.1. Under Management, select Environment Settings.1. Click on the subscription name.1. Click Settings & monitoring.1. Set the Status for Endpoint protection to On.1. Click Continue.Remediate from Azure CLIUse the below command to enable Standard pricing tier for Storage Accountsaz account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X PUT -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/<subscriptionID>/providers/Microsoft.Security/settings/WDATP?api-version=2021-06-01 -d@'input.json''Where input.json contains the Request body json data as mentioned below.{ 'id': '/subscriptions/<Your_Subscription_Id>/providers/Microsoft.Security/settings/WDATP', 'kind': 'DataExportSettings', 'type': 'Microsoft.Security/settings', 'properties': { 'enabled': true }}

IMPORTANT: When enabling integration between DfE & DfC it needs to be taken into account that this will have some side effects that may be undesirable.1. For server 2019 & above if defender is installed (default for these server SKUs) this will trigger a deployment of the new unified agent and link to any of the extended configuration in the Defender portal.1. If the new unified agent is required for server SKUs of Win 2016 or Linux and lower there is additional integration that needs to be switched on and agents need to be aligned.NOTE: 'Microsoft Defender for Endpoint (MDE)' was formerly known as 'Windows Defender Advanced Threat Protection (WDATP).' There are a number of places (e.g. Azure CLI) where the 'WDATP' acronym is still used within Azure.

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Using disk snapshots, the agentless scanner scans for installed software, vulnerabilities, and plain text secrets.

By default, Agentless scanning for machines is off.

Audit from Azure Portal1. From the Azure Portal Home page, select Microsoft Defender for Cloud1. Under Management select Environment Settings1. Select a subscription1. Under Settings > Defender Plans, click Settings & monitoring1. Under the Component column, locate the row for Agentless scanning for machines1. Ensure that On is selectedRepeat the above for any additional subscriptions.

Agentless scanning for machines requires licensing and is included in these plans:- Defender CSPM- Defender for Servers plan 2

Manual

The Microsoft Defender for Cloud agentless machine scanner provides threat detection, vulnerability detection, and discovery of sensitive information.

Audit from Azure Portal1. From the Azure Portal Home page, select Microsoft Defender for Cloud1. Under Management select Environment Settings1. Select a subscription1. Under Settings > Defender Plans, click Settings & monitoring1. Under the Component column, locate the row for Agentless scanning for machines1. Select On1. Click Continue in the top left Repeat the above for any additional subscriptions.

Level 2

3 Security

3.1 Microsoft Defender For Cloud

File Integrity Monitoring (FIM) is a feature that monitors critical system files in Windows or Linux for potential signs of attack or compromise.

By default, File Integrity Monitoring is Off.

Audit from Azure Portal1. From the Azure Portal Home page, select Microsoft Defender for Cloud1. Under Management select Environment Settings1. Select a subscription1. Under Settings > Defender Plans, click Settings & monitoring1. Under the Component column, locate the row for File Integrity Monitoring1. Ensure that On is selectedRepeat the above for any additional subscriptions.

File Integrity Monitoring requires licensing and is included in these plans:- Defender for Servers plan 2

Manual

FIM provides a detection mechanism for compromised files. When FIM is enabled, critical system files are monitored for changes that might indicate a threat actor is attempting to modify system files for lateral compromise within a host operating system.

Audit from Azure Portal1. From the Azure Portal Home page, select Microsoft Defender for Cloud1. Under Management select Environment Settings1. Select a subscription1. Under Settings > Defender Plans, click Settings & monitoring1. Under the Component column, locate the row for File Integrity Monitoring1. Select On1. Click Continue in the top left Repeat the above for any additional subscriptions.

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Turning on Microsoft Defender for Containers enables threat detection for Container Registries including Kubernetes, providing threat intelligence, anomaly detection, and behavior analytics in the Microsoft Defender for Cloud. The following services will be enabled for container instances:- Defender agent in Azure- Azure Policy for Kubernetes- Agentless discovery for Kubernetes- Agentless container vulnerability assessment

By default, Microsoft Defender for Containers is off.

Audit from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select Defender plans.5. Ensure the Status for Containers is set to On.Audit from Azure CLIEnsure the output of the commands below indicates Standard pricing.For legacy Defender for Container Registries instances:az security pricing show --name 'ContainerRegistry' --query pricingTierFor new Defender for Containers instances:az security pricing show --name 'Containers' --query pricingTierAudit from PowerShellEnsure the output of the commands below indicates Standard pricing.For legacy Defender for Container Registries instances:Get-AzSecurityPricing -Name 'ContainerRegistry' | Select-Object Name,PricingTierFor new Defender for Containers instances:Get-AzSecurityPricing -Name 'Containers' | Select-Object Name,PricingTierAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 1c988dd6-ade4-430f-a608-2a3e5b0a6d38 - Name: 'Microsoft Defender for Containers should be enabled'

Turning on Microsoft Defender for Containers incurs an additional cost per resource.

Automated

Enabling Microsoft Defender for Container Registries allows for greater defense-in-depth, with threat detection provided by the Microsoft Security Response Center (MSRC).

Remediate from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select Defender plans.5. Set Status to On for Containers.6. Click Save.Remediate from Azure CLI(Note: 'ContainerRegistry' has been deprecated and is replaced by 'Containers')Use the below command to enable Standard pricing tier for Containers. az security pricing create -n 'Containers' --tier 'standard'Remediate from PowerShell(Note: 'ContainerRegistry' has been deprecated and is replaced by 'Containers')Use the below command to enable Standard pricing tier for Containers. Set-AzSecurityPricing -Name 'Containers' -PricingTier 'Standard'

Deprecation of previous product plans 'Container registries' and 'Kubernetes' plans for Microsoft Defender are being deprecated and replaced with 'Containers' or Microsoft Defender for Containers.

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Enable automatic discovery and configuration scanning of the Microsoft Kubernetes clusters.

By default, Microsoft Defender for Containers is Off.If Defender for Containers is enabled from the Microsoft Defender for Cloud portal, auto provisioning will be enabled.

Audit from Azure Portal1. From the Azure Portal Home page, select Microsoft Defender for Cloud1. Under Management select Environment Settings1. Select a subscription1. Under Settings > Defender Plans, click Settings & monitoring1. Locate the row for Agentless discovery for Kubernetes1. Ensure that On is selectedRepeat the above for any additional subscriptions.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 1c988dd6-ade4-430f-a608-2a3e5b0a6d38 - Name: 'Microsoft Defender for Containers should be enabled'

Agentless discovery for Kubernetes requires licensing and is included in:- Defender CSPM- Defender for Containers plans.

Automated

As with any compute resource, Container environments require hardening and run-time protection to ensure safe operations and detection of threats and vulnerabilities.

Audit from Azure Portal1. From the Azure Portal Home page, select Microsoft Defender for Cloud1. Under Management select Environment Settings1. Select a subscription1. Under Settings > Defender Plans, click Settings & monitoring1. Locate the row for Agentless discovery for Kubernetes1. Select On1. Click Continue in the top left Repeat the above for any additional subscriptions.

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Enable automatic vulnerability management for images stored in ACR or running in AKS clusters.

By default, Microsoft Defender for Containers is Off.If Defender for Containers is enabled from the Microsoft Defender for Cloud portal, auto provisioning will be enabled.

Audit from Azure Portal1. From the Azure Portal Home page, select Microsoft Defender for Cloud1. Under Management select Environment Settings1. Select a subscription1. Under Settings > Defender Plans, click Settings & monitoring1. Locate the row for Agentless container vulnerability assessment1. Ensure that On is selectedRepeat the above for any additional subscriptions.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 1c988dd6-ade4-430f-a608-2a3e5b0a6d38 - Name: 'Microsoft Defender for Containers should be enabled'

Agentless container vulnerability assessment requires licensing and is included in:- Defender CSPM- Defender for Containers plans.

Automated

Agentless vulnerability scanning will examine container images - whether running or in storage - for vulnerable configurations.

Audit from Azure Portal1. From the Azure Portal Home page, select Microsoft Defender for Cloud1. Under Management select Environment Settings1. Select a subscription1. Under Settings > Defender Plans, click Settings & monitoring1. Locate the row for Agentless container vulnerability assessment1. Select On1. Click Continue in the top left Repeat the above for any additional subscriptions.

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Turning on Microsoft Defender for Storage enables threat detection for Storage, providing threat intelligence, anomaly detection, and behavior analytics in the Microsoft Defender for Cloud.

By default, Microsoft Defender plan is off.

Audit from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Ensure Status is set to On for Storage.Audit from Azure CLIEnsure the output of the below command is Standardaz security pricing show -n StorageAccountsAudit from PowerShellGet-AzSecurityPricing -Name 'StorageAccounts' | Select-Object Name,PricingTierEnsure output for Name PricingTier is StorageAccounts StandardAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 308fbb08-4ab8-4e67-9b29-592e93fb94fa - Name: 'Microsoft Defender for Storage (Classic) should be enabled'

Turning on Microsoft Defender for Storage incurs an additional cost per resource.

Automated

Enabling Microsoft Defender for Storage allows for greater defense-in-depth, with threat detection provided by the Microsoft Security Response Center (MSRC).

Remediate from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Set Status to On for Storage.6. Select Save.Remediate from Azure CLIEnsure the output of the below command is Standardaz security pricing create -n StorageAccounts --tier 'standard'Remediate from PowerShellSet-AzSecurityPricing -Name 'StorageAccounts' -PricingTier 'Standard'

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Turning on Microsoft Defender for App Service enables threat detection for App Service, providing threat intelligence, anomaly detection, and behavior analytics in the Microsoft Defender for Cloud.

By default, Microsoft Defender plan is off.

Audit from Azure Portal1. Go to Microsoft Defender for Cloud2. Under Management, select Environment Settings3. Click on the subscription name4. Select Defender plans5. Ensure Status is On for App ServiceAudit from Azure CLIRun the following command:az security pricing show -n AppServicesEnsure -PricingTier is set to StandardAudit from PowerShellRun the following command:Get-AzSecurityPricing -Name 'AppServices' |Select-Object Name,PricingTierEnsure the -PricingTier is set to StandardAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 2913021d-f2fd-4f3d-b958-22354e2bdbcb - Name: 'Azure Defender for App Service should be enabled'

Turning on Microsoft Defender for App Service incurs an additional cost per resource.

Automated

Enabling Microsoft Defender for App Service allows for greater defense-in-depth, with threat detection provided by the Microsoft Security Response Center (MSRC).

Remediate from Azure Portal1. Go to Microsoft Defender for Cloud2. Under Management, select Environment Settings3. Click on the subscription name4. Select Defender plans5. Set App Service Status to On6. Select SaveRemediate from Azure CLIRun the following command:az security pricing create -n Appservices --tier 'standard'Remediate from PowerShellRun the following command:Set-AzSecurityPricing -Name 'AppServices' -PricingTier 'Standard'

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Microsoft Defender for Azure Cosmos DB scans all incoming network requests for threats to your Azure Cosmos DB resources.

By default, Microsoft Defender for Azure Cosmos DB is not enabled.

Audit from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. On the Database row click on Select types >.6. Ensure the toggle switch next to Azure Cosmos DB is set to On.Audit from Azure CLIEnsure the output of the below command is Standardaz security pricing show -n CosmosDbs --query pricingTierAudit from PowerShellGet-AzSecurityPricing -Name 'CosmosDbs' | Select-Object Name,PricingTier Ensure output of -PricingTier is StandardAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: adbe85b5-83e6-4350-ab58-bf3a4f736e5e - Name: 'Microsoft Defender for Azure Cosmos DB should be enabled'

Enabling Microsoft Defender for Azure Cosmos DB requires enabling Microsoft Defender for your subscription. Both will incur additional charges.

Automated

In scanning Azure Cosmos DB requests within a subscription, requests are compared to a heuristic list of potential security threats. These threats could be a result of a security breach within your services, thus scanning for them could prevent a potential security threat from being introduced.

Remediate from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. On the Database row click on Select types >.6. Set the toggle switch next to Azure Cosmos DB to On.7. Click Continue.8. Click Save.Remediate from Azure CLIRun the following command:az security pricing create -n 'CosmosDbs' --tier 'standard'Remediate from PowerShellUse the below command to enable Standard pricing tier for Azure Cosmos DBSet-AzSecurityPricing -Name 'CosmosDbs' -PricingTier 'Standard

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Turning on Microsoft Defender for Open-source relational databases enables threat detection for Open-source relational databases, providing threat intelligence, anomaly detection, and behavior analytics in the Microsoft Defender for Cloud.

By default, Microsoft Defender plan is off.

Audit from Azure Portal1. Go to Microsoft Defender for Cloud.1. Under Management, select Environment Settings.1. Click on the subscription name.1. Select the Defender plans blade.1. Click Select types > in the row for Databases.1. Ensure the toggle switch next to Open-source relational databases is set to On.Audit from Azure CLIRun the following command:az security pricing show -n OpenSourceRelationalDatabases --query pricingTierAudit from PowerShellGet-AzSecurityPricing | Where-Object {$_.Name -eq 'OpenSourceRelationalDatabases'} | Select-Object Name, PricingTierEnsure output for Name PricingTier is OpenSourceRelationalDatabases StandardAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 0a9fbe0d-c5c4-4da8-87d8-f4fd77338835 - Name: 'Azure Defender for open-source relational databases should be enabled'

Turning on Microsoft Defender for Open-source relational databases incurs an additional cost per resource.

Automated

Enabling Microsoft Defender for Open-source relational databases allows for greater defense-in-depth, with threat detection provided by the Microsoft Security Response Center (MSRC).

Remediate from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Click Select types > in the row for Databases.6. Set the toggle switch next to Open-source relational databases to On.7. Select Continue.8. Select Save.Remediate from Azure CLIRun the following command:az security pricing create -n 'OpenSourceRelationalDatabases' --tier 'standard'Remediate from PowerShellUse the below command to enable Standard pricing tier for Open-source relational databasesset-azsecuritypricing -name 'OpenSourceRelationalDatabases' -pricingtier 'Standard'

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Turning on Microsoft Defender for Azure SQL Databases enables threat detection for Managed Instance Azure SQL databases, providing threat intelligence, anomaly detection, and behavior analytics in Microsoft Defender for Cloud.

By default, Microsoft Defender plan is off.

Audit from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Click Select types > in the row for Databases.6. Ensure the toggle switch next to Azure SQL Databases is set to On.Audit from Azure CLIRun the following command:az security pricing show -n SqlServersEnsure -PricingTier is set to StandardAudit from PowerShellRun the following command:Get-AzSecurityPricing -Name 'SqlServers' | Select-Object Name,PricingTierEnsure the -PricingTier is set to StandardAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 7fe3b40f-802b-4cdd-8bd4-fd799c948cc2 - Name: 'Azure Defender for Azure SQL Database servers should be enabled'- Policy ID: abfb7388-5bf4-4ad7-ba99-2cd2f41cebb9 - Name: 'Azure Defender for SQL should be enabled for unprotected SQL Managed Instances'

Turning on Microsoft Defender for Azure SQL Databases incurs an additional cost per resource.

Automated

Enabling Microsoft Defender for Azure SQL Databases allows for greater defense-in-depth, includes functionality for discovering and classifying sensitive data, surfacing and mitigating potential database vulnerabilities, and detecting anomalous activities that could indicate a threat to your database.

Remediate from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Click Select types > in the row for Databases.6. Set the toggle switch next to Azure SQL Databases to On.7. Select Continue.8. Select Save.Remediate from Azure CLIRun the following command:az security pricing create -n SqlServers --tier 'standard'Remediate from PowerShellRun the following command:Set-AzSecurityPricing -Name 'SqlServers' -PricingTier 'Standard'

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Turning on Microsoft Defender for SQL servers on machines enables threat detection for SQL servers on machines, providing threat intelligence, anomaly detection, and behavior analytics in Microsoft Defender for Cloud.

By default, Microsoft Defender plan is off.

Audit from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Click Select types > in the row for Databases.6. Ensure the toggle switch next to SQL servers on machines is set to On.Audit from Azure CLIEnsure Defender for SQL is licensed with the following command:az security pricing show -n SqlServerVirtualMachinesEnsure the 'PricingTier' is set to 'Standard'Audit from PowerShellRun the following command:Get-AzSecurityPricing -Name 'SqlServerVirtualMachines' | Select-Object Name,PricingTierEnsure the 'PricingTier' is set to 'Standard'Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 6581d072-105e-4418-827f-bd446d56421b - Name: 'Azure Defender for SQL servers on machines should be enabled'- Policy ID: abfb4388-5bf4-4ad7-ba82-2cd2f41ceae9 - Name: 'Azure Defender for SQL should be enabled for unprotected Azure SQL servers'

Turning on Microsoft Defender for SQL servers on machines incurs an additional cost per resource.

Automated

Enabling Microsoft Defender for SQL servers on machines allows for greater defense-in-depth, functionality for discovering and classifying sensitive data, surfacing and mitigating potential database vulnerabilities, and detecting anomalous activities that could indicate a threat to your database.

Remediate from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Click Select types > in the row for Databases.6. Set the toggle switch next to SQL servers on machines to On.7. Select Continue.8. Select Save.Remediate from Azure CLIRun the following command:az security pricing create -n SqlServerVirtualMachines --tier 'standard'Remediate from PowerShellRun the following command:Set-AzSecurityPricing -Name 'SqlServerVirtualMachines' -PricingTier 'Standard'

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Turning on Microsoft Defender for Key Vault enables threat detection for Key Vault, providing threat intelligence, anomaly detection, and behavior analytics in the Microsoft Defender for Cloud.

By default, Microsoft Defender plan is off.

Audit from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Ensure Status is set to On for Key Vault.Audit from Azure CLIEnsure the output of the below command is Standardaz security pricing show -n 'KeyVaults' --query 'pricingTier'Audit from PowerShellGet-AzSecurityPricing -Name 'KeyVaults' | Select-Object Name,PricingTierEnsure output for PricingTier is StandardAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 0e6763cc-5078-4e64-889d-ff4d9a839047 - Name: 'Azure Defender for Key Vault should be enabled'

Turning on Microsoft Defender for Key Vault incurs an additional cost per resource.

Automated

Enabling Microsoft Defender for Key Vault allows for greater defense-in-depth, with threat detection provided by the Microsoft Security Response Center (MSRC).

Remediate from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Select On under Status for Key Vault.6. Select Save.Remediate from Azure CLIEnable Standard pricing tier for Key Vault:az security pricing create -n 'KeyVaults' --tier 'Standard'Remediate from PowerShellEnable Standard pricing tier for Key Vault:Set-AzSecurityPricing -Name 'KeyVaults' -PricingTier 'Standard'

Level 2

3 Security

3.1 Microsoft Defender For Cloud

Microsoft Defender for Resource Manager scans incoming administrative requests to change your infrastructure from both CLI and the Azure portal.

By default, Microsoft Defender for Resource Manager is not enabled.

Audit from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Ensure Status is set to On for Resource Manager.Audit from Azure CLIEnsure the output of the below command is Standardaz security pricing show -n 'Arm' --query 'pricingTier'Audit from PowerShellGet-AzSecurityPricing -Name 'Arm' | Select-Object Name,PricingTierEnsure the output of PricingTier is StandardAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: c3d20c29-b36d-48fe-808b-99a87530ad99 - Name: 'Azure Defender for Resource Manager should be enabled'

Enabling Microsoft Defender for Resource Manager requires enabling Microsoft Defender for your subscription. Both will incur additional charges.

Automated

Scanning resource requests lets you be alerted every time there is suspicious activity in order to prevent a security threat from being introduced.

Remediate from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Select On under Status for Resource Manager.6. Select `Save.Remediate from Azure CLIUse the below command to enable Standard pricing tier for Defender for Resource Manageraz security pricing create -n 'Arm' --tier 'Standard'Remediate from PowerShellUse the below command to enable Standard pricing tier for Defender for Resource ManagerSet-AzSecurityPricing -Name 'Arm' -PricingTier 'Standard'

Level 1

3 Security

3.1 Microsoft Defender For Cloud

Ensure that the latest OS patches for all virtual machines are applied.

By default, patches are not automatically deployed.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Defender for Cloud1. Then the Recommendations blade1. Ensure that there are no recommendations for Apply system updatesAlternatively, you can employ your own patch assessment and management tool to periodically assess, report and install the required security patches for your OS.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: bd876905-5b84-4f73-ab2d-2e7a7c4568d9 - Name: 'Machines should be configured to periodically check for missing system updates'

Running Microsoft Defender for Cloud incurs additional charges for each resource monitored. Please see attached reference for exact charges per hour.

Automated

Windows and Linux virtual machines should be kept updated to: - Address a specific bug or flaw- Improve an OS or application’s general stability- Fix a security vulnerabilityMicrosoft Defender for Cloud retrieves a list of available security and critical updates from Windows Update or Windows Server Update Services (WSUS), depending on which service is configured on a Windows VM. The security center also checks for the latest updates in Linux systems. If a VM is missing a system update, the security center will recommend system updates be applied.

Follow Microsoft Azure documentation to apply security patches from the security center. Alternatively, you can employ your own patch assessment and management tool to periodically assess, report, and install the required security patches for your OS.

Level 1

3 Security

3.1 Microsoft Defender For Cloud

The Microsoft Cloud Security Benchmark (or 'MCSB') is an Azure Policy Initiative containing many security policies to evaluate resource configuration against best practice recommendations. If a policy in the MCSB is set with effect type Disabled, it is not evaluated and may prevent administrators from being informed of valuable security recommendations.

By default, the MCSB policy initiative is associated to all subscriptions and most policies will have an effect of Audit. Some policies will have a default effect of Disabled.

Audit from Azure Portal1. From Azure Home select the Portal Menu.1. Select Microsoft Defender for Cloud.1. Under Management, select Environment Settings.1. Select the appropriate Subscription.1. Click on Security policies in the left column.1. Click on Microsoft cloud security benchmark.1. Click Add Filter and select Effect.1. Check the Disabled box to search for all disabled policies.1. Click Apply.If no Policies are shown, no Policies are in Disabled status and no remediation is necessary. If any Policies remain in the list, the policy Effect should be changed to Audit.

Policies within the MCSB default to an effect of Audit and will evaluate - but not enforce - policy recommendations. Ensuring these policies are set to Audit simply ensures that the evaluation occurs to allow administrators to understand where an improvement may be possible. Administrators will need to determine if the recommendations are relevant and desirable for their environment, then manually take action to resolve the status if desired.

Manual

A security policy defines the desired configuration of resources in your environment and helps ensure compliance with company or regulatory security requirements. The MCSB Policy Initiative a set of security recommendations based on best practices and is associated with every subscription by default. When a policy 'Effect' is set to Audit, policies in the MCSB ensure that Defender for Cloud evaluates relevant resources for supported recommendations. To ensure that policies within the MCSB are not being missed when the Policy Initiative is evaluated, none of the policies should have an Effect of Disabled.

Remediate from Azure PortalPart A - List all disabled policies1. From Azure Home select the Portal Menu1. Select Microsoft Defender for Cloud1. Under Management, select Environment Settings1. Select the appropriate Subscription1. Click on Security policies in the left column1. Click on Microsoft cloud security benchmark1. Click Add Filter and select Effect1. Check the Disabled box to search for all disabled policies1. Click ApplyPart B - Remediate Policy EffectFor each policy that remains in the list:1. Click the blue ellipses ... to the right of the policy name1. Click Manage effect and parameters1. Under Policy effect, select the Audit radio button1. Click Save1. Click RefreshRepeat 'Part B - Remediate Policy Effect' until no more policies are listed.

Level 1

3 Security

3.1 Microsoft Defender For Cloud

Enable security alert emails to subscription owners.

By default, Owner is selected

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Defender for Cloud1. Under Management, select Environment Settings1. Click on the appropriate Management Group, Subscription, or Workspace1. Click on Email notifications1. Ensure that All users with the following roles is set to OwnerAudit from Azure CLIEnsure the command below returns state of On and that Owner appears in roles.az account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X GET -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/$0/providers/Microsoft.Security/securityContacts?api-version=2020-01-01-preview'| jq '.[] | select(.name=='default').properties.notificationsByRole'

Automated

Enabling security alert emails to subscription owners ensures that they receive security alert emails from Microsoft. This ensures that they are aware of any potential security issues and can mitigate the risk in a timely fashion.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Defender for Cloud1. Under Management, select Environment Settings1. Click on the appropriate Management Group, Subscription, or Workspace1. Click on Email notifications1. In the drop down of the All users with the following roles field select Owner1. Click SaveRemediate from Azure CLIUse the below command to set Send email also to subscription owners to On.az account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X PUT -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/$0/providers/Microsoft.Security/securityContacts/default1?api-version=2017-08-01-preview -d@'input.json''Where input.json contains the data below, replacing validEmailAddress with a single email address or multiple comma-separated email addresses: { 'id': '/subscriptions/<Your_Subscription_Id>/providers/Microsoft.Security/securityContacts/default1', 'name': 'default1', 'type': 'Microsoft.Security/securityContacts', 'properties': { 'email': '<validEmailAddress>', 'alertNotifications': 'On', 'alertsToAdmins': 'On', 'notificationsByRole': 'Owner' } }

Excluding any entries in the input.json properties block disables the specific setting by default.

Level 1

3 Security

3.1 Microsoft Defender For Cloud

Microsoft Defender for Cloud emails the subscription owners whenever a high-severity alert is triggered for their subscription. You should provide a security contact email address as an additional email address.

By default, there are no additional email addresses entered.

Audit from Azure Portal1. From Azure Home select the Portal Menu.1. Select Microsoft Defender for Cloud.1. Under Management, select Environment Settings.1. Click on the appropriate Management Group, Subscription, or Workspace.1. Click on Email notifications.1. Ensure that a valid security contact email address is listed in the Additional email addresses field.Audit from Azure CLIEnsure the output of the below command is not empty and is set with appropriate email ids:az account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X GET -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/$0/providers/Microsoft.Security/securityContacts?api-version=2020-01-01-preview' | jq '.|.[] | select(.name=='default')'|jq '.properties.emails'Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 4f4f78b8-e367-4b10-a341-d9a4ad5cf1c7 - Name: 'Subscriptions should have a contact email address for security issues'

Automated

Microsoft Defender for Cloud emails the Subscription Owner to notify them about security alerts. Adding your Security Contact's email address to the 'Additional email addresses' field ensures that your organization's Security Team is included in these alerts. This ensures that the proper people are aware of any potential compromise in order to mitigate the risk in a timely fashion.

Remediate from Azure Portal1. From Azure Home select the Portal Menu.1. Select Microsoft Defender for Cloud.1. Under Management, select Environment Settings.1. Click on the appropriate Management Group, Subscription, or Workspace.1. Click on Email notifications.1. Enter a valid security contact email address (or multiple addresses separated by commas) in the Additional email addresses field.1. Click Save.Remediate from Azure CLIUse the below command to set Security contact emails to On.az account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X PUT -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/$0/providers/Microsoft.Security/securityContacts/default?api-version=2020-01-01-preview -d@'input.json''Where input.json contains the data below, replacing validEmailAddress with a single email address or multiple comma-separated email addresses: { 'id': '/subscriptions/<Your_Subscription_Id>/providers/Microsoft.Security/securityContacts/default', 'name': 'default', 'type': 'Microsoft.Security/securityContacts', 'properties': { 'email': '<validEmailAddress>', 'alertNotifications': 'On', 'alertsToAdmins': 'On' } }

Excluding any entries in the input.json properties block disables the specific setting by default.

Level 1

3 Security

3.1 Microsoft Defender For Cloud

Enables emailing security alerts to the subscription owner or other designated security contact.

By default, Notify about alerts with the following severity (or higher): is set to High.

Audit from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Defender for Cloud1. Under Management, select Environment Settings1. Click on the appropriate Management Group, Subscription, or Workspace1. Click on Email notifications1. Under Notification types, ensure that the Notify about alerts with the following severity (or higher): setting is checked and set to HighAudit from Azure CLIEnsure the output of below command is set to true, enter your Subscription ID at the $0 between /subscriptions/<$0>/providers.az account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X GET -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/$0/providers/Microsoft.Security/securityContacts?api-version=2020-01-01-preview' | jq '.|.[] | select(.name=='default')'|jq '.properties.alertNotifications'Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 6e2593d9-add6-4083-9c9b-4b7d2188c899 - Name: 'Email notification for high severity alerts should be enabled'

Automated

Enabling security alert emails ensures that security alert emails are received from Microsoft. This ensures that the right people are aware of any potential security issues and are able to mitigate the risk.

Remediate from Azure Portal1. From Azure Home select the Portal Menu1. Select Microsoft Defender for Cloud1. Under Management, select Environment Settings1. Click on the appropriate Management Group, Subscription, or Workspace1. Click on Email notifications1. Under Notification types, check the check box next to Notify about alerts with the following severity (or higher): and select High from the drop down menu1. Click SaveRemediate from Azure CLIUse the below command to set Send email notification for high severity alerts to On.az account get-access-token --query '{subscription:subscription,accessToken:accessToken}' --out tsv | xargs -L1 bash -c 'curl -X PUT -H 'Authorization: Bearer $1' -H 'Content-Type: application/json' https://management.azure.com/subscriptions/<$0>/providers/Microsoft.Security/securityContacts/default1?api-version=2017-08-01-preview -d@'input.json''Where input.json contains the data below, replacing validEmailAddress with a single email address or multiple comma-separated email addresses: { 'id': '/subscriptions/<Your_Subscription_Id>/providers/Microsoft.Security/securityContacts/default1', 'name': 'default1', 'type': 'Microsoft.Security/securityContacts', 'properties': { 'email': '<validEmailAddress>', 'alertNotifications': 'On', 'alertsToAdmins': 'On' } }

Excluding any entries in the input.json properties block disables the specific setting by default.This recommendation has been updated to reflect recent changes to Microsoft REST APIs for getting and updating security contact information.

Level 2

3 Security

3.1 Microsoft Defender For Cloud

An organization's attack surface is the collection of assets with a public network identifier or URI that an external threat actor can see or access from outside your cloud. It is the set of points on the boundary of a system, a system element, system component, or an environment where an attacker can try to enter, cause an effect on, or extract data from, that system, system element, system component, or environment. The larger the attack surface, the harder it is to protect.This tool can be configured to scan your organization's online infrastructure such as specified domains, hosts, CIDR blocks, and SSL certificates, and store them in an Inventory. Inventory items can be added, reviewed, approved, and removed, and may contain enrichments ('insights') and additional information collected from the tool's different scan engines and open-source intelligence sources.A Defender EASM workspace will generate an Inventory of publicly exposed assets by crawling and scanning the internet using Seeds you provide when setting up the tool. Seeds can be FQDNs, IP CIDR blocks, and WHOIS records.Defender EASM will generate Insights within 24-48 hours after Seeds are provided, and these insights include vulnerability data (CVEs), ports and protocols, and weak or expired SSL certificates that could be used by an attacker for reconnaisance or exploitation.Results are classified High/Medium/Low and some of them include proposed mitigations.

Microsoft Defender EASM is an optional, paid Azure Resource that must be created and configured inside a Subscription and Resource Group.

To view Defender EASM workspaces created for your Subscriptions, search for EASM in the Azure Portal using the search box.

Microsoft Defender EASM workspaces are currently available as Azure Resources with a 30-day free trial period but can quickly accrue significant charges. The costs are calculated daily as (Number of 'billable' inventory items) x (item cost per day; approximately: $0.017). Estimated cost is not provided within the tool, and users are strongly advised to contact their Microsoft sales representative for pricing and set a calendar reminder for the end of the trial period. For an EASM workspace having an Inventory of 5k-10k billable items (IP addresses, hostnames, SSL certificates, etc) a typical cost might be approximiately $85-170 per day or $2500-5000 USD/month at the time of publication.If the workspace is deleted by the last day of a free trial period, no charges are billed.

Manual

This tool can monitor the externally exposed resources of an organization, provide valuable insights, and export these findings in a variety of formats (including CSV) for use in vulnerability management operations and red/purple team exercises.

To begin remediation, a Microsoft Defender EASM workspace must be created. The resources and inventory items added to this workspace will depend on your environment.

Microsoft added its Defender for External Attack Surface management (EASM) offering to Azure following its 2022 acquisition of EASM SaaS tool company RiskIQ.

Level 2

3 Security

3.1 Microsoft Defender For Cloud

[NOTE: As of August 1, 2023 customers with an existing subscription to Defender for DNS can continue to use the service, but new subscribers will receive alerts about suspicious DNS activity as part of Defender for Servers P2.]Microsoft Defender for DNS scans all network traffic exiting from within a subscription.

By default, Microsoft Defender for DNS is not enabled.

Audit from Azure Portal1. Go to Microsoft Defender for Cloud2. Under Management, select Environment Settings3. Click on the subscription name4. Select the Defender plans blade5. Ensure Status is set to On for DNS.Audit from Azure CLIEnsure the output of the below command is Standardaz security pricing show -n 'DNS' --query 'PricingTier'Audit from PowerShellGet-AzSecurityPricing --Name 'DNS' | Select-Object Name,PricingTierEnsure output of PricingTier is StandardAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: bdc59948-5574-49b3-bb91-76b7c986428d - Name: 'Azure Defender for DNS should be enabled'

Enabling Microsoft Defender for DNS requires enabling Microsoft Defender for your subscription. Both will incur additional charges, with Defender for DNS being a small amount per million queries.

Automated

DNS lookups within a subscription are scanned and compared to a dynamic list of websites that might be potential security threats. These threats could be a result of a security breach within your services, thus scanning for them could prevent a potential security threat from being introduced.

Remediate from Azure Portal1. Go to Microsoft Defender for Cloud.2. Under Management, select Environment Settings.3. Click on the subscription name.4. Select the Defender plans blade.5. Select On under Status for DNS.6. Select Save.Remediate from Azure CLIEnable Standard pricing tier for DNS:az security pricing create -n 'DNS' --tier 'Standard'Remediate from PowerShellEnable Standard pricing tier for DNS:Set-AzSecurityPricing -Name 'DNS' -PricingTier 'Standard'

[NOTE: As of August 1, 2023 customers with an existing subscription to Defender for DNS can continue to use the service, but new subscribers will receive alerts about suspicious DNS activity as part of Defender for Servers P2.]

Level 2

3 Security

3.2 Microsoft Defender for IoT

Microsoft Defender for IoT acts as a central security hub for IoT devices within your organization.

By default, Microsoft Defender for IoT is not enabled.

Audit from Azure Portal1. Go to IoT Hub.2. Select a IoT Hub to validate.3. Select Overview in Defender for IoT.4. The Threat prevention and Threat detection screen will appear, if Defender for IoT is Enabled.

Enabling Microsoft Defender for IoT will incur additional charges dependent on the level of usage.

Manual

IoT devices are very rarely patched and can be potential attack vectors for enterprise networks. Updating their network configuration to use a central security hub allows for detection of these breaches.

Remediate from Azure Portal1. Go to IoT Hub.2. Select a IoT Hub to validate.3. Select Overview in Defender for IoT.4. Click on Secure your IoT solution, and complete the onboarding.

There are additional configurations for Microsoft Defender for IoT that allow for types of deployments called hybrid or local. Both run on your physical infrastructure. These are complicated setups and are primarily outside of the scope of a purely Azure benchmark. Please see the references to consider these options for your organization.

Level 1

3 Security

3.3 Key Vault

Ensure that all Keys in Role Based Access Control (RBAC) Azure Key Vaults have an expiration date set.

By default, keys do not expire.

Audit from Azure Portal1. Go to Key vaults.2. For each Key vault, click on Keys.3. In the main pane, ensure that an appropriate Expiration date is set for any keys that are Enabled.Audit from Azure CLIGet a list of all the key vaults in your Azure environment by running the following command:az keyvault listThen for each key vault listed ensure that the output of the below command contains Key ID (kid), enabled status as true and Expiration date (expires) is not empty or null:az keyvault key list --vault-name <VaultName> --query '[*].{'kid':kid,'enabled':attributes.enabled,'expires':attributes.expires}'Audit from PowerShellRetrieve a list of Azure Key vaults:Get-AzKeyVaultFor each Key vault run the following command to determine which vaults are configured to use RBAC.Get-AzKeyVault -VaultName <VaultName>For each Key vault with the EnableRbacAuthorizatoin setting set to True, run the following command.Get-AzKeyVaultKey -VaultName <VaultName>Make sure the Expires setting is configured with a value as appropriate wherever the Enabled setting is set to True.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 152b15f7-8e1f-4c1f-ab71-8c010ba5dbc0 - Name: 'Key Vault keys should have an expiration date'

Keys cannot be used beyond their assigned expiration dates respectively. Keys need to be rotated periodically wherever they are used.

Automated

Azure Key Vault enables users to store and use cryptographic keys within the Microsoft Azure environment. The exp (expiration date) attribute identifies the expiration date on or after which the key MUST NOT be used for encryption of new data, wrapping of new keys, and signing. By default, keys never expire. It is thus recommended that keys be rotated in the key vault and set an explicit expiration date for all keys to help enforce the key rotation. This ensures that the keys cannot be used beyond their assigned lifetimes.

Remediate from Azure Portal1. Go to Key vaults.2. For each Key vault, click on Keys.3. In the main pane, ensure that an appropriate Expiration date is set for any keys that are Enabled.Remediate from Azure CLIUpdate the Expiration date for the key using the below command:az keyvault key set-attributes --name <keyName> --vault-name <vaultName> --expires Y-m-d'T'H:M:S'Z'**Note:**To view the expiration date on all keys in a Key Vault using Microsoft API, the 'List' Key permission is required.To update the expiration date for the keys:1. Go to the Key vault, click on Access Control (IAM).2. Click on Add role assignment and assign the role of Key Vault Crypto Officer to the appropriate user.Remediate from PowerShellSet-AzKeyVaultKeyAttribute -VaultName <VaultName> -Name <KeyName> -Expires <DateTime>

Level 1

3 Security

3.3 Key Vault

Ensure that all Keys in Non Role Based Access Control (RBAC) Azure Key Vaults have an expiration date set.

By default, keys do not expire.

Audit from Azure Portal1. Go to Key vaults.2. For each Key vault, click on Keys.3. In the main pane, ensure that the status of the key is Enabled.4. For each enabled key, ensure that an appropriate Expiration date is set.Audit from Azure CLIGet a list of all the key vaults in your Azure environment by running the following command:az keyvault listFor each key vault, ensure that the output of the below command contains Key ID (kid), enabled status as true and Expiration date (expires) is not empty or null:az keyvault key list --vault-name <KEYVAULTNAME> --query '[*].{'kid':kid,'enabled':attributes.enabled,'expires':attributes.expires}' Audit from PowerShellRetrieve a list of Azure Key vaults:Get-AzKeyVaultFor each Key vault, run the following command to determine which vaults are configured to not use RBAC:Get-AzKeyVault -VaultName <Vault Name>For each Key vault with the EnableRbacAuthorizatoin setting set to False or empty, run the following command.Get-AzKeyVaultKey -VaultName <Vault Name>Make sure the Expires setting is configured with a value as appropriate wherever the Enabled setting is set to True.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 152b15f7-8e1f-4c1f-ab71-8c010ba5dbc0 - Name: 'Key Vault keys should have an expiration date'

Keys cannot be used beyond their assigned expiration dates respectively. Keys need to be rotated periodically wherever they are used.

Automated

Azure Key Vault enables users to store and use cryptographic keys within the Microsoft Azure environment. The exp (expiration date) attribute identifies the expiration date on or after which the key MUST NOT be used for a cryptographic operation. By default, keys never expire. It is thus recommended that keys be rotated in the key vault and set an explicit expiration date for all keys. This ensures that the keys cannot be used beyond their assigned lifetimes.

Remediate from Azure Portal1. Go to Key vaults.2. For each Key vault, click on Keys.3. In the main pane, ensure that the status of the key is Enabled.4. For each enabled key, ensure that an appropriate Expiration date is set.Remediate from Azure CLIUpdate the Expiration date for the key using the below command:az keyvault key set-attributes --name <keyName> --vault-name <vaultName> --expires Y-m-d'T'H:M:S'Z'**Note:**To view the expiration date on all keys in a Key Vault using Microsoft API, the 'List' Key permission is required.To update the expiration date for the keys:1. Go to Key vault, click on Access policies.2. Click on Create and add an access policy with the Update permission (in the Key Permissions - Key Management Operations section).Remediate from PowerShellSet-AzKeyVaultKeyAttribute -VaultName <Vault Name> -Name <Key Name> -Expires <DateTime>

Level 1

3 Security

3.3 Key Vault

Ensure that all Secrets in Role Based Access Control (RBAC) Azure Key Vaults have an expiration date set.

By default, secrets do not expire.

Audit from Azure Portal1. Go to Key vaults.2. For each Key vault, click on Secrets.3. In the main pane, ensure that the status of the secret is Enabled.4. For each enabled secret, ensure that an appropriate Expiration date is set.Audit from Azure CLIEnsure that the output of the below command contains ID (id), enabled status as true and Expiration date (expires) is not empty or null:az keyvault secret list --vault-name <KEYVAULTNAME> --query '[*].{'kid':kid,'enabled':attributes.enabled,'expires':attributes.expires}'Audit from PowerShellRetrieve a list of Key vaults:Get-AzKeyVaultFor each Key vault, run the following command to determine which vaults are configured to use RBAC:Get-AzKeyVault -VaultName <Vault Name>For each Key vault with the EnableRbacAuthorization setting set to True, run the following command:Get-AzKeyVaultSecret -VaultName <Vault Name>Make sure the Expires setting is configured with a value as appropriate wherever the Enabled setting is set to True.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 98728c90-32c7-4049-8429-847dc0f4fe37 - Name: 'Key Vault secrets should have an expiration date'

Secrets cannot be used beyond their assigned expiry date respectively. Secrets need to be rotated periodically wherever they are used.

Automated

The Azure Key Vault enables users to store and keep secrets within the Microsoft Azure environment. Secrets in the Azure Key Vault are octet sequences with a maximum size of 25k bytes each. The exp (expiration date) attribute identifies the expiration date on or after which the secret MUST NOT be used. By default, secrets never expire. It is thus recommended to rotate secrets in the key vault and set an explicit expiration date for all secrets. This ensures that the secrets cannot be used beyond their assigned lifetimes.

Remediate from Azure Portal1. Go to Key vaults.2. For each Key vault, click on Secrets.3. In the main pane, ensure that the status of the secret is Enabled.4. For each enabled secret, ensure that an appropriate Expiration date is set.Remediate from Azure CLIUpdate the Expiration date for the secret using the below command:az keyvault secret set-attributes --name <secret_name> --vault-name <vault_name> --expires Y-m-d'T'H:M:S'Z'Note:To view the expiration date on all secrets in a Key Vault using Microsoft API, the List Secret permission is required.To update the expiration date for the secrets:1. Go to the Key vault, click on Access Control (IAM).2. Click on Add role assignment and assign the role of Key Vault Secrets Officer to the appropriate user.Remediate from PowerShellSet-AzKeyVaultSecretAttribute -VaultName <vault_name> -Name <secret_name> -Expires <date_time>

Level 1

3 Security

3.3 Key Vault

Ensure that all Secrets in Non Role Based Access Control (RBAC) Azure Key Vaults have an expiration date set.

By default, secrets do not expire.

Audit from Azure Portal1. Go to Key vaults.2. For each Key vault, click on Secrets.3. In the main pane, ensure that the status of the secret is Enabled.4. Set an appropriate Expiration date on all secrets.Audit from Azure CLIGet a list of all the key vaults in your Azure environment by running the following command:az keyvault listFor each key vault, ensure that the output of the below command contains ID (id), enabled status as true and Expiration date (expires) is not empty or null:az keyvault secret list --vault-name <KEYVALUTNAME> --query '[*].{'kid':kid,'enabled':attributes.enabled,'expires':attributes.expires}'Audit from PowerShellRetrieve a list of Key vaults:Get-AzKeyVaultFor each Key vault run the following command to determine which vaults are configured to use RBAC:Get-AzKeyVault -VaultName <Vault Name>For each Key Vault with the EnableRbacAuthorization setting set to False or empty, run the following command.Get-AzKeyVaultSecret -VaultName <Vault Name>Make sure the Expires setting is configured with a value as appropriate wherever the Enabled setting is set to True.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 98728c90-32c7-4049-8429-847dc0f4fe37 - Name: 'Key Vault secrets should have an expiration date'

Secrets cannot be used beyond their assigned expiry date respectively. Secrets need to be rotated periodically wherever they are used.

Automated

The Azure Key Vault enables users to store and keep secrets within the Microsoft Azure environment. Secrets in the Azure Key Vault are octet sequences with a maximum size of 25k bytes each. The exp (expiration date) attribute identifies the expiration date on or after which the secret MUST NOT be used. By default, secrets never expire. It is thus recommended to rotate secrets in the key vault and set an explicit expiration date for all secrets. This ensures that the secrets cannot be used beyond their assigned lifetimes.

Remediate from Azure Portal1. Go to Key vaults.2. For each Key vault, click on Secrets.3. In the main pane, ensure that the status of the secret is Enabled.4. Set an appropriate Expiration date on all secrets.Remediate from Azure CLIUpdate the Expiration date for the secret using the below command:az keyvault secret set-attributes --name <secret_name> --vault-name <vault_name> --expires Y-m-d'T'H:M:S'Z'Note:To view the expiration date on all secrets in a Key Vault using Microsoft API, the List Secret permission is required.To update the expiration date for the secrets:1. Go to Key vault, click on Access policies.2. Click on Create and add an access policy with the Update permission (in the Secret Permissions - Secret Management Operations section).Remediate from PowerShellFor each Key vault with the EnableRbacAuthorization setting set to False or empty, run the following command.Set-AzKeyVaultSecret -VaultName <vault_name> -Name <secret_name> -Expires <date_time>

Level 1

3 Security

3.3 Key Vault

The Key Vault contains object keys, secrets, and certificates. Accidental unavailability of a Key Vault can cause immediate data loss or loss of security functions (authentication, validation, verification, non-repudiation, etc.) supported by the Key Vault objects.It is recommended the Key Vault be made recoverable by enabling the 'Do Not Purge' and 'Soft Delete' functions. This is in order to prevent loss of encrypted data, including storage accounts, SQL databases, and/or dependent services provided by Key Vault objects (Keys, Secrets, Certificates) etc. This may happen in the case of accidental deletion by a user or from disruptive activity by a malicious user.NOTE: In February 2025, Microsoft will enable soft-delete protection on all key vaults, and users will no longer be able to opt out of or turn off soft-delete. WARNING: A current limitation is that role assignments disappearing when Key Vault is deleted. All role assignments will need to be recreated after recovery.

When a new Key Vault is created,- enableSoftDelete is enabled by default, and - enablePurgeProtection is disabled by default.NOTE: In February 2025, Microsoft will enable soft-delete protection on all key vaults, and users will no longer be able to opt out of or turn off soft-delete.

Audit from Azure Portal1. Go to Key Vaults.2. For each Key Vault.3. Click Properties.4. Ensure the 'Enable purge protection (enforce a mandatory retention period for deleted vaults and vault objects)' is selected for Purge protection option on this key vault.**Audit from Azure CLI**1. List all Resources of type Key Vaults:```az resource list --query '[?type=='Microsoft.KeyVault/vaults']'```2. For Every Key Vault ID ensure check parameters enablePurgeProtectionis set to true.```az resource show --id /subscriptions/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<resourceGroupName>/providers/Microsoft.KeyVault/vaults/<keyVaultName>```**Audit from PowerShell**Get all Key Vaults.```Get-AzKeyVault```For each Key Vault run the following command.```Get-AzKeyVault -VaultName <Vault Name>```Examine the results of the above command for theEnablePurgeProtectionsetting. Make sure enablePurgeProtection is set toTrue`.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 0b60c0b2-2dc2-4e1c-b5c9-abbed971de53 - Name: 'Key vaults should have deletion protection enabled'- Policy ID: 1e66c121-a66a-4b1f-9b83-0fd99bf0fc2d - Name: 'Key vaults should have soft delete enabled'

Once purge-protection and soft-delete are enabled for a Key Vault, the action is irreversible.

Automated

There could be scenarios where users accidentally run delete/purge commands on Key Vault or an attacker/malicious user deliberately does so in order to cause disruption. Deleting or purging a Key Vault leads to immediate data loss, as keys encrypting data and secrets/certificates allowing access/services will become non-accessible. There is a Key Vault property that plays a role in permanent unavailability of a Key Vault:enablePurgeProtection: Setting this parameter to 'true' for a Key Vault ensures that even if Key Vault is deleted, Key Vault itself or its objects remain recoverable for the next 90 days. Key Vault/objects can either be recovered or purged (permanent deletion) during those 90 days. If no action is taken, the key vault and its objects will subsequently be purged.Enabling the enablePurgeProtection parameter on Key Vaults ensures that Key Vaults and their objects cannot be deleted/purged permanently.

To enable 'Do Not Purge' and 'Soft Delete' for a Key Vault: Remediate from Azure Portal1. Go to Key Vaults.2. For each Key Vault.3. Click Properties.4. Ensure the status of Purge protection reads Enable purge protection (enforce a mandatory retention period for deleted vaults and vault objects).Note, once enabled you cannot disable it.Remediate from Azure CLIaz resource update --id /subscriptions/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<resourceGroupName>/providers/Microsoft.KeyVault/vaults/<keyVaultName> --set properties.enablePurgeProtection=trueRemediate from PowerShellUpdate-AzKeyVault -VaultName <vaultName -ResourceGroupName <resourceGroupName -EnablePurgeProtection

When a key is used for SQL server TDE or Encrypting Storage Account, both the features 'Do Not Purge' and 'Soft Delete' are enabled for the corresponding Key Vault by default by Azure Backend.WARNING: A current limitation of the soft-delete feature across all Azure services is role assignments disappearing when Key Vault is deleted. All role assignments will need to be recreated after recovery.

Level 2

3 Security

3.3 Key Vault

The recommended way to access Key Vaults is to use the Azure Role-Based Access Control (RBAC) permissions model.Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources. It allows users to manage Key, Secret, and Certificate permissions. It provides one place to manage all permissions across all key vaults.

The default value for Access control in Key Vaults is Vault Policy.

Audit from Azure Portal1. From Azure Home open the Portal Menu in the top left corner2. Select Key Vaults3. Select a Key Vault to audit4. Select Access configuration5. Ensure the Permission Model radio button is set to Azure role-based access controlAudit from Azure CLIRun the following command for each Key Vault in each Resource Group:az keyvault show --resource-group <resource_group> --name <vault_name>Ensure the enableRbacAuthorization setting is set to true within the output of the above command.Audit from PowerShellRun the following PowerShell command:Get-AzKeyVault -Vaultname <vault_name> -ResourceGroupName <resource_group>Ensure the Enabled For RBAC Authorization setting is set to TrueAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 12d4fa5e-1f9f-4c21-97a9-b99b3c6611b5 - Name: 'Azure Key Vault should use RBAC permission model'

Implementation needs to be properly designed from the ground up, as this is a fundamental change to the way key vaults are accessed/managed. Changing permissions to key vaults will result in loss of service as permissions are re-applied. For the least amount of downtime, map your current groups and users to their corresponding permission needs.

Automated

The new RBAC permissions model for Key Vaults enables a much finer grained access control for key vault secrets, keys, certificates, etc., than the vault access policy. This in turn will permit the use of privileged identity management over these roles, thus securing the key vaults with JIT Access management.

Remediate from Azure PortalKey Vaults can be configured to use Azure role-based access control on creation.For existing Key Vaults:1. From Azure Home open the Portal Menu in the top left corner2. Select Key Vaults3. Select a Key Vault to audit4. Select Access configuration5. Set the Permission model radio button to Azure role-based access control, taking note of the warning message6. Click Save7. Select Access Control (IAM)8. Select the Role Assignments tab9. Reapply permissions as needed to groups or usersRemediate from Azure CLITo enable RBAC Authorization for each Key Vault, run the following Azure CLI command:az keyvault update --resource-group <resource_group> --name <vault_name> --enable-rbac-authorization trueRemediate from PowerShellTo enable RBAC authorization on each Key Vault, run the following PowerShell command:Update-AzKeyVault -ResourceGroupName <resource_group> -VaultName <vault_name> -EnableRbacAuthorization $True

Level 2

3 Security

3.3 Key Vault

Private endpoints will secure network traffic from Azure Key Vault to the resources requesting secrets and keys.

By default, Private Endpoints are not enabled for any services within Azure.

Audit from Azure Portal1. From Azure Home open the Portal Menu in the top left.2. Select Key Vaults.3. Select a Key Vault to audit.4. Select Networking in the left column.5. Select Private endpoint connections from the top row.6. View if there is an endpoint attached.Audit from Azure CLIRun the following command within a subscription for each Key Vault you wish to audit.az keyvault show --name <keyVaultName>Ensure that privateEndpointConnections is not null.Audit from PowerShellRun the following command within a subscription for each Key Vault you wish to audit.Get-AzPrivateEndpointConnection -PrivateLinkResourceId '/subscriptions/<subscriptionNumber>/resourceGroups/<resourceGroup>/providers/Microsoft.KeyVault/vaults/<keyVaultName>/'Ensure that the response contains details of a private endpoint.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: a6abeaec-4d90-4a02-805f-6b26c4d3fbe9 - Name: 'Azure Key Vaults should use private link'

Incorrect or poorly-timed changing of network configuration could result in service interruption. There are also additional costs tiers for running a private endpoint per petabyte or more of networking traffic.

Automated

Private endpoints will keep network requests to Azure Key Vault limited to the endpoints attached to the resources that are whitelisted to communicate with each other. Assigning the Key Vault to a network without an endpoint will allow other resources on that network to view all traffic from the Key Vault to its destination. In spite of the complexity in configuration, this is recommended for high security secrets.

Please see the additional information about the requirements needed before starting this remediation procedure.****Remediate from Azure Portal1. From Azure Home open the Portal Menu in the top left.2. Select Key Vaults.3. Select a Key Vault to audit.4. Select Networking in the left column.5. Select Private endpoint connections from the top row.6. Select + Create.7. Select the subscription the Key Vault is within, and other desired configuration.8. Select Next.9. For resource type select Microsoft.KeyVault/vaults.10. Select the Key Vault to associate the Private Endpoint with.11. Select Next.12. In the Virtual Networking field, select the network to assign the Endpoint.13. Select other configuration options as desired, including an existing or new application security group.14. Select Next.15. Select the private DNS the Private Endpoints will use.16. Select Next.17. Optionally add Tags.18. Select Next : Review + Create.19. Review the information and select Create. Follow the Audit Procedure to determine if it has successfully applied.20. Repeat steps 3-19 for each Key Vault.Remediate from Azure CLI1. To create an endpoint, run the following command:az network private-endpoint create --resource-group <resourceGroup --vnet-name <vnetName> --subnet <subnetName> --name <PrivateEndpointName> --private-connection-resource-id '/subscriptions/<AZURE SUBSCRIPTION ID>/resourceGroups/<resourceGroup>/providers/Microsoft.KeyVault/vaults/<keyVaultName>' --group-ids vault --connection-name <privateLinkConnectionName> --location <azureRegion> --manual-request2. To manually approve the endpoint request, run the following command:az keyvault private-endpoint-connection approve --resource-group <resourceGroup> --vault-name <keyVaultName> –name <privateLinkName>3. Determine the Private Endpoint's IP address to connect the Key Vault to the Private DNS you have previously created:4. Look for the property networkInterfaces then id; the value must be placed in the variable <privateEndpointNIC> within step 7.az network private-endpoint show -g <resourceGroupName> -n <privateEndpointName> 5. Look for the property networkInterfaces then id; the value must be placed on <privateEndpointNIC> in step 7.az network nic show --ids <privateEndpointName> 6. Create a Private DNS record within the DNS Zone you created for the Private Endpoint:az network private-dns record-set a add-record -g <resourcecGroupName> -z 'privatelink.vaultcore.azure.net' -n <keyVaultName> -a <privateEndpointNIC>7. nslookup the private endpoint to determine if the DNS record is correct:nslookup <keyVaultName>.vault.azure.netnslookup <keyVaultName>.privatelink.vaultcore.azure.n

This recommendation assumes that you have created a Resource Group containing a Virtual Network that the services are already associated with and configured private DNS. A Bastion on the virtual network is also required, and the service to which you are connecting must already have a Private Endpoint. For information concerning the installation of these services, please see the attached documentation.Microsoft's own documentation lists the requirements as: A Key Vault. An Azure virtual network. A subnet in the virtual network. Owner or contributor permissions for both the Key Vault and the virtual network.

Level 2

3 Security

3.3 Key Vault

Automatic Key Rotation is available in Public Preview. The currently supported applications are Key Vault, Managed Disks, and Storage accounts accessing keys within Key Vault. The number of supported applications will incrementally increased.

By default, Automatic Key Rotation is not enabled.

Audit from Azure Portal1. From Azure Portal select the Portal Menu in the top left.2. Select Key Vaults.3. Select a Key Vault to audit. 4. Under Objects select Keys.5. Select a key to audit.6. In the top row select Rotation policy. 7. Ensure Enable auto rotation is set to Enabled.8. Repeat steps 3-7 for each Key Vault and Key.Audit from Azure CLIRun the following command:az keyvault key rotation-policy show --vault-name <vaultName> --name <keyName>Ensure that the response contains a lifetime action of Rotate.Audit from PowerShellRun the following command:Get-AzKeyVaultKeyRotationPolicy -VaultName <vaultName> -Name <keyName>Ensure that the response contains a lifetime action of Rotate.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: d8cf8476-a2ec-4916-896e-992351803c44 - Name: 'Keys should have a rotation policy ensuring that their rotation is scheduled within the specified number of days after creation.'

There are an additional costs per operation in running the needed applications.

Automated

Once set up, Automatic Private Key Rotation removes the need for manual administration when keys expire at intervals determined by your organization's policy. The recommended key lifetime is 2 years. Your organization should determine its own key expiration policy.

**Note:**Azure CLI and Powershell use ISO8601 flags to input timespans. Every timespan input will be in the format P<timespanInISO8601Format>(Y,M,D). The leading P is required with it denoting period. The (Y,M,D) are for the duration of Year, Month,and Day respectively. A time frame of 2 years, 2 months, 2 days would be (P2Y2M2D).Remediate from Azure Portal1. From Azure Portal select the Portal Menu in the top left.2. Select Key Vaults.3. Select a Key Vault to audit. 4. Under Objects select Keys.5. Select a key to audit.6. In the top row select Rotation policy. 7. Select an Expiry time.8. Set Enable auto rotation to Enabled.9. Set an appropriate Rotation option and Rotation time.10. Optionally set the Notification time.11. Select Save.12. Repeat steps 3-11 for each Key Vault and Key.Remediate from Azure CLIRun the following command for each key to update its policy to be auto-rotated:az keyvault key rotation-policy update -n <keyName> --vault-name <vaultName> --value <path/to/policy.json>Note: It is easiest to supply the policy flags in a .json file. An example json file would be:{ 'lifetimeActions': [ { 'trigger': { 'timeAfterCreate': '<timespanInISO8601Format>', 'timeBeforeExpiry' : null }, 'action': { 'type': 'Rotate' } }, { 'trigger': { 'timeBeforeExpiry' : '<timespanInISO8601Format>' }, 'action': { 'type': 'Notify' } } ], 'attributes': { 'expiryTime': '<timespanInISO8601Format>' }}Remediate from PowerShellRun the following command for each key to update its policy:Set-AzKeyVaultKeyRotationPolicy -VaultName test-kv -Name test-key -PolicyPath rotation_policy.jsonNote: It is easiest to supply the policy flags in a .json file. An example json file would be:<# rotation_policy.json{ 'lifetimeActions': [ { 'trigger': { 'timeAfterCreate': 'P<timespanInISO8601Format>M', 'timeBeforeExpiry': null }, 'action': { 'type': 'Rotate' } }, { 'trigger': { 'timeBeforeExpiry': 'P<timespanInISO8601Format>D' }, 'action': { 'type': 'Notify' } } ], 'attributes': { 'expiryTime': 'P<timespanInISO8601Format>Y' } }#>

Automatic Key Rotation is in public preview, so any configuration will not change upon full release.**Note: **Azure CLI and Powershell use ISO8601 flags to input timespans. Every timespan input will be in the format P<timespanInISO8601Format>(Y,M,D). The leading P is required with it denoting period. The (Y,M,D) are for the duration of Year, Month, Day respectively. A time frame of 2 years, 2 months, 2 days would be (P2Y2M2D).

Level 1

4 Storage Accounts

Enable data encryption in transit.

By default, Secure transfer required is set to Disabled.

Audit from Azure Portal1. Go to Storage Accounts.1. For each storage account, under Settings, click Configuration.1. Ensure that Secure transfer required is set to Enabled.Audit from Azure CLIUse the below command to ensure the Secure transfer required is enabled for all the Storage Accounts by ensuring the output contains true for each of the Storage Accounts.az storage account list --query '[*].[name,enableHttpsTrafficOnly]'Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 404c3081-a854-4457-ae30-26a93ef643f9 - Name: 'Secure transfer to storage accounts should be enabled'

Automated

The secure transfer option enhances the security of a storage account by only allowing requests to the storage account by a secure connection. For example, when calling REST APIs to access storage accounts, the connection must use HTTPS. Any requests using HTTP will be rejected when 'secure transfer required' is enabled. When using the Azure files service, connection without encryption will fail, including scenarios using SMB 2.1, SMB 3.0 without encryption, and some flavors of the Linux SMB client. Because Azure storage doesn’t support HTTPS for custom domain names, this option is not applied when using a custom domain name.

Remediate from Azure Portal1. Go to Storage Accounts.1. For each storage account, under Settings, click Configuration.1. Set Secure transfer required to Enabled.1. Click Save.Remediate from Azure CLIUse the below command to enable Secure transfer required for a `Storage Account````az storage account update --name <storageAccountName> --resource-group <resourceGroupName> --https-only true```

Level 2

4 Storage Accounts

Enabling encryption at the hardware level on top of the default software encryption for Storage Accounts accessing Azure storage solutions.

By default, Infrastructure Encryption is disabled in blob creation.

Audit from Azure Portal1. From Azure Portal select the portal menu in the top left.2. Select Storage Accounts.3. Click on each storage account within each resource group you wish to audit.4. In the overview, under Security, ensure Infrastructure encryption is set to Enabled.Audit from Azure CLIaz storage blob show \ --account-name <storage-account> \ --container-name <container> \ --name <blob> \ --query 'properties.serverEncrypted'Audit from PowerShell$account = Get-AzStorageAccount -ResourceGroupName <resource-group> ` -Name <storage-account>$blob = Get-AzStorageBlob -Context $account.Context ` -Container <container> ` -Blob <blob>$blob.ICloudBlob.Properties.IsServerEncryptedAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 4733ea7b-a883-42fe-8cac-97454c2a9e4a - Name: 'Storage accounts should have infrastructure encryption'

The read and write speeds to the storage will be impacted if both default encryption and Infrastructure Encryption are checked, as a secondary form of encryption requires more resource overhead for the cryptography of information. This performance impact should be considered in an analysis for justifying use of the feature in your environment. Customer-managed keys are recommended for the most secure implementation, leading to overhead of key management. The key will also need to be backed up in a secure location, as loss of the key will mean loss of the information in the storage.

Automated

Azure Storage automatically encrypts all data in a storage account at the network level using 256-bit AES encryption, which is one of the strongest, FIPS 140-2-compliant block ciphers available. Customers who require higher levels of assurance that their data is secure can also enable 256-bit AES encryption at the Azure Storage infrastructure level for double encryption. Double encryption of Azure Storage data protects against a scenario where one of the encryption algorithms or keys may be compromised. Similarly, data is encrypted even before network transmission and in all backups. In this scenario, the additional layer of encryption continues to protect your data. For the most secure implementation of key based encryption, it is recommended to use a Customer Managed asymmetric RSA 2048 Key in Azure Key Vault.

Remediate from Azure Portal1. During Storage Account creation, in the Encryption tab, check the box next to Enable infrastructure encryption.Remediate from Azure CLIReplace the information within <> with appropriate values:az storage account create \ --name <storage-account> \ --resource-group <resource-group> \ --location <location> \ --sku Standard_RAGRS \ --kind StorageV2 \ --require-infrastructure-encryptionRemediate from PowerShellReplace the information within <> with appropriate values:New-AzStorageAccount -ResourceGroupName <resource_group> ` -AccountName <storage-account> ` -Location <location> ` -SkuName 'Standard_RAGRS' ` -Kind StorageV2 ` -RequireInfrastructureEncryptionEnabling Infrastructure Encryption after Storage Account CreationIf infrastructure encryption was not enabled on blob storage creation, there is no official way to enable it. Please see the additional information section.

The default service side encryption for Azure Storage is enabled on every block blob, append blob, or page blob that was written to Azure Storage after October 20, 2017. Hardware encryption, however, cannot be enabled on a blob storage after its creation. There are ways to copy all data from a blob storage into another or download and reupload into another blob storage. This could result in data loss and is not recommended.

Level 1

4 Storage Accounts

Access Keys authenticate application access requests to data contained in Storage Accounts. A periodic rotation of these keys is recommended to ensure that potentially compromised keys cannot result in a long-term exploitable credential. The 'Rotation Reminder' is an automatic reminder feature for a manual procedure.

By default, Key rotation reminders is not configured.

Audit from Azure Portal1. Go to Storage Accounts2. For each Storage Account, under Security + networking, go to Access keys3. If the button Edit rotation reminder is displayed, the Storage Account is compliant. Click Edit rotation reminder and review the Remind me every field for a desirable periodic setting that fits your security program's needs. If the button Set rotation reminder is displayed, the Storage Account is not compliant.Audit from Powershell$rgName = <resource group name for the storage>$accountName = <storage account name>$account = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountNameWrite-Output $accountName ->Write-Output 'Expiration Reminder set to: $($account.KeyPolicy.KeyExpirationPeriodInDays) Days'Write-Output 'Key1 Last Rotated: $($account.KeyCreationTime.Key1.ToShortDateString())'Write-Output 'Key2 Last Rotated: $($account.KeyCreationTime.Key2.ToShortDateString())'Key rotation is recommended if the creation date for any key is empty. If the reminder is set, the period in days will be returned. The recommended period is 90 days.

This recommendation only creates a periodic reminder to regenerate access keys. Regenerating access keys can affect services in Azure as well as the organization's applications that are dependent on the storage account. All clients that use the access key to access the storage account must be updated to use the new key.

Manual

Reminders such as those generated by this recommendation will help maintain a regular and healthy cadence for activities which improve the overall efficacy of a security program. Cryptographic key rotation periods will vary depending on your organization's security requirements and the type of data which is being stored in the Storage Account. For example, PCI DSS mandates that cryptographic keys be replaced or rotated 'regularly,' and advises that keys for static data stores be rotated every 'few months.'For the purposes of this recommendation, 90 days will prescribed for the reminder. Review and adjustment of the 90 day period is recommended, and may even be necessary. Your organization's security requirements should dictate the appropriate setting.

Remediate from Azure Portal1. Go to Storage Accounts1. For each Storage Account that is not compliant, under Security + networking, go to Access keys1. Click Set rotation reminder1. Check Enable key rotation reminders1. In the Send reminders field select Custom, then set the Remind me every field to 90 and the period drop down to Days1. Click SaveRemediate from Powershell$rgName = <resource group name for the storage>$accountName = <storage account name>$account = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountNameif ($account.KeyCreationTime.Key1 -eq $null -or $account.KeyCreationTime.Key2 -eq $null){ Write-output ('You must regenerate both keys at least once before setting expiration policy')} else { $account = Set-AzStorageAccount -ResourceGroupName $rgName -Name $accountName -KeyExpirationPeriodInDay 90}$account.KeyPolicy.KeyExpirationPeriodInDays

Level 1

4 Storage Accounts

For increased security, regenerate storage account access keys periodically.

By default, access keys are not regenerated periodically.

Audit from Azure Portal1. Go to Storage Accounts.2. For each Storage Account, under Security + networking, go to Access keys.3. Review the date and days in the Last rotated field for each key.If the Last rotated field indicates a number or days greater than 90 [or greater than your organization's period of validity], the key should be rotated.Audit from Azure CLI1. Get a list of storage accountsaz storage account list --subscription <subscription-id>Make a note of id, name and resourceGroup. 2. For every storage account make sure that key is regenerated in past 90 days.az monitor activity-log list --namespace Microsoft.Storage --offset 90d --query '[?contains(authorization.action, 'regenerateKey')]' --resource-id <resource id> The output should contain'authorization'/'scope': <your_storage_account> AND 'authorization'/'action': 'Microsoft.Storage/storageAccounts/regeneratekey/action' AND 'status'/'localizedValue': 'Succeeded' 'status'/'Value': 'Succeeded'

Regenerating access keys can affect services in Azure as well as the organization's applications that are dependent on the storage account. All clients who use the access key to access the storage account must be updated to use the new key.

Manual

When a storage account is created, Azure generates two 512-bit storage access keys which are used for authentication when the storage account is accessed. Rotating these keys periodically ensures that any inadvertent access or exposure does not result from the compromise of these keys.Cryptographic key rotation periods will vary depending on your organization's security requirements and the type of data which is being stored in the Storage Account. For example, PCI DSS mandates that cryptographic keys be replaced or rotated 'regularly,' and advises that keys for static data stores be rotated every 'few months.'For the purposes of this recommendation, 90 days will prescribed for the reminder. Review and adjustment of the 90 day period is recommended, and may even be necessary. Your organization's security requirements should dictate the appropriate setting.

Remediate from Azure Portal1. Go to Storage Accounts.2. For each Storage Account with outdated keys, under Security + networking, go to Access keys.3. Click Rotate key next to the outdated key, then click Yes to the prompt confirming that you want to regenerate the access key.After Azure regenerates the Access Key, you can confirm that Access keys reflects a Last rotated date of (0 days ago).

Level 1

4 Storage Accounts

Expire shared access signature tokens within an hour.

By default, expiration for shared access signature is set to 8 hours.

Currently, SAS token expiration times cannot be audited. Until Microsoft makes token expiration time a setting rather than a token creation parameter, this recommendation would require a manual verification.

Manual

A shared access signature (SAS) is a URI that grants restricted access rights to Azure Storage resources. A shared access signature can be provided to clients who should not be trusted with the storage account key but for whom it may be necessary to delegate access to certain storage account resources. Providing a shared access signature URI to these clients allows them access to a resource for a specified period of time. This time should be set as low as possible and preferably no longer than an hour.

When generating shared access signature tokens, use start and end time such that it falls within an hour.Remediate from Azure Portal1. Go to Storage Accounts1. For each storage account where a shared access signature is required, under Security + networking, go to Shared access signature1. Select the appropriate Allowed resource types1. Set the Start and expiry date/time to be within one hour1. Click Generate SAS and connection string

Level 1

4 Storage Accounts

Disallowing public network access for a storage account overrides the public access settings for individual containers in that storage account for Azure Resource Manager Deployment Model storage accounts. Azure Storage accounts that use the classic deployment model will be retired on August 31, 2024.

By default, Public Network Access is set to Enabled from all networks for the Storage Account.

Audit from Azure Portal1. Go to Storage Accounts.2. For each storage account, under the Security + networking section, click Networking.3. Ensure the Public network access setting is set to Disabled.Audit from Azure CLIEnsure publicNetworkAccess is Disabled az storage account show --name <storage-account> --resource-group <resource-group> --query '{publicNetworkAccess:publicNetworkAccess}'Audit from PowerShellFor each Storage Account, ensure PublicNetworkAccess is `Disabled````Get-AzStorageAccount -Name <storage account name> -ResourceGroupName <resource group name> |select PublicNetworkAccess```Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: b2982f36-99f2-4db5-8eff-283140c09693 - Name: 'Storage accounts should disable public network access'

Access will have to be managed using shared access signatures or via Azure AD RBAC.

Automated

The default network configuration for a storage account permits a user with appropriate permissions to configure public network access to containers and blobs in a storage account. Keep in mind that public access to a container is always turned off by default and must be explicitly configured to permit anonymous requests. It grants read-only access to these resources without sharing the account key, and without requiring a shared access signature.It is recommended not to provide public network access to storage accounts until, and unless, it is strongly desired. A shared access signature token or Azure AD RBAC should be used for providing controlled and timed access to blob containers.

Remediate from Azure PortalFirst, follow Microsoft documentation and create shared access signature tokens for your blob containers. Then, 1. Go to Storage Accounts.1. For each storage account, under the Security + networking section, click Networking.1. Set Public network access to Disabled.1. Click Save.Remediate from Azure CLISet 'Public Network Access' to Disabled on the storage account az storage account update --name <storage-account> --resource-group <resource-group> --public-network-access DisabledRemediate from PowerShellFor each Storage Account, run the following to set the PublicNetworkAccess setting to `Disabled````Set-AzStorageAccount -ResourceGroupName <resource group name> -Name <storage account name> -PublicNetworkAccess Disabled```

For classic storage accounts (to be retired on August 31, 2024), each container in the account must be configured to block anonymous access. Either configure all containers or to configure at the storage account level, migrate to the Azure Resource Manager deployment model.

Level 1

4 Storage Accounts

Restricting default network access helps to provide a new layer of security, since storage accounts accept connections from clients on any network. To limit access to selected networks, the default action must be changed.

By default, Storage Accounts will accept connections from clients on any network.

Audit from Azure Portal1. Go to Storage Accounts.2. For each storage account, under Security + networking, click Networking.4. Click the Firewalls and virtual networks heading.3. Ensure that Public network access is not set to Enabled from all networks.Audit from Azure CLIEnsure defaultAction is not set to Allow. az storage account list --query '[*].networkRuleSet'Audit from PowerShellConnect-AzAccountSet-AzContext -Subscription <subscription ID>Get-AzStorageAccountNetworkRuleset -ResourceGroupName <resource group> -Name <storage account name> |Select-Object DefaultActionPowerShell Result - Non-CompliantDefaultAction : AllowPowerShell Result - CompliantDefaultAction : DenyAudit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 34c877ad-507e-4c82-993e-3452a6e0ad3c - Name: 'Storage accounts should restrict network access'- Policy ID: 2a1a9cdf-e04d-429a-8416-3bfb72a1b26f - Name: 'Storage accounts should restrict network access using virtual network rules'

All allowed networks will need to be whitelisted on each specific network, creating administrative overhead. This may result in loss of network connectivity, so do not turn on for critical resources during business hours.

Automated

Storage accounts should be configured to deny access to traffic from all networks (including internet traffic). Access can be granted to traffic from specific Azure Virtual networks, allowing a secure network boundary for specific applications to be built. Access can also be granted to public internet IP address ranges to enable connections from specific internet or on-premises clients. When network rules are configured, only applications from allowed networks can access a storage account. When calling from an allowed network, applications continue to require proper authorization (a valid access key or SAS token) to access the storage account.

Remediate from Azure Portal1. Go to Storage Accounts.1. For each storage account, under Security + networking, click Networking.1. Click the Firewalls and virtual networks heading.1. Set Public network access to Enabled from selected virtual networks and IP addresses.1. Add rules to allow traffic from specific networks and IP addresses.1. Click Save.Remediate from Azure CLIUse the below command to update default-action to Deny. az storage account update --name <StorageAccountName> --resource-group <resourceGroupName> --default-action Deny

Level 2

4 Storage Accounts

NOTE: This recommendation assumes that the Public network access parameter is set to Enabled from selected virtual networks and IP addresses. Please ensure the prerequisite recommendation has been implemented before proceeding: - Ensure Default Network Access Rule for Storage Accounts is Set to DenySome Azure services that interact with storage accounts operate from networks that can't be granted access through network rules. To help this type of service work as intended, allow the set of trusted Azure services to bypass the network rules. These services will then use strong authentication to access the storage account. If the Allow Azure services on the trusted services list to access this storage account exception is enabled, the following services are granted access to the storage account: Azure Backup, Azure Data Box, Azure DevTest Labs, Azure Event Grid, Azure Event Hubs, Azure File Sync, Azure HDInsight, Azure Import/Export, Azure Monitor, Azure Networking Services, and Azure Site Recovery (when registered in the subscription).

By default, Storage Accounts will accept connections from clients on any network.

Audit from Azure Portal1. Go to Storage Accounts.1. For each storage account, under Security + networking, click Networking.1. Click on the Firewalls and virtual networks heading.1. Under Exceptions, ensure that Allow Azure services on the trusted services list to access this storage account is checked.Audit from Azure CLIEnsure bypass contains AzureServices````az storage account list --query '[*].networkRuleSet'```**Audit from PowerShell**```Connect-AzAccountSet-AzContext -Subscription <subscription ID>Get-AzStorageAccountNetworkRuleset -ResourceGroupName <resource group> -Name <storage account name> |Select-Object Bypass```If the response from the above command is None, the storage account configuration is out of compliance with this check. If the response is AzureServices`, the storage account configuration is in compliance with this check.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: c9d007d0-c057-4772-b18c-01e546713bcd - Name: 'Storage accounts should allow access from trusted Microsoft services'

This creates authentication credentials for services that need access to storage resources so that services will no longer need to communicate via network request. There may be a temporary loss of communication as you set each Storage Account. It is recommended to not do this on mission-critical resources during business hours.

Automated

Turning on firewall rules for a storage account will block access to incoming requests for data, including from other Azure services. We can re-enable this functionality by allowing access to trusted Azure services through networking exceptions.

Remediate from Azure Portal1. Go to Storage Accounts.1. For each storage account, under Security + networking, click Networking.1. Click on the Firewalls and virtual networks heading.1. Under Exceptions, check the box next to Allow Azure services on the trusted services list to access this storage account.1. Click Save.Remediate from Azure CLIUse the below command to update bypass to Azure services.az storage account update --name <StorageAccountName> --resource-group <resourceGroupName> --bypass AzureServices

Level 2

4 Storage Accounts

Use private endpoints for your Azure Storage accounts to allow clients and services to securely access data located over a network via an encrypted Private Link. To do this, the private endpoint uses an IP address from the VNet for each service. Network traffic between disparate services securely traverses encrypted over the VNet. This VNet can also link addressing space, extending your network and accessing resources on it. Similarly, it can be a tunnel through public networks to connect remote infrastructures together. This creates further security through segmenting network traffic and preventing outside sources from accessing it.

By default, Private Endpoints are not created for Storage Accounts.

Audit from Azure Portal1. Open the Storage Accounts blade.1. For each listed Storage Account, perform the following check:1. Under the Security + networking heading, click on Networking. 1. Click on the Private endpoint connections tab at the top of the networking window.1. Ensure that for each VNet that the Storage Account must be accessed from, a unique Private Endpoint is deployed and the Connection state for each Private Endpoint is Approved.Repeat the procedure for each Storage Account.Audit from PowerShell$storageAccount = Get-AzStorageAccount -ResourceGroup '<ResourceGroupName>' -Name '<storageaccountname>'Get-AzPrivateEndpoint -ResourceGroup '<ResourceGroupName>'|Where-Object {$_.PrivateLinkServiceConnectionsText -match $storageAccount.id}If the results of the second command returns information, the Storage Account is using a Private Endpoint and complies with this Benchmark, otherwise if the results of the second command are empty, the Storage Account generates a finding.Audit from Azure CLIaz storage account show --name '<storage account name>' --query 'privateEndpointConnections[0].id'If the above command returns data, the Storage Account complies with this Benchmark, otherwise if the results are empty, the Storage Account generates a finding.Audit from Azure PolicyIf referencing a digital copy of this Benchmark, clicking a Policy ID will open a link to the associated Policy definition in Azure.If referencing a printed copy, you can search Policy IDs from this URL: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyMenuBlade/~/Definitions- Policy ID: 6edd7eda-6dd8-40f7-810d-67160c639cd9 - Name: 'Storage accounts should use private link'

A Private Endpoint costs approximately US$7.30 per month. If an Azure Virtual Network is not implemented correctly, this may result in the loss of critical network traffic.

Automated

Securing traffic between services through encryption protects the data from easy interception and reading.

Remediate from Azure Portal1. Open the Storage Accounts blade1. For each listed Storage Account, perform the following:1. Under the Security + networking heading, click on Networking 1. Click on the Private endpoint connections tab at the top of the networking window1. Click the + Private endpoint button1. In the 1 - Basics tab/step: - Enter a name that will be easily recognizable as associated with the Storage Account (Note: The 'Network Interface Name' will be automatically completed, but you can customize it if needed.) - Ensure that the Region matches the region of the Storage Account - Click Next1. In the 2 - Resource tab/step: - Select the target sub-resource based on what type of storage resource is being made available - Click Next1. In the 3 - Virtual Network tab/step: - Select the Virtual network that your Storage Account will be connecting to - Select the Subnet that your Storage Account will be connecting to - (Optional) Select other network settings as appropriate for your environment - Click Next1. In the 4 - DNS tab/step: - (Optional) Select other DNS settings as appropriate for your environment - Click Next1. In the 5 - Tags tab/step: - (Optional) Set any tags that are relevant to your organization - Click Next1. In the 6 - Review + create tab/step: - A validation attempt will be made and after a few moments it should indicate Validation Passed - if it does not pass, double-check your settings before beginning more in depth troubleshooting. - If validation has passed, click Create then wait for a few minutes for the scripted deployment to complete.Repeat the above procedure for each Private Endpoint required within every Storage Account.Remediate from PowerShell$storageAccount = Get-AzStorageAccount -ResourceGroupName '<ResourceGroupName>' -Name '<storageaccountname>'$privateEndpointConnection = @{ Name = 'connectionName' PrivateLinkServiceId = $storageAccount.Id GroupID = 'blob|blob_secondary|file|file_secondary|table|table_secondary|queue|queue_secondary|web|web_secondary|dfs|dfs_secondary'}$privateLinkServiceConnection = New-AzPrivateLinkServiceConnection @privateEndpointConnection$virtualNetDetails = Get-AzVirtualNetwork -ResourceGroupName '<ResourceGroupName>' -Name '<name>'$privateEndpoint = @{ ResourceGroupName = '<ResourceGroupName>' Name = '<PrivateEndpointName>' Location = '<location>' Subnet = $virtualNetDetails.Subnets[0] PrivateLinkServiceConnection = $privateLinkServiceConnection}New-AzPrivateEndpoint @privateEndpoint Remediate from Azure CLIaz network private-endpoint create --resource-group <ResourceGroupName --location <location> --name <private endpoint name> --vnet-name <VNET Name> --subnet <subnet name> --private-connection-resource-id <storage account ID> --connection-name <private link service connection name> --group-id <blob|blob_secondary|file|file_secondary|table|table_secondary|queue|queue_secondary|web|web_secondary|dfs|dfs_secondary>

A NAT gateway is the recommended solution for outbound internet access.

Level 1

4 Storage Accounts

The Azure Storage blobs contain data like ePHI or Financial, which can be secret or personal. Data that is erroneously modified or deleted by an application or other storage account user will cause data loss or unavailability.It is recommended that both Azure Containers with attached Blob Storage and standalone containers with Blob Storage be made recoverable by enabling the soft delete configuration. This is to save and recover data when blobs or blob snapshots are deleted.

Soft delete for containers and blob storage is enabled by default on storage accounts created via the Azure Portal, and disabled by default on storage accounts created via Azure CLI or PowerShell.

Audit from Azure Portal1. Go to Storage Accounts.1. For each Storage Account, under Data management, go to Data protection.1. Ensure that Enable soft delete for blobs is checked.1. Ensure that Enable soft delete for containers is checked.1. Ensure that the retention period for both is a sufficient length for your organization.Audit from Azure CLIBlob Storage: Ensure that the output of the below command contains enabled status as true and days is not empty or nullaz storage blob service-properties delete-policy show --account-name <storageAccount> --account-key <accountkey>Azure Containers: Ensure that within containerDeleteRetentionPolicy, the enabled property is set to true.az storage account blob-service-properties show --account-name <storageAccount> --resource-group <resourceGroup>

Additional storage costs may be incurred as snapshots are retained.

Automated

Containers and Blob Storage data can be incorrectly deleted. An attacker/malicious user may do this deliberately in order to cause disruption. Deleting an Azure Storage blob causes immediate data loss. Enabling this configuration for Azure storage ensures that even if blobs/data were deleted from the storage account, Blobs/data objects are recoverable for a particular time which is set in the 'Retention policies,' ranging from 7 days to 365 days.

Remediate from Azure Portal1. Go to Storage Accounts.1. For each Storage Account, under Data management, go to Data protection.1. Check the box next to Enable soft delete for blobs.1. Check the box next to Enable soft delete for containers.1. Set the retention period for both to a sufficient length for your organization.1. Click Save.Remediate from Azure CLIUpdate blob storage retention days in below commandaz storage blob service-properties delete-policy update --days-retained <RetentionDaysValue> --account-name <StorageAccountName> --account-key <AccountKey> --enable trueUpdate container retention with the below commandaz storage account blob-service-properties update --enable-container-delete-retention true --container-delete-retention-days <days> --account-name <storageAccount> --resource-group <resourceGroup>