diff --git a/dashboard/compliance/cis_7_0_m365.py b/dashboard/compliance/cis_7_0_m365.py new file mode 100644 index 0000000000..94558f33ad --- /dev/null +++ b/dashboard/compliance/cis_7_0_m365.py @@ -0,0 +1,24 @@ +import warnings + +from dashboard.common_methods import get_section_containers_cis + +warnings.filterwarnings("ignore") + + +def get_table(data): + aux = data[ + [ + "REQUIREMENTS_ID", + "REQUIREMENTS_DESCRIPTION", + "REQUIREMENTS_ATTRIBUTES_SECTION", + "CHECKID", + "STATUS", + "REGION", + "ACCOUNTID", + "RESOURCEID", + ] + ].copy() + + return get_section_containers_cis( + aux, "REQUIREMENTS_ID", "REQUIREMENTS_ATTRIBUTES_SECTION" + ) diff --git a/prowler/CHANGELOG.md b/prowler/CHANGELOG.md index 27aef3e1a1..d79f30b11d 100644 --- a/prowler/CHANGELOG.md +++ b/prowler/CHANGELOG.md @@ -9,6 +9,7 @@ All notable changes to the **Prowler SDK** are documented in this file. - `entra_conditional_access_policy_explicitly_targets_azure_devops` check for M365 provider, verifying at least one enabled Conditional Access policy explicitly includes the Azure DevOps cloud application instead of relying on a broad "All cloud apps" policy [(#11182)](https://github.com/prowler-cloud/prowler/pull/11182) - `entra_conditional_access_policy_no_exclusion_gaps` check for M365 provider, verifying every user, group, role, or application excluded from an enabled Conditional Access policy stays in scope of another enabled policy [(#11577)](https://github.com/prowler-cloud/prowler/pull/11577) - `stepfunctions_statemachine_encrypted_with_cmk` check for AWS provider, verifying that each Step Functions state machine uses a customer-managed KMS key for encryption at rest rather than the default AWS-owned key [(#11538)](https://github.com/prowler-cloud/prowler/pull/11538) +- CIS Microsoft 365 Foundations Benchmark v7.0.0 compliance framework for the M365 provider [(#11699)](https://github.com/prowler-cloud/prowler/pull/11699) - `waf_regional_webacl_logging_enabled` check for AWS provider, verifying that each AWS WAF Classic Regional Web ACL has logging enabled to a Kinesis Data Firehose stream [(#11539)](https://github.com/prowler-cloud/prowler/pull/11539) --- diff --git a/prowler/compliance/m365/cis_7.0_m365.json b/prowler/compliance/m365/cis_7.0_m365.json new file mode 100644 index 0000000000..49c700ba28 --- /dev/null +++ b/prowler/compliance/m365/cis_7.0_m365.json @@ -0,0 +1,3536 @@ +{ + "Framework": "CIS", + "Name": "CIS Microsoft 365 Foundations Benchmark v7.0.0", + "Version": "7.0", + "Provider": "M365", + "Description": "The CIS Microsoft 365 Foundations Benchmark provides prescriptive guidance for establishing a secure configuration posture for Microsoft 365 Cloud offerings running on any OS. This guide includes recommendations for Exchange Online, SharePoint Online, OneDrive for Business, Teams, Power BI (Fabric) and Microsoft Entra ID.", + "Requirements": [ + { + "Id": "1.1.1", + "Description": "Administrative accounts are special privileged accounts that could have varying levels of access to data, users, and settings. Regular user accounts should never be utilized for administrative tasks and care should be taken, in the case of a hybrid environment, to keep administrative accounts separate from on-prem accounts. Administrative accounts should not have applications assigned so that they have no access to potentially vulnerable services (EX. email, Teams, SharePoint, etc.) and only access to perform tasks as needed for administrative purposes. Ensure administrative accounts are not On-premises sync enabled.", + "Checks": [ + "entra_admin_users_cloud_only" + ], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.1 Users", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Administrative accounts are special privileged accounts that could have varying levels of access to data, users, and settings. Regular user accounts should never be utilized for administrative tasks and care should be taken, in the case of a hybrid environment, to keep administrative accounts separate from on-prem accounts. Administrative accounts should not have applications assigned so that they have no access to potentially vulnerable services (EX. email, Teams, SharePoint, etc.) and only access to perform tasks as needed for administrative purposes. Ensure administrative accounts are not On-premises sync enabled.", + "RationaleStatement": "In a hybrid environment, having separate accounts will help ensure that in the event of a breach in the cloud, that the breach does not affect the on-prem environment and vice versa.", + "ImpactStatement": "Administrative users will need to utilize login/logout functionality to switch accounts when performing administrative tasks, which means they will not benefit from SSO. This will require a migration process from the 'daily driver' account to a dedicated admin account. Once the new admin account is created, permission sets should be migrated from the 'daily driver' account to the new admin account. This includes both M365 and Azure RBAC roles. Failure to migrate Azure RBAC roles could prevent an admin from seeing their subscriptions/resources while using their admin account.", + "RemediationProcedure": "Remediation will require first identifying the privileged accounts that are synced from on- premises and then creating a new cloud-only account for that user. Once a replacement account is established, the hybrid account should have its role reduced to that of a non- privileged user or removed depending on the need.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Identity > Users and select All users. 3. To the right of the search box click the Add filter button. 4. Add the On-premises sync enabled filter with the value set to Yes and click Apply. 5. Verify that no user accounts in administrative roles are present in the filtered list. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"RoleManagement.Read.Directory\",\"User.Read.All\" 2. Run the following PowerShell script: $DirectoryRoles = Get-MgDirectoryRole # Get privileged role IDs $PrivilegedRoles = $DirectoryRoles | Where-Object { $_.DisplayName -like \"*Administrator*\" -or $_.DisplayName -eq \"Global Reader\" } # Get the members of these various roles $RoleMembers = $PrivilegedRoles | ForEach-Object { Get-MgDirectoryRoleMember -DirectoryRoleId $_.Id } | Select-Object Id -Unique # Retrieve details about the members in these roles $PrivilegedUsers = $RoleMembers | ForEach-Object { Get-MgUser -UserId $_.Id -Property UserPrincipalName, DisplayName, Id, OnPremisesSyncEnabled } $PrivilegedUsers | Where-Object { $_.OnPremisesSyncEnabled -eq $true } | ft DisplayName,UserPrincipalName,OnPremisesSyncEnabled 3. The script will output any hybrid users that are also members of privileged roles. If nothing returns, then no users with that criteria exist.", + "AdditionalInformation": "", + "DefaultValue": "N/A", + "References": "https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/add-users?view=o365-worldwide:https://learn.microsoft.com/en-us/microsoft-365/enterprise/protect-your-global-administrator-accounts?view=o365-worldwide:https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices#9-use-cloud-native-accounts-for-microsoft-entra-roles:https://learn.microsoft.com/en-us/entra/fundamentals/whatis:https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference" + } + ] + }, + { + "Id": "1.1.2", + "Description": "Emergency access or \"break glass\" accounts are limited for emergency scenarios where normal administrative accounts are unavailable. They are not assigned to a specific user and will have a combination of physical and technical controls to prevent them from being accessed outside a true emergency. These emergencies could be due to several things, including: - Technical failures of a cellular provider or Microsoft related service such as MFA. - The last remaining Global Administrator account is inaccessible. Ensure two Emergency Access accounts have been defined. Note: Microsoft provides several recommendations for these accounts and how to configure them. For more information on this, please refer to the references section. The CIS Benchmark outlines the more critical things to consider.", + "Checks": [ + "entra_break_glass_account_fido2_security_key_registered", + "entra_emergency_access_exclusion" + ], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.1 Users", + "Profile": "E3 Level 1", + "AssessmentStatus": "Manual", + "Description": "Emergency access or \"break glass\" accounts are limited for emergency scenarios where normal administrative accounts are unavailable. They are not assigned to a specific user and will have a combination of physical and technical controls to prevent them from being accessed outside a true emergency. These emergencies could be due to several things, including: - Technical failures of a cellular provider or Microsoft related service such as MFA. - The last remaining Global Administrator account is inaccessible. Ensure two Emergency Access accounts have been defined. Note: Microsoft provides several recommendations for these accounts and how to configure them. For more information on this, please refer to the references section. The CIS Benchmark outlines the more critical things to consider.", + "RationaleStatement": "In various situations, an organization may require the use of a break glass account to gain emergency access. In the event of losing access to administrative functions, an organization may experience a significant loss in its ability to provide support, lose insight into its security posture, and potentially suffer financial losses.", + "ImpactStatement": "Failure to properly implement emergency access accounts can weaken the security posture. Microsoft recommends excluding at least one of the two emergency access accounts from all conditional access rules, necessitating passwords with sufficient entropy and length to protect against random guesses. For a secure passwordless solution, FIDO2 security keys may be used instead of passwords.", + "RemediationProcedure": "To remediate using the UI: Step 1 - Create two emergency access accounts: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com 2. Expand Users > Active Users 3. Click Add user and create a new user with this criteria: o Name the account in a way that does NOT identify it with a particular person. o Assign the account to the default .onmicrosoft.com domain and not the organization's. o The password must be at least 16 characters and generated randomly. o Do not assign a license. o Assign the user the Global Administrator role. 4. Repeat the above steps for the second account. Step 2 - Exclude at least one account from conditional access policies: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand Protection > Conditional Access. 3. Inspect the conditional access policies. 4. For each rule add an exclusion for at least one of the emergency access accounts. 5. Users > Exclude > Users and groups and select one emergency access account. Step 3 - Ensure the necessary procedures and policies are in place: - In order for accounts to be effectively used in a break glass situation the proper policies and procedures must be authorized and distributed by senior management. - FIDO2 Security Keys should be locked in a secure separate fireproof location. - Passwords should be at least 16 characters, randomly generated and MAY be separated in multiple pieces to be joined in case of an emergency. Warning: As of 10/15/2024 MFA is required for all users including Break Glass Accounts. It is recommended to update these accounts to use passkey (FIDO2) or configure certificate-based authentication for MFA. Both methods satisfy the MFA requirement. Additional suggestions for emergency account management: - Create access reviews for these users. - Exclude users from conditional access rules. - Add the account to a restricted management administrative unit. Warning: If CA (conditional access) exclusion is managed by a group, this group should be added to PIM for groups (licensing required) or be created as a role-assignable group. If it is a regular security group, then users with the Group Administrators role are able to bypass CA entirely.", + "AuditProcedure": "To audit using the UI: Step 1 - Ensure a policy and procedure is in place at the organization: - In order for accounts to be effectively used in a break-glass situation the proper policies and procedures must be authorized and distributed by senior management. - FIDO2 Security Keys should be locked in a secure separate fireproof location. - Passwords should be at least 16 characters, randomly generated and MAY be separated in multiple pieces to be joined in case of an emergency. Step 2 - Ensure two emergency access accounts are defined: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com 2. Expand Users > Active Users 3. Inspect the designated emergency access accounts and ensure the following: o The accounts are named correctly, and do NOT identify with a particular person. o The accounts use the default .onmicrosoft.com domain and not the organization's. o The accounts are cloud-only. o The accounts are unlicensed. o The accounts are not disabled or Sign-in blocked. o The accounts are assigned the Global Administrator directory role. Step 3 - Ensure at least one account is excluded from all conditional access rules: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand Protection > Conditional Access. 3. Inspect the conditional access rules. 4. Ensure one of the emergency access accounts is excluded from all rules. Warning: As of 10/15/2024 MFA is required for all users including Break Glass Accounts. It is recommended to update these accounts to use passkey (FIDO2) or configure certificate-based authentication for MFA. Both methods satisfy the MFA requirement.", + "AdditionalInformation": "Microsoft has additional instructions regarding using Azure Monitor to capture events in the Log Analytics workspace, and then generate alerts for Emergency Access accounts. This requires an Azure subscription but should be strongly considered as a method of monitoring activity on these accounts: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security- emergency-access#monitor-sign-in-and-audit-logs", + "DefaultValue": "Not defined.", + "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-planning#stage-1-critical-items-to-do-right-now:https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access:https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/admin-units-restricted-management:https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication#accounts" + } + ] + }, + { + "Id": "1.1.3", + "Description": "Between two and four global administrators should be designated in the tenant. Ideally, these accounts will not have licenses assigned to them which supports additional controls found in this benchmark.", + "Checks": [ + "admincenter_users_between_two_and_four_global_admins" + ], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.1 Users", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Between two and four global administrators should be designated in the tenant. Ideally, these accounts will not have licenses assigned to them which supports additional controls found in this benchmark.", + "RationaleStatement": "The Global Administrator role grants unrestricted access across all services in Microsoft Entra ID and should never be used for routine daily activities. Limiting the number of Global Administrators reduces the attack surface of the tenant and aligns with the principle of least privilege. Fewer than two Global Administrators creates a single point of failure and removes the peer oversight needed to detect unauthorized actions. More than four increases the likelihood of account compromise by an external attacker. Maintaining between two and four Global Administrators balances operational redundancy against privileged access risk. For any accounts assigned the Global Administrator role, at least one strong authentication method such as a FIDO2 key or certificate is strongly advised.", + "ImpactStatement": "The potential impact associated with ensuring compliance with this requirement is dependent upon the current number of global administrators configured in the tenant. If there is only one global administrator in a tenant, an additional global administrator will need to be identified and configured. If there are more than four global administrators, a review of role requirements for current global administrators will be required to identify which of the users require global administrator access.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft 365 admin center https://admin.microsoft.com 2. Select Users > Active Users. 3. In the Search field enter the name of the user to be made a Global Administrator. 4. To create a new Global Admin: 1. Select the user's name. 2. A window will appear to the right. 3. Select Manage roles. 4. Select Admin center access. 5. Check Global Administrator. 6. Click Save changes. 5. To remove a Global Admin: 1. In the Search field, enter the name of the user to be removed. 2. Select the user's name. 3. A window will appear to the right. 4. Under Roles, select Manage roles. 5. Uncheck Global Administrator. 6. Click Save changes.", + "AuditProcedure": "Note: If an organization's tenant is using a third-party identity provider, the audit and remediation procedures presented here may not be relevant. The principle of the recommendation is still relevant, and compensating controls that are relevant to the third-party identity provider should be implemented. To audit using the UI: 1. Navigate to the Microsoft 365 admin center https://admin.microsoft.com 2. Select Roles > Role assignments. 3. Select the Global Administrator role from the list and click on Assigned. 4. Review the list of Global Administrators. o If there are groups present, then inspect each group and its members. o Take note of the total number of Global Administrators in and outside of groups. 5. Verify the number of Global Administrators is between two and four. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes Directory.Read.All 2. Run the following PowerShell script: # Determine Id of GA role using the immutable RoleTemplateId value. $GlobalAdminRole = Get-MgDirectoryRole -Filter \"RoleTemplateId eq '62e90394- 69f5-4237-9190-012177145e10'\" $RoleMembers = Get-MgDirectoryRoleMember -DirectoryRoleId $GlobalAdminRole.Id $GlobalAdmins = [System.Collections.Generic.List[Object]]::new() foreach ($object in $RoleMembers) { $Type = $object.AdditionalProperties.'@odata.type' # Check for and process role assigned groups if ($Type -eq '#microsoft.graph.group') { $GroupId = $object.Id $GroupMembers = (Get-MgGroupMember -GroupId $GroupId).AdditionalProperties foreach ($member in $GroupMembers) { if ($member.'@odata.type' -eq '#microsoft.graph.user') { $GlobalAdmins.Add([PSCustomObject][Ordered]@{ DisplayName = $member.displayName UserPrincipalName = $member.userPrincipalName }) } } } elseif ($Type -eq '#microsoft.graph.user') { $DisplayName = $object.AdditionalProperties.displayName $UPN = $object.AdditionalProperties.userPrincipalName $GlobalAdmins.Add([PSCustomObject][Ordered]@{ DisplayName = $DisplayName UserPrincipalName = $UPN }) } } $GlobalAdmins = $GlobalAdmins | select DisplayName,UserPrincipalName -Unique Write-Host \"*** There are\" $GlobalAdmins.Count \"Global Administrators in the organization.\" 3. Review the output and ensure there are between 2 and 4 Global Administrators. Note: When tallying the number of Global Administrators, the above does not account for Partner relationships. Those are located under Settings > Partner Relationships and should be reviewed on a recurring basis.", + "AdditionalInformation": "", + "DefaultValue": "", + "References": "https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.identity.directorymanagement/get-mgdirectoryrole?view=graph-powershell-1.0:https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#all-roles:https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices#5-limit-the-number-of-global-administrators-to-less-than-5:https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/about-admin-roles?view=o365-worldwide#security-guidelines-for-assigning-roles" + } + ] + }, + { + "Id": "1.1.4", + "Description": "Administrative accounts are special privileged accounts that could have varying levels of access to data, users, and settings. A license can enable an account to gain access to a variety of different applications, depending on the license assigned. The recommended state is to not license a privileged account or use licenses without associated applications such as Microsoft Entra ID P1 or Microsoft Entra ID P2.", + "Checks": [ + "admincenter_users_admins_reduced_license_footprint" + ], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.1 Users", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Administrative accounts are special privileged accounts that could have varying levels of access to data, users, and settings. A license can enable an account to gain access to a variety of different applications, depending on the license assigned. The recommended state is to not license a privileged account or use licenses without associated applications such as Microsoft Entra ID P1 or Microsoft Entra ID P2.", + "RationaleStatement": "Ensuring administrative accounts do not use licenses with applications assigned to them will reduce the attack surface of high privileged identities in the organization's environment. Granting access to a mailbox or other collaborative tools increases the likelihood that privileged users might interact with these applications, raising the risk of exposure to social engineering attacks or malicious content. These activities should be restricted to an unprivileged 'daily driver' account. Note: In order to participate in Microsoft 365 security services such as Identity Protection, PIM and Conditional Access an administrative account will need a license attached to it. Ensure that the license used does not include any applications with potentially vulnerable services by using either Microsoft Entra ID P1 or Microsoft Entra ID P2 for the cloud-only account with administrator roles.", + "ImpactStatement": "Administrative users will be required to switch accounts and use manual login/logout procedures when performing privileged tasks. This change also means they will not benefit from Single Sign-On (SSO), potentially impacting workflow efficiency and user experience. Note: Alerts will be sent to TenantAdmins, including Global Administrators, by default. To ensure proper receipt, configure alerts to be sent to security or operations staff with valid email addresses or a security operations center. Otherwise, after adoption of this recommendation, alerts sent to TenantAdmins may go unreceived due to the lack of an application-based license assigned to the Global Administrator accounts.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Users > Active users. 3. Click Add a user. 4. Fill out the appropriate fields for Name, user, etc. 5. When prompted to assign licenses select as needed Microsoft Entra ID P1 or Microsoft Entra ID P2, then click Next. 6. Under the Option settings screen you may choose from several types of privileged roles. Choose Admin center access followed by the appropriate role then click Next. 7. Select Finish adding. Note: Utilizing PIM to best practices will satisfy this control. CIS and Microsoft recommend an organization keep zero permanently active assignments for roles other than emergency access accounts.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Users > Active users. 3. Sort by the Licenses column. 4. For each user account in an administrative role verify the account is assigned a license that is not associated with applications i.e. (Microsoft Entra ID P1, Microsoft Entra ID P2). o If an organization uses PIM to elevate a daily driver account to privileged levels, this control and licensing requirement can be considered satisfied. Note: The final step assumes PIM is properly configured to best practices. Accounts eligible for the Global Administrator role should require approval to activate. Using the PIM blade to permanently assign accounts to privileged roles would not satisfy this audit procedure. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"RoleManagement.Read.Directory\",\"User.Read.All\" 2. Run the following PowerShell script: $DirectoryRoles = Get-MgDirectoryRole # Get privileged role IDs $PrivilegedRoles = $DirectoryRoles | Where-Object { $_.DisplayName -like \"*Administrator*\" -or $_.DisplayName -eq \"Global Reader\" } # Get the members of these various roles $RoleMembers = $PrivilegedRoles | ForEach-Object { Get-MgDirectoryRoleMember -DirectoryRoleId $_.Id } | Select-Object Id -Unique # Retrieve details about the members in these roles $PrivilegedUsers = $RoleMembers | ForEach-Object { Get-MgUser -UserId $_.Id -Property UserPrincipalName, DisplayName, Id } $Report = [System.Collections.Generic.List[Object]]::new() foreach ($Admin in $PrivilegedUsers) { $License = $null $License = (Get-MgUserLicenseDetail -UserId $Admin.id).SkuPartNumber - join \", \" $Object = [pscustomobject][ordered]@{ DisplayName = $Admin.DisplayName UserPrincipalName = $Admin.UserPrincipalName License = $License } $Report.Add($Object) } $Report 3. The output will display users assigned privileged roles alongside their assigned licenses. Additional manual assessment is required to determine if the licensing is appropriate for the user.", + "AdditionalInformation": "", + "DefaultValue": "N/A", + "References": "https://learn.microsoft.com/en-us/microsoft-365/enterprise/protect-your-global-administrator-accounts?view=o365-worldwide:https://learn.microsoft.com/en-us/entra/fundamentals/whatis#what-are-the-microsoft-entra-id-licenses:https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference:https://learn.microsoft.com/en-us/microsoft-365/business-premium/m365bp-protect-admin-accounts?view=o365-worldwide:https://learn.microsoft.com/en-us/microsoft-365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings?view=o365-worldwide#licenses:https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-deployment-plan#principle-of-least-privilege" + } + ] + }, + { + "Id": "1.2.1", + "Description": "Microsoft 365 Groups is the foundational membership service that drives all teamwork across Microsoft 365. With Microsoft 365 Groups, you can give a group of people access to a collection of shared resources. When a new group is created in the Administration panel, the default privacy value of the group is \"Public\". (In this case, 'public' means accessible to the identities within the organization without requiring group owner authorization to join.) The recommended state is Microsoft 365 Groups are set to Private in the Administration panel. Note: Although there are several different group types, this recommendation concerns Microsoft 365 Groups specifically.", + "Checks": [ + "admincenter_groups_not_public_visibility" + ], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.2 Teams & groups", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Microsoft 365 Groups is the foundational membership service that drives all teamwork across Microsoft 365. With Microsoft 365 Groups, you can give a group of people access to a collection of shared resources. When a new group is created in the Administration panel, the default privacy value of the group is \"Public\". (In this case, 'public' means accessible to the identities within the organization without requiring group owner authorization to join.) The recommended state is Microsoft 365 Groups are set to Private in the Administration panel. Note: Although there are several different group types, this recommendation concerns Microsoft 365 Groups specifically.", + "RationaleStatement": "If group privacy is not controlled, any user may access sensitive information, depending on the group they try to access. When the privacy value of a group is set to \"Public,\" users may access data related to this group (e.g. SharePoint) via three methods: 1. The Azure Portal: Users can add themselves to the public group via the Azure Portal; however, administrators are notified when users access the Portal. 2. Access Requests: Users can request to join the group via the Groups application in the Access Panel. This provides the user with immediate access to the group, even though they are required to send a message to the group owner when requesting to join. 3. SharePoint URL: Users can directly access a group via its SharePoint URL, which is usually guessable and can be found in the Groups application within the Access Panel.", + "ImpactStatement": "If the recommendation is applied, group owners could receive more access requests than usual, especially regarding groups originally meant to be public.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Teams & groups > Active teams & groups. 3. On the Active teams and groups page, select the group's name that is public. 4. On the popup groups name page, Select Settings. 5. Under Privacy, select Private.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Teams & groups > Active teams & groups. 3. On the Active teams and groups page, check that no groups have the status 'Public' in the privacy column. To audit using PowerShell: 1. Connect to the Microsoft Graph service using Connect-MgGraph -Scopes \"Group.Read.All\". 2. Run the following Microsoft Graph PowerShell command: $Groups = Get-MgGroup -All -Filter \"groupTypes/any(c:c eq 'Unified')\" ` -Property Id,DisplayName,Visibility,GroupTypes # Displays the groups to the console for review $Groups | ft Id,DisplayName,Visibility 3. Verify that Visibility is Private for each group.", + "AdditionalInformation": "", + "DefaultValue": "Public when created from the Administration portal; private otherwise.", + "References": "https://learn.microsoft.com/en-us/entra/identity/users/groups-self-service-management:https://learn.microsoft.com/en-us/microsoft-365/admin/create-groups/compare-groups?view=o365-worldwide" + } + ] + }, + { + "Id": "1.2.2", + "Description": "Shared mailboxes are used when multiple people need access to the same mailbox, such as a company information or support email address, reception desk, or other function that might be shared by multiple people. Users with permissions to the group mailbox can send as or send on behalf of the mailbox email address if the administrator has given that user permissions to do that. This is particularly useful for help and support mailboxes because users can send emails from \"Contoso Support\" or \"Building A Reception Desk.\" Shared mailboxes are created with a corresponding user account using a system generated password that is unknown at the time of creation. The recommended state is Sign in blocked for Shared mailboxes.", + "Checks": [ + "exchange_shared_mailbox_sign_in_disabled" + ], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.2 Teams & groups", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Shared mailboxes are used when multiple people need access to the same mailbox, such as a company information or support email address, reception desk, or other function that might be shared by multiple people. Users with permissions to the group mailbox can send as or send on behalf of the mailbox email address if the administrator has given that user permissions to do that. This is particularly useful for help and support mailboxes because users can send emails from \"Contoso Support\" or \"Building A Reception Desk.\" Shared mailboxes are created with a corresponding user account using a system generated password that is unknown at the time of creation. The recommended state is Sign in blocked for Shared mailboxes.", + "RationaleStatement": "The intent of the shared mailbox is to only allow delegated access from other mailboxes. An admin could reset the password, or an attacker could potentially gain access to the shared mailbox allowing the direct sign-in to the shared mailbox and subsequently the sending of email from a sender that does not have a unique identity. To prevent this, block sign-in for the account that is associated with the shared mailbox.", + "ImpactStatement": "Blocking sign-in to shared mailboxes prevents direct authentication to these accounts. Authorized users can still access shared mailbox content through their own accounts using Outlook delegation or by being granted Send As/Send on Behalf permissions. This change strengthens security by ensuring shared mailboxes cannot serve as entry points for unauthorized access.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com/ 2. Click to expand Teams & groups and select Shared mailboxes. 3. Take note of all shared mailboxes. 4. Click to expand Users and select Active users. 5. Select a shared mailbox account to open its properties pane and then select Block sign-in. 6. Check the box for Block this user from signing in. 7. Repeat for any additional shared mailboxes. To remediate using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"User.ReadWrite.All\" 2. Connect to Exchange Online using Connect-ExchangeOnline. 3. To disable sign-in for a single account: $MBX = Get-EXOMailbox -Identity TestUser@example.com Update-MgUser -UserId $MBX.ExternalDirectoryObjectId -AccountEnabled:$false The following can be used block sign-in to all Shared Mailboxes: $MBX = Get-EXOMailbox -RecipientTypeDetails SharedMailbox $MBX | ForEach-Object { Update-MgUser -UserId $_.ExternalDirectoryObjectId - AccountEnabled:$false }", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com/ 2. Expand Teams & groups and select Shared mailboxes. 3. Take note of all shared mailboxes. 4. Expand Users and select Active users. 5. Select a shared mailbox account to open its properties pane, and review. 6. Verify that the text under the name reads Sign-in blocked. 7. Repeat for any additional shared mailboxes. Note: If sign-in is not blocked there will be an option to Block sign-in. This means the shared mailbox is out of compliance with this recommendation. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline 2. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"User.Read.All\" 3. Run the following PowerShell commands: $MBX = Get-EXOMailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited $MBX | ForEach-Object { Get-MgUser -UserId $_.ExternalDirectoryObjectId ` -Property DisplayName, UserPrincipalName, AccountEnabled } | Format-Table DisplayName, UserPrincipalName, AccountEnabled 4. Ensure AccountEnabled is set to False for all Shared Mailboxes.", + "AdditionalInformation": "", + "DefaultValue": "AccountEnabled: True", + "References": "https://learn.microsoft.com/en-us/microsoft-365/admin/email/about-shared-mailboxes?view=o365-worldwide:https://learn.microsoft.com/en-us/microsoft-365/admin/email/create-a-shared-mailbox?view=o365-worldwide#block-sign-in-for-the-shared-mailbox-account:https://learn.microsoft.com/en-us/microsoft-365/enterprise/block-user-accounts-with-microsoft-365-powershell?view=o365-worldwide#block-individual-user-accounts" + } + ] + }, + { + "Id": "1.3.1", + "Description": "Microsoft cloud-only accounts have a pre-defined password policy that cannot be changed. The only items that can change are the number of days until a password expires and whether or not passwords expire at all.", + "Checks": [ + "admincenter_settings_password_never_expire" + ], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.3 Settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft cloud-only accounts have a pre-defined password policy that cannot be changed. The only items that can change are the number of days until a password expires and whether or not passwords expire at all.", + "RationaleStatement": "Organizations such as NIST and Microsoft recommend against arbitrarily requiring users to change their passwords after a set period, unless there is evidence of compromise or the user has forgotten the password. This guidance applies even to single-factor (password-only) scenarios, as forced, periodic changes often lead to weaker passwords and reduced security. Additionally, this Benchmark advises implementing multi-factor authentication (MFA) for all accounts, which further diminishes the value of password expiration policies. Long-lived passwords can be further strengthened by enabling additional password protection features in Entra ID.", + "ImpactStatement": "When setting passwords not to expire it is important to have other controls in place to supplement this setting. See below for related recommendations and user guidance. - Ban common passwords. - Educate users to not reuse organization passwords anywhere else. - Enforce Multi-Factor Authentication registration for all users.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings > Org Settings. 3. Click on Security & privacy. 4. Check the Set passwords to never expire (recommended) box. 5. Click Save. To remediate using PowerShell: 1. Connect to the Microsoft Graph service using Connect-MgGraph -Scopes \"Domain.ReadWrite.All\". 2. Run the following Microsoft Graph PowerShell command: Update-MgDomain -DomainId -PasswordValidityPeriodInDays 2147483647", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings > Org Settings. 3. Click on Security & privacy. 4. Select Password expiration policy and verify that Set passwords to never expire (recommended) has been checked. To audit using PowerShell: 1. Connect to the Microsoft Graph service using Connect-MgGraph -Scopes \"Domain.Read.All\". 2. Run the following Microsoft Online PowerShell command: Get-MgDomain | ft id,PasswordValidityPeriodInDays 3. Verify the value returned for valid domains is 2147483647", + "AdditionalInformation": "", + "DefaultValue": "If the property is not set, a default value of 90 days will be used", + "References": "https://pages.nist.gov/800-63-3/sp800-63b.html:https://www.cisecurity.org/white-papers/cis-password-policy-guide/:https://learn.microsoft.com/en-us/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide" + } + ] + }, + { + "Id": "1.3.2", + "Description": "Idle session timeout allows the configuration of a setting which will timeout inactive users after a pre-determined amount of time. When a user reaches the set idle timeout session, they'll get a notification that they're about to be signed out. They must choose to stay signed in or they'll be automatically signed out of all Microsoft 365 web apps. Combined with a Conditional Access rule this will only impact unmanaged devices. A managed device is considered a device managed by Intune MDM or joined to a domain (Entra ID or Hybrid joined). The following Microsoft 365 web apps are supported. - Outlook Web App - OneDrive - SharePoint - Microsoft Fabric - Microsoft365.com and other start pages - Microsoft 365 web apps (Word, Excel, PowerPoint) - Microsoft 365 Admin Center - M365 Defender Portal - Microsoft Purview Compliance Portal The recommended setting is 3 hours (or less) for unmanaged devices. Note: Idle session timeout doesn't affect Microsoft 365 desktop and mobile apps.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.3 Settings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Idle session timeout allows the configuration of a setting which will timeout inactive users after a pre-determined amount of time. When a user reaches the set idle timeout session, they'll get a notification that they're about to be signed out. They must choose to stay signed in or they'll be automatically signed out of all Microsoft 365 web apps. Combined with a Conditional Access rule this will only impact unmanaged devices. A managed device is considered a device managed by Intune MDM or joined to a domain (Entra ID or Hybrid joined). The following Microsoft 365 web apps are supported. - Outlook Web App - OneDrive - SharePoint - Microsoft Fabric - Microsoft365.com and other start pages - Microsoft 365 web apps (Word, Excel, PowerPoint) - Microsoft 365 Admin Center - M365 Defender Portal - Microsoft Purview Compliance Portal The recommended setting is 3 hours (or less) for unmanaged devices. Note: Idle session timeout doesn't affect Microsoft 365 desktop and mobile apps.", + "RationaleStatement": "Ending idle sessions through an automatic process can help protect sensitive company data and will add another layer of security for end users who work on unmanaged devices that can potentially be accessed by the public. Unauthorized individuals onsite or remotely can take advantage of systems left unattended over time. Automatic timing out of sessions makes this more difficult.", + "ImpactStatement": "If step 2 in the Audit/Remediation procedure is left out, then there is no issue with this from a security standpoint. However, it will require users on trusted devices to sign in more frequently which could result in credential prompt fatigue. Users don't get signed out in these cases: - If they get single sign-on (SSO) into the web app from the device joined account. - If they selected Stay signed in at the time of sign-in. For more info on hiding this option for your organization, see Add branding to your organization's sign-in page. - If they're on a managed device, that is compliant or joined to a domain and using a supported browser, like Microsoft Edge, or Google Chrome with the Microsoft Single Sign On extension. Note: Idle session timeout also affects the Azure Portal idle timeout if this is not explicitly set to a different timeout. The Azure Portal idle timeout applies to all kinds of devices, not just unmanaged. See: change the directory timeout setting admin", + "RemediationProcedure": "Step 1 - Configure Idle session timeout: To remediate using the UI: 1. Navigate to the Microsoft 365 admin center https://admin.microsoft.com/. 2. Expand Settings > Org settings. 3. Click Security & Privacy tab. 4. Select Idle session timeout. 5. Check the box Turn on to set the period of inactivity for users to be signed off of Microsoft 365 web apps 6. Set a maximum value of 3 hours. 7. Click save. Step 2 - Ensure the Conditional Access policy is in place: To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand Protect > Conditional Access. 3. Click New policy and give the policy a name. o Select Users > All users. o Select Cloud apps or actions > Select apps and select Office 365 o Select Conditions > Client apps > Yes check only Browser unchecking all other boxes. o Select Sessions and check Use app enforced restrictions. 4. Set Enable policy to On and click Create. Note: To ensure that idle timeouts affect only unmanaged devices, both steps 1 and 2 must be completed. Otherwise managed devices will also be impacted by the timeout policy.", + "AuditProcedure": "Step 1 - Ensure Idle session timeout is configured: To audit using the UI: 1. Navigate to the Microsoft 365 admin center https://admin.microsoft.com/. 2. Expand Settings > Org settings. 3. Click Security & Privacy tab. 4. Select Idle session timeout. 5. Verify that Turn on to set the period of inactivity for users to be signed off of Microsoft 365 web apps is set to 3 hours (or less). To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.All\": 2. Run the following script: $TimeoutPolicy = Get-MgPolicyActivityBasedTimeoutPolicy $BenchmarkTimeSpan = [TimeSpan]::Parse('03:00:00') # 3 hours if ($TimeoutPolicy) { $PolicyDefinition = $TimeoutPolicy.Definition | ConvertFrom-Json $Timeout = $PolicyDefinition.ActivityBasedTimeoutPolicy.ApplicationPolicies[0].WebSessio nIdleTimeout $TimeSpan = [TimeSpan]::Parse($Timeout) $TimeoutReadable = \"{0} days, {1} hours, {2} minutes\" ` -f $TimeSpan.Days, $TimeSpan.Hours, $TimeSpan.Minutes if ($TimeSpan -le $BenchmarkTimeSpan) { Write-Host \"** PASS ** Timeout is set to $TimeoutReadable.\" } else { Write-Host \"** FAIL ** Timeout is too long. It is set to $TimeoutReadable.\" } } else { Write-Host \"** FAIL **: Idle session timeout is not configured.\" } 3. Verify the policy exists and is 3 hours or less. Step 2 - Ensure the Conditional Access policy is in place: To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand Protect > Conditional Access. 3. Inspect existing conditional access rules for one that meets the below conditions: o Users or agents (Preview) is set to include All users. o Cloud apps or actions > Select apps is set to Office 365. o Conditions > Client apps is Browser and nothing else. o Session is set to Use app enforced restrictions. o Enable Policy is set to On To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.All\": 2. Run the following script: $Caps = Get-MgIdentityConditionalAccessPolicy -All | Where-Object { $_.SessionControls.ApplicationEnforcedRestrictions.IsEnabled } $CapReport = [System.Collections.Generic.List[Object]]::new() # Filter to policies with \"Use app enforced restrictions\" enabled # Loop through policies and generate a per policy report. foreach ($policy in $Caps) { $Name = $policy.DisplayName $Users = $policy.Conditions.Users.IncludeUsers $Targets = $policy.Conditions.Applications.IncludeApplications $ClientApps = $policy.Conditions.ClientAppTypes $Restrictions = $policy.SessionControls.ApplicationEnforcedRestrictions.IsEnabled $State = $policy.State $CountPass = $Targets.count -eq 1 -and $ClientApps.count -eq 1 $Pass = $Targets -eq 'Office365' -and $ClientApps -eq 'browser' -and $Restrictions -and $CountPass -and $State -eq 'enabled' $obj = [PSCustomObject]@{ DisplayName = $Name AuditState = if ($Pass) { \"PASS\" } else { \"FAIL\" } IncludeUsers = $Users IncludeApplications = $Targets ClientAppTypes = $ClientApps AppEnforcedRestrictions = $Restrictions State = $State } $CapReport.Add($obj) } if ($Caps) { $CapReport } else { Write-Host \"** FAIL **: There are no qualifying conditional access policies.\" } 3. The script will output qualifying Conditional Access Policies. If one policy passes, then the recommendation passes. A passing policy will have the following properties: DisplayName : (CIS) Idle timeout for unmanaged AuditState : PASS IncludeUsers : {All} # IncludeUsers not currently scored IncludeApplications : {Office365} ClientAppTypes : {browser} AppEnforcedRestrictions : True State : enabled Note: Both steps 1 and 2 must pass audit checks in order for the recommendation to pass as a whole.", + "AdditionalInformation": "According to Microsoft idle session timeout isn't supported when third party cookies are disabled in the browser. Users won't see any sign-out prompts.", + "DefaultValue": "Not configured. (Idle sessions will not timeout.)", + "References": "https://learn.microsoft.com/en-us/microsoft-365/admin/manage/idle-session-timeout-web-apps?view=o365-worldwide" + } + ] + }, + { + "Id": "1.3.3", + "Description": "External calendar sharing allows an administrator to enable the ability for users to share calendars with anyone outside of the organization. Outside users will be sent a URL that can be used to view the calendar.", + "Checks": [ + "admincenter_external_calendar_sharing_disabled" + ], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.3 Settings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "External calendar sharing allows an administrator to enable the ability for users to share calendars with anyone outside of the organization. Outside users will be sent a URL that can be used to view the calendar.", + "RationaleStatement": "Attackers often spend time learning about organizations before launching an attack. Publicly available calendars can help attackers understand organizational relationships and determine when specific users may be more vulnerable to an attack, such as when they are traveling.", + "ImpactStatement": "This functionality is not widely used. As a result, it is unlikely that implementation of this setting will cause an impact to most users. Users that do utilize this functionality are likely to experience a minor inconvenience when scheduling meetings or synchronizing calendars with people outside the tenant.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings select Org settings. 3. In the Services section click Calendar. 4. Uncheck Let your users share their calendars with people outside of your organization who have Office 365 or Exchange. 5. Click Save. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following Exchange Online PowerShell command: Set-SharingPolicy -Identity \"Default Sharing Policy\" -Enabled $False", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings > Org settings. 3. In the Services section click Calendar. 4. Verify that Let your users share their calendars with people outside of your organization who have Office 365 or Exchange is unchecked. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following Exchange Online PowerShell command: Get-SharingPolicy -Identity \"Default Sharing Policy\" | ft Name,Enabled 3. Verify that Enabled is set to False", + "AdditionalInformation": "The following script can be used to audit any mailboxes that might be sharing calendars prior to disabling the feature globally: $mailboxes = Get-Mailbox -ResultSize Unlimited foreach ($mailbox in $mailboxes) { # Get the name of the default calendar folder (depends on the mailbox's language) $calendarFolder = [string](Get-ExoMailboxFolderStatistics $mailbox.PrimarySmtpAddress -FolderScope Calendar| Where-Object { $_.FolderType -eq 'Calendar' }).Name # Get users calendar folder settings for their default Calendar folder # calendar has the format identity:\\ $calendar = Get-MailboxCalendarFolder -Identity \"$($mailbox.PrimarySmtpAddress):\\$calendarFolder\" if ($calendar.PublishEnabled) { Write-Host -ForegroundColor Yellow \"Calendar publishing is enabled for $($mailbox.PrimarySmtpAddress) on $($calendar.PublishedCalendarUrl)\" } }", + "DefaultValue": "Enabled (True)", + "References": "https://learn.microsoft.com/en-us/microsoft-365/admin/manage/share-calendars-with-external-users?view=o365-worldwide" + } + ] + }, + { + "Id": "1.3.4", + "Description": "By default, users can install add-ins in their Microsoft Word, Excel, and PowerPoint applications, allowing data access within the application. Do not allow users to install add-ins in Word, Excel, or PowerPoint.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.3 Settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "By default, users can install add-ins in their Microsoft Word, Excel, and PowerPoint applications, allowing data access within the application. Do not allow users to install add-ins in Word, Excel, or PowerPoint.", + "RationaleStatement": "Attackers commonly use vulnerable and custom-built add-ins to access data in user applications. While allowing users to install add-ins by themselves does allow them to easily acquire useful add-ins that integrate with Microsoft applications, it can represent a risk if not used and monitored carefully. Disabling future users' ability to install add-ins in Microsoft Word, Excel, or PowerPoint helps reduce your threat-surface and mitigate this risk.", + "ImpactStatement": "Implementation of this change will impact both end users and administrators. End users will not be able to install add-ins that they may want to install.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings > Org settings. 3. In Services select User owned apps and services. 4. Uncheck Let users access the Office Store and Let users start trials on behalf of your organization. 5. Click Save. To remediate using PowerShell 1. Connect to the Microsoft Graph service using Connect-MgGraph -Scopes \"OrgSettings-AppsAndServices.ReadWrite.All\". 2. Run the following Microsoft Graph PowerShell commands: $uri = \"https://graph.microsoft.com/beta/admin/appsAndServices\" $body = @{ \"Settings\" = @{ \"isAppAndServicesTrialEnabled\" = $false \"isOfficeStoreEnabled\" = $false } } | ConvertTo-Json Invoke-MgGraphRequest -Method PATCH -Uri $uri -Body $body", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings > Org settings. 3. In Services select User owned apps and services. 4. Verify that Let users access the Office Store and Let users start trials on behalf of your organization are not checked. To Audit using PowerShell: 1. Connect to the Microsoft Graph service using Connect-MgGraph -Scopes \"OrgSettings-AppsAndServices.Read.All\". 2. Run the following Microsoft Graph PowerShell command: $Uri = \"https://graph.microsoft.com/beta/admin/appsAndServices/settings\" Invoke-MgGraphRequest -Uri $Uri 3. Verify both isOfficeStoreEnabled and isAppAndServicesTrialEnabled are False.", + "AdditionalInformation": "", + "DefaultValue": "Let users access the Office Store is Checked Let users start trials on behalf of your organization is Checked", + "References": "https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-addins-in-the-admin-center?view=o365-worldwide#manage-add-in-downloads-by-turning-onoff-the-office-store-across-all-apps-except-outlook" + } + ] + }, + { + "Id": "1.3.5", + "Description": "Microsoft Forms can be used for phishing attacks by asking personal or sensitive information and collecting the results. Microsoft 365 has built-in protection that will proactively scan for phishing attempt in forms such personal information request.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.3 Settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft Forms can be used for phishing attacks by asking personal or sensitive information and collecting the results. Microsoft 365 has built-in protection that will proactively scan for phishing attempt in forms such personal information request.", + "RationaleStatement": "Enabling internal phishing protection for Microsoft Forms will prevent attackers using forms for phishing attacks by asking personal or other sensitive information and URLs.", + "ImpactStatement": "If potential phishing was detected, the form will be temporarily blocked and cannot be distributed, and response collection will not happen until it is unblocked by the administrator or keywords were removed by the creator.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings > Org settings. 3. Under Services select Microsoft Forms. 4. Click the checkbox labeled Add internal phishing protection under Phishing protection. 5. Click Save. To remediate using PowerShell 1. Connect to the Microsoft Graph service using Connect-MgGraph -Scopes \"OrgSettings-AppsAndServices.ReadWrite.All\". 2. Run the following Microsoft Graph PowerShell commands: $uri = 'https://graph.microsoft.com/beta/admin/forms/settings' $body = @{ \"isInOrgFormsPhishingScanEnabled\" = $true } | ConvertTo-Json Invoke-MgGraphRequest -Method PATCH -Uri $uri -Body $body", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings > Org settings. 3. Under Services select Microsoft Forms. 4. Verify the checkbox labeled Add internal phishing protection is checked under Phishing protection. To Audit using PowerShell: 1. Connect to the Microsoft Graph service using Connect-MgGraph -Scopes \"OrgSettings-Forms.Read.All\". 2. Run the following Microsoft Graph PowerShell commands: $uri = 'https://graph.microsoft.com/beta/admin/forms/settings' Invoke-MgGraphRequest -Uri $uri | select isInOrgFormsPhishingScanEnabled 3. Verify that isInOrgFormsPhishingScanEnabled is 'True'.", + "AdditionalInformation": "", + "DefaultValue": "Internal Phishing Protection is enabled.", + "References": "https://learn.microsoft.com/en-US/microsoft-forms/administrator-settings-microsoft-forms:https://learn.microsoft.com/en-US/microsoft-forms/review-unblock-forms-users-detected-blocked-potential-phishing" + } + ] + }, + { + "Id": "1.3.6", + "Description": "Customer Lockbox is a security feature that provides an additional layer of control and transparency to customer data in Microsoft 365. It offers an approval process for Microsoft support personnel to access organization data and creates an audited trail to meet compliance requirements.", + "Checks": [ + "admincenter_organization_customer_lockbox_enabled" + ], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.3 Settings", + "Profile": "E5 Level 2", + "AssessmentStatus": "Automated", + "Description": "Customer Lockbox is a security feature that provides an additional layer of control and transparency to customer data in Microsoft 365. It offers an approval process for Microsoft support personnel to access organization data and creates an audited trail to meet compliance requirements.", + "RationaleStatement": "Enabling this feature protects organizational data against data spillage and exfiltration.", + "ImpactStatement": "Administrators will need to grant Microsoft access to the tenant environment prior to a Microsoft engineer accessing the environment for support or troubleshooting.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings > Org settings. 3. Select Security & privacy tab. 4. Click Customer lockbox. 5. Check the box Require approval for all data access requests. 6. Click Save. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-OrganizationConfig -CustomerLockBoxEnabled $true", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings > Org settings. 3. Select Security & privacy tab. 4. Click Customer lockbox. 5. Verify the box labeled Require approval for all data access requests is checked. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-OrganizationConfig | Select-Object CustomerLockBoxEnabled 3. Verify the value is set to True.", + "AdditionalInformation": "", + "DefaultValue": "Require approval for all data access requests - Unchecked CustomerLockboxEnabled - False", + "References": "https://learn.microsoft.com/en-us/purview/customer-lockbox-requests#turn-customer-lockbox-requests-on-or-off" + } + ] + }, + { + "Id": "1.3.7", + "Description": "Third-party storage can be enabled for users in Microsoft 365, allowing them to store and share documents using services such as Dropbox, alongside OneDrive and team sites. Ensure Microsoft 365 on the web third-party storage services are restricted.", + "Checks": [ + "exchange_mailbox_policy_additional_storage_restricted" + ], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.3 Settings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Third-party storage can be enabled for users in Microsoft 365, allowing them to store and share documents using services such as Dropbox, alongside OneDrive and team sites. Ensure Microsoft 365 on the web third-party storage services are restricted.", + "RationaleStatement": "By using external storage services an organization may increase the risk of data breaches and unauthorized access to confidential information. Additionally, third-party services may not adhere to the same security standards as the organization, making it difficult to maintain data privacy and security.", + "ImpactStatement": "Impact associated with this change is highly dependent upon current practices in the tenant. If users do not use other storage providers, then minimal impact is likely. However, if users do regularly utilize providers outside of the tenant this will affect their ability to continue to do so.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com 2. Go to Settings > Org Settings > Services > Microsoft 365 on the web 3. Uncheck Let users open files stored in third-party storage services in Microsoft 365 on the web To remediate using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Application.ReadWrite.All\" 2. Run the following script: $SP = Get-MgServicePrincipal -Filter \"appId eq 'c1f33bc0-bdb4-4248-ba9b- 096807ddb43e'\" # If the service principal doesn't exist then create it first. if (-not $SP) { $SP = New-MgServicePrincipal -AppId \"c1f33bc0-bdb4-4248-ba9b- 096807ddb43e\" } Update-MgServicePrincipal -ServicePrincipalId $SP.Id -AccountEnabled:$false", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com 2. Go to Settings > Org Settings > Services > Microsoft 365 on the web 3. Verify that Let users open files stored in third-party storage services in Microsoft 365 on the web is not checked. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Application.Read.All\". 2. Run the following script: $SP = Get-MgServicePrincipal -Filter \"appId eq 'c1f33bc0-bdb4-4248-ba9b- 096807ddb43e'\" if ((-not $SP) -or $SP.AccountEnabled) { Write-Host \"Audit Result: ** FAIL **\" } else { Write-Host \"Audit Result: ** PASS **\" } 3. Verify that AccountEnabled is False. Note: The check will also fail if the Service Principal does not exist as users will still be able to open files stored in third-party storage services in Microsoft 365 on the web.", + "AdditionalInformation": "", + "DefaultValue": "Enabled - Users are able to open files stored in third-party storage services", + "References": "https://learn.microsoft.com/en-us/microsoft-365/admin/setup/set-up-file-storage-and-sharing?view=o365-worldwide#enable-or-disable-third-party-storage-services" + } + ] + }, + { + "Id": "1.3.8", + "Description": "Sway is a Microsoft 365 app that lets organizations create interactive, web-based presentations using images, text, videos and other media. Its design engine simplifies the process, allowing for quick customization. Presentations can then be shared via a link. This setting controls user Sway sharing capability, both within and outside of the organization. By default, Sway is enabled for everyone in the organization.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.3 Settings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Manual", + "Description": "Sway is a Microsoft 365 app that lets organizations create interactive, web-based presentations using images, text, videos and other media. Its design engine simplifies the process, allowing for quick customization. Presentations can then be shared via a link. This setting controls user Sway sharing capability, both within and outside of the organization. By default, Sway is enabled for everyone in the organization.", + "RationaleStatement": "Disable external sharing of Sway documents that can contain sensitive information to prevent accidental or arbitrary data leaks.", + "ImpactStatement": "Interactive reports, presentations, newsletters, and other items created in Sway will not be shared outside the organization by users.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings > Org settings. 3. Under Services select Sway o Uncheck: Let people in your organization share their sways with people outside your organization. 4. Click Save.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings > Org settings. 3. Under Services select Sway. 4. Verify that under Sharing, the following is not checked: o Let people in your organization share their sways with people outside your organization.", + "AdditionalInformation": "", + "DefaultValue": "Let people in your organization share their sways with people outside your organization - Enabled", + "References": "https://support.microsoft.com/en-us/office/administrator-settings-for-sway-d298e79b-b6ab-44c6-9239-aa312f5784d4:https://learn.microsoft.com/en-us/office365/servicedescriptions/microsoft-sway-service-description" + } + ] + }, + { + "Id": "1.3.9", + "Description": "Shared Bookings allows you to invite your team members and create booking pages and let your customers book time with you and your team. It contains various settings to define services, manage staff members, configure schedules and availability, business hours and customize how appointments are scheduled. These pages can be customized to fit the diverse needs of your organization. It is an extension of Person Bookings. The recommended state is to restrict the OwaMailboxPolicy-Default policy or disable at the organization level.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Microsoft 365 admin center", + "SubSection": "1.3 Settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Shared Bookings allows you to invite your team members and create booking pages and let your customers book time with you and your team. It contains various settings to define services, manage staff members, configure schedules and availability, business hours and customize how appointments are scheduled. These pages can be customized to fit the diverse needs of your organization. It is an extension of Person Bookings. The recommended state is to restrict the OwaMailboxPolicy-Default policy or disable at the organization level.", + "RationaleStatement": "Shared Bookings pages can be exploited by threat actors to impersonate legitimate users using convincing internal email addresses. A compromised low-privilege account could be used to mimic high-profile identities (e.g., the CEO) and bypass impersonation filters to initiate fraudulent actions like fund transfers. Additionally, attackers may create authoritative-looking addresses (e.g., admin@, hostmaster@) to conduct social engineering attacks on external parties aimed at the transfer of infrastructure control. To reduce this risk, access to Shared Bookings should be limited to users with a clear business need and subject to monitoring and governance.", + "ImpactStatement": "Disabling Shared Bookings will limit users' ability to create self-service scheduling pages, which may reduce convenience for teams that rely on automated meeting coordination. Approved users will need to be added to a separate OWA Policy which will increase administrative overhead. Note: Before modifying the default owa policy, ensure that any users who rely on Shared Bookings are assigned a separate policy that explicitly allows its use. This will help prevent unintended service disruptions.", + "RemediationProcedure": "To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-OwaMailboxPolicy \"OwaMailboxPolicy-Default\" - BookingsMailboxCreationEnabled $false Optionally: For a more restrictive state Bookings can be disabled at the organization level 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following command: Set-OrganizationConfig -BookingsEnabled $false Note: Disabling Bookings at the tenant (organization) level will be more impactful to end users and is not required for compliance.", + "AuditProcedure": "Ensure Shared Bookings is turned off in the OWA Default policy. If booking is disabled at the tenant (OrganizationConfig) level this is also a compliant state. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following command: Get-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default | fl BookingsMailboxCreationEnabled 3. Verify that BookingsMailboxCreationEnabled is set to False. Optionally: If Bookings is disabled at the organization level, this is also considered a compliant state. 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following command: Get-OrganizationConfig | fl BookingsEnabled 3. If BookingsEnabled is set to False, the organization is using a more restrictive and compliant configuration. In this case changing the default OWA policy would not be required for compliance.", + "AdditionalInformation": "", + "DefaultValue": "BookingsMailboxCreationEnabled : True (OwaMailboxPolicy-Default) BookingsEnabled : True", + "References": "https://learn.microsoft.com/en-us/microsoft-365/bookings/turn-bookings-on-or-off?view=o365-worldwide:https://techcommunity.microsoft.com/blog/office365businessappsblog/enhancing-security-in-microsoft-bookings-best-practices-for-admins/4382447:https://learn.microsoft.com/en-us/microsoft-365/bookings/best-practices-shared-bookings?view=o365-worldwide&source=recommendations:https://www.cyberis.com/article/microsoft-bookings-facilitating-impersonation" + } + ] + }, + { + "Id": "2.1.1", + "Description": "Enabling Safe Links policy for Office applications allows URL's that exist inside of Office documents and email applications opened by Office, Office Online and Office mobile to be processed against Defender for Office time-of-click verification and rewritten if required. Note: E5 Licensing includes a number of Built-in Protection policies. When auditing policies note which policy you are viewing, and keep in mind CIS recommendations often extend the Default or Built-in Policies provided by MS. In order to Pass the highest priority policy must match all settings recommended.", + "Checks": [ + "defender_safelinks_policy_enabled" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E5 Level 2", + "AssessmentStatus": "Automated", + "Description": "Enabling Safe Links policy for Office applications allows URL's that exist inside of Office documents and email applications opened by Office, Office Online and Office mobile to be processed against Defender for Office time-of-click verification and rewritten if required. Note: E5 Licensing includes a number of Built-in Protection policies. When auditing policies note which policy you are viewing, and keep in mind CIS recommendations often extend the Default or Built-in Policies provided by MS. In order to Pass the highest priority policy must match all settings recommended.", + "RationaleStatement": "Safe Links for Office applications extends phishing protection to documents and emails that contain hyperlinks, even after they have been delivered to a user.", + "ImpactStatement": "User impact associated with this change is minor - users may experience a very short delay when clicking on URLs in Office documents before being directed to the requested site. Users should be informed of the change as, in the event a link is unsafe and blocked, they will receive a message that it has been blocked.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com 2. Under Email & collaboration select Policies & rules 3. Select Threat policies then Safe Links 4. Click on +Create 5. Name the policy then click Next 6. In Domains select all valid domains for the organization and Next 7. Ensure the following URL & click protection settings are defined: Email o Checked On: Safe Links checks a list of known, malicious links when users click links in email. URLs are rewritten by default o Checked Apply Safe Links to email messages sent within the organization o Checked Apply real-time URL scanning for suspicious links and links that point to files o Checked Wait for URL scanning to complete before delivering the message o Unchecked Do not rewrite URLs, do checks via Safe Links API only. Teams o Checked On: Safe Links checks a list of known, malicious links when users click links in Microsoft Teams. URLs are not rewritten Office 365 Apps o Checked On: Safe Links checks a list of known, malicious links when users click links in Microsoft Office apps. URLs are not rewritten Click protection settings o Checked Track user clicks o Unchecked Let users click through the original URL o There is no recommendation for organization branding. 8. Click Next twice and finally Submit To remediate using PowerShell: 1. Connect using Connect-ExchangeOnline. 2. Run the following PowerShell script to create a policy at highest priority that will apply to all valid domains on the tenant: # Create the Policy $params = @{ Name = \"CIS SafeLinks Policy\" EnableSafeLinksForEmail = $true EnableSafeLinksForTeams = $true EnableSafeLinksForOffice = $true TrackClicks = $true AllowClickThrough = $false ScanUrls = $true EnableForInternalSenders = $true DeliverMessageAfterScan = $true DisableUrlRewrite = $false } New-SafeLinksPolicy @params # Create the rule for all users in all valid domains and associate with Policy New-SafeLinksRule -Name \"CIS SafeLinks\" -SafeLinksPolicy \"CIS SafeLinks Policy\" -RecipientDomainIs (Get-AcceptedDomain).Name -Priority 0", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com 2. Under Email & collaboration select Policies & rules 3. Select Threat policies then Safe Links 4. Inspect each policy and attempt to identify one that matches the parameters outlined below. 5. Scroll down the pane and click on Edit Protection settings (Global Readers will look for on or off values) 6. Verify that the following protection settings are set as outlined: Email o Checked On: Safe Links checks a list of known, malicious links when users click links in email. URLs are rewritten by default o Checked Apply Safe Links to email messages sent within the organization o Checked Apply real-time URL scanning for suspicious links and links that point to files o Checked Wait for URL scanning to complete before delivering the message o Unchecked Do not rewrite URLs, do checks via Safe Links API only. Teams o Checked On: Safe Links checks a list of known, malicious links when users click links in Microsoft Teams. URLs are not rewritten Office 365 Apps o Checked On: Safe Links checks a list of known, malicious links when users click links in Microsoft Office apps. URLs are not rewritten Click protection settings oChecked Track user clicks oUnchecked Let users click through the original URL 7. There is no recommendation for organization branding. 8. Click close To audit using PowerShell: 1. Connect using Connect-ExchangeOnline. 2. Run the following to output properties from all Safe Links policies: $params = @( 'Identity', 'EnableSafeLinksForEmail', 'EnableSafeLinksForTeams', 'EnableSafeLinksForOffice', 'TrackClicks', 'AllowClickThrough', 'ScanUrls', 'EnableForInternalSenders', 'DeliverMessageAfterScan', 'DisableUrlRewrite' ) Get-SafeLinksPolicy | Select-Object -Property $Params 3. Verify there is at least one policy that matches the properties and values below: Identity : EnableSafeLinksForEmail : True EnableSafeLinksForTeams : True EnableSafeLinksForOffice : True TrackClicks : True AllowClickThrough : False ScanUrls : True EnableForInternalSenders : True DeliverMessageAfterScan : True DisableUrlRewrite : False", + "AdditionalInformation": "", + "DefaultValue": "", + "References": "https://learn.microsoft.com/en-us/defender-office-365/safe-links-policies-configure?view=o365-worldwide:https://learn.microsoft.com/en-us/powershell/module/exchange/set-safelinkspolicy?view=exchange-ps:https://learn.microsoft.com/en-us/defender-office-365/preset-security-policies?view=o365-worldwide" + } + ] + }, + { + "Id": "2.1.2", + "Description": "The Common Attachment Types Filter is a setting within Exchange Online Protection's anti-malware policy that blocks inbound and outbound email messages containing attachments of specified file types. When enabled, messages with attachments matching the blocked extensions are quarantined before delivery. Microsoft maintains a default set of file types considered high risk; organizations may also add custom extensions to the list. The recommended state is Enable the common attachments filter set to On, on the default anti-malware policy, with the default list of blocked file types.", + "Checks": [ + "defender_malware_policy_common_attachments_filter_enabled" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "The Common Attachment Types Filter is a setting within Exchange Online Protection's anti-malware policy that blocks inbound and outbound email messages containing attachments of specified file types. When enabled, messages with attachments matching the blocked extensions are quarantined before delivery. Microsoft maintains a default set of file types considered high risk; organizations may also add custom extensions to the list. The recommended state is Enable the common attachments filter set to On, on the default anti-malware policy, with the default list of blocked file types.", + "RationaleStatement": "Email is a primary delivery vector for malware, including ransomware, trojans, and remote access tools distributed via executable, script, and installer file formats. The Common Attachment Types Filter blocks delivery of file types that have no legitimate business use in email but are routinely weaponized (such as .exe, .vbs, .bat, .msi), and similar formats. Enforcing this filter at the gateway reduces the attack surface before any client-side or endpoint control has the opportunity to respond.", + "ImpactStatement": "Emails containing attachments with blocked extensions, including those sent by trusted internal senders, will be quarantined and not delivered. Some file types in the default block list may be used legitimately in some IT workflows. Administrators who need to permit specific extensions for specific users or groups should create a scoped custom anti-malware policy with a higher priority than the Default policy rather than modifying the Default policy's file type list.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules. 3. On the Policies & rules page select Threat policies. 4. Under polices select Anti-malware and click on the Default (Default) policy. 5. On the Policy page that appears on the right hand pane scroll to the bottom and click on Edit protection settings, check the Enable the common attachments filter. o If any of the default file types are missing click Select file types and add the missing file types in. o Reference the Default Value section of this document for the list of extensions that should be blocked. 6. Click Save to save the changes. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following to enable the common attachment filter: Set-MalwareFilterPolicy -Identity Default -EnableFileFilter $true 3. Use Set-MalwareFilterPolicy -Identity Default with the -FileTypes parameter to add any missing file types from the default list. o FileTypes accepts an array of strings. o To avoid using it destructively, first retrieve the existing list of file types using Get-MalwareFilterPolicy and append any missing file types to the list before using Set-MalwareFilterPolicy to update the policy.", + "AuditProcedure": "Note: The following procedures audit only the Default anti-malware policy. Auditing custom policies is not required for compliance and is discretionary based on the organization's needs. To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules. 3. On the Policies & rules page select Threat policies. 4. Under Policies select Anti-malware and click on the Default (Default) policy. 5. On the policy page that appears on the righthand pane, under Protection settings, verify that the Enable the common attachments filter has the value of On. 6. Click on Edit protection settings to view the list of file types that are blocked by the common attachment filter. Verify that the list of file types contains at least the 53 file types found in the Default Value section of this document. Note: Verifying the complete file type list via the UI requires manual comparison against the default extensions listed in the Default Value section of this document. Auditors who require a programmatic comparison should use the PowerShell method. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following Exchange Online PowerShell command: Get-MalwareFilterPolicy -Identity Default 3. Verify that the EnableFileFilter property has the value of True. 4. Verify that the FileTypes property contains at least default list of 53 file types found in the Default Value section of this document.", + "AdditionalInformation": "", + "DefaultValue": "EnableFileFilter : True Default extensions: [ \"ani\", \"apk\", \"app\", \"appx\", \"arj\", \"bat\", \"cab\", \"cmd\", \"com\", \"deb\", \"dex\", \"dll\", \"docm\", \"elf\", \"exe\", \"hta\", \"img\", \"iso\", \"jar\", \"jnlp\", \"kext\", \"lha\", \"lib\", \"library\", \"lnk\", \"lzh\", \"macho\", \"msc\", \"msi\", \"msix\", \"msp\", \"mst\", \"pif\", \"ppa\", \"ppam\", \"reg\", \"rev\", \"scf\", \"scr\", \"sct\", \"sys\", \"uif\", \"vb\", \"vbe\", \"vbs\", \"vxd\", \"wsc\", \"wsf\", \"wsh\", \"xll\", \"xz\", \"z\", \"ace\" ]", + "References": "https://learn.microsoft.com/en-us/powershell/module/exchange/get-malwarefilterpolicy?view=exchange-ps:https://learn.microsoft.com/en-us/defender-office-365/anti-malware-policies-configure?view=o365-worldwide" + } + ] + }, + { + "Id": "2.1.3", + "Description": "Exchange Online Protection (EOP) is Microsoft's cloud-based filtering service that protects organizations against spam, malware, and other email threats. EOP is included in all Microsoft 365 organizations with Exchange Online mailboxes. EOP uses flexible anti-malware policies for malware protection settings. These policies can be set to notify Admins of malicious activity.", + "Checks": [ + "defender_malware_policy_notifications_internal_users_malware_enabled" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Exchange Online Protection (EOP) is Microsoft's cloud-based filtering service that protects organizations against spam, malware, and other email threats. EOP is included in all Microsoft 365 organizations with Exchange Online mailboxes. EOP uses flexible anti-malware policies for malware protection settings. These policies can be set to notify Admins of malicious activity.", + "RationaleStatement": "This setting alerts administrators that an internal user sent a message that contained malware. This may indicate an account or machine compromise that would need to be investigated.", + "ImpactStatement": "Notification of account with potential issues should not have an impact on the user.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand E-mail & Collaboration > Policies & rules. 3. On the Policies & rules page select Threat policies. 4. Under Policies select Anti-malware. 5. Click on the Default (Default) policy. 6. Click on Edit protection settings and change the settings for Notify an admin about undelivered messages from internal senders to On and enter the email address of the administrator who should be notified under Administrator email address. 7. Click Save. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following command: Set-MalwareFilterPolicy -Identity '{Identity Name}' - EnableInternalSenderAdminNotifications $True -InternalSenderAdminAddress {admin@domain1.com} Note: Audit and Remediation guidance may focus on the Default policy however, if a Custom Policy exists in the organization's tenant, then ensure the setting is set as outlined in the highest priority policy listed.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand E-mail & Collaboration > Policies & rules. 3. On the Policies & rules page select Threat policies. 4. Under Policies select Anti-malware. 5. Click on the Default (Default) policy. 6. Verify that Notify an admin about undelivered messages from internal senders is set to On and that there is at least one email address under Administrator email address. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following command: Get-MalwareFilterPolicy | fl Identity, EnableInternalSenderAdminNotifications, InternalSenderAdminAddress 3. Verify that EnableInternalSenderAdminNotifications is set to True and a InternalSenderAdminAddress address is defined. Note: Audit and Remediation guidance may focus on the Default policy however, if a Custom Policy exists in the organization's tenant, then ensure the setting is set as outlined in the highest priority policy listed.", + "AdditionalInformation": "", + "DefaultValue": "EnableInternalSenderAdminNotifications : False InternalSenderAdminAddress : $null", + "References": "https://learn.microsoft.com/en-us/defender-office-365/anti-malware-protection-about:https://learn.microsoft.com/en-us/defender-office-365/anti-malware-policies-configure" + } + ] + }, + { + "Id": "2.1.4", + "Description": "The Safe Attachments policy helps protect users from malware in email attachments by scanning attachments for viruses, malware, and other malicious content. When an email attachment is received by a user, Safe Attachments will scan the attachment in a secure environment and provide a verdict on whether the attachment is safe or not.", + "Checks": [ + "defender_safe_attachments_policy_enabled" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E5 Level 2", + "AssessmentStatus": "Automated", + "Description": "The Safe Attachments policy helps protect users from malware in email attachments by scanning attachments for viruses, malware, and other malicious content. When an email attachment is received by a user, Safe Attachments will scan the attachment in a secure environment and provide a verdict on whether the attachment is safe or not.", + "RationaleStatement": "Enabling Safe Attachments policy helps protect against malware threats in email attachments by analyzing suspicious attachments in a secure, cloud-based environment before they are delivered to the user's inbox. This provides an additional layer of security and can prevent new or unseen types of malware from infiltrating the organization's network.", + "ImpactStatement": "Delivery of email with attachments may be delayed while scanning is occurring.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand E-mail & Collaboration > Policies & rules. 3. On the Policies & rules page select Threat policies. 4. Under Policies select Safe Attachments. 5. Click + Create. 6. Create a Policy Name and Description, and then click Next. 7. Select all valid domains and click Next. 8. Select Block. 9. Quarantine policy is AdminOnlyAccessPolicy. 10. Leave Enable redirect unchecked. 11. Click Next and finally Submit. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. To change an existing policy modify the example below and run the following PowerShell command: Set-SafeAttachmentPolicy -Identity 'Example policy' -Action 'Block' - QuarantineTag 'AdminOnlyAccessPolicy' -Enable $true 3. Or, edit and run the below example to create a new safe attachments policy. New-SafeAttachmentPolicy -Name \"CIS 2.1.4\" -Enable $true -Action 'Block' - QuarantineTag 'AdminOnlyAccessPolicy' New-SafeAttachmentRule -Name \"CIS 2.1.4 Rule\" -SafeAttachmentPolicy \"CIS 2.1.4\" -RecipientDomainIs 'exampledomain[.]com' Note: Policy targets such as users and domains should include domains, or groups that provide coverage for a majority of users in the organization. Different inclusion and exclusion use cases are not covered in the benchmark.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand E-mail & Collaboration > Policies & rules. 3. On the Policies & rules page select Threat policies. 4. Under Policies select Safe Attachments. 5. Inspect the highest priority policy. 6. Verify that Users and domains and Included recipient domains are in scope for the organization. 7. Verify that Safe Attachments detection response: is set to Block - Block current and future messages and attachments with detected malware. 8. Verify that Quarantine Policy is set to AdminOnlyAccessPolicy. 9. Verify that the policy is not disabled. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-SafeAttachmentPolicy | ft Identity,Enable,Action,QuarantineTag 3. Inspect the highest priority safe attachments policy and ensure the properties and values match the below: Enable : True Action : Block QuarantineTag : AdminOnlyAccessPolicy Note: To view the priority for a policy the Get-SafeAttachmentRule must be used. Built-in policies will always have a priority of lowest while presets like strict and standard can be viewed with Get-ATPProtectionPolicyRule. Strict and standard presets always operate at a higher priority than custom policies.", + "AdditionalInformation": "", + "DefaultValue": "Identity : Built-In Protection Policy Enable : True Action : Block QuarantineTag : AdminOnlyAccessPolicy Priority : (lowest)", + "References": "https://learn.microsoft.com/en-us/defender-office-365/safe-attachments-about:https://learn.microsoft.com/en-us/defender-office-365/safe-attachments-policies-configure" + } + ] + }, + { + "Id": "2.1.5", + "Description": "Safe Attachments for SharePoint, OneDrive, and Microsoft Teams scans these services for malicious files.", + "Checks": [ + "defender_atp_safe_attachments_and_docs_configured" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E5 Level 2", + "AssessmentStatus": "Automated", + "Description": "Safe Attachments for SharePoint, OneDrive, and Microsoft Teams scans these services for malicious files.", + "RationaleStatement": "Safe Attachments for SharePoint, OneDrive, and Microsoft Teams protect organizations from inadvertently sharing malicious files. When a malicious file is detected that file is blocked so that no one can open, copy, move, or share it until further actions are taken by the organization's security team.", + "ImpactStatement": "Impact associated with Safe Attachments is minimal, and equivalent to impact associated with anti-virus scanners in an environment.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com 2. Under Email & collaboration select Policies & rules 3. Select Threat policies then Safe Attachments. 4. Click on Global settings 5. Click to Enable Turn on Defender for Office 365 for SharePoint, OneDrive, and Microsoft Teams 6. Click to Enable Turn on Safe Documents for Office clients 7. Click to Disable Allow people to click through Protected View even if Safe Documents identified the file as malicious. 8. Click Save To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-AtpPolicyForO365 -EnableATPForSPOTeamsODB $true -EnableSafeDocs $true - AllowSafeDocsOpen $false", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Under Email & collaboration select Policies & rules. 3. Select Threat policies then Safe Attachments. 4. Click on Global settings. 5. Verify that the Turn on Defender for Office 365 for SharePoint, OneDrive, and Microsoft Teams toggle is set to Enabled. 6. Verify that the Turn on Safe Documents for Office clients toggle is set to Enabled. 7. Verify that the Allow people to click through Protected View even if Safe Documents identified the file as malicious toggle is set to Disabled. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-AtpPolicyForO365 | fl Name,EnableATPForSPOTeamsODB,EnableSafeDocs,AllowSafeDocsOpen Verify the values for each parameter as below: EnableATPForSPOTeamsODB : True EnableSafeDocs : True AllowSafeDocsOpen : False", + "AdditionalInformation": "", + "DefaultValue": "", + "References": "https://learn.microsoft.com/en-us/defender-office-365/safe-attachments-for-spo-odfb-teams-about" + } + ] + }, + { + "Id": "2.1.6", + "Description": "In Microsoft 365 organizations with mailboxes in Exchange Online or standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes, email messages are automatically protected against spam (junk email) by EOP. Configure Exchange Online Spam Policies to copy emails and notify someone when a sender in the organization has been blocked for sending spam emails.", + "Checks": [ + "defender_antispam_outbound_policy_configured" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "In Microsoft 365 organizations with mailboxes in Exchange Online or standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes, email messages are automatically protected against spam (junk email) by EOP. Configure Exchange Online Spam Policies to copy emails and notify someone when a sender in the organization has been blocked for sending spam emails.", + "RationaleStatement": "A blocked account is a good indication that the account in question has been breached, and an attacker is using it to send spam emails to other people.", + "ImpactStatement": "Notification of users that have been blocked should not cause an impact to the user.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules> Threat policies. 3. Under Policies select Anti-spam. 4. Click on the Anti-spam outbound policy (default). 5. Select Edit protection settings then under Notifications: 6. Check Send a copy of suspicious outbound messages or message that exceed these limits to these users and groups then enter the desired email addresses. 7. Check Notify these users and groups if a sender is blocked due to sending outbound spam then enter the desired email addresses. 8. Click Save. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: $BccEmailAddress = @(\"\") $NotifyEmailAddress = @(\"\") Set-HostedOutboundSpamFilterPolicy -Identity Default - BccSuspiciousOutboundAdditionalRecipients $BccEmailAddress - BccSuspiciousOutboundMail $true -NotifyOutboundSpam $true - NotifyOutboundSpamRecipients $NotifyEmailAddress Note: Audit and Remediation guidance may focus on the Default policy however, if a Custom Policy exists in the organization's tenant, then ensure the setting is set as outlined in the highest priority policy listed.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules > Threat policies. 3. Under Policies select Anti-spam. 4. Click on the Anti-spam outbound policy (default). 5. Verify that Send a copy of suspicious outbound messages or message that exceed these limits to these users and groups is set to On, ensure the email address is correct. 6. Verify that Notify these users and groups if a sender is blocked due to sending outbound spam is set to On, ensure the email address is correct. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-HostedOutboundSpamFilterPolicy | Select-Object Bcc*, Notify* 3. Verify both BccSuspiciousOutboundMail and NotifyOutboundSpam are set to True and the email addresses to be notified are correct. Note: Audit and Remediation guidance may focus on the Default policy however, if a Custom Policy exists in the organization's tenant, then ensure the setting is set as outlined in the highest priority policy listed.", + "AdditionalInformation": "", + "DefaultValue": "BccSuspiciousOutboundAdditionalRecipients : {} BccSuspiciousOutboundMail : False NotifyOutboundSpamRecipients : {} NotifyOutboundSpam : False", + "References": "https://learn.microsoft.com/en-us/defender-office-365/outbound-spam-protection-about" + } + ] + }, + { + "Id": "2.1.7", + "Description": "By default, Office 365 includes built-in features that help protect users from phishing attacks. Set up anti-phishing polices to increase this protection, for example by refining settings to better detect and prevent impersonation and spoofing attacks. The default policy applies to all users within the organization and is a single view to fine-tune anti- phishing protection. Custom policies can be created and configured for specific users, groups or domains within the organization and will take precedence over the default policy for the scoped users.", + "Checks": [ + "defender_antiphishing_policy_configured" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E5 Level 2", + "AssessmentStatus": "Automated", + "Description": "By default, Office 365 includes built-in features that help protect users from phishing attacks. Set up anti-phishing polices to increase this protection, for example by refining settings to better detect and prevent impersonation and spoofing attacks. The default policy applies to all users within the organization and is a single view to fine-tune anti- phishing protection. Custom policies can be created and configured for specific users, groups or domains within the organization and will take precedence over the default policy for the scoped users.", + "RationaleStatement": "Protects users from phishing attacks (like impersonation and spoofing) and uses safety tips to warn users about potentially harmful messages.", + "ImpactStatement": "Mailboxes that are used for support systems such as helpdesk and billing systems send mail to internal users and are often not suitable candidates for impersonation protection. Care should be taken to ensure that these systems are excluded from Impersonation Protection.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules 3. Select Threat policies. 4. Under Policies select Anti-phishing and click Create. 5. Name the policy, continuing and clicking Next as needed: o Add Groups and/or Domains that contain a majority of the organization. o Set Phishing email threshold to 3 - More Aggressive o Check Enable users to protect and add up to 350 users o Check Enable domains to protect and check Include domains I own o Check Enable mailbox intelligence (Recommended) o Check Enable Intelligence for impersonation protection (Recommended) o Check Enable spoof intelligence (Recommended) 6. Under Actions configure the following: o Set If a message is detected as user impersonation to Quarantine the message o Set If a message is detected as domain impersonation to Quarantine the message o Set If Mailbox Intelligence detects an impersonated user to Quarantine the message o Leave Honor DMARC record policy when the message is detected as spoof checked. o Check Show first contact safety tip (Recommended) o Check Show user impersonation safety tip o Check Show domain impersonation safety tip o Check Show user impersonation unusual characters safety tip 7. Finally, click Next and Submit the policy. Note: DefaultFullAccessWithNotificationPolicy is suggested but not required. Users will be notified that impersonation emails are in the Quarantine. To remediate using PowerShell: 1. Connect to Exchange Online service using Connect-ExchangeOnline. 2. Run the following Exchange Online PowerShell script to create an AntiPhish policy: # Create the Policy $params = @{ Name = \"CIS AntiPhish Policy\" PhishThresholdLevel = 3 EnableTargetedUserProtection = $true EnableOrganizationDomainsProtection = $true EnableMailboxIntelligence = $true EnableMailboxIntelligenceProtection = $true EnableSpoofIntelligence = $true TargetedUserProtectionAction = 'Quarantine' TargetedDomainProtectionAction = 'Quarantine' MailboxIntelligenceProtectionAction = 'Quarantine' TargetedUserQuarantineTag = 'DefaultFullAccessWithNotificationPolicy' MailboxIntelligenceQuarantineTag = 'DefaultFullAccessWithNotificationPolicy' TargetedDomainQuarantineTag = 'DefaultFullAccessWithNotificationPolicy' EnableFirstContactSafetyTips = $true EnableSimilarUsersSafetyTips = $true EnableSimilarDomainsSafetyTips = $true EnableUnusualCharactersSafetyTips = $true HonorDmarcPolicy = $true } New-AntiPhishPolicy @params # Create the rule for all users in all valid domains and associate with Policy New-AntiPhishRule -Name $params.Name -AntiPhishPolicy $params.Name - RecipientDomainIs (Get-AcceptedDomain).Name -Priority 0 3. The new policy can be edited in the UI or via PowerShell. Note: Remediation guidance is intended to help create a qualifying AntiPhish policy that meets the recommended criteria while protecting the majority of the organization. It's understood some individual user exceptions may exist or exceptions for the entire policy if another product acts as a similar control.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules 3. Select Threat policies. 4. Under Policies select Anti-phishing. 5. Verify an AntiPhish policy exists that is On and meets the following criteria: 6. Under Users, groups, and domains o Verify that the included domains and groups includes a majority of the organization. 7. Under Phishing threshold & protection verify the following: o Phishing email threshold is at least 3 - More Aggressive. o User impersonation protection is On and contains a subset of users. o Domain impersonation protection is On for owned domains. o Mailbox intelligence and Mailbox intelligence for impersonations and Spoof intelligence are On. 8. Under Actions verify the following: o If a message is detected as user impersonation is set to Quarantine the message. o If a message is detected as domain impersonation is set to Quarantine the message. o If Mailbox Intelligence detects an impersonated user is set to Quarantine the message. o First contact safety tip is On. o User impersonation safety tip is On. o Domain impersonation safety tip is On. o Unusual characters safety tip is On. o Honor DMARC record policy when the message is detected as spoof is On. Note: DefaultFullAccessWithNotificationPolicy is suggested but not required. Users will be notified that impersonation emails are in the Quarantine. To audit using PowerShell: 1. Connect to Exchange Online service using Connect-ExchangeOnline. 2. Run the following Exchange Online PowerShell commands: $params = @( \"name\",\"Enabled\",\"PhishThresholdLevel\",\"EnableTargetedUserProtection\" \"EnableOrganizationDomainsProtection\",\"EnableMailboxIntelligence\" \"EnableMailboxIntelligenceProtection\",\"EnableSpoofIntelligence\" \"TargetedUserProtectionAction\",\"TargetedDomainProtectionAction\" \"MailboxIntelligenceProtectionAction\",\"EnableFirstContactSafetyTips\" \"EnableSimilarUsersSafetyTips\",\"EnableSimilarDomainsSafetyTips\" \"EnableUnusualCharactersSafetyTips\",\"TargetedUsersToProtect\" \"HonorDmarcPolicy\" ) Get-AntiPhishPolicy | fl $params 3. Verify there is a policy created that has matching values for the following parameters: Enabled : True PhishThresholdLevel : 3 EnableTargetedUserProtection : True EnableOrganizationDomainsProtection : True EnableMailboxIntelligence : True EnableMailboxIntelligenceProtection : True EnableSpoofIntelligence : True TargetedUserProtectionAction : Quarantine TargetedDomainProtectionAction : Quarantine MailboxIntelligenceProtectionAction : Quarantine EnableFirstContactSafetyTips : True EnableSimilarUsersSafetyTips : True EnableSimilarDomainsSafetyTips : True EnableUnusualCharactersSafetyTips : True TargetedUsersToProtect : {} HonorDmarcPolicy : True 4. Verify that TargetedUsersToProtect contains a subset of the organization, up to 350 users, for targeted Impersonation Protection. 5. Use PowerShell to verify the AntiPhishRule is configured and enabled. Get-AntiPhishRule | ft AntiPhishPolicy,Priority,State,SentToMemberOf,RecipientDomainIs 6. Identity correct rule from the matching AntiPhishPolicy name in step 3. Ensure the rule defines groups or domains that include the majority of the organization by inspecting SentToMemberOf or RecipientDomainIs. Note: Audit guidance is intended to help identify a qualifying AntiPhish policy+rule that meets the recommended criteria while protecting the majority of the organization. It's understood some individual user exceptions may exist or exceptions for the entire policy if another product stands in as an equivalent control.", + "AdditionalInformation": "", + "DefaultValue": "", + "References": "https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about:https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-eop-configure" + } + ] + }, + { + "Id": "2.1.8", + "Description": "For each domain that is configured in Exchange, a corresponding Sender Policy Framework (SPF) record should be created.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "For each domain that is configured in Exchange, a corresponding Sender Policy Framework (SPF) record should be created.", + "RationaleStatement": "SPF records enable Exchange Online Protection and other mail systems to verify which servers are authorized to send email for a domain. This helps those systems determine whether a message is legitimate or potentially spoofed. Enforcing a -all or ~all ensures that any undocumented or unauthorized networks attempting to send on behalf of the organization are immediately rejected, reducing the risk of impersonation. If an organization does not have full visibility into where its email originates, this represents a significant security gap. For example, if an email server is sending mail from an unexpected location across the country without your knowledge, that is a serious issue. Addressing this requires a deliberate discovery process to identify all legitimate sending sources, rather than allowing unknown systems to continue sending email unchecked.", + "ImpactStatement": "Setting up SPF records typically has minimal operational impact. However, organizations must ensure proper configuration, as misconfigured SPF records can cause legitimate email to be flagged as spam or fail authentication checks. Additionally, identifying all legitimate senders outside of the default Microsoft 365 IP ranges may require extra time and coordination during the discovery phase.", + "RemediationProcedure": "To remediate using a DNS provider: For each domain identified as non-compliant during the audit, make the necessary updates in your DNS provider or through your third-party SPF management service. Missing SPF Record: If a domain does not currently have an SPF record, create one similar to the example below, assuming all email is routed through Exchange Online (Microsoft 365 or Microsoft 365 GCC): # Hard fail v=spf1 include:spf.protection.outlook.com -all # Soft fail v=spf1 include:spf.protection.outlook.com ~all Additional Senders: If other authorized email services are used, add their SPF entries using the include: mechanism as needed. For example: v=spf1 include:spf.protection.outlook.com include:exampledomain.net -all", + "AuditProcedure": "STEP 1: Determine the list of domains to audit Using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com 2. Expand Settings > Domains. 3. Take note of all custom domains and subdomains defined. o Exclude the (MOERA) domain *.onmicrosoft.com o Exclude the coexistence domain *.mail.onmicrosoft.com (if shown). 4. Use this list of domains in the audit procedure. Using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following: Get-AcceptedDomain | Where-Object {$_.IsCoExistenceDomain -eq $false -and $_.InitialDomain -eq $false} 3. Use this list in the audit procedure. Note: Microsoft owns the tenant's organizational level *.onmicrosoft.com domains, so it is not necessary to create SPF records for the initial (MOERA) or the coexistence (hybrid) domain. STEP 2: Perform the Audit using PowerShell: 1. Open a PowerShell prompt. 2. Run the following for each custom domain identified in Step 1 that sends email from Exchange Online: Resolve-DnsName domain1.com -Type TXT | fl Ensure the following criteria are met: 1. A valid TXT record must begin with v=spf1, which indicates it is SPF v1 (the current standard). 2. The record must be either directly or indirectly managed: o An indirectly managed record uses a modifier like redirect=[domain], which allows centralized SPF management by a trusted vendor. 3. The record must end with a hard or soft fail policy: o The record must end with: -all or ~all, allowing for a hard fail or soft fail. o If the SPF record uses the redirect= modifier, the redirected SPF record must terminate with a compliant qualifier (not the parent). This will require repeating the DNS lookup against the redirected domain. o Other qualifiers not listed are not compliant as an end state. Parked domains: Ensure that any domain not used for sending email has an SPF record explicitly indicating that no mail is authorized from that domain, using v=spf1 - all. Below are examples of SPF records that are compliant. The audit does not evaluate specific include domains for compliant states. v=spf1 include:spf.protection.outlook.com -all v=spf1 include:spf.protection.outlook.com ~all # GCC High or DoD example v=spf1 include:exampledomain.net include:spf.protection.office365.us ~all # 21Vianet v=spf1 include:spf.protection.partner.outlook.cn ~all # Parked domains v=spf1 -all Note: Resolve-DnsName is not available on versions of Windows earlier than Windows 8 and Windows Server 2012. Use alternatives such as nslookup when needed.", + "AdditionalInformation": "", + "DefaultValue": "", + "References": "https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-spf-configure?view=o365-worldwide:https://datatracker.ietf.org/doc/html/rfc7208:https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure?view=o365-worldwide#scenario-parked-domains" + } + ] + }, + { + "Id": "2.1.9", + "Description": "DKIM is one of the trio of Authentication methods (SPF, DKIM and DMARC) that help prevent attackers from sending messages that look like they come from your domain. DKIM lets an organization add a digital signature to outbound email messages in the message header. When DKIM is configured, the organization authorizes it's domain to associate, or sign, it's name to an email message using cryptographic authentication. Email systems that get email from this domain can use a digital signature to help verify whether incoming email is legitimate. Use of DKIM in addition to SPF and DMARC to help prevent malicious actors using spoofing techniques from sending messages that look like they are coming from your domain.", + "Checks": [ + "defender_domain_dkim_enabled" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "DKIM is one of the trio of Authentication methods (SPF, DKIM and DMARC) that help prevent attackers from sending messages that look like they come from your domain. DKIM lets an organization add a digital signature to outbound email messages in the message header. When DKIM is configured, the organization authorizes it's domain to associate, or sign, it's name to an email message using cryptographic authentication. Email systems that get email from this domain can use a digital signature to help verify whether incoming email is legitimate. Use of DKIM in addition to SPF and DMARC to help prevent malicious actors using spoofing techniques from sending messages that look like they are coming from your domain.", + "RationaleStatement": "By enabling DKIM with Office 365, messages that are sent from Exchange Online will be cryptographically signed. This will allow the receiving email system to validate that the messages were generated by a server that the organization authorized and not being spoofed.", + "ImpactStatement": "There should be no impact of setting up DKIM however, organizations should ensure appropriate setup to ensure continuous mail-flow.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Expand Email & collaboration > Policies & rules > Threat policies. 3. Under Rules section click Email authentication settings. 4. Select DKIM 5. Select the domain to remediate. 6. Click Create DKIM keys. 7. Microsoft provides the properly formatted CNAME records, copy these for later use. 8. In another browser tab or window, go to the domain registrar for the domain, and then create the two CNAME records using the information from the previous step. 9. Return the domain properties flyout and toggle Sign messages for this domain with DKIM signatures to Enabled. If successful the status will show Signing DKIM signatures for this domain.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Expand Email & collaboration > Policies & rules > Threat policies. 3. Under Rules section click Email authentication settings. 4. Select DKIM. 5. For each Accepted domain that is configured to send email: o Skip any *.onmicrosoft.com domain (MOERA or Coexistence), these outbound messages are automatically signed by Microsoft. o Click on the domain name. o Confirm Sign messages for this domain with DKIM signatures is Enabled. o Ensure Status reads Signing DKIM signatures for this domain. 6. A status of Not signing DKIM signatures for this domain or No DKIM keys saved for this domain is out of compliance. Note: For step 5 these can also be audited the overview showing all domains. In this case a passing audit procedure will display the Toggle set as Enabled and Status as Valid. To audit using PowerShell: 1. Connect to Exchange Online service using Connect-ExchangeOnline. 2. Run the following: # Get-DkimSigningConfig does not display unconfigured domains, # so we first get all accepted domains and then match them against # the DKIM signing configurations. $Domains = Get-AcceptedDomain | Where-Object {$_.IsCoExistenceDomain -eq $false -and $_.InitialDomain -eq $false} $DKIMCfg = Get-DkimSigningConfig # Generate the report $Report = foreach ($Domain in $Domains) { $DKIM = $DKIMCfg | Where-Object { $_.Name -eq $Domain.Name } [PSCustomObject]@{ DomainName = $Domain.Name Enabled = [bool]$DKIM.Enabled Status = if ($DKIM) { $DKIM.Status } else { \"Not Configured\" } IsCISCompliant = ($DKIM.Enabled -and $DKIM.Status -eq \"Valid\") } } # Output the report $Report | Format-Table -AutoSize # Optionally, export the report to a CSV file # $Report | Export-Csv -Path \"2_1_9.csv\" -NoTypeInformation 3. For each domain that is configured to send email verify: o Enabled is True o Status is Valid. o Note: The property IsCISCompliant will also validate whether the state is compliant. Note: If you own registered domains that aren't used for email or anything at all (also known as parked domains), don't publish DKIM records for those domains. The lack of a DKIM record (hence, the lack of a public key in DNS to validate the message signature) prevents DKIM validation of forged domains.", + "AdditionalInformation": "", + "DefaultValue": "Custom domains: Not configured by default MOERA onmicrosoft.com domain: Outbound email is automatically signed", + "References": "https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dkim-configure?view=o365-worldwide" + } + ] + }, + { + "Id": "2.1.10", + "Description": "DMARC, or Domain-based Message Authentication, Reporting, and Conformance, assists recipient mail systems in determining the appropriate action to take when messages from a domain fail to meet SPF or DKIM authentication criteria.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "DMARC, or Domain-based Message Authentication, Reporting, and Conformance, assists recipient mail systems in determining the appropriate action to take when messages from a domain fail to meet SPF or DKIM authentication criteria.", + "RationaleStatement": "DMARC strengthens the trustworthiness of messages sent from an organization's domain to destination email systems. When combined with SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail), DMARC significantly enhances defenses against email spoofing and phishing attempts. This includes the MOERA domain (e.g., contoso.onmicrosoft.com), which is provisioned with every Microsoft 365 tenant and is capable of originating email. Because it is often overlooked in favor of custom domains, it represents a common gap in email authentication coverage if left unprotected. Leaving a DMARC policy set to p=none can result in the mail system taking no action when a spear-phishing email fails DMARC but passes SPF and DKIM checks. Having DMARC fully configured is a critical part of preventing business email compromise.", + "ImpactStatement": "The remediation portion can take time to implement and involves a multi-staged approach over time. First, a baseline of the current state of email will be established with p=none and rua and ruf. Once the environment is better understood and reports have been analyzed, an organization will move to the final state with DMARC record values as outlined in the audit section.", + "RemediationProcedure": "To remediate using a DNS provider: 1. For any out of compliance domain sending email, add the following record to DNS: Record: _dmarc.domain1.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:; ruf=mailto: 2. This will create a basic DMARC policy that will allow the organization to start monitoring message statistics. 3. One week is enough time for data generated by the reports to be useful in understanding email trends and traffic. The final step requires implementing a policy of p=reject OR p=quarantine and pct=100 with the necessary rua and ruf email addresses defined: Record: _dmarc.domain1.com Type: TXT Value: v=DMARC1; p=reject; pct=100; rua=mailto:; ruf=mailto: Parked Domains: For any domain not used for sending email, add the following record to DNS: Record: _dmarc.domain1.com Type: TXT Value: v=DMARC1; p=reject; To remediate the MOERA domain using the UI: 1. Navigate to the Microsoft 365 admin center https://admin.microsoft.com/ 2. Expand Settings and select Domains. 3. Select your tenant domain (for example, contoso.onmicrosoft.com). 4. Select DNS records and click + Add record. 5. Add a new record with the TXT name of _dmarc with the appropriate values outlined above.", + "AuditProcedure": "STEP 1: Determine the list of domains to audit Using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com 2. Expand Settings > Domains. 3. Take note of all custom domains and subdomains defined. o Exclude the coexistence domain *.mail.onmicrosoft.com (if shown). 4. Include the MOERA domain: [tenant].onmicrosoft.com 5. Use this list of domains in the audit procedure. Using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following: Get-AcceptedDomain | Where-Object {$_.IsCoExistenceDomain -eq $false} 3. Use this list in the audit procedure. STEP 2: Perform the Audit using PowerShell: Note: Resolve-DnsName is not available on versions of Windows earlier than Windows 8 and Windows Server 2012. Use alternatives such as nslookup when needed. 1. Open a PowerShell prompt. 2. Run the following for each domain identified in Step 1: Resolve-DnsName _dmarc.domain1.com -Type TXT 3. Ensure the following criteria are met: 1. The record must be either directly or indirectly managed: - An indirectly managed record would use a CNAME to point to another record. - If the record is managed indirectly then that record must meet all criteria. This would require an additional DNS lookup. 2. The version v tag value must be v=DMARC1, which identifies it as a DMARC record. 3. The policy p tag value is p=quarantine OR p=reject. 4. The sampling rate pct tag value is pct=100 or does not exist. (A non- existent pct tag indicates sampling is 100 percent) 5. The aggregate data rua tag value is configured, i.e. rua=mailto:. 6. The failure data ruf tag value is configured, i.e. ruf=mailto:. 4. Subdomain considerations o When subdomains of the organizational domain are in scope, DMARC policy is determined using a two-step record discovery process (RFC 7489, Section 6.6.3): 1. If the subdomain has its own valid DMARC record (i.e., a record that includes the required p= tag), only that record is used. Nothing is inherited from the organizational domain. Any tags not explicitly defined in the subdomain's record fall back to their RFC- defined default values. 2. If the subdomain does not have a valid DMARC record - either because no record exists or because the record is malformed (e.g., missing the required p= tag) - the organizational domain's record is used. When determining policy disposition, the sp= (subdomain policy) tag is applied if present; otherwise, the p= tag is used. o This fallback is record discovery, not per-tag inheritance. The lookup always falls back to the organizational domain directly. Intermediate parent subdomains are never consulted. o The sp= tag is only meaningful when set on the organizational domain's record and is ignored on subdomain records. 5. Compliance is met when each domain and subdomain meets the requirements in steps 3 and 4. Parked Domains: Ensure that any domain not used for sending email has a DMARC record explicitly indicating that no mail is authorized from that domain. 1. The version v tag value must be v=DMARC1, which identifies it as a DMARC record. 2. The policy p tag value is p=reject. The following example records would pass as they contain a policy that would either quarantine or reject messages failing DMARC, and the policy affects 100% of mail pct=100 as well as containing valid reporting and aggregate addresses: v=DMARC1; p=reject; pct=100; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com; fo=1 v=DMARC1; p=reject; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com; fo=1 v=DMARC1; p=quarantine; pct=100; sp=none; fo=1; ri=3600; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com; # Parked domains v=DMARC1; p=reject; Note: The third example includes sp=none, which sets the subdomain policy to monitor- only. While the organizational domain itself would be compliant, any subdomains would not meet the audit criteria if they exist. Auditors must evaluate subdomains separately to confirm compliance.", + "AdditionalInformation": "Microsoft has a list of best practices for implementing DMARC that cover these steps in detail.", + "DefaultValue": "", + "References": "https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure?view=o365-worldwide:https://learn.microsoft.com/en-us/defender-office-365/step-by-step-guides/how-to-enable-dmarc-reporting-for-microsoft-online-email-routing-address-moera-and-parked-domains?view=o365-worldwide:https://media.defense.gov/2024/May/02/2003455483/-1/-1/0/CSA-NORTH-KOREAN-ACTORS-EXPLOIT-WEAK-DMARC.PDF:https://www.rfc-editor.org/rfc/rfc7489" + } + ] + }, + { + "Id": "2.1.11", + "Description": "The Common Attachment Types Filter lets a user block known and custom malicious file types from being attached to emails. The policy provided by Microsoft covers 53 extensions, and an additional custom list of extensions can be defined. The list of 186 extensions provided in this recommendation is comprehensive but not exhaustive.", + "Checks": [ + "defender_malware_policy_comprehensive_attachments_filter_applied" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "The Common Attachment Types Filter lets a user block known and custom malicious file types from being attached to emails. The policy provided by Microsoft covers 53 extensions, and an additional custom list of extensions can be defined. The list of 186 extensions provided in this recommendation is comprehensive but not exhaustive.", + "RationaleStatement": "Blocking known malicious file types can help prevent malware-infested files from infecting a host or performing other malicious attacks such as phishing and data extraction. Defining a comprehensive list of attachments can help protect against additional unknown and known threats. Many legacy file formats, binary files and compressed files have been used as delivery mechanisms for malicious software. Organizations can protect themselves from Business E-mail Compromise (BEC) by allow-listing only the file types relevant to their line of business and blocking all others.", + "ImpactStatement": "For file types that are business necessary users will need to use other organizationally approved methods to transfer blocked extension types between business partners.", + "RemediationProcedure": "To Remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following script after editing InternalSenderAdminAddress: # Create an attachment policy and associated rule. The rule is # intentionally disabled allowing the org to enable it when ready $Policy = @{ Name = \"CIS L2 Attachment Policy\" EnableFileFilter = $true ZapEnabled = $true EnableInternalSenderAdminNotifications = $true InternalSenderAdminAddress = 'admin@contoso.com' # Change this. } $L2Extensions = @( \"7z\", \"a3x\", \"ace\", \"ade\", \"adp\", \"ani\", \"app\", \"appinstaller\", \"applescript\", \"application\", \"appref-ms\", \"appx\", \"appxbundle\", \"arj\", \"asd\", \"asx\", \"bas\", \"bat\", \"bgi\", \"bz2\", \"cab\", \"chm\", \"cmd\", \"com\", \"cpl\", \"crt\", \"cs\", \"csh\", \"daa\", \"dbf\", \"dcr\", \"deb\", \"desktopthemepackfile\", \"dex\", \"diagcab\", \"dif\", \"dir\", \"dll\", \"dmg\", \"doc\", \"docm\", \"dot\", \"dotm\", \"elf\", \"eml\", \"exe\", \"fxp\", \"gadget\", \"gz\", \"hlp\", \"hta\", \"htc\", \"htm\", \"html\", \"hwpx\", \"ics\", \"img\", \"inf\", \"ins\", \"iqy\", \"iso\", \"isp\", \"jar\", \"jnlp\", \"js\", \"jse\", \"kext\", \"ksh\", \"lha\", \"lib\", \"library-ms\", \"lnk\", \"lzh\", \"macho\", \"mam\", \"mda\", \"mdb\", \"mde\", \"mdt\", \"mdw\", \"mdz\", \"mht\", \"mhtml\", \"mof\", \"msc\", \"msi\", \"msix\", \"msp\", \"msrcincident\", \"mst\", \"ocx\", \"odt\", \"ops\", \"oxps\", \"pcd\", \"pif\", \"plg\", \"pot\", \"potm\", \"ppa\", \"ppam\", \"ppkg\", \"pps\", \"ppsm\", \"ppt\", \"pptm\", \"prf\", \"prg\", \"ps1\", \"ps11\", \"ps11xml\", \"ps1xml\", \"ps2\", \"ps2xml\", \"psc1\", \"psc2\", \"pub\", \"py\", \"pyc\", \"pyo\", \"pyw\", \"pyz\", \"pyzw\", \"rar\", \"reg\", \"rev\", \"rtf\", \"scf\", \"scpt\", \"scr\", \"sct\", \"searchConnector-ms\", \"service\", \"settingcontent-ms\", \"sh\", \"shb\", \"shs\", \"shtm\", \"shtml\", \"sldm\", \"slk\", \"so\", \"spl\", \"stm\", \"svg\", \"swf\", \"sys\", \"tar\", \"theme\", \"themepack\", \"timer\", \"uif\", \"url\", \"uue\", \"vb\", \"vbe\", \"vbs\", \"vhd\", \"vhdx\", \"vxd\", \"wbk\", \"website\", \"wim\", \"wiz\", \"ws\", \"wsc\", \"wsf\", \"wsh\", \"xla\", \"xlam\", \"xlc\", \"xll\", \"xlm\", \"xls\", \"xlsb\", \"xlsm\", \"xlt\", \"xltm\", \"xlw\", \"xnk\", \"xps\", \"xsl\", \"xz\", \"z\" ) # Create the policy New-MalwareFilterPolicy @Policy -FileTypes $L2Extensions # Create the rule for all accepted domains $Rule = @{ Name = $Policy.Name Enabled = $false MalwareFilterPolicy = $Policy.Name RecipientDomainIs = (Get-AcceptedDomain).Name Priority = 0 } New-MalwareFilterRule @Rule 3. When prepared enable the rule either through the UI or PowerShell. Note: Due to the number of extensions the UI method is not covered. The objects can however be edited in the UI or manually added using the list from the script. 1. Navigate to Microsoft Defender at https://security.microsoft.com/ 2. Browse to Policies & rules > Threat policies > Anti-malware.", + "AuditProcedure": "For this control, a Level 2 comprehensive attachment policy is defined as one that includes at least 120 extensions. The 184 extensions included are a known vector for malicious activity. To pass, organizations must demonstrate at least a 90% adoption rate of the extension list referenced in the script below, with allowances for justified exceptions. Since individual extensions are not assigned specific risk weights, exceptions should be based on documented business needs. Note: Utilizing the UI for auditing Anti-malware policies can be very time consuming so it is recommended to use a script like the one supplied below. To Audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following script: $AttachExts = @( '7z', 'a3x', 'ace', 'ade', 'adp', 'ani', 'apk', 'app', 'appinstaller', 'applescript', 'application', 'appref-ms', 'appx', 'appxbundle', 'arj', 'asd', 'asx', 'bas', 'bat', 'bgi', 'bz2', 'cab', 'chm', 'cmd', 'com', 'cpl', 'crt', 'cs', 'csh', 'daa', 'dbf', 'dcr', 'deb', 'desktopthemepackfile', 'dex', 'diagcab', 'dif', 'dir', 'dll', 'dmg', 'doc', 'docm', 'dot', 'dotm', 'elf', 'eml', 'exe', 'fxp', 'gadget', 'gz', 'hlp', 'hta', 'htc', 'htm', 'html', 'hwpx', 'ics', 'img', 'inf', 'ins', 'iqy', 'iso', 'isp', 'jar', 'jnlp', 'js', 'jse', 'kext', 'ksh', 'lha', 'lib', 'library', 'library-ms', 'lnk', 'lzh', 'macho', 'mam', 'mda', 'mdb', 'mde', 'mdt', 'mdw', 'mdz', 'mht', 'mhtml', 'mof', 'msc', 'msi', 'msix', 'msp', 'msrcincident', 'mst', 'ocx', 'odt', 'ops', 'oxps', 'pcd', 'pif', 'plg', 'pot', 'potm', 'ppa', 'ppam', 'ppkg', 'pps', 'ppsm', 'ppt', 'pptm', 'prf', 'prg', 'ps1', 'ps11', 'ps11xml', 'ps1xml', 'ps2', 'ps2xml', 'psc1', 'psc2', 'pub', 'py', 'pyc', 'pyo', 'pyw', 'pyz', 'pyzw', 'rar', 'reg', 'rev', 'rtf', 'scf', 'scpt', 'scr', 'sct', 'searchConnector-ms', 'service', 'settingcontent-ms', 'sh', 'shb', 'shs', 'shtm', 'shtml', 'sldm', 'slk', 'so', 'spl', 'stm', 'svg', 'swf', 'sys', 'tar', 'theme', 'themepack', 'timer', 'uif', 'url', 'uue', 'vb', 'vbe', 'vbs', 'vhd', 'vhdx', 'vxd', 'wbk', 'website', 'wim', 'wiz', 'ws', 'wsc', 'wsf', 'wsh', 'xla', 'xlam', 'xlc', 'xll', 'xlm', 'xls', 'xlsb', 'xlsm', 'xlt', 'xltm', 'xlw', 'xnk', 'xps', 'xsl', 'xz', 'z' ) $MalwareFilterPolicies = Get-MalwareFilterPolicy $MalwareFilterRules = Get-MalwareFilterRule # A policy must have at least 90% of the extensions in the reference list to pass. # This allows for some flexibility with exceptions. $PassingValue = .90 # 90% $FailThreshold = [int]($AttachExts.count * (1 - $PassingValue)) # Only evaluate policies that have more than 120 extensions defined # so we don't output failures on policies that aren't specific to # extension filtering. $CompPolicies = $MalwareFilterPolicies | Where-Object { $_.FileTypes.Count - gt 120 } if (-not $CompPolicies) { Write-Output \"## FAIL ## No comprehensive policies found to evaluate.\" return } $ExtensionReport = foreach ($policy in $CompPolicies) { $Missing = Compare-Object -ReferenceObject $AttachExts ` -DifferenceObject $policy.FileTypes ` -PassThru | Where-Object { $_.SideIndicator -eq '<=' } $FoundRule = $MalwareFilterRules | Where-Object { $_.MalwareFilterPolicy -eq $policy.Id } # Define passing conditions to determine if this policy passes all checks. $Pass = ($Missing.Count -lt $FailThreshold) -and ($FoundRule.State -eq 'Enabled') -and ($policy.EnableFileFilter -eq $true) [PSCustomObject]@{ PolicyName = $policy.Identity IsCISCompliant = $Pass EnableFileFilter = $policy.EnableFileFilter State = $FoundRule.State MissingCount = $Missing.count MissingExtensions = $Missing -join \", \" ExtensionCount = $policy.FileTypes.count } } # Output results in various formats $ExtensionReport | Format-Table -AutoSize <# Optional: Export methods $ExtensionReport | Out-GridView -Title \"Attachment Filter results\" $ExtensionReport | Export-Csv -Path \"2.1.11.csv\" -NoTypeInformation $ExtensionReport | ConvertTo-Json | Out-File -FilePath \"2.1.11.json\" #> 3. Review the results, only policies with over 120 extensions defined will be evaluated. At the end of the script examples of different output formats are given. 4. A pass is given for the following conditions: o A single active policy exists that covers all file extensions listed except those defined as an exception by the organization. o The policy has a state of Enabled. o The EnableFileFilter property is set to True. 5. The report includes a IsCISCompliant property, where True indicates in compliance, allowing for up to 10% of the listed extensions to be missing as documented exceptions. Note: Organizations should evaluate any extensions missing from the report to determine if they are valid exceptions. Note: The audit procedure intentionally does not include the action taken for matched extensions, e.g. Reject with NDR or Quarantine the message. These are considered organization specific and are not scored. When FileTypeAction is not specified the action will default to Reject the message with a non-delivery receipt (NDR). The Quarantine Policy is also considered organization specific.", + "AdditionalInformation": "", + "DefaultValue": "The following extensions are blocked by default: ace, ani, apk, app, appx, arj, bat, cab, cmd, com, deb, dex, dll, docm, elf, exe, hta, img, iso, jar, jnlp, kext, lha, lib, library, lnk, lzh, macho, msc, msi, msix, msp, mst, pif, ppa, ppam, reg, rev, scf, scr, sct, sys, uif, vb, vbe, vbs, vxd, wsc, wsf, wsh, xll, xz, z", + "References": "https://learn.microsoft.com/en-us/powershell/module/exchange/get-malwarefilterpolicy?view=exchange-ps:https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-malware-policies-configure?view=o365-worldwide:https://learn.microsoft.com/en-us/office/compatibility/office-file-format-reference" + } + ] + }, + { + "Id": "2.1.12", + "Description": "In Microsoft 365 organizations with Exchange Online mailboxes or standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes, connection filtering and the default connection filter policy identify good or bad source email servers by IP addresses. The key components of the default connection filter policy are IP Allow List, IP Block List and Safe list. The recommended state is IP Allow List empty or undefined.", + "Checks": [ + "defender_antispam_connection_filter_policy_empty_ip_allowlist" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "In Microsoft 365 organizations with Exchange Online mailboxes or standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes, connection filtering and the default connection filter policy identify good or bad source email servers by IP addresses. The key components of the default connection filter policy are IP Allow List, IP Block List and Safe list. The recommended state is IP Allow List empty or undefined.", + "RationaleStatement": "Without additional verification like mail flow rules, email from sources in the IP Allow List skips spam filtering and sender authentication (SPF, DKIM, DMARC) checks. This method creates a high risk of attackers successfully delivering email to the Inbox that would otherwise be filtered. Messages that are determined to be malware or high confidence phishing are filtered.", + "ImpactStatement": "This is the default behavior. IP Allow lists may reduce false positives, however, this benefit is outweighed by the importance of a policy which scans all messages regardless of the origin. This supports the principle of zero trust.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules> Threat policies. 3. Under Policies select Anti-spam. 4. Click on the Connection filter policy (Default). 5. Click Edit connection filter policy. 6. Remove any IP entries from Always allow messages from the following IP addresses or address range:. 7. Click Save. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-HostedConnectionFilterPolicy -Identity Default -IPAllowList @{}", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules > Threat policies. 3. Under Policies select Anti-spam. 4. Click on the Connection filter policy (Default). 5. Verify that IP Allow list contains no entries. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-HostedConnectionFilterPolicy -Identity Default | fl IPAllowList 3. Verify that IPAllowList is empty or {}", + "AdditionalInformation": "", + "DefaultValue": "IPAllowList : {}", + "References": "https://learn.microsoft.com/en-us/defender-office-365/connection-filter-policies-configure:https://learn.microsoft.com/en-us/defender-office-365/create-safe-sender-lists-in-office-365#use-the-ip-allow-list:https://learn.microsoft.com/en-us/defender-office-365/how-policies-and-protections-are-combined#user-and-tenant-settings-conflict" + } + ] + }, + { + "Id": "2.1.13", + "Description": "In Microsoft 365 organizations with Exchange Online mailboxes or standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes, connection filtering and the default connection filter policy identify good or bad source email servers by IP addresses. The key components of the default connection filter policy are IP Allow List, IP Block List and Safe list. The safe list is a pre-configured allow list that is dynamically updated by Microsoft. The recommended safe list state is: Off or False", + "Checks": [ + "defender_antispam_connection_filter_policy_safe_list_off" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "In Microsoft 365 organizations with Exchange Online mailboxes or standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes, connection filtering and the default connection filter policy identify good or bad source email servers by IP addresses. The key components of the default connection filter policy are IP Allow List, IP Block List and Safe list. The safe list is a pre-configured allow list that is dynamically updated by Microsoft. The recommended safe list state is: Off or False", + "RationaleStatement": "Without additional verification like mail flow rules, email from sources in the IP Allow List skips spam filtering and sender authentication (SPF, DKIM, DMARC) checks. This method creates a high risk of attackers successfully delivering email to the Inbox that would otherwise be filtered. Messages that are determined to be malware or high confidence phishing are filtered. The safe list is managed dynamically by Microsoft, and administrators do not have visibility into which senders are included. Incoming messages from email servers on the safe list bypass spam filtering.", + "ImpactStatement": "This is the default behavior. IP Allow lists may reduce false positives, however, this benefit is outweighed by the importance of a policy which scans all messages regardless of the origin. This supports the principle of zero trust.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules> Threat policies. 3. Under Policies select Anti-spam. 4. Click on the Connection filter policy (Default). 5. Click Edit connection filter policy. 6. Uncheck Turn on safe list. 7. Click Save. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-HostedConnectionFilterPolicy -Identity Default -EnableSafeList $false", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules > Threat policies. 3. Under Policies select Anti-spam. 4. Click on the Connection filter policy (Default). 5. Verify that Safe list is Off. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-HostedConnectionFilterPolicy -Identity Default | fl EnableSafeList 3. Verify that EnableSafeList is False", + "AdditionalInformation": "", + "DefaultValue": "EnableSafeList : False", + "References": "https://learn.microsoft.com/en-us/defender-office-365/connection-filter-policies-configure:https://learn.microsoft.com/en-us/defender-office-365/create-safe-sender-lists-in-office-365#use-the-ip-allow-list:https://learn.microsoft.com/en-us/defender-office-365/how-policies-and-protections-are-combined#user-and-tenant-settings-conflict" + } + ] + }, + { + "Id": "2.1.14", + "Description": "Anti-spam protection is a feature of Exchange Online that utilizes policies to help to reduce the amount of junk email, bulk and phishing emails a mailbox receives. These policies contain lists to allow or block specific senders or domains. - The allowed senders list - The allowed domains list - The blocked senders list - The blocked domains list The recommended state is: Do not define any Allowed domains", + "Checks": [ + "defender_antispam_policy_inbound_no_allowed_domains" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Anti-spam protection is a feature of Exchange Online that utilizes policies to help to reduce the amount of junk email, bulk and phishing emails a mailbox receives. These policies contain lists to allow or block specific senders or domains. - The allowed senders list - The allowed domains list - The blocked senders list - The blocked domains list The recommended state is: Do not define any Allowed domains", + "RationaleStatement": "Messages from entries in the allowed senders list or the allowed domains list bypass most email protection (except malware and high confidence phishing) and email authentication checks (SPF, DKIM and DMARC). Entries in the allowed senders list or the allowed domains list create a high risk of attackers successfully delivering email to the Inbox that would otherwise be filtered. The risk is increased even more when allowing common domain names as these can be easily spoofed by attackers. Microsoft specifies in its documentation that allowed domains should be used for testing purposes only.", + "ImpactStatement": "This is the default behavior. Allowed domains may reduce false positives, however, this benefit is outweighed by the importance of having a policy which scans all messages regardless of the origin. As an alternative consider sender based lists. This supports the principle of zero trust.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules> Threat policies. 3. Under Policies select Anti-spam. 4. Open each out of compliance inbound anti-spam policy by clicking on it. 5. Click Edit allowed and blocked senders and domains. 6. Select Allow domains. 7. Delete each domain from the domains list. 8. Click Done > Save. 9. Repeat as needed. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-HostedContentFilterPolicy -Identity -AllowedSenderDomains @{} Or, run this to remove allowed domains from all inbound anti-spam policies: $AllowedDomains = Get-HostedContentFilterPolicy | Where-Object {$_.AllowedSenderDomains} $AllowedDomains | Set-HostedContentFilterPolicy -AllowedSenderDomains @{}", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules > Threat policies. 3. Under Policies select Anti-spam. 4. Inspect each inbound anti-spam policy 5. Verify that Allowed domains does not contain any domain names. 6. Repeat as needed for any additional inbound anti-spam policy. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-HostedContentFilterPolicy | ft Identity,AllowedSenderDomains 3. Verify that AllowedSenderDomains is undefined for each inbound policy. Note: Each inbound policy must pass for this recommendation to be considered to be in a passing state.", + "AdditionalInformation": "", + "DefaultValue": "AllowedSenderDomains : {}", + "References": "https://learn.microsoft.com/en-us/defender-office-365/anti-spam-protection-about#allow-and-block-lists-in-anti-spam-policies" + } + ] + }, + { + "Id": "2.1.15", + "Description": "The default outbound anti-spam policy in Microsoft Defender automatically applies to all users and is designed to detect and limit suspicious email-sending behavior. The policy enforces limits based on both volume and spam detection. If a user sends too many emails too quickly or if a high percentage of their messages are flagged as spam, their ability to send email can be temporarily restricted. This helps prevent abuse from compromised accounts or inadvertent spam campaigns. When these limits are exceeded, Microsoft routes the messages through a high-risk delivery pool to protect its IP reputation and notifies administrators through built-in alert policies. The recommended state is: - External: Restrict sending to external recipients (per hour) - 500 - Internal: Restrict sending to internal recipients (per hour) - 1000 - Daily: Maximum recipient limit per day - 1000 - Action: Over limit action - Restrict the user from sending mail", + "Checks": [ + "defender_antispam_outbound_policy_configured" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.1 Email & collaboration", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "The default outbound anti-spam policy in Microsoft Defender automatically applies to all users and is designed to detect and limit suspicious email-sending behavior. The policy enforces limits based on both volume and spam detection. If a user sends too many emails too quickly or if a high percentage of their messages are flagged as spam, their ability to send email can be temporarily restricted. This helps prevent abuse from compromised accounts or inadvertent spam campaigns. When these limits are exceeded, Microsoft routes the messages through a high-risk delivery pool to protect its IP reputation and notifies administrators through built-in alert policies. The recommended state is: - External: Restrict sending to external recipients (per hour) - 500 - Internal: Restrict sending to internal recipients (per hour) - 1000 - Daily: Maximum recipient limit per day - 1000 - Action: Over limit action - Restrict the user from sending mail", + "RationaleStatement": "Message limit settings help lessen the impact of a Business Email Compromise (BEC) by automatically restricting accounts that send unusually high volumes of email. This containment prevents compromised accounts from launching large-scale attacks and helps ensure the organization's email remains trusted and deliverable. Without these limits, excessive or suspicious outbound traffic could result in Microsoft blocking the organization's email, disrupting communication and damaging reputation.", + "ImpactStatement": "Enforcing message limits may result in legitimate users being temporarily blocked from sending email if their bulk messaging activity resembles spam or exceeds volume thresholds. This can disrupt business operations, delay communication, and require administrative effort to investigate and restore access. However, these adverse effects typically stem from a lack of planning around mass mailings. To avoid triggering these limits, Microsoft recommends sending bulk email through custom subdomains or third- party bulk email providers.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules> Threat policies. 3. Under Policies select Anti-spam and click to open Anti-spam outbound policy (Default). 4. Select Edit protection settings. 5. Set the following settings to the recommended values, or more restrictive values. Message limit values of 0 are not compliant, as it represents the service default o External: Set an external message limit - 500 o Internal: Set an internal message limit - 1000 o Daily: Set a daily message limit - 1000 o Action: Restriction placed on users who reach the message limit - Restrict the user from sending mail 6. Verify that Notify these users and groups if a sender is blocked due to sending outbound spam contains a monitored mailbox. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Change the example email addresses below and run the following PowerShell commands: $params = @{ RecipientLimitExternalPerHour = 500 RecipientLimitInternalPerHour = 1000 RecipientLimitPerDay = 1000 ActionWhenThresholdReached = 'BlockUser' NotifyOutboundSpamRecipients = @('admin@example.com','security@example.com') } Set-HostedOutboundSpamFilterPolicy -Identity 'Default' @params", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com. 2. Expand Email & collaboration > Policies & rules > Threat policies. 3. Under Policies select Anti-spam and click to open Anti-spam outbound policy (Default). 4. Verify the following settings are configured to the recommended level or a more restrictive value. Message limit values of 0 are not compliant, as it represents the service default: o External: Restrict sending to external recipients (per hour) - 500 o Internal: Restrict sending to internal recipients (per hour) - 1000 o Daily: Maximum recipient limit per day - 1000 o Action: Over limit action - Restrict the user from sending mail 5. Verify that a monitored mailbox is configured as a recipient under Notify these users and groups if a sender is blocked due to sending outbound spam. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following: $params = @( 'RecipientLimitExternalPerHour' 'RecipientLimitInternalPerHour' 'RecipientLimitPerDay' 'ActionWhenThresholdReached' 'NotifyOutboundSpamRecipients' ) Get-HostedOutboundSpamFilterPolicy -Identity Default | fl $params 3. Verify that each of the following properties is configured as specified: o RecipientLimitExternalPerHour is 500 or less, but not 0 o RecipientLimitInternalPerHour is 1000 or less, but not 0 o RecipientLimitPerDay is 1000 or less, but not 0 o ActionWhenThresholdReached is BlockUser o NotifyOutboundSpamRecipients contains a monitored mailbox. Note: Microsoft's Recommended Strict values represent a more restrictive and also compliant configuration. These values 400, 800, and 800 align with the values above. For further details on Standard and Strict settings, refer to the references section.", + "AdditionalInformation": "", + "DefaultValue": "RecipientLimitExternalPerHour : 0 RecipientLimitInternalPerHour : 0 RecipientLimitPerDay : 0 ActionWhenThresholdReached : BlockUserForToday The value of 0 means the service defaults are being used. More information on sending limits is here: https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange- online-service-description/exchange-online-limits#sending-limits-1", + "References": "https://learn.microsoft.com/en-us/defender-office-365/outbound-spam-protection-about:https://learn.microsoft.com/en-us/defender-office-365/recommended-settings-for-eop-and-office365#outbound-spam-policy-settings:https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#sending-limits-1" + } + ] + }, + { + "Id": "2.2.1", + "Description": "Organizations should monitor sign-in and audit log activity from the emergency accounts and trigger notifications to other administrators. When you monitor the activity for emergency access accounts, you can verify these accounts are only used for testing or actual emergencies. You can use Azure Monitor, Microsoft Sentinel, Defender for Cloud Apps or other tools to monitor the sign-in logs and trigger email and SMS alerts to your administrators whenever emergency access accounts sign in. This recommendation uses Defender for Cloud Apps Policies to alert on emergency access account activity. The recommended state is to monitor Activity type Log on on break-glass or emergency access accounts.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.2 Cloud apps", + "Profile": "E5 Level 1", + "AssessmentStatus": "Manual", + "Description": "Organizations should monitor sign-in and audit log activity from the emergency accounts and trigger notifications to other administrators. When you monitor the activity for emergency access accounts, you can verify these accounts are only used for testing or actual emergencies. You can use Azure Monitor, Microsoft Sentinel, Defender for Cloud Apps or other tools to monitor the sign-in logs and trigger email and SMS alerts to your administrators whenever emergency access accounts sign in. This recommendation uses Defender for Cloud Apps Policies to alert on emergency access account activity. The recommended state is to monitor Activity type Log on on break-glass or emergency access accounts.", + "RationaleStatement": "Emergency access accounts should be used in very few scenarios, for example, the last Global Administrator has left the organization and the account is inaccessible. All activity on an emergency access account should be reviewed at the time of the event to ensure the sign on is legitimate and authorized.", + "ImpactStatement": "There is no real world impact to monitoring these accounts beyond allocating staff. The frequency of emergency account sign on should be so low that any activity raises a red flag that is treated with the highest priority.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com 2. Under the Cloud Apps section select Policies -> Policy management. 3. Click on All policies and then Create policy -> Activity policy. 4. Give the policy a name and set the following: o Policy severity to High severity. o Category to Privileged accounts. o Act on Single activity. o Click Select a filter -> Activity type equals Log on. o Click Add a filter -> User Name equals as Any role. o Ensure all emergency access accounts are added to this policy or another. o Select an alert method such as Send alert as email. Note: Multiple accounts can be monitored by a single policy or by separate policies.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com 2. Under the Cloud Apps section select Policies -> Policy management. 3. Locate a privileged accounts policy that meets the following criteria o Policy severity is High severity. o Category is Privileged accounts. o Act on Single activity is selected. o Under Activities matching all of the following verify: o Filter1: Activity type equals Log on o Filter2: User Name equals as Any role o Verify all additional emergency access accounts are accounted for. o Under Alerts, verify alerting is configured. 4. Repeat this process for any additional emergency access or break-glass accounts in the organization. If matching policies do not exist, then the audit procedure is considered a fail. Note: Multiple accounts can be monitored by a single policy or by separate policies. Note: Emergency access account activity can be monitored in various ways. The audit procedure passes as long as all emergency access account activity is monitored.", + "AdditionalInformation": "", + "DefaultValue": "A policy to monitor emergency access accounts does not exist by default.", + "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access#monitor-sign-in-and-audit-logs:https://learn.microsoft.com/en-us/defender-cloud-apps/control-cloud-apps-with-policies" + } + ] + }, + { + "Id": "2.4.1", + "Description": "Identify priority accounts to utilize Microsoft 365's advanced custom security features. This is an essential tool to bolster protection for users who are frequently targeted due to their critical positions, such as executives, leaders, managers, or others who have access to sensitive, confidential, financial, or high-priority information. Once these accounts are identified, several services and features can be enabled, including threat policies, enhanced sign-in protection through conditional access policies, and alert policies, enabling faster response times for incident response teams.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.4 System", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "Identify priority accounts to utilize Microsoft 365's advanced custom security features. This is an essential tool to bolster protection for users who are frequently targeted due to their critical positions, such as executives, leaders, managers, or others who have access to sensitive, confidential, financial, or high-priority information. Once these accounts are identified, several services and features can be enabled, including threat policies, enhanced sign-in protection through conditional access policies, and alert policies, enabling faster response times for incident response teams.", + "RationaleStatement": "Enabling priority account protection for users in Microsoft 365 is necessary to enhance security for accounts with access to sensitive data and high privileges, such as CEOs, CISOs, CFOs, and IT admins. These priority accounts are often targeted by spear phishing or whaling attacks and require stronger protection to prevent account compromise. To address this, Microsoft 365 and Microsoft Defender for Office 365 offer several key features that provide extra security, including the identification of incidents and alerts involving priority accounts and the use of built-in custom protections designed specifically for them.", + "ImpactStatement": "", + "RemediationProcedure": "To remediate using the UI: Remediate with a 3-step process Step 1: Enable Priority account protection in Microsoft 365 Defender: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Select System > Settings near the bottom of the left most panel. 3. Select E-mail & Collaboration > Priority account protection 4. Ensure Priority account protection is set to On Step 2: Tag priority accounts: 5. Select User tags 6. Select the PRIORITY ACCOUNT tag and click Edit 7. Select Add members to add users, or groups. Groups are recommended. 8. Repeat the previous 2 steps for any additional tags needed, such as Finance or HR. 9. Next and Submit. Step 3: Configure E-mail alerts for Priority Accounts: 10. Expand E-mail & Collaboration on the left column. 11. Select Policies & rules > Alert policy 12. Select New Alert Policy 13. Enter a valid policy Name & Description. Set Severity to High and Category to Threat management. 14. Set Activity is to Detected malware in an e-mail message 15. Mail direction is Inbound 16. Select Add Condition and User: recipient tags are 17. In the Selection option field add chosen priority tags such as Priority account. 18. Select Every time an activity matches the rule. 19. Next and verify valid recipient(s) are selected. 20. Next and select Yes, turn it on right away. Click Submit to save the alert. 21. Repeat steps 12 - 18 to create a 2nd alert for the Activity field Activity is: Phishing email detected at time of delivery Note: Any additional activity types may be added as needed. Above are the minimum recommended.", + "AuditProcedure": "To audit using the UI: Audit with a 3-step process Step 1: Verify Priority account protection is enabled: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Select System > Settings near the bottom of the left most panel. 3. Select E-mail & collaboration > Priority account protection 4. Verify that Priority account protection is set to On Step 2: Verify that priority accounts are identified and tagged accordingly: 5. Select User tags 6. Select the PRIORITY ACCOUNT tag and click Edit 7. Verify the assigned members match the organization's defined priority accounts or groups. 8. Repeat the previous 2 steps for any additional tags identified, such as Finance or HR. Step 3: Ensure alerts are configured: 9. Expand E-mail & Collaboration on the left column. 10. Select Policies & rules > Alert policy 11. Verify that at least two alert policies are configured to monitor priority accounts for the activities Detected malware in an email message and Phishing email detected at time of delivery. These alerts should meet the following criteria: o Severity: High o Category: Threat management o Mail Direction: Inbound o Recipient Tags: Includes Priority account To audit using PowerShell: 1. Connect to Exchange using Connect-ExchangeOnline 2. Retrieve the Priority Account protection state: Get-EmailTenantSettings | select EnablePriorityAccountProtection - Ensure EnablePriorityAccountProtection is true. 3. Connect to Security & Compliance PowerShell using Connect-IPPSSession 4. Retrieve alert policies targeting priority accounts: Get-ProtectionAlert | Where-Object { $_.RecipientTags -Match 'Priority account' } 5. For each returned policy, verify all of the following criteria: o Severity is High o Filter matches the pattern Mail.Direction -eq 'Inbound' o RecipientTags matches the pattern Priority account o NotificationEnabled is true o NotifyUser contains a valid email recipient o Disabled is false 6. The control is compliant when the results include: o One passing phishing policy (ThreatType = Phish) o One passing malware policy (ThreatType = Malware). o EnablePriorityAccountProtection is true from step 2.", + "AdditionalInformation": "", + "DefaultValue": "By default, priority accounts are undefined.", + "References": "https://learn.microsoft.com/en-us/microsoft-365/admin/setup/priority-accounts:https://learn.microsoft.com/en-us/defender-office-365/priority-accounts-security-recommendations" + } + ] + }, + { + "Id": "2.4.2", + "Description": "Preset security policies have been established by Microsoft, utilizing observations and experiences within datacenters to strike a balance between the exclusion of malicious content from users and limiting unwarranted disruptions. These policies can apply to all, or select users and encompass recommendations for addressing spam, malware, and phishing threats. The policy parameters are pre-determined and non-adjustable. Strict protection has the most aggressive protection of the 3 presets. - EOP: Anti-spam, Anti-malware and Anti-phishing - Defender: Spoof protection, Impersonation protection and Advanced phishing - Defender: Safe Links and Safe Attachments NOTE: The preset security polices cannot target Priority account TAGS currently, groups should be used instead.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.4 System", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "Preset security policies have been established by Microsoft, utilizing observations and experiences within datacenters to strike a balance between the exclusion of malicious content from users and limiting unwarranted disruptions. These policies can apply to all, or select users and encompass recommendations for addressing spam, malware, and phishing threats. The policy parameters are pre-determined and non-adjustable. Strict protection has the most aggressive protection of the 3 presets. - EOP: Anti-spam, Anti-malware and Anti-phishing - Defender: Spoof protection, Impersonation protection and Advanced phishing - Defender: Safe Links and Safe Attachments NOTE: The preset security polices cannot target Priority account TAGS currently, groups should be used instead.", + "RationaleStatement": "Enabling priority account protection for users in Microsoft 365 is necessary to enhance security for accounts with access to sensitive data and high privileges, such as CEOs, CISOs, CFOs, and IT admins. These priority accounts are often targeted by spear phishing or whaling attacks and require stronger protection to prevent account compromise. The implementation of stringent, pre-defined policies may result in instances of false positive, however, the benefit of requiring the end-user to preview junk email before accessing their inbox outweighs the potential risk of mistakenly perceiving a malicious email as safe due to its placement in the inbox.", + "ImpactStatement": "Strict policies are more likely to cause false positives in anti-spam, phishing, impersonation, spoofing and intelligence responses.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Expand E-mail & collaboration > Policies & rules > Threat policies. 3. Select Preset security policies. 4. Click to Manage protection settings for Strict protection preset. 5. For Apply Exchange Online Protection select at minimum Specific recipients and include the Accounts/Groups identified as Priority Accounts. 6. For Apply Defender for Office 365 Protection select at minimum Specific recipients and include the Accounts/Groups identified as Priority Accounts. 7. For Impersonation protection click Next and add valid e-mails or priority accounts both internal and external that may be subject to impersonation. 8. For Protected custom domains add the organization's domain name, along side other key partners. 9. Click Next and finally Confirm", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Expand E-mail & collaboration > Policies & rules > Threat policies. 3. From here visit each section in turn: Anti-phishing Anti-spam Anti-malware Safe Attachments Safe Links 4. Verify that each contains a policy named Strict Preset Security Policy that includes the organization's priority accounts and groups. To audit using PowerShell: 1. Connect to Exchange using Connect-ExchangeOnline 2. Retrieve the ATP strict presets rule for Defender: Get-ATPProtectionPolicyRule | Where-Object { $_.Identity -eq 'Strict Preset Security Policy' } 3. Retrieve the EOP strict preset rule for Defender: Get-EOPProtectionPolicyRule | Where-Object { $_.Identity -eq 'Strict Preset Security Policy' } 4. Verify the following criteria for both the EOP Rule and ATP Rule: o State is Enabled o At least one recipient target is populated with a VIP, i.e.: - SentTo, SentToMemberOf or RecipientDomainIs is not null 5. The control is compliant when both the ATP rule and the EOP rule exist and pass the criteria in step 4.", + "AdditionalInformation": "", + "DefaultValue": "By default, presets are not applied to any users or groups.", + "References": "https://learn.microsoft.com/en-us/defender-office-365/preset-security-policies?view=o365-worldwide:https://learn.microsoft.com/en-us/defender-office-365/priority-accounts-security-recommendations:https://learn.microsoft.com/en-us/defender-office-365/recommended-settings-for-eop-and-office365?view=o365-worldwide#impersonation-settings-in-anti-phishing-policies-in-microsoft-defender-for-office-365" + } + ] + }, + { + "Id": "2.4.3", + "Description": "Microsoft Defender for Cloud Apps is a Cloud Access Security Broker (CASB). It provides visibility into suspicious activity in Microsoft 365, enabling investigation into potential security issues and facilitating the implementation of remediation measures if necessary. Some risk detection methods provided by Entra Identity Protection also require Microsoft Defender for Cloud Apps: - Suspicious manipulation of inbox rules - Suspicious inbox forwarding - New country detection - Impossible travel detection - Activity from anonymous IP addresses - Mass access to sensitive files", + "Checks": [], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.4 System", + "Profile": "E5 Level 2", + "AssessmentStatus": "Manual", + "Description": "Microsoft Defender for Cloud Apps is a Cloud Access Security Broker (CASB). It provides visibility into suspicious activity in Microsoft 365, enabling investigation into potential security issues and facilitating the implementation of remediation measures if necessary. Some risk detection methods provided by Entra Identity Protection also require Microsoft Defender for Cloud Apps: - Suspicious manipulation of inbox rules - Suspicious inbox forwarding - New country detection - Impossible travel detection - Activity from anonymous IP addresses - Mass access to sensitive files", + "RationaleStatement": "Security teams can receive notifications of triggered alerts for atypical or suspicious activities, see how the organization's data in Microsoft 365 is accessed and used, suspend user accounts exhibiting suspicious activity, and require users to log back in to Microsoft 365 apps after an alert has been triggered.", + "ImpactStatement": "", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Expand System > Settings > Cloud apps. 3. Scroll to Information Protection and select Files. 4. Check Enable file monitoring. 5. Scroll up to Cloud Discovery and select Microsoft Defender for Endpoint. 6. Check Enforce app access, configure a Notification URL and Save. Note: Defender for Endpoint requires a Defender for Endpoint license. Configure App Connectors: 1. Scroll to Connected apps and select App connectors. 2. Click on Connect an app and select Microsoft 365. 3. Check all Azure and Office 365 boxes then click Connect Office 365. 4. Repeat for the Microsoft Azure application.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Expand System > Settings > Cloud apps. 3. Scroll to Connected apps and select App connectors. 4. Verify that Microsoft 365 and Microsoft Azure both show in the list as Connected. 5. Go to Cloud Discovery > Microsoft Defender for Endpoint and verify that the integration is enabled. 6. Go to Information Protection > Files and verify Enable file monitoring is checked.", + "AdditionalInformation": "Additional Microsoft 365 Defender features include: - The option to use Defender for cloud apps as a reverse proxy, allowing for the application of access or session controls through the definition of a conditional access policy. - The purchase and implementation of the \"App Governance\" add-on, which provides more precise control over OAuth app permissions and includes additional built-in policies. A list of Defender for Cloud Apps built-in policies for Office 365 can be found at https://learn.microsoft.com/en-us/defender-cloud-apps/protect-office-365.", + "DefaultValue": "Disabled", + "References": "https://learn.microsoft.com/en-us/defender-cloud-apps/protect-office-365#connect-microsoft-365-to-microsoft-defender-for-cloud-apps:https://learn.microsoft.com/en-us/defender-cloud-apps/protect-azure#connect-azure-to-microsoft-defender-for-cloud-apps:https://learn.microsoft.com/en-us/defender-cloud-apps/best-practices:https://learn.microsoft.com/en-us/defender-cloud-apps/get-started:https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks" + } + ] + }, + { + "Id": "2.4.4", + "Description": "Zero-hour auto purge (ZAP) is a protection feature that retroactively detects and neutralizes malware and high confidence phishing. When ZAP for Teams protection blocks a message, the message is blocked for everyone in the chat. The initial block happens right after delivery, but ZAP occurs up to 48 hours after delivery.", + "Checks": [ + "defender_zap_for_teams_enabled" + ], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.4 System", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "Zero-hour auto purge (ZAP) is a protection feature that retroactively detects and neutralizes malware and high confidence phishing. When ZAP for Teams protection blocks a message, the message is blocked for everyone in the chat. The initial block happens right after delivery, but ZAP occurs up to 48 hours after delivery.", + "RationaleStatement": "ZAP is intended to protect users that have received zero-day malware messages or content that is weaponized after being delivered to users. It does this by continually monitoring spam and malware signatures taking automated retroactive action on messages that have already been delivered.", + "ImpactStatement": "As with any anti-malware or anti-phishing product, false positives may occur.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Expand System > Settings > Email & collaboration > Microsoft Teams protection. 3. Set Zero-hour auto purge (ZAP) to On (Default) To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following cmdlet: Set-TeamsProtectionPolicy -Identity \"Teams Protection Policy\" -ZapEnabled $true", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Expand System > Settings > Email & collaboration > Microsoft Teams protection. 3. Verify that Zero-hour auto purge (ZAP) is set to On (Default) 4. Under Exclude these participants review the list of exclusions and verify they are justified and within tolerance for the organization. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following cmdlets: Get-TeamsProtectionPolicy | fl ZapEnabled Get-TeamsProtectionPolicyRule | fl ExceptIf* 3. Verify that ZapEnabled is True. 4. Review the list of exclusions and ensure they are justified and within tolerance for the organization. If nothing returns from the 2nd cmdlet then there are no exclusions defined.", + "AdditionalInformation": "", + "DefaultValue": "On (Default)", + "References": "https://learn.microsoft.com/en-us/defender-office-365/zero-hour-auto-purge?view=o365-worldwide#zero-hour-auto-purge-zap-in-microsoft-teams:https://learn.microsoft.com/en-us/defender-office-365/mdo-support-teams-about?view=o365-worldwide#configure-zap-for-teams-protection-in-defender-for-office-365-plan-2" + } + ] + }, + { + "Id": "2.4.5", + "Description": "Automated Investigation and Response (AIR) investigates alerts and correlates related signals into investigations. When AIR identifies malicious email messages, it groups them into clusters based on shared characteristics like common malicious file, URL, or sending attributes and produces remediation actions for each cluster. This setting controls whether AIR-identified malicious message clusters are remediated automatically, without requiring SecOps approval. Administrators can enable automatic remediation for one or more cluster types: - Similar files: Clusters sharing a similar malicious file - Similar URLs: Clusters sharing a similar malicious URL - Multiple similar attributes: Clusters grouped by multiple shared attributes such as sender IP address, sender domain, or message subject When enabled, the configured remediation action is applied immediately upon cluster identification. The recommended state is to automatically remediate message clusters.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Microsoft Defender", + "SubSection": "2.4 System", + "Profile": "E5 Level 1", + "AssessmentStatus": "Manual", + "Description": "Automated Investigation and Response (AIR) investigates alerts and correlates related signals into investigations. When AIR identifies malicious email messages, it groups them into clusters based on shared characteristics like common malicious file, URL, or sending attributes and produces remediation actions for each cluster. This setting controls whether AIR-identified malicious message clusters are remediated automatically, without requiring SecOps approval. Administrators can enable automatic remediation for one or more cluster types: - Similar files: Clusters sharing a similar malicious file - Similar URLs: Clusters sharing a similar malicious URL - Multiple similar attributes: Clusters grouped by multiple shared attributes such as sender IP address, sender domain, or message subject When enabled, the configured remediation action is applied immediately upon cluster identification. The recommended state is to automatically remediate message clusters.", + "RationaleStatement": "When automatic remediation is disabled, malicious message clusters identified by AIR remain in users' mailboxes as pending actions until a security analyst manually approves each remediation. During this approval window, users may interact with, open, or forward malicious messages, increasing the risk of a successful compromise. Enabling automatic remediation ensures identified threats are contained immediately upon detection, minimizing the exposure window and reducing the operational burden on security teams to manually review and approve routine threat clusters.", + "ImpactStatement": "Automatic remediation removes the manual SecOps approval step for qualifying message cluster actions. If AIR incorrectly classifies a legitimate message cluster as malicious, affected messages will be soft deleted without prior review. Soft deleted messages are moved to the Recoverable Items folder and can be restored through the Action center, Threat Explorer, or Advanced Hunting, subject to each mailbox's deleted item retention period (14 days by default). Organizations should verify retention policies and legal obligations before enabling this setting, as retention configuration affects whether soft deleted messages remain recoverable. Clusters exceeding 10,000 messages are always excluded from automatic remediation and will continue to require manual approval. License Requirement: This setting requires Defender for Office 365 Plan 2 which is included in Microsoft 365 E5.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Expand System > Settings > Email & collaboration > MDO automation settings. 3. Under Message clusters check the following: o Similar files o Similar URLs o Multiple similar attributes 4. Click Save to apply the changes.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Defender https://security.microsoft.com/ 2. Expand System > Settings > Email & collaboration > MDO automation settings. 3. Verify that under Message clusters the following are checked: o Similar files o Similar URLs o Multiple similar attributes Note: At the time of publication, Soft delete is the only available remediation action and is selected by default. Because the action cannot be changed, verifying the selected remediation action is not part of the audit criteria for this recommendation.", + "AdditionalInformation": "", + "DefaultValue": "By default automatic remediation for message clusters is disabled.", + "References": "https://learn.microsoft.com/en-us/defender-office-365/air-auto-remediation:https://learn.microsoft.com/en-us/defender-office-365/air-about:https://learn.microsoft.com/en-us/exchange/security-and-compliance/recoverable-items-folder/recoverable-items-folder:https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-user-mailboxes/change-deleted-item-retention" + } + ] + }, + { + "Id": "3.1.1", + "Description": "When audit log search is enabled in the Microsoft Purview compliance portal, user and admin activity within the organization is recorded in the audit log and retained for 180 days by default. However, some organizations may prefer to use a third-party security information and event management (SIEM) application to access their auditing data. In this scenario, a global admin can choose to turn off audit log search in Microsoft 365.", + "Checks": [ + "purview_audit_log_search_enabled" + ], + "Attributes": [ + { + "Section": "3 Microsoft Purview", + "SubSection": "3.1 Audit", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "When audit log search is enabled in the Microsoft Purview compliance portal, user and admin activity within the organization is recorded in the audit log and retained for 180 days by default. However, some organizations may prefer to use a third-party security information and event management (SIEM) application to access their auditing data. In this scenario, a global admin can choose to turn off audit log search in Microsoft 365.", + "RationaleStatement": "Enabling audit log search in the Microsoft Purview compliance portal can help organizations improve their security posture, meet regulatory compliance requirements, respond to security incidents, and gain valuable operational insights.", + "ImpactStatement": "", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Purview https://purview.microsoft.com/ 2. Select Solutions and then Audit to open the audit search. 3. Click blue bar Start recording user and admin activity. 4. Click Yes on the dialog box to confirm. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Purview https://purview.microsoft.com/ 2. Select Solutions and then Audit to open the audit search. 3. Choose a date and time frame in the past 30 days. 4. Verify search capabilities (e.g. try searching for Activities as Accessed file and results should be displayed). To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled 3. Ensure UnifiedAuditLogIngestionEnabled is set to True. Note: If the Get-AdminAuditLogConfig cmdlet is executed while connected to both Security & Compliance PowerShell as well as Exchange Online PowerShell then UnifiedAuditLogIngestionEnabled will always display False. This depends on the orders the module were imported. If Security & Compliance is needed in the same session be sure to connect to it first, and then Exchange PowerShell second.", + "AdditionalInformation": "", + "DefaultValue": "180 days", + "References": "https://learn.microsoft.com/en-us/purview/audit-log-enable-disable?view=o365-worldwide&tabs=microsoft-purview-portal:https://learn.microsoft.com/en-us/powershell/module/exchange/set-adminauditlogconfig?view=exchange-ps:https://learn.microsoft.com/en-us/purview/audit-log-enable-disable?view=o365-worldwide&tabs=microsoft-purview-portal#verify-the-auditing-status-for-your-organization" + } + ] + }, + { + "Id": "3.2.1", + "Description": "Data Loss Prevention (DLP) policies allow Exchange Online and SharePoint Online content to be scanned for specific types of data like social security numbers, credit card numbers, or passwords.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Microsoft Purview", + "SubSection": "3.2 Data Loss Protection", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Data Loss Prevention (DLP) policies allow Exchange Online and SharePoint Online content to be scanned for specific types of data like social security numbers, credit card numbers, or passwords.", + "RationaleStatement": "Enabling DLP policies alerts users and administrators that specific types of data should not be exposed, helping to protect the data from accidental exposure.", + "ImpactStatement": "Enabling a Teams DLP policy will allow sensitive data in Exchange Online and SharePoint Online to be detected or blocked. Always ensure to follow appropriate procedures during testing and implementation of DLP policies based on organizational standards.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Purview https://purview.microsoft.com/ 2. Click Solutions > Data loss prevention then Policies. 3. Click Create policy. 4. Create a policy that is specific to the types of data the organization wishes to protect.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Purview https://purview.microsoft.com/ 2. Click Solutions > Data loss prevention and then Policies. 3. Inspect the list of policies and verify the following criteria: o A policy exists that meets the organizations DLP needs o Mode is On 4. Open the policy and verify there is at least one of the following locations defined: o Exchange email o SharePoint sites o OneDrive accounts o Teams chat and channel messages 5. Compliance is met when there is at least one policy the meets the above criteria. To audit using the PowerShell: 1. Connect to the Security & Compliance PowerShell using Connect-IPPSSession. 2. Execute the following cmdlet to get a list of DLP Policies: Get-DlpCompliancePolicy 3. For each policy returned verify the following criteria: o Mode is Enable o At least one of the following locations is defined: o ExchangeLocation o SharePointLocation o OneDriveLocation o TeamsLocation 4. Compliance is met when there is at least one policy the meets the above criteria. Note: The types of policies an organization should implement to protect information are specific to their industry. However, certain types of information, such as credit card numbers, social security numbers, and certain personally identifiable information (PII), are universally important to safeguard across all industries.", + "AdditionalInformation": "", + "DefaultValue": "", + "References": "https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp?view=o365-worldwide" + } + ] + }, + { + "Id": "3.2.2", + "Description": "The default Teams Data Loss Prevention (DLP) policy rule in Microsoft 365 is a preconfigured rule that is automatically applied to all Teams conversations and channels. The default rule helps prevent accidental sharing of sensitive information by detecting and blocking certain types of content that are deemed sensitive or inappropriate by the organization. By default, the rule includes a check for the sensitive info type Credit Card Number which is pre-defined by Microsoft.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Microsoft Purview", + "SubSection": "3.2 Data Loss Protection", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "The default Teams Data Loss Prevention (DLP) policy rule in Microsoft 365 is a preconfigured rule that is automatically applied to all Teams conversations and channels. The default rule helps prevent accidental sharing of sensitive information by detecting and blocking certain types of content that are deemed sensitive or inappropriate by the organization. By default, the rule includes a check for the sensitive info type Credit Card Number which is pre-defined by Microsoft.", + "RationaleStatement": "Enabling the default Teams DLP policy rule in Microsoft 365 helps protect an organization's sensitive information by preventing accidental sharing or leakage of Credit Card information in Teams conversations and channels. DLP rules are not one size fits all, but at a minimum something should be defined. The organization should identify sensitive information important to them and seek to intercept it using DLP.", + "ImpactStatement": "End-users may be prevented from sharing certain types of content, which may require them to adjust their behavior or seek permission from administrators to share specific content. Administrators may receive requests from end-users for permission to share certain types of content or to modify the policy to better fit the needs of their teams.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Purview compliance portal https://purview.microsoft.com/ 2. Under Solutions select Data loss prevention then Policies. 3. Click Policies tab. 4. Check Default policy for Teams then click Edit policy. 5. The edit policy window will appear click Next 6. At the Choose locations to apply the policy page, turn the status toggle to On for Teams chat and channel messages location and then click Next. 7. On Customized advanced DLP rules page, ensure the Default Teams DLP policy rule Status is On and click Next. 8. On the Policy mode page, select the radial for Turn it on right away and click Next. 9. Review all the settings for the created policy on the Review your policy and create it page, and then click submit. 10. Once the policy has been successfully submitted click Done. Note: Some tenants may not have a default policy for teams as Microsoft started creating these by default at a particular point in time. In this case a new policy will have to be created that includes a rule to protect data important to the organization such as credit cards and PII.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Purview compliance portal https://purview.microsoft.com/ 2. Under Solutions select Data loss prevention then Policies. 3. Locate the Default policy for Teams. 4. Verify the Status is On. 5. Verify Locations include Teams chat and channel messages - All accounts. 6. Verify Policy settings includes the Default Teams DLP policy rule or one specific to the organization. Note: If there is not a default policy for teams inspect existing policies starting with step 4. DLP rules are specific to the organization and each organization should take steps to protect the data that matters to them. The default teams DLP rule will only alert on Credit Card matches. To audit using PowerShell: 1. Connect to the Security & Compliance PowerShell using Connect-IPPSSession. 2. Run the following to return policies that include Teams chat and channel messages: $DlpPolicy = Get-DlpCompliancePolicy $DlpPolicy | Where-Object {$_.Workload -match \"Teams\"} | ft Name,Mode,TeamsLocation* 3. If nothing returns, then there are no policies that include Teams and remediation is required. 4. For any returned policy verify Mode is set to Enable. 5. Verify TeamsLocation includes All. 6. Verify TeamsLocationException includes only permitted exceptions. Note: Some tenants may not have a default policy for teams as Microsoft started creating these by default at a particular point in time. In this case a new policy will have to be created that includes a rule to protect data important to the organization such as credit cards and PII.", + "AdditionalInformation": "", + "DefaultValue": "Enabled (On)", + "References": "https://learn.microsoft.com/en-us/powershell/exchange/connect-to-scc-powershell?view=exchange-ps:https://learn.microsoft.com/en-us/purview/dlp-teams-default-policy:https://learn.microsoft.com/en-us/powershell/module/exchange/connect-ippssession?view=exchange-ps" + } + ] + }, + { + "Id": "3.2.3", + "Description": "Microsoft Purview Data Loss Prevention (DLP) policies can be scoped to Microsoft 365 Copilot and Copilot Chat interactions. When active, these policies can restrict Copilot from processing or surfacing content that matches configured sensitive information types. Organizations must define the sensitive data categories relevant to their environment and configure at least one DLP policy that covers Copilot interactions in enforcement mode. The recommended state is to configure at least one DLP policy that includes Microsoft 365 Copilot and Copilot Chat - All accounts as a location with rules specific to the organization's needs.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Microsoft Purview", + "SubSection": "3.2 Data Loss Protection", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft Purview Data Loss Prevention (DLP) policies can be scoped to Microsoft 365 Copilot and Copilot Chat interactions. When active, these policies can restrict Copilot from processing or surfacing content that matches configured sensitive information types. Organizations must define the sensitive data categories relevant to their environment and configure at least one DLP policy that covers Copilot interactions in enforcement mode. The recommended state is to configure at least one DLP policy that includes Microsoft 365 Copilot and Copilot Chat - All accounts as a location with rules specific to the organization's needs.", + "RationaleStatement": "Microsoft 365 Copilot can retrieve, summarize, and generate content based on data the authenticated user has access to across M365 workloads, including SharePoint, OneDrive, Teams, and Exchange. Without a DLP policy scoped to Copilot interactions, no technical control exists to prevent sensitive information such as PII, financial data, or health records from being incorporated into Copilot-generated responses and potentially exposed to users who would not otherwise have direct access to the source content. Enforcing DLP policies for Copilot ensures that sensitive data categories defined by the organization are intercepted before they are processed or surfaced by AI-generated responses.", + "ImpactStatement": "Users may find that Copilot declines to process or respond to prompts that involve content matching the organization's configured sensitive information types. In these cases, Copilot will notify the user that the request was blocked by policy. Users who rely on Copilot to summarize, draft, or retrieve content containing sensitive data such as documents with PII, financial records, or health information may need to rephrase their prompts or work with the content directly outside of Copilot. Administrators should communicate the scope of active DLP policies to affected users prior to enforcement.", + "RemediationProcedure": "To remediate using the UI: Note: Microsoft provides a guided wizard to create the Default DLP policy - Protect sensitive M365 Copilot interactions policy, which can be used when no Copilot DLP policy exists in the tenant. The steps below describe how to create a custom policy from scratch with Copilot included as a location. 1. Navigate to Microsoft Purview compliance portal https://purview.microsoft.com/ 2. Under Solutions select Data loss prevention then Policies. 3. Click Policies tab. 4. Click + Create Policy. 5. Click on Enterprise applications & devices. 6. Under Categories select Custom and then Custom policy for the regulation. 7. Name the policy, and if appropriate, select an Admin Unit. 8. In Locations select Microsoft 365 Copilot and Copilot Chat. 9. Click on Next to proceed to the Advanced DLP rules page. 10. Click on + Create Rule 1. Name the rule and give a brief description of the data that is being targeted. 2. Click on + Add condition and select Content Contains 3. Click on Add and select Sensitive info types 4. Select the sensitive information types the organization wants to protect from being processed in Copilot interactions and click Add. 5. Click on + Add an action and select Restrict Copilot from processing content 6. Check the box for a relevant restriction. 7. Click on Save. 11. Repeat step 10 to create as many rules as the organization requires 12. Click Next. 13. On the Policy mode page, select the radial for Turn it on right away and click Next. 14. Click Submit to create the policy once it has been reviewed. 15. Finally, click Done. Note: Compliance with this recommendation is not achieved until the policy is in enforcement mode.", + "AuditProcedure": "Note: Some tenants may have a default policy called Default DLP policy - Protect sensitive M365 Copilot interactions that was automatically created. If not present, it can also be created using a guided process in the Policies blade. If this policy exists, it may be used to satisfy the requirements of this control provided it meets the compliance criteria below. To audit using the UI: 1. Navigate to Microsoft Purview compliance portal https://purview.microsoft.com/ 2. Under Solutions select Data loss prevention then Policies. 3. Inspect the list of policies and verify the following criteria: o Locations includes Microsoft 365 Copilot and Copilot Chat - All accounts. o Mode is On. o The policy includes Rules that restrict sensitive data from being shared in Copilot interactions based on the organization's needs. 4. Compliance is met when there is at least one policy that meets the above criteria. To audit using PowerShell: 1. Connect to the Security & Compliance PowerShell using Connect-IPPSSession. 2. Run the following to return policies that include Teams chat and channel messages: $DlpPolicy = Get-DlpCompliancePolicy $DlpPolicy | Where-Object {$_.EnforcementPlanes -match \"CopilotExperiences\"} | FT Name,Mode,LocationInclusions,LocationExclusions 3. If nothing returns, then there are no policies that include Copilot and remediation is required. 4. For any returned policy verify Mode is set to Enable. 5. Verify LocationInclusions includes All. 6. Verify LocationExclusions includes only permitted exceptions. Note: DLP rules are specific to the organization and each organization should take steps to protect the data that matters to them. At a minimum, organizations should consider protecting personally identifiable information (PII) specific to their locale.", + "AdditionalInformation": "", + "DefaultValue": "No Copilot DLP policy exists by default for most tenants. Some tenants may have had a Default DLP policy - Protect sensitive M365 Copilot interactions policy automatically provisioned by Microsoft; if present, it may satisfy this recommendation if it meets the audit criteria.", + "References": "https://learn.microsoft.com/en-us/purview/dlp-microsoft365-copilot-location-learn-about:https://learn.microsoft.com/en-us/purview/dlp-microsoft365-copilot-location-default-policy:https://learn.microsoft.com/en-us/powershell/exchange/connect-to-scc-powershell?view=exchange-ps" + } + ] + }, + { + "Id": "3.3.1", + "Description": "Sensitivity labels enable organizations to classify and label content across Microsoft 365 based on its sensitivity and business impact. These labels can be applied manually by users or automatically based on the content. When applied, labels can automatically encrypt content, provide \"Confidential\" watermarks, restrict access, and offer various data protection features. Labels can be scoped to data assets and containers: - Files & other data assets in Microsoft 365, Fabric, Azure, AWS and other platforms - Email messages sent from all versions of Outlook - Meeting calendar events and schedules in Outlook and Teams - Teams, Microsoft 365 Groups and SharePoint sites", + "Checks": [], + "Attributes": [ + { + "Section": "3 Microsoft Purview", + "SubSection": "3.3 Information Protection", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Sensitivity labels enable organizations to classify and label content across Microsoft 365 based on its sensitivity and business impact. These labels can be applied manually by users or automatically based on the content. When applied, labels can automatically encrypt content, provide \"Confidential\" watermarks, restrict access, and offer various data protection features. Labels can be scoped to data assets and containers: - Files & other data assets in Microsoft 365, Fabric, Azure, AWS and other platforms - Email messages sent from all versions of Outlook - Meeting calendar events and schedules in Outlook and Teams - Teams, Microsoft 365 Groups and SharePoint sites", + "RationaleStatement": "Consistent usage of sensitivity labels can help reduce the risk of data loss or exposure and enable more effective incident response if a breach does occur. They can also help organizations comply with regulatory requirements and provide visibility and control over sensitive information.", + "ImpactStatement": "Encryption configurations (control access, DKE, BYOK) in the individual labels may impact users' ability to access site documents and information. Careful consideration of the individual sensitivity label configurations should be exercised prior to applying an auto labeling policy, publishing policy, sensitivity label configuration, or PowerShell based label settings to SharePoint sites. Additionally, when updating or deleting Sensitivity Labels, an assessment of the potential impacts should be conducted to avoid unintended consequences. If tenants are configured for sharing with guests or external domains and Sensitivity Labels have encryption applied, this can affect the ability to share documents via email stored in SharePoint. Some recipients may be unable to open the document depending on their email client, which could trigger Purview Advanced Encryptions and OME flows based on the recipient type and the cloud license from which the email is sent (e.g., government clouds vs. commercial clouds).", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Purview compliance portal https://purview.microsoft.com/ 2. Select Information protection > Sensitivity labels. 3. Click Create a label to create a label. 4. Click Publish labels and select any newly created labels to publish according to the organization's information protection needs.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Purview compliance portal https://purview.microsoft.com/ 2. Select Information protection > Policies > Label publishing policies. 3. Ensure that a Label policy exists and is published according to the organization's information protection needs. To audit using PowerShell: 1. Connect to the Security & Compliance PowerShell using Connect-IPPSSession. 2. Run the following script: $Policies = Get-LabelPolicy -WarningAction Ignore | Where-Object { $_.Type -eq \"PublishedSensitivityLabel\" } if ($Policies) { $Policies | Format-List -Property Name, *Location* Write-Host \"$($Policies.Count) Sensitivity Label policies found.\" } else { Write-Host \"No Sensitivity Label policies found\" } 3. Ensure there is at least one sensitivity label policy published. 4. Review the locations defined to ensure they're in scope with the organization's needs. Note: These policies are specific to the information protection needs of each organization. Whether an organization passes the audit is open to interpretation by the auditor and depends largely on how effectively it implements information protection features to safeguard data.", + "AdditionalInformation": "", + "DefaultValue": "The \"Global sensitivity label policy\" exists by default.", + "References": "https://learn.microsoft.com/en-us/purview/sensitivity-labels:https://learn.microsoft.com/en-us/purview/create-sensitivity-labels" + } + ] + }, + { + "Id": "4.1", + "Description": "Compliance policies are sets of rules and conditions that are used to evaluate the configuration of managed devices. These policies can help secure organizational data and resources from devices that don't meet those configuration requirements. Managed devices must satisfy the conditions you set in your policies to be considered compliant by Intune. When combined with conditional access, this allows more control over how non-compliant devices are treated. The recommended state is Mark devices with no compliance policy assigned as as Not compliant", + "Checks": [ + "intune_device_compliance_policy_unassigned_devices_not_compliant_by_default" + ], + "Attributes": [ + { + "Section": "4 Microsoft Intune admin center", + "SubSection": "", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Compliance policies are sets of rules and conditions that are used to evaluate the configuration of managed devices. These policies can help secure organizational data and resources from devices that don't meet those configuration requirements. Managed devices must satisfy the conditions you set in your policies to be considered compliant by Intune. When combined with conditional access, this allows more control over how non-compliant devices are treated. The recommended state is Mark devices with no compliance policy assigned as as Not compliant", + "RationaleStatement": "Implementing this setting is a first step in adopting compliance policies for devices. When used together with Conditional Access policies the attack surface can be reduced by forcing an action to be taken for non-compliant devices. Note: This section does not focus on which compliance policies to use, only that an organization should adopt and enforce them to their needs.", + "ImpactStatement": "Any devices without a compliance policy will be marked not compliant. Care should be taken to first deploy any new compliance policies with a Conditional Access (CA) policy that is in the Report-only state. After the environment's device compliance is better understood it is then appropriate to finally align with Mark devices with no compliance policy assigned as and enable any CA policies that enforce actions based on device compliance. If a mature environment already has an existing device compliance CA policy and a large number of devices without an assigned compliance policy, this could cause disruption as those devices would then be suddenly considered not compliant.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Intune admin center https://intune.microsoft.com/ 2. Select Devices and then under Manage devices click Compliance 3. Click Compliance settings. 4. Set Mark devices with no compliance policy assigned as to Not compliant. To remediate using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"DeviceManagementConfiguration.ReadWrite.All\" 2. Run the following commands: $Uri = 'https://graph.microsoft.com/v1.0/deviceManagement' $Body = @{ settings = @{ secureByDefault = $true } } | ConvertTo-Json Invoke-MgGraphRequest -Uri $Uri -Method PATCH -Body $Body", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Intune admin center https://intune.microsoft.com/ 2. Select Devices and then under Manage devices click Compliance 3. Click Compliance settings. 4. Verify that Mark devices with no compliance policy assigned as is set to Not compliant. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"DeviceManagementConfiguration.Read.All\" 2. Run the following commands: $Uri = 'https://graph.microsoft.com/v1.0/deviceManagement/settings' Invoke-MgGraphRequest -Uri $Uri -Method GET 3. Verify that secureByDefault is set to True.", + "AdditionalInformation": "", + "DefaultValue": "UI: \"Compliant\" Graph: secureByDefault = $false", + "References": "https://learn.microsoft.com/en-us/mem/intune/protect/device-compliance-get-started" + } + ] + }, + { + "Id": "4.2", + "Description": "Device enrollment restrictions let you restrict devices from enrolling in Intune based on certain device attributes such as device limit, device platform, OS Version, manufacturer or device ownership (Personally owned devices). The recommended state is to Block personally owned devices from enrollment.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Microsoft Intune admin center", + "SubSection": "", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Device enrollment restrictions let you restrict devices from enrolling in Intune based on certain device attributes such as device limit, device platform, OS Version, manufacturer or device ownership (Personally owned devices). The recommended state is to Block personally owned devices from enrollment.", + "RationaleStatement": "Restricting the enrollment of personally owned devices prevents attackers who have bypassed other controls from registering a new device to gain an additional foothold, further hiding or obscuring their activities. An attack path could be: 1. Account Compromise via Phishing and AiTM 2. Conditional Access Bypass 3. Reconnaissance using e.g. ROADrecon, GraphRunner or AADInternals 4. Lateral Movement, Privilege Escalation or Persistence through a newly registered device enrolled in Intune", + "ImpactStatement": "Per platform personally owned device enrollment impacts are listed below. It is important to test the changes to the defaults prior to moving into production and implementing this control. Windows Devices The following enrollment methods are authorized for corporate enrollment for Windows devices, any other enrollment method will be considered \"Personal\" and blocked: - The device enrolls through Windows Autopilot. - The device enrolls through GPO, or automatic enrollment from Configuration Manager for co-management. - The device enrolls through a bulk provisioning package. - The enrolling user is using a device enrollment manager account. MacOS By default, Intune classifies macOS devices as personally owned. To be classified as corporate-owned, a Mac must fulfill one of the following conditions: - Registered with a serial number. - Enrolled via Apple Automated Device Enrollment (ADE). iOS/IPadOS devices By default, Intune classifies iOS/iPadOS devices as personally owned. To be classified as corporate-owned, an iOS/iPadOS device must fulfill one of the following conditions: - Registered with a serial number or IMEI. - Enrolled by using Automated Device Enrollment (formerly Device Enrollment Program). Android devices By default, until you manually make changes in the admin center, your Android Enterprise work profile device settings and Android device administrator device settings are the same. If you block Android Enterprise work profile enrollment on personal devices, only corporate-owned devices can enroll with personally owned work profiles.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Intune admin center https://intune.microsoft.com/ 2. Select Devices and then under Device onboarding click Enrollment 3. Under Enrollment options select Device platform restriction. 4. Inspect the policies listed under Device type restrictions o For the Default priority policy, click All Users. o Select Properties. 5. Click Edit to change Platform settings. 6. In the Personally owned column set each platform to Block. Note: Blocking platforms that are not used in the organization is a more restrictive best practice and will also effectively block enrollment of personally owned devices for the selected platform, ensuring compliance for this recommendation.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Intune admin center https://intune.microsoft.com/ 2. Select Devices and then under Device onboarding click Enrollment 3. Under Enrollment options select Device platform restriction. 4. Inspect the policies listed under Device type restrictions o For the Default priority policy, click All Users. o Select Properties. 5. Verify that all platforms are set to Block in the Personally owned column. 6. If the Platform itself is set to Block for any of the platforms shown this is also a passing state for that platform. Note: Blocking platforms that are not used in the organization is a more restrictive best practice and will also effectively block enrollment of personally owned devices for the selected platform, ensuring compliance for this recommendation. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"DeviceManagementConfiguration.Read.All\" 2. Run the following script: $Uri = 'https://graph.microsoft.com/beta/deviceManagement/deviceEnrollmentConfigurat ions' $Config = (Invoke-MgGraphRequest -Uri $Uri -Method GET).value | Where-Object { $_.id -match 'DefaultPlatformRestrictions' -and $_.priority - eq 0 } $Result = [PSCustomObject]@{ WindowsPersonalDeviceEnrollmentBlocked = $Config.windowsRestriction.personalDeviceEnrollmentBlocked iOSPersonalDeviceEnrollmentBlocked = $Config.iosRestriction.personalDeviceEnrollmentBlocked AndroidForWorkPersonalDeviceEnrollmentBlocked = $Config.androidForWorkRestriction.personalDeviceEnrollmentBlocked MacOPersonalDeviceEnrollmentBlocked = $Config.macOSRestriction.personalDeviceEnrollmentBlocked AndroidPersonalDeviceEnrollmentBlocked = $Config.androidRestriction.personalDeviceEnrollmentBlocked } $Result 3. Inspect the output, ensure each platform displays True next to its property. A passing output will look like the below: WindowsPersonalDeviceEnrollmentBlocked : True iOSPersonalDeviceEnrollmentBlocked : True AndroidForWorkPersonalDeviceEnrollmentBlocked : True MacOPersonalDeviceEnrollmentBlocked : True AndroidPersonalDeviceEnrollmentBlocked : True Note: If platformBlocked is true then that platform is also in compliance as the platform is blocked from enrollment entirely. This is not currently reflected in the audit script but can be queried from the same API call.", + "AdditionalInformation": "", + "DefaultValue": "Allow", + "References": "https://learn.microsoft.com/en-us/mem/intune/enrollment/enrollment-restrictions-set:https://www.glueckkanja.com/blog/security/2025/01/compliant-device-bypass-en/" + } + ] + }, + { + "Id": "5.1.2.1", + "Description": "Legacy per-user Multi-Factor Authentication (MFA) can be configured to require individual users to provide multiple authentication factors, such as passwords and additional verification codes, to access their accounts. It was introduced in earlier versions of Office 365, prior to the more comprehensive implementation of Conditional Access (CA).", + "Checks": [ + "entra_users_mfa_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.2 Users", + "Profile": "E3 Level 1", + "AssessmentStatus": "Manual", + "Description": "Legacy per-user Multi-Factor Authentication (MFA) can be configured to require individual users to provide multiple authentication factors, such as passwords and additional verification codes, to access their accounts. It was introduced in earlier versions of Office 365, prior to the more comprehensive implementation of Conditional Access (CA).", + "RationaleStatement": "Both security defaults and conditional access with security defaults turned off are not compatible with per-user multi-factor authentication (MFA), which can lead to undesirable user authentication states. The CIS Microsoft 365 Benchmark explicitly employs Conditional Access for MFA as an enhancement over security defaults and as a replacement for the outdated per-user MFA. To ensure a consistent authentication state disable per-user MFA on all accounts.", + "ImpactStatement": "Accounts using per-user MFA will need to be migrated to use CA. Prior to disabling per-user MFA the organization must be prepared to implement conditional access MFA to avoid security gaps and allow for a smooth transition. This will help ensure relevant accounts are covered by MFA during the change phase from disabling per-user MFA to enabling CA MFA. Section 5.2.2 in this document covers the creation of a CA rule for both administrators and all users in the tenant. Microsoft has documentation on migrating from per-user MFA Convert users from per- user MFA to Conditional Access based MFA", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Users and select All users. 3. Click on Per-user MFA on the top row. 4. Click the empty box next to Display Name to select all accounts. 5. On the far right under quick steps click Disable.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Users and select All users. 3. Click on Per-user MFA on the top row. 4. Verify that the Multi-factor Auth Status column shows Disabled for each account. To audit using Microsoft Graph 1. Determine the id or userPrincipalName of the user being audited. 2. Execute a GET request to the following relative URI: beta/users/{id | userPrincipalName}/authentication/requirements # Example https://graph.microsoft.com/beta/users/071cc716-8147-4397-a5ba- b2105951cc0b/authentication/requirements 3. Verify that the perUserMfaState property is set to disabled. 4. Repeat this process for all users within the tenant. Note: This API is in beta and does not support a list operation. To prevent server-side throttling, clients should implement batching and client-side rate limiting when auditing medium to large sized environments.", + "AdditionalInformation": "", + "DefaultValue": "Disabled", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-userstates#convert-users-from-per-user-mfa-to-conditional-access:https://learn.microsoft.com/en-us/microsoft-365/admin/security-and-compliance/set-up-multi-factor-authentication?view=o365-worldwide#use-conditional-access-policies:https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-userstates#convert-per-user-mfa-enabled-and-enforced-users-to-disabled:https://learn.microsoft.com/en-us/graph/api/authentication-get?view=graph-rest-beta" + } + ] + }, + { + "Id": "5.1.2.2", + "Description": "This setting controls whether standard users can register applications in the Microsoft Entra ID directory. When enabled, any user can create app registrations, which function as identity objects for applications.", + "Checks": [ + "entra_thirdparty_integrated_apps_not_allowed" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.2 Users", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting controls whether standard users can register applications in the Microsoft Entra ID directory. When enabled, any user can create app registrations, which function as identity objects for applications.", + "RationaleStatement": "Allowing standard users to create app registrations expands the tenant's attack surface. A compromised account or malicious insider could create a rogue app registration to establish a persistent OAuth client, facilitate token theft, or impersonate a legitimate application. Restricting app registration to privileged roles ensures that new application identities in the directory are subject to administrative review and approval before they can be granted permissions to organizational resources.", + "ImpactStatement": "End users will no longer be able to register applications independently, including both third-party integrations and custom applications. Developers and IT staff who create app registrations as part of normal workflows will be affected and will need to submit registration requests to a privileged administrator (e.g., Application Administrator or Cloud Application Administrator). Organizations should establish a formal request and approval process before implementing this change to avoid workflow disruption.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Users and select Users settings. 3. Set Users can register applications to No. 4. Click Save. To remediate using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.ReadWrite.Authorization\" 2. Run the following commands: $param = @{ AllowedToCreateApps = $false } Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions $param", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Users and select Users settings. 3. Verify that Users can register applications is set to No. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.All\" 2. Run the following command: (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | fl AllowedToCreateApps 3. Verify the returned value is False.", + "AdditionalInformation": "", + "DefaultValue": "Yes (Users can register applications.)", + "References": "https://learn.microsoft.com/en-us/entra/identity-platform/how-applications-are-added:https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/delegate-app-roles#restrict-who-can-create-applications" + } + ] + }, + { + "Id": "5.1.2.3", + "Description": "Non-privileged users can create tenants in the Microsoft Entra ID and Microsoft Entra administration portal under \"Manage tenant\". The creation of a tenant is recorded in the Audit log as category \"DirectoryManagement\" and activity \"Create Company\". By default, the user who creates a Microsoft Entra tenant is automatically assigned the Global Administrator role. The newly created tenant doesn't inherit any settings or configurations.", + "Checks": [ + "entra_policy_ensure_default_user_cannot_create_tenants" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.2 Users", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Non-privileged users can create tenants in the Microsoft Entra ID and Microsoft Entra administration portal under \"Manage tenant\". The creation of a tenant is recorded in the Audit log as category \"DirectoryManagement\" and activity \"Create Company\". By default, the user who creates a Microsoft Entra tenant is automatically assigned the Global Administrator role. The newly created tenant doesn't inherit any settings or configurations.", + "RationaleStatement": "Restricting tenant creation prevents unauthorized or uncontrolled deployment of resources and ensures that the organization retains control over its infrastructure. User generation of shadow IT could lead to multiple, disjointed environments that can make it difficult for IT to manage and secure the organization's data, especially if other users in the organization began using these tenants for business purposes under the misunderstanding that they were secured by the organization's security team.", + "ImpactStatement": "Non-admin users will need to contact I.T. if they have a valid reason to create a tenant.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand Entra ID > Users and select User settings. 3. Set Restrict non-admin users from creating tenants to Yes then Save. To remediate using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.ReadWrite.Authorization\" 2. Run the following commands: # Create hashtable and update the auth policy $params = @{ AllowedToCreateTenants = $false } Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions $params", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand Entra ID > Users and select User settings. 3. Verify that Restrict non-admin users from creating tenants is set to Yes To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.All\" 2. Run the following commands: (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Select-Object AllowedToCreateTenants 3. Verify the returned value is False", + "AdditionalInformation": "", + "DefaultValue": "No - Non-administrators can create tenants. AllowedToCreateTenants is True", + "References": "https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions:https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#tenant-creator" + } + ] + }, + { + "Id": "5.1.2.4", + "Description": "This setting restricts non-administrators from loading a set of frequently visited pages in the Microsoft Entra admin center and Azure portal, including home, tenant overview, and the users list. What does it not do? - It does not block programmatic access to Microsoft Entra data via PowerShell, Microsoft Graph API, or other tools like Visual Studio. - It does not apply to users with an administrative role, including custom roles. - It does not prevent all access to the admin center. Many areas are still reachable through alternate paths.", + "Checks": [ + "entra_admin_portals_access_restriction" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.2 Users", + "Profile": "E3 Level 1", + "AssessmentStatus": "Manual", + "Description": "This setting restricts non-administrators from loading a set of frequently visited pages in the Microsoft Entra admin center and Azure portal, including home, tenant overview, and the users list. What does it not do? - It does not block programmatic access to Microsoft Entra data via PowerShell, Microsoft Graph API, or other tools like Visual Studio. - It does not apply to users with an administrative role, including custom roles. - It does not prevent all access to the admin center. Many areas are still reachable through alternate paths.", + "RationaleStatement": "The Microsoft Entra admin center contains sensitive data and permission settings, which are still enforced based on the user's role. However, an end user may inadvertently change properties or account settings on their own account. This could result in increased administrative overhead. Additionally, a compromised end-user account could be used to enumerate tenant structure, users, and group memberships to support privilege escalation or lateral movement.", + "ImpactStatement": "Non-administrators who own groups will be unable to reach group management pages through the standard admin center navigation. Self-service access to other portal-facing features may also be affected depending on the navigation path used. Because the restriction targets specific frequently accessed pages rather than all portal content, users with direct (deep) links to other admin center sections may still be able to access them. Note: Users will still be able to sign into Microsoft Entra admin center but will be unable to see directory information.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand Entra ID > Users and select User settings. 3. Set Restrict access to Microsoft Entra admin center to Yes then Save.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand Entra ID > Users and select User settings. 3. Verify under the Administration center section that Restrict access to Microsoft Entra admin center is set to Yes.", + "AdditionalInformation": "", + "DefaultValue": "No - Non-administrators can access the Microsoft Entra admin center.", + "References": "https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions" + } + ] + }, + { + "Id": "5.1.2.5", + "Description": "The option for the user to Stay signed in, or the Keep me signed in option, will prompt a user after a successful login. When the user selects this option, a persistent refresh token is created. The refresh token lasts for 90 days by default and does not prompt for sign-in or multifactor.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.2 Users", + "Profile": "E3 Level 2", + "AssessmentStatus": "Manual", + "Description": "The option for the user to Stay signed in, or the Keep me signed in option, will prompt a user after a successful login. When the user selects this option, a persistent refresh token is created. The refresh token lasts for 90 days by default and does not prompt for sign-in or multifactor.", + "RationaleStatement": "Allowing users to select this option presents risk, especially if the user signs into their account on a publicly accessible computer/web browser. In this case it would be trivial for an unauthorized person to gain access to any associated cloud data from that account.", + "ImpactStatement": "Once this setting is hidden users will no longer be prompted upon sign-in with the message Stay signed in?. This may mean users will be forced to sign in more frequently. Important: some features of SharePoint Online and Office 2010 have a dependency on users remaining signed in. If you hide this option, users may get additional and unexpected sign in prompts.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Users and select User settings. 3. Set Show keep user signed in to No. 4. Click Save.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Users and select User settings. 3. Verify that Show keep user signed in is highlighted No.", + "AdditionalInformation": "", + "DefaultValue": "Users may select stay signed in", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/concepts-azure-multi-factor-authentication-prompts-session-lifetime:https://learn.microsoft.com/en-us/entra/fundamentals/how-to-manage-stay-signed-in-prompt" + } + ] + }, + { + "Id": "5.1.2.6", + "Description": "LinkedIn account connections allow users to connect their Microsoft work or school account with LinkedIn. After a user connects their accounts, information and highlights from LinkedIn are available in some Microsoft apps and services.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.2 Users", + "Profile": "E3 Level 2", + "AssessmentStatus": "Manual", + "Description": "LinkedIn account connections allow users to connect their Microsoft work or school account with LinkedIn. After a user connects their accounts, information and highlights from LinkedIn are available in some Microsoft apps and services.", + "RationaleStatement": "Disabling LinkedIn integration prevents potential phishing attacks and risk scenarios where an external party could accidentally disclose sensitive information.", + "ImpactStatement": "Users will not be able to sync contacts or use LinkedIn integration.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Users and select User settings. 3. Under LinkedIn account connections select No. 4. Click Save.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Users and select User settings. 3. Under LinkedIn account connections, verify that No is selected.", + "AdditionalInformation": "", + "DefaultValue": "LinkedIn integration is enabled by default.", + "References": "https://learn.microsoft.com/en-us/entra/identity/users/linkedin-integration:https://learn.microsoft.com/en-us/entra/identity/users/linkedin-user-consent" + } + ] + }, + { + "Id": "5.1.3.1", + "Description": "This setting allows users in the organization to create new security groups and add members to these groups in the Azure portal, API, or PowerShell. These new groups also show up in the Access Panel for all other users. If the policy setting on the group allows it, other users can create requests to join these groups. The recommended state is Users can create security groups in Azure portals, API or PowerShell set to No.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.3 Groups", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting allows users in the organization to create new security groups and add members to these groups in the Azure portal, API, or PowerShell. These new groups also show up in the Access Panel for all other users. If the policy setting on the group allows it, other users can create requests to join these groups. The recommended state is Users can create security groups in Azure portals, API or PowerShell set to No.", + "RationaleStatement": "Allowing end users to create security groups without oversight can lead to uncontrolled group sprawl, increasing the risk of inappropriate access to sensitive data. The default assignment of group ownership to the creator introduces a potential for privilege escalation, especially if IT teams overlook how these groups are later used to manage access. A more malicious scenario arises when a compromised non-privileged user creates deceptively named security groups such as \"Accounting\" or \"Break-glass\", or uses homograph techniques to mimic legitimate group names. Third-party IT teams may be particularly susceptible, as they might not be familiar with the environment or lack consistent naming conventions. An unsuspecting administrator could then mistakenly assign elevated privileges, grant access to sensitive data, or exclude these groups from Conditional Access policies, inadvertently creating a serious security gap.", + "ImpactStatement": "Restrictions may introduce some operational friction, particularly in fast-paced or decentralized environments where teams rely on self-service capabilities for collaboration and access management. This can increase reliance on IT teams for routine tasks, potentially causing delays. However, these impacts can be minimized through automated approval workflows and clear governance processes.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Groups and select General. 3. Set Users can create security groups in Azure portals, API or PowerShell to No. 4. Click Save. To remediate using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.ReadWrite.Authorization\" 2. Run the following commands: $params = @{ defaultUserRolePermissions = @{ AllowedToCreateSecurityGroups = $false } } Update-MgPolicyAuthorizationPolicy -BodyParameter $params", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Groups and select General. 3. Verify that Users can create security groups in Azure portals, API or PowerShell is set to No. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.All\" 2. Run the following command: (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | fl 3. Verify that AllowedToCreateSecurityGroups is False.", + "AdditionalInformation": "", + "DefaultValue": "AllowedToCreateSecurityGroups : True", + "References": "https://learn.microsoft.com/en-us/entra/identity/users/groups-self-service-management?WT.mc_id=Portal-Microsoft_AAD_IAM#group-settings:https://learn.microsoft.com/en-us/graph/api/authorizationpolicy-get?view=graph-rest-1.0&tabs=http:https://learn.microsoft.com/en-us/entra/identity/users/groups-self-service-management#making-a-group-available-for-end-user-self-service" + } + ] + }, + { + "Id": "5.1.3.2", + "Description": "This setting restricts standard users from accessing the My Groups web interface in the My Account portal (https://myaccount.microsoft.com/groups). When set to Yes, this web interface access is removed for standard users. The recommended state is Yes.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.3 Groups", + "Profile": "E3 Level 2", + "AssessmentStatus": "Manual", + "Description": "This setting restricts standard users from accessing the My Groups web interface in the My Account portal (https://myaccount.microsoft.com/groups). When set to Yes, this web interface access is removed for standard users. The recommended state is Yes.", + "RationaleStatement": "By default, any authenticated user can access the My Groups portal and enumerate group memberships, SharePoint site URLs, group email addresses, Teams URLs, and Yammer URLs across the tenant. This information enables reconnaissance, where a user could identify high-value or privileged groups, map resource URLs, and use that data to plan further attacks or lateral movement. Restricting the web interface limits passive enumeration by users who do not require group browsing as part of their duties, reducing the available attack surface without impacting core productivity. Note: This setting applies only to the My Groups web interface. API-based enumeration remains possible for users with appropriate permissions or tooling, and this control should not be treated as a complete enumeration defense.", + "ImpactStatement": "Setting this to Yes creates administrative overhead for users who need to look up group memberships and must now request that information from an administrator.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Groups and select General. 3. Under Self Service Group Management, set Restrict user ability to access groups features in My Groups. Group and User Admin will have read-only access when the value of this setting is 'Yes' to Yes. 4. Click Save.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Groups and select General. 3. Under Self Service Group Management, verify that Restrict user ability to access groups features in My Groups. Group and User Admin will have read-only access when the value of this setting is 'Yes' is set to Yes.", + "AdditionalInformation": "", + "DefaultValue": "No", + "References": "https://learn.microsoft.com/en-us/entra/identity/users/groups-self-service-management" + } + ] + }, + { + "Id": "5.1.3.3", + "Description": "Microsoft Entra ID provides self-service group management features that enable users to create and manage their own security groups or Microsoft 365 groups. The owner of the group can approve or deny membership requests and delegate control of group membership. Self-service group management features aren't available for mail-enabled security groups or distribution lists. The recommended state is No.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.3 Groups", + "Profile": "E3 Level 1", + "AssessmentStatus": "Manual", + "Description": "Microsoft Entra ID provides self-service group management features that enable users to create and manage their own security groups or Microsoft 365 groups. The owner of the group can approve or deny membership requests and delegate control of group membership. Self-service group management features aren't available for mail-enabled security groups or distribution lists. The recommended state is No.", + "RationaleStatement": "Group owners are standard users who may not have visibility into access governance requirements for a given group. Allowing owners to approve membership requests through My Groups means additions to security groups or Microsoft 365 groups can occur without administrator review, bypassing formal access provisioning controls. Unauthorized or excessive group membership can expand a user's effective permissions and increase the blast radius of a compromised account.", + "ImpactStatement": "Administrators will be responsible for managing group membership requests instead of group owners, which is the default behavior. Administrative overhead will only increase if this setting was previously changed to Yes.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Groups select General. 3. Set Owners can manage group membership requests in My Groups to No. 4. Click Save.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Groups and select General. 3. Verify that Owners can manage group membership requests in My Groups is set to No", + "AdditionalInformation": "", + "DefaultValue": "No", + "References": "https://learn.microsoft.com/en-us/entra/identity/users/groups-self-service-management#making-a-group-available-for-end-user-self-service" + } + ] + }, + { + "Id": "5.1.3.4", + "Description": "All users within a Microsoft Entra organization are permitted to create new Microsoft 365 groups and add members to those groups through the Azure portal, API, or PowerShell. Newly created groups also appear in the Access Panel for all other users. When the applicable group policy settings allow it, users can submit requests to join these groups. The recommended state is No.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.3 Groups", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "All users within a Microsoft Entra organization are permitted to create new Microsoft 365 groups and add members to those groups through the Azure portal, API, or PowerShell. Newly created groups also appear in the Access Panel for all other users. When the applicable group policy settings allow it, users can submit requests to join these groups. The recommended state is No.", + "RationaleStatement": "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.", + "ImpactStatement": "Enabling this setting could create a number of requests that would need to be managed by an administrator.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Groups and select General. 3. Set Users can create Microsoft 365 groups in Azure portals, API or PowerShell to No 4. Click Save. To remediate using the Microsoft Graph API: 1. Execute a PATCH request to the following relative URI: v1.0/groupSettings 2. Target the object with the templateId of 62375ab9-6b52-47ed-826b- 58e47e0e304b 3. Update EnableGroupCreation to false. Note: If a group with the above templateId doesn't exist this means the defaults are present and it would be advisable to use the UI to remediate, as this will automatically create the Group.Unified object with its defaults. Microsoft's documentation does cover using a POST request to build this using the API, however.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Groups and select General. 3. Verify that Users can create Microsoft 365 groups in Azure portals, API or PowerShell is set to No To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/groupSettings 2. Filter to groups with the templateId of 62375ab9-6b52-47ed-826b- 58e47e0e304b 3. Verify that EnableGroupCreation is false. 4. If the group with the above templateId does not exist, then it means the setting is in its default state and is not compliant.", + "AdditionalInformation": "", + "DefaultValue": "Yes", + "References": "https://learn.microsoft.com/en-us/microsoft-365/solutions/manage-creation-of-groups:https://learn.microsoft.com/en-us/graph/api/group-list-settings?view=graph-rest-0&tabs=http:https://learn.microsoft.com/en-us/graph/api/groupsetting-update?view=graph-rest-1.0&tabs=http" + } + ] + }, + { + "Id": "5.1.4.1", + "Description": "This setting enables you to select the users who can register their devices as Microsoft Entra joined devices. The recommended state is Selected or None. Note: This setting is applicable only to Microsoft Entra join on Windows 10 or newer. This setting doesn't apply to Microsoft Entra hybrid joined devices, Microsoft Entra joined VMs in Azure, or Microsoft Entra joined devices that use Windows Autopilot self- deployment mode because these methods work in a userless context.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.4 Devices", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "This setting enables you to select the users who can register their devices as Microsoft Entra joined devices. The recommended state is Selected or None. Note: This setting is applicable only to Microsoft Entra join on Windows 10 or newer. This setting doesn't apply to Microsoft Entra hybrid joined devices, Microsoft Entra joined VMs in Azure, or Microsoft Entra joined devices that use Windows Autopilot self- deployment mode because these methods work in a userless context.", + "RationaleStatement": "If a threat actor compromises a standard user account, they can enroll a rogue device under that user's identity. This device may inherit MDM policies and appear compliant, giving attackers persistent access to cloud resources without triggering MFA. In a 2023 blog, Microsoft IR reports that it has detected threat actors registering their own devices to the Microsoft Entra tenant, giving them a platform to escalate the cyberattack. While simply joining a device to a Microsoft Entra tenant may present limited immediate risk, it could allow a threat actor to establish a foothold in the environment.", + "ImpactStatement": "Restricting the setting requires IT teams to assign enrollment permissions to specific staff, such as helpdesk or provisioning personnel, which may impact user-driven Autopilot scenarios and increase administrative overhead for device onboarding and support.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Set Users may join devices to Microsoft Entra to Selected (and add members) or None.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Verify that Users may join devices to Microsoft Entra is set to Selected or None. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: beta/policies/deviceRegistrationPolicy 3. Verify that azureADJoin.allowedToJoin.@odata.type is one of the following: o #microsoft.graph.enumeratedDeviceRegistrationMembership (Selected) o #microsoft.graph.noDeviceRegistrationMembership (None). Note: When set to Selected, users and groups will also appear in the output of the Graph Request.", + "AdditionalInformation": "", + "DefaultValue": "All", + "References": "https://learn.microsoft.com/en-us/entra/identity/devices/manage-device-identities#configure-device-settings:https://www.microsoft.com/en-us/security/blog/2023/12/05/microsoft-incident-response-lessons-on-preventing-cloud-identity-compromise/#poor-device:https://learn.microsoft.com/en-us/graph/api/resources/deviceregistrationpolicy?view=graph-rest-beta" + } + ] + }, + { + "Id": "5.1.4.2", + "Description": "This setting defines the maximum number of Microsoft Entra joined or registered devices that a user can have in Microsoft Entra ID. Once this limit is reached, no additional devices can be added until existing ones are removed. Values above 100 are automatically capped at 100. The recommended state is 10 or less.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.4 Devices", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting defines the maximum number of Microsoft Entra joined or registered devices that a user can have in Microsoft Entra ID. Once this limit is reached, no additional devices can be added until existing ones are removed. Values above 100 are automatically capped at 100. The recommended state is 10 or less.", + "RationaleStatement": "Microsoft incident response teams have observed threat actors enrolling their own devices to establish persistence after a non-privileged user has been compromised. High device quotas can exacerbate this risk by enabling attackers to register multiple devices that appear legitimate, while also contributing to unmanaged or personal devices cluttering the environment, driving up licensing costs and complicating compliance efforts. Enforcing a reasonable device limit per user supports good governance, reduces the attack surface, and encourages administrators to reassess and clean up legacy or unused device enrollments.", + "ImpactStatement": "IT staff who need to enroll more than 10 devices on behalf of the organization must be assigned the role of Device Enrollment Manager in the Intune admin center. Device Enrollment Managers are non-administrator accounts that can enroll and manage up to 1,000 devices. It is recommended to use dedicated service accounts for this role rather than assigning it to users' primary or daily-use accounts. Warning: Do not delete accounts assigned as a Device enrollment manager if any devices were enrolled using the account. Doing so will lead to issues with these devices.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Set Maximum number of devices per user to 10 or less.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Verify that Maximum number of devices per user is set to 10 or less. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/policies/deviceRegistrationPolicy 2. Verify that userDeviceQuota is 10 or less.", + "AdditionalInformation": "", + "DefaultValue": "50", + "References": "https://learn.microsoft.com/en-us/entra/identity/devices/manage-device-identities#configure-device-settings:https://learn.microsoft.com/en-us/intune/intune-service/enrollment/device-enrollment-manager-enroll:https://learn.microsoft.com/en-us/graph/api/resources/deviceregistrationpolicy?view=graph-rest-beta" + } + ] + }, + { + "Id": "5.1.4.3", + "Description": "This setting controls whether the Global Administrator role is automatically added to the local administrators group on a device during the Microsoft Entra join process. The recommended state is No.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.4 Devices", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting controls whether the Global Administrator role is automatically added to the local administrators group on a device during the Microsoft Entra join process. The recommended state is No.", + "RationaleStatement": "System administrators may be inclined to use over-privileged accounts for convenience when managing devices. Enforcing this control helps discourage that behavior by requiring administrative actions to be performed using accounts specifically designated for local administration. This promotes adherence to the principle of least privilege and reduces the risk associated with using high-level roles for routine tasks. For example, using a Global Administrator account to authenticate to a compromised endpoint and continue performing tasks significantly increases the risk of broader organizational compromise.", + "ImpactStatement": "Restricting the default behavior and requiring manual assignment to least privilege roles introduces minor administrative overhead. During the Microsoft Entra join process, the Microsoft Entra Joined Device Local Administrator role is automatically added to the device's local administrators group and should be used instead.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Set Global administrator role is added as local administrator on the device during Microsoft Entra join (Preview) to No.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Verify that Global administrator role is added as local administrator on the device during Microsoft Entra join (Preview) is set to No. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: beta/policies/deviceRegistrationPolicy 2. Verify that azureADJoin.localAdmins.enableGlobalAdmins is False.", + "AdditionalInformation": "", + "DefaultValue": "Yes", + "References": "https://learn.microsoft.com/en-us/entra/identity/devices/manage-device-identities#configure-device-settings:https://learn.microsoft.com/en-us/graph/api/resources/deviceregistrationpolicy?view=graph-rest-beta:https://learn.microsoft.com/en-us/entra/identity/devices/assign-local-admin" + } + ] + }, + { + "Id": "5.1.4.4", + "Description": "This setting determines if the Microsoft Entra user registering their device as Microsoft Entra join will be added to the local administrators group. This setting applies only once during the actual registration of the device as Microsoft Entra join. The recommended state is Selected or None.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.4 Devices", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting determines if the Microsoft Entra user registering their device as Microsoft Entra join will be added to the local administrators group. This setting applies only once during the actual registration of the device as Microsoft Entra join. The recommended state is Selected or None.", + "RationaleStatement": "To uphold the principle of least privilege, the assignment of local administrator rights during Microsoft Entra join should be centrally managed using appropriate built-in roles through Intune. This approach minimizes the number of disparate users with elevated privileges, reducing the attack surface and potential for misuse. Centralized management also streamlines the deprovisioning process, ensuring that administrative access can be revoked efficiently and consistently across all devices, rather than requiring manual intervention on each individual endpoint.", + "ImpactStatement": "Restricting the default behavior and requiring manual assignment to built-in roles introduces minor administrative overhead. During the Microsoft Entra join process, the Microsoft Entra Joined Device Local Administrator role is automatically added to the device's local administrators group and should be used instead.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Set Registering user is added as local administrator on the device during Microsoft Entra join (Preview) to Selected (and add members) or None.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Verify that Registering user is added as local administrator on the device during Microsoft Entra join (Preview) is set to Selected or None. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: beta/policies/deviceRegistrationPolicy 2. Verify that azureADJoin.localAdmins.registeringUsers.@odata.type is one of the following: o #microsoft.graph.enumeratedDeviceRegistrationMembership (Selected) o #microsoft.graph.noDeviceRegistrationMembership (None). Note: When set to Selected, users and groups will also appear in the output of the Graph Request.", + "AdditionalInformation": "", + "DefaultValue": "All", + "References": "https://learn.microsoft.com/en-us/entra/identity/devices/manage-device-identities#configure-device-settings:https://learn.microsoft.com/en-us/graph/api/resources/deviceregistrationpolicy?view=graph-rest-beta:https://learn.microsoft.com/en-us/entra/identity/devices/assign-local-admin" + } + ] + }, + { + "Id": "5.1.4.5", + "Description": "Local Administrator Password Solution (LAPS) is the management of local account passwords on Windows devices. LAPS provides a solution to securely manage and retrieve the built-in local admin password. With cloud version of LAPS, customers can enable storing and rotation of local admin passwords for both Microsoft Entra and Microsoft Entra hybrid join devices The recommended state is Yes.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.4 Devices", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Local Administrator Password Solution (LAPS) is the management of local account passwords on Windows devices. LAPS provides a solution to securely manage and retrieve the built-in local admin password. With cloud version of LAPS, customers can enable storing and rotation of local admin passwords for both Microsoft Entra and Microsoft Entra hybrid join devices The recommended state is Yes.", + "RationaleStatement": "Managing local Administrator passwords across multiple systems can be challenging. As a result, many organizations opt to configure the same password on all workstations and/or member servers during deployment. However, this practice introduces a significant security risk: if an attacker compromises one system and obtains the local Administrator password, they can potentially gain administrative access to every other system using that same password. Additionally, enabling LAPS at the tenant level is a prerequisite for implementing LAPS- related recommendations outlined in the CIS Microsoft Intune for Windows Workstation Benchmarks. Note: Enabling LAPS at the tenant level does not automatically enforce password rotation for built-in Administrator accounts. To activate LAPS functionality, appropriate policies must be configured in Intune Settings Catalog or under the Endpoint security > Account protection blade. The CIS Microsoft 365 Foundations Benchmark focuses on hardening at the tenant level, while the CIS Intune Benchmarks focus on endpoint-specific configurations.", + "ImpactStatement": "Enabling LAPS requires some additional operational overhead. Although unlikely if a password is rotated and not retrieved or backed up before the device becomes unreachable (e.g., due to hardware failure, network isolation, or being decommissioned), administrators may be locked out.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Set Enable Microsoft Entra Local Administrator Password Solution (LAPS) to Yes.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Verify that Enable Microsoft Entra Local Administrator Password Solution (LAPS) is set to Yes. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/policies/deviceRegistrationPolicy 2. Verify that localAdminPassword.isEnabled is True.", + "AdditionalInformation": "", + "DefaultValue": "No", + "References": "https://learn.microsoft.com/en-us/entra/identity/devices/manage-device-identities#configure-device-settings:https://learn.microsoft.com/en-us/graph/api/resources/deviceregistrationpolicy?view=graph-rest-beta:https://learn.microsoft.com/en-us/entra/identity/devices/howto-manage-local-admin-passwords" + } + ] + }, + { + "Id": "5.1.4.6", + "Description": "This setting determines if users can self-service recover their BitLocker key(s). 'Yes' restricts non-admin users from being able to see the BitLocker key(s) for their owned devices if there are any. 'No' allows all users to recover their BitLocker key(s). The recommended state is Yes.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.4 Devices", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "This setting determines if users can self-service recover their BitLocker key(s). 'Yes' restricts non-admin users from being able to see the BitLocker key(s) for their owned devices if there are any. 'No' allows all users to recover their BitLocker key(s). The recommended state is Yes.", + "RationaleStatement": "Restricting user access to the self-service BitLocker recovery key portal helps mitigate the risk of recovery key exposure in the event of a compromised user account. If an attacker gains access to both the user's credentials and the physical device, they could potentially retrieve the recovery key and decrypt sensitive data. The recovery key itself is also considered sensitive information.", + "ImpactStatement": "Restricting this setting will increase administrative overhead and may introduce friction between end users and the helpdesk, as users will no longer be able to retrieve BitLocker recovery keys through the self-service portal. This portal was originally designed to streamline recovery and reduce support burden. During the CrowdStrike Falcon Sensor outage in July 2024, many endpoints entered recovery mode, and delays in accessing recovery keys contributed to prolonged downtime. Limiting self-service access could exacerbate such delays in future incidents, especially in large or distributed environments.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Set Restrict users from recovering the BitLocker key(s) for their owned devices to Yes. To remediate using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.ReadWrite.Authorization\" 2. Run the following: $params = @{ defaultUserRolePermissions = @{ AllowedToReadBitlockerKeysForOwnedDevice = $false } } Update-MgPolicyAuthorizationPolicy -BodyParameter $params", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Devices and select Device settings. 3. Verify that Restrict users from recovering the BitLocker key(s) for their owned devices is set to Yes. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.All\" 2. Run the following: (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | fl 3. Verify that AllowedToReadBitlockerKeysForOwnedDevice is False.", + "AdditionalInformation": "", + "DefaultValue": "No", + "References": "https://learn.microsoft.com/en-us/entra/identity/devices/manage-device-identities#configure-device-settings:https://learn.microsoft.com/en-us/graph/api/authorizationpolicy-get?view=graph-rest-1.0:https://techcommunity.microsoft.com/blog/intunecustomersuccess/user-self-service-bitlocker-recovery-key-access-with-intune-company-portal-websi/4150458:https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/recovery-process#self-recovery" + } + ] + }, + { + "Id": "5.1.5.1", + "Description": "Control when end users and group owners are allowed to grant consent to applications, and when they will be required to request administrator review and approval. Allowing users to grant apps access to data helps them acquire useful applications and be productive but can represent a risk in some situations if it's not monitored and controlled carefully.", + "Checks": [ + "entra_policy_restricts_user_consent_for_apps" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.5 Enterprise apps", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Control when end users and group owners are allowed to grant consent to applications, and when they will be required to request administrator review and approval. Allowing users to grant apps access to data helps them acquire useful applications and be productive but can represent a risk in some situations if it's not monitored and controlled carefully.", + "RationaleStatement": "Attackers commonly use custom applications to trick users into granting them access to company data. Restricting user consent mitigates this risk and helps to reduce the threat-surface.", + "ImpactStatement": "If user consent is disabled, previous consent grants will still be honored but all future consent operations must be performed by an administrator. Tenant-wide admin consent can be requested by users through an integrated administrator consent request workflow or through organizational support processes.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Consent and permissions > User consent settings. 4. Under User consent for applications select Do not allow user consent. 5. Click the Save option at the top of the window.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Consent and permissions > User consent settings. 4. Verify that User consent for applications is set to Do not allow user consent. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.All\" 2. Run the following command: (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Select-Object -ExpandProperty PermissionGrantPoliciesAssigned 3. Verify that the returned array does not contain either ManagePermissionGrantsForSelf.microsoft-user-default-low or ManagePermissionGrantsForSelf.microsoft-user-default-legacy. If either of these strings is present, the audit fails.", + "AdditionalInformation": "", + "DefaultValue": "UI - Allow user consent for apps", + "References": "https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent?pivots=portal:https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.identity.signins/get-mgpolicyauthorizationpolicy?view=graph-powershell-1.0" + } + ] + }, + { + "Id": "5.1.5.2", + "Description": "The admin consent workflow gives admins a secure way to grant access to applications that require admin approval. When a user tries to access an application but is unable to provide consent, they can send a request for admin approval. The request is sent via email to admins who have been designated as reviewers. A reviewer takes action on the request, and the user is notified of the action.", + "Checks": [ + "entra_admin_consent_workflow_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.5 Enterprise apps", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "The admin consent workflow gives admins a secure way to grant access to applications that require admin approval. When a user tries to access an application but is unable to provide consent, they can send a request for admin approval. The request is sent via email to admins who have been designated as reviewers. A reviewer takes action on the request, and the user is notified of the action.", + "RationaleStatement": "The admin consent workflow (Preview) gives admins a secure way to grant access to applications that require admin approval. When a user tries to access an application but is unable to provide consent, they can send a request for admin approval. The request is sent via email to admins who have been designated as reviewers. A reviewer acts on the request, and the user is notified of the action.", + "ImpactStatement": "To approve requests, a reviewer must be a global administrator, cloud application administrator, or application administrator. The reviewer must already have one of these admin roles assigned; simply designating them as a reviewer doesn't elevate their privileges.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Consent and permissions. 4. Under Manage select Admin consent settings. 5. Set Users can request admin consent to apps they are unable to consent to to Yes under Admin consent requests. 6. Under the Reviewers choose the Roles and Groups that will review user generated app consent requests. 7. Set Selected users will receive email notifications for requests to Yes 8. Select Save at the top of the window.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Consent and permissions. 4. Under Manage select Admin consent settings. 5. Verify that Users can request admin consent to apps they are unable to consent to is set to Yes. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.All\" 2. Run the following command: Get-MgPolicyAdminConsentRequestPolicy | fl IsEnabled,NotifyReviewers,RemindersEnabled 3. Verify that IsEnabled is True.", + "AdditionalInformation": "", + "DefaultValue": "- Users can request admin consent to apps they are unable to consent to: No - Selected users to review admin consent requests: None - Selected users will receive email notifications for requests: Yes - Selected users will receive request expiration reminders: Yes - Consent request expires after (days): 30", + "References": "https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-admin-consent-workflow" + } + ] + }, + { + "Id": "5.1.5.3", + "Description": "In Microsoft Entra ID, applications and service principals can authenticate using either certificate credentials or password credentials (also referred to as client secrets). This setting enforces a tenant-wide restriction that prevents new password credentials from being added to any application registration or service principal. The policy is implemented through the default app management policy and applies to all applications unless scoped exceptions are configured. The setting does not revoke or invalidate existing password credentials; credentials created before the policy was enabled remain valid until they expire or are explicitly removed. The recommended state is Block password addition set to On.", + "Checks": [ + "entra_default_app_management_policy_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.5 Enterprise apps", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "In Microsoft Entra ID, applications and service principals can authenticate using either certificate credentials or password credentials (also referred to as client secrets). This setting enforces a tenant-wide restriction that prevents new password credentials from being added to any application registration or service principal. The policy is implemented through the default app management policy and applies to all applications unless scoped exceptions are configured. The setting does not revoke or invalidate existing password credentials; credentials created before the policy was enabled remain valid until they expire or are explicitly removed. The recommended state is Block password addition set to On.", + "RationaleStatement": "Password credentials (client secrets) used for application authentication are static string values that offer weaker security guarantees than certificate or federated credentials. Unlike certificates, client secrets carry no built-in proof of possession and are frequently stored in plaintext in source code, configuration files, CI/CD pipelines, and shell history. A leaked client secret grants any holder the ability to authenticate as the application to Microsoft Entra ID, potentially accessing any resource or permission scope assigned to that application. Blocking the addition of new password credentials eliminates this attack surface for applications created going forward and forces adoption of stronger credential types such as certificates.", + "ImpactStatement": "This policy applies to new password credential additions only. Existing client secrets remain valid until they expire or are explicitly revoked; this recommendation does not retroactively invalidate credentials created before the policy was enabled. Any automated process, pipeline, or script that programmatically adds client secrets to application registrations or service principals will be blocked once the policy is enabled, unless an exception is configured. Applications that have not yet migrated to certificate- based authentication or workload identity federation will require changes before new credentials can be added.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Application policies. 4. Select Block password addition. 5. Set Status to On. 6. Set Applies to to one of the following: o All applications o All applications with exclusions (if using exclusions, ensure they are reviewed annually). 7. Set Only apply to apps created after to a desired date or leave it unconfigured. 8. Select Save and close to apply the changes. To remediate using the Microsoft Graph API: Important: The PATCH request replaces the passwordCredentials array in full. Retrieve the current policy first and include all existing entries in the request body to avoid overwriting other configured restrictions or exclusions. 1. Execute a GET request to retrieve the current policy: v1.0/policies/defaultAppManagementPolicy 2. Modify the returned JSON to reflect the following changes: - Set isEnabled to true. - Under applicationRestrictions.passwordCredentials, locate the entry where restrictionType is passwordAddition and set the following: o state to enabled o restrictForAppsCreatedAfterDateTime to 0001-01-01T00:00:00Z or a desired date. - Under servicePrincipalRestrictions.passwordCredentials, locate the entry where restrictionType is passwordAddition and set the following: o state to enabled o restrictForAppsCreatedAfterDateTime to 0001-01-01T00:00:00Z or a desired date. 3. Execute a PATCH request to the same URI with the modified JSON in the request body to apply the changes. Note: The References section includes a link to the API documentation with full remediation examples in multiple languages including HTTP, PowerShell, and Python.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Application policies. 4. Select Block password addition. 5. Verify that Status is set to On. 6. Verify that Applies to is set to one of the following: o All applications o All applications with exclusions (if using exclusions, verify they are reviewed annually). 7. Verify that Only apply to apps created after is one of the following states: o Not configured (Field will show Select a date with no date selected) o A date that is on or before the date of the assessment. 8. Compliance is met when all of the above conditions are satisfied. To audit using the Microsoft Graph API: Note: Both the application restrictions and service principal restrictions must be audited to ensure password addition is properly blocked, as they can be independently configured in Graph or PowerShell. The UI only surfaces the combined state of both settings. 1. Execute a GET request to the following relative URI to get the default app management policy: v1.0/policies/defaultAppManagementPolicy 2. Verify that isEnabled is true, this indicates that the default app management policy is enabled and being applied to the tenant. Part 1: Audit application restrictions 1. Under applicationRestrictions.passwordCredentials, locate the entry where restrictionType is passwordAddition. 2. Verify the following conditions are met for applicationRestrictions.passwordCredentials: o state is enabled o restrictForAppsCreatedAfterDateTime is one of the following states: - 0001-01-01T00:00:00Z (not configured) - A date that is on or before the date of the assessment. 3. Compliance is met when all of the above conditions are satisfied. Part 2: Audit service principal restrictions 1. Under servicePrincipalRestrictions.passwordCredentials, locate the entry where restrictionType is passwordAddition. 2. Verify the following conditions are met for servicePrincipalRestrictions.passwordCredentials: o state is enabled o restrictForAppsCreatedAfterDateTime is one of the following states: - 0001-01-01T00:00:00Z (not configured) - A date that is on or before the date of the assessment. 3. Compliance is met when all of the above conditions are satisfied. Note: Presently the API does not surface application exclusions, only excluded callers, so it is not necessary to audit them for compliance.", + "AdditionalInformation": "", + "DefaultValue": "Off", + "References": "https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-app-management-policies?tabs=portal:https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-enforce-secret-standards?pivots=ms-graph:https://learn.microsoft.com/en-us/graph/api/resources/tenantappmanagementpolicy?view=graph-rest-1.0:https://learn.microsoft.com/en-us/entra/fundamentals/zero-trust-protect-identities#enforce-standards-for-app-secrets-and-certificates" + } + ] + }, + { + "Id": "5.1.5.4", + "Description": "In Microsoft Entra ID, applications and service principals can authenticate using password credentials (also referred to as client secrets). This setting enforces a tenant- wide maximum lifetime for new password credentials added to any application registration or service principal. When enabled, any client secret created must have an expiration date that falls within the configured maximum, which for this recommendation is 180 days or less. The policy is implemented through the default app management policy and applies to all applications unless scoped exceptions are configured. The setting does not retroactively shorten or invalidate existing password credentials; secrets created before the policy was enabled remain valid until they expire or are explicitly removed. The recommended state is Restrict max password lifetime set to On: 180 days or less.", + "Checks": [ + "entra_default_app_management_policy_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.5 Enterprise apps", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "In Microsoft Entra ID, applications and service principals can authenticate using password credentials (also referred to as client secrets). This setting enforces a tenant- wide maximum lifetime for new password credentials added to any application registration or service principal. When enabled, any client secret created must have an expiration date that falls within the configured maximum, which for this recommendation is 180 days or less. The policy is implemented through the default app management policy and applies to all applications unless scoped exceptions are configured. The setting does not retroactively shorten or invalidate existing password credentials; secrets created before the policy was enabled remain valid until they expire or are explicitly removed. The recommended state is Restrict max password lifetime set to On: 180 days or less.", + "RationaleStatement": "Long-lived client secrets extend the window of exploitation if a credential is compromised. A secret valid for multiple years that is never rotated remains usable even if it was leaked in source code, a build log, or a security breach long after the initial exposure. Enforcing a maximum lifetime of 180 days ensures that client secrets expire on a regular basis, limiting the period during which a stolen credential remains valid and reducing the blast radius of a compromise. This control also encourages teams to establish automated rotation practices, which further reduces reliance on static, long- lived credentials.", + "ImpactStatement": "Any automated process, pipeline, or script that creates client secrets with a lifetime exceeding the configured maximum will fail once the policy is enabled, unless an exception is configured. Organizations will need to update secret creation workflows to specify expiration dates within the allowed range and establish rotation processes for secrets approaching expiry.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Application policies. 4. Select Restrict max password lifetime. 5. Set Status to On. 6. Set the maximum lifetime to 180 days or less. 7. Set Applies to to one of the following: o All applications o All applications with exclusions (if using exclusions, ensure they are reviewed annually). 8. Set Only apply to apps created after to a desired date or leave it unconfigured. 9. Select Save and close to apply the changes. To remediate using the Microsoft Graph API: Important: The PATCH request replaces the passwordCredentials array in full. Retrieve the current policy first and include all existing entries in the request body to avoid overwriting other configured restrictions or exclusions. 1. Execute a GET request to retrieve the current policy: v1.0/policies/defaultAppManagementPolicy 2. Modify the returned JSON to reflect the following changes: o Set isEnabled to true. o Under applicationRestrictions.passwordCredentials, locate the entry where restrictionType is passwordLifetime and set the following: - state to enabled - maxLifetime to P180D or a shorter duration. - restrictForAppsCreatedAfterDateTime to 0001-01- 01T00:00:00Z or a desired date. o Under servicePrincipalRestrictions.passwordCredentials, locate the entry where restrictionType is passwordLifetime and set the following: - state to enabled - maxLifetime to P180D or a shorter duration. - restrictForAppsCreatedAfterDateTime to 0001-01- 01T00:00:00Z or a desired date. 3. Execute a PATCH request to the same URI with the modified JSON in the request body to apply the changes. Note: The References section includes a link to the API documentation with full remediation examples in multiple languages including HTTP, PowerShell, and Python.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Application policies. 4. Select Restrict max password lifetime. 5. Verify that Status is set to On. 6. Verify that the configured maximum lifetime is 180 days or less. 7. Verify that Applies to is set to one of the following: o All applications o All applications with exclusions (if using exclusions, verify they are reviewed annually). 8. Verify that Only apply to apps created after is one of the following states: o Not configured (Field will show Select a date with no date selected) o A date that is on or before the date of the assessment. 9. Compliance is met when all of the above conditions are satisfied. To audit using the Microsoft Graph API: Note: Both the application restrictions and service principal restrictions must be audited to ensure the password lifetime is properly restricted, as they can be independently configured in Graph or PowerShell. The UI only surfaces the combined state of both settings. 1. Execute a GET request to the following relative URI to get the default app management policy: v1.0/policies/defaultAppManagementPolicy 2. Verify that isEnabled is true, this indicates that the default app management policy is enabled and being applied to the tenant. Part 1: Audit application restrictions 1. Under applicationRestrictions.passwordCredentials, locate the entry where restrictionType is passwordLifetime. 2. Verify the following conditions are met for applicationRestrictions.passwordCredentials: o state is enabled o maxLifetime is P180D or a shorter duration (e.g., P90D, P30D, etc.) o restrictForAppsCreatedAfterDateTime is one of the following states: - 0001-01-01T00:00:00Z (not configured) - A date that is on or before the date of the assessment. 3. Compliance is met when all of the above conditions are satisfied. Part 2: Audit service principal restrictions 1. Under servicePrincipalRestrictions.passwordCredentials, locate the entry where restrictionType is passwordLifetime. 2. Verify the following conditions are met for servicePrincipalRestrictions.passwordCredentials: o state is enabled o maxLifetime is P180D or a shorter duration (e.g., P90D, P30D, etc.) o restrictForAppsCreatedAfterDateTime is one of the following states: - 0001-01-01T00:00:00Z (not configured) - A date that is on or before the date of the assessment. 3. Compliance is met when all of the above conditions are satisfied. Note: Presently the API does not surface application exclusions, only excluded callers, so it is not necessary to audit them for compliance.", + "AdditionalInformation": "", + "DefaultValue": "Off", + "References": "https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-app-management-policies?tabs=portal:https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-enforce-secret-standards?pivots=ms-graph:https://learn.microsoft.com/en-us/graph/api/resources/tenantappmanagementpolicy?view=graph-rest-1.0:https://learn.microsoft.com/en-us/entra/fundamentals/zero-trust-protect-identities#enforce-standards-for-app-secrets-and-certificates" + } + ] + }, + { + "Id": "5.1.5.5", + "Description": "In Microsoft Entra ID, applications and service principals can authenticate using password credentials (also referred to as client secrets). By default, when adding a new password credential, the caller may supply a custom password value or allow the system to generate one. This setting enforces a tenant-wide restriction that blocks the use of custom password values, requiring all new password credentials to be system- generated. The policy is implemented through the default app management policy and applies to all applications unless scoped exceptions are configured. The setting does not affect existing password credentials; credentials created before the policy was enabled remain valid until they expire or are explicitly removed. The recommended state is Block custom passwords set to On.", + "Checks": [ + "entra_default_app_management_policy_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.5 Enterprise apps", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "In Microsoft Entra ID, applications and service principals can authenticate using password credentials (also referred to as client secrets). By default, when adding a new password credential, the caller may supply a custom password value or allow the system to generate one. This setting enforces a tenant-wide restriction that blocks the use of custom password values, requiring all new password credentials to be system- generated. The policy is implemented through the default app management policy and applies to all applications unless scoped exceptions are configured. The setting does not affect existing password credentials; credentials created before the policy was enabled remain valid until they expire or are explicitly removed. The recommended state is Block custom passwords set to On.", + "RationaleStatement": "Custom password values are chosen by the caller and are susceptible to low entropy, predictable patterns, and reuse across multiple applications. A weak or reused client secret that is compromised through source code exposure, logging, or a supply-chain breach can be trivially exploited by an attacker to authenticate as the application. System-generated passwords use random values of sufficient length and complexity, making them resistant to brute-force and dictionary attacks. Blocking custom passwords removes the weakest credential creation path and ensures that all new client secrets meet a consistent entropy baseline.", + "ImpactStatement": "Any automated process, pipeline, or script that programmatically creates a client secret by supplying a custom password value will be blocked once the policy is enabled, unless an exception is configured. Most tooling, including the Microsoft Entra admin center, Azure CLI, and Azure PowerShell, already defaults to system-generated values, so the operational impact for typical workflows is minimal. Organizations that rely on custom password values in their automation will need to update those workflows to omit the custom value and accept the system-generated secret. Organizations that have policies or regulatory requirements that mandate specific password formats may need to maintain exclusions for certain applications. Exceptions should be scoped narrowly and reviewed regularly to minimize risk.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Application policies. 4. Select Block custom passwords. 5. Set Status to On. 6. Set Applies to to one of the following: o All applications o All applications with exclusions (if using exclusions, ensure they are reviewed annually). 7. Set Only apply to apps created after to a desired date or leave it unconfigured. 8. Select Save and close to apply the changes. To remediate using the Microsoft Graph API: Important: The PATCH request replaces the passwordCredentials array in full. Retrieve the current policy first and include all existing entries in the request body to avoid overwriting other configured restrictions or exclusions. 1. Execute a GET request to retrieve the current policy: v1.0/policies/defaultAppManagementPolicy 2. Modify the returned JSON to reflect the following changes: o Set isEnabled to true. o Under applicationRestrictions.passwordCredentials, locate the entry where restrictionType is customPasswordAddition and set the following: - state to enabled - restrictForAppsCreatedAfterDateTime to 0001-01- 01T00:00:00Z or a desired date. o Under servicePrincipalRestrictions.passwordCredentials, locate the entry where restrictionType is customPasswordAddition and set the following: - state to enabled - restrictForAppsCreatedAfterDateTime to 0001-01- 01T00:00:00Z or a desired date. 3. Execute a PATCH request to the same URI with the modified JSON in the request body to apply the changes. Note: The References section includes a link to the API documentation with full remediation examples in multiple languages including HTTP, PowerShell, and Python.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Application policies. 4. Select Block custom passwords. 5. Verify that Status is set to On. 6. Verify that Applies to is set to one of the following: o All applications o All applications with exclusions (if using exclusions, verify they are reviewed annually). 7. Verify that Only apply to apps created after is one of the following states: o Not configured (Field will show Select a date with no date selected) o A date that is on or before the date of the assessment. 8. Compliance is met when all of the above conditions are satisfied. To audit using the Microsoft Graph API: Note: Both the application restrictions and service principal restrictions must be audited to ensure custom password addition is properly blocked, as they can be independently configured in Graph or PowerShell. The UI only surfaces the combined state of both settings. 1. Execute a GET request to the following relative URI to get the default app management policy: v1.0/policies/defaultAppManagementPolicy 2. Verify that isEnabled is true, this indicates that the default app management policy is enabled and being applied to the tenant. Part 1: Audit application restrictions 1. Under applicationRestrictions.passwordCredentials, locate the entry where restrictionType is customPasswordAddition. 2. Verify the following conditions are met for applicationRestrictions.passwordCredentials: o state is enabled o restrictForAppsCreatedAfterDateTime is one of the following states: - 0001-01-01T00:00:00Z (not configured) - A date that is on or before the date of the assessment. 3. Compliance is met when all of the above conditions are satisfied. Part 2: Audit service principal restrictions 1. Under servicePrincipalRestrictions.passwordCredentials, locate the entry where restrictionType is customPasswordAddition. 2. Verify the following conditions are met for servicePrincipalRestrictions.passwordCredentials: o state is enabled o restrictForAppsCreatedAfterDateTime is one of the following states: - 0001-01-01T00:00:00Z (not configured) - A date that is on or before the date of the assessment. 3. Compliance is met when all of the above conditions are satisfied. Note: Presently the API does not surface application exclusions, only excluded callers, so it is not necessary to audit them for compliance.", + "AdditionalInformation": "", + "DefaultValue": "Off", + "References": "https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-app-management-policies?tabs=portal:https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-enforce-secret-standards?pivots=ms-graph:https://learn.microsoft.com/en-us/graph/api/resources/tenantappmanagementpolicy?view=graph-rest-1.0:https://learn.microsoft.com/en-us/entra/fundamentals/zero-trust-protect-identities#enforce-standards-for-app-secrets-and-certificates" + } + ] + }, + { + "Id": "5.1.5.6", + "Description": "In Microsoft Entra ID, applications and service principals can authenticate using certificate credentials. This setting enforces a tenant-wide maximum lifetime for new certificate credentials added to any application registration or service principal. When enabled, any certificate uploaded must have a validity period that falls within the configured maximum, which for this recommendation is 180 days or less. The policy is implemented through the default app management policy and applies to all applications unless scoped exceptions are configured. The setting does not retroactively shorten or invalidate existing certificate credentials; certificates uploaded before the policy was enabled remain valid until they expire or are explicitly removed. The recommended state is Restrict maximum certificate lifetime set to On: 180 days or less.", + "Checks": [ + "entra_default_app_management_policy_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.5 Enterprise apps", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "In Microsoft Entra ID, applications and service principals can authenticate using certificate credentials. This setting enforces a tenant-wide maximum lifetime for new certificate credentials added to any application registration or service principal. When enabled, any certificate uploaded must have a validity period that falls within the configured maximum, which for this recommendation is 180 days or less. The policy is implemented through the default app management policy and applies to all applications unless scoped exceptions are configured. The setting does not retroactively shorten or invalidate existing certificate credentials; certificates uploaded before the policy was enabled remain valid until they expire or are explicitly removed. The recommended state is Restrict maximum certificate lifetime set to On: 180 days or less.", + "RationaleStatement": "Long-lived certificates extend the window of exploitation if a credential is compromised. A certificate valid for multiple years that is never rotated remains usable even if the private key was exposed through a server breach, misconfigured storage, or supply- chain compromise long after the initial exposure. Enforcing a maximum lifetime of 180 days ensures that certificates expire on a regular basis, limiting the period during which a stolen credential remains valid and reducing the blast radius of a compromise. This control also encourages teams to establish automated certificate rotation practices, which further reduces reliance on static, long-lived credentials.", + "ImpactStatement": "Any automated process, pipeline, or script that uploads certificates with a validity period exceeding the configured maximum will be blocked once the policy is enabled, unless an exception is configured. Organizations will need to update certificate issuance workflows to generate certificates with expiration dates within the allowed range and establish rotation processes for certificates approaching expiry.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Application policies. 4. Select Restrict max certificate lifetime. 5. Set Status to On. 6. Set Applies to to one of the following: o All applications o All applications with exclusions (if using exclusions, ensure they are reviewed annually). 7. Set Only apply to apps created after to a desired date or leave it unconfigured. 8. Set Maximum lifetime (in days) to 180 days or less. 9. Select Save and close to apply the changes. To remediate using the Microsoft Graph API: 1. Execute a GET request to retrieve the current policy: v1.0/policies/defaultAppManagementPolicy 2. Modify the returned JSON to reflect the following changes: o Set isEnabled to true. o Under applicationRestrictions.keyCredentials, locate the entry where restrictionType is asymmetricKeyLifetime and set the following: - state to enabled - maxLifetime to P180D or a shorter duration. - restrictForAppsCreatedAfterDateTime to 0001-01- 01T00:00:00Z or a desired date. o Under servicePrincipalRestrictions.keyCredentials, locate the entry where restrictionType is asymmetricKeyLifetime and set the following: - state to enabled - maxLifetime to P180D or a shorter duration. - restrictForAppsCreatedAfterDateTime to 0001-01- 01T00:00:00Z or a desired date. 3. Execute a PATCH request to the same URI with the modified JSON in the request body to apply the changes. Note: The References section includes a link to the API documentation with full remediation examples in multiple languages including HTTP, PowerShell, and Python.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID and select Enterprise apps. 3. Under Security select Application policies. 4. Select Restrict max certificate lifetime. 5. Verify that Status is set to On. 6. Verify that Applies to is set to one of the following: o All applications o All applications with exclusions (if using exclusions, verify they are reviewed annually). 7. Verify that Only apply to apps created after is one of the following states: o Not configured (Field will show Select a date with no date selected) o A date that is on or before the date of the assessment. 8. Verify that Maximum lifetime (in days) is 180 days or less. 9. Compliance is met when all of the above conditions are satisfied. To audit using the Microsoft Graph API: Note: Both the application restrictions and service principal restrictions must be audited to ensure the certificate lifetime is properly restricted, as they can be independently configured in Graph or PowerShell. The UI only surfaces the combined state of both settings. 1. Execute a GET request to the following relative URI to get the default app management policy: v1.0/policies/defaultAppManagementPolicy 2. Verify that isEnabled is true, this indicates that the default app management policy is enabled and being applied to the tenant. Part 1: Audit application restrictions 1. Under applicationRestrictions.keyCredentials, locate the entry where restrictionType is asymmetricKeyLifetime. 2. Verify the following conditions are met for applicationRestrictions.keyCredentials: o state is enabled o maxLifetime is P180D or a shorter duration (e.g., P90D, P30D, etc.) o restrictForAppsCreatedAfterDateTime is one of the following states: - 0001-01-01T00:00:00Z (not configured) - A date that is on or before the date of the assessment. 3. Compliance is met when all of the above conditions are satisfied. Part 2: Audit service principal restrictions 1. Under servicePrincipalRestrictions.keyCredentials, locate the entry where restrictionType is asymmetricKeyLifetime. 2. Verify the following conditions are met for servicePrincipalRestrictions.keyCredentials: o state is enabled o maxLifetime is P180D or a shorter duration (e.g., P90D, P30D, etc.) o restrictForAppsCreatedAfterDateTime is one of the following states: - 0001-01-01T00:00:00Z (not configured) - A date that is on or before the date of the assessment. 3. Compliance is met when all of the above conditions are satisfied. Note: Presently the API does not surface application exclusions, only excluded callers, so it is not necessary to audit them for compliance.", + "AdditionalInformation": "", + "DefaultValue": "Off", + "References": "https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-app-management-policies?tabs=portal:https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-enforce-secret-standards?pivots=ms-graph:https://learn.microsoft.com/en-us/graph/api/resources/tenantappmanagementpolicy?view=graph-rest-1.0:https://learn.microsoft.com/en-us/entra/fundamentals/zero-trust-protect-identities#enforce-standards-for-app-secrets-and-certificates" + } + ] + }, + { + "Id": "5.1.6.1", + "Description": "B2B collaboration is a feature within Microsoft Entra External ID that allows for guest invitations to an organization. Ensure users can only send invitations to specified domains. Note: This list works independently from OneDrive for Business and SharePoint Online allow/block lists. To restrict individual file sharing in SharePoint Online, set up an allow or blocklist for OneDrive for Business and SharePoint Online. For instance, in SharePoint or OneDrive users can still share with external users from prohibited domains by using Anyone links if they haven't been disabled.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.6 External Identities", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "B2B collaboration is a feature within Microsoft Entra External ID that allows for guest invitations to an organization. Ensure users can only send invitations to specified domains. Note: This list works independently from OneDrive for Business and SharePoint Online allow/block lists. To restrict individual file sharing in SharePoint Online, set up an allow or blocklist for OneDrive for Business and SharePoint Online. For instance, in SharePoint or OneDrive users can still share with external users from prohibited domains by using Anyone links if they haven't been disabled.", + "RationaleStatement": "By specifying allowed domains for collaborations, external user's companies are explicitly identified. Also, this prevents internal users from inviting unknown external users such as personal accounts and granting them access to resources.", + "ImpactStatement": "This could make collaboration more difficult if the setting is not quickly updated when a new domain is identified as \"allowed\".", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > External Identities and select External collaboration settings. 3. Under Collaboration restrictions, select Allow invitations only to the specified domains (most restrictive) is selected. Then specify the allowed domains under Target domains.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > External Identities and select External collaboration settings. 3. Under Collaboration restrictions, verify that Allow invitations only to the specified domains (most restrictive) is selected. Then verify allowed domains are specified under Target domains. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.All\" 2. Run the following: $Uri = \"https://graph.microsoft.com/beta/legacy/policies\" $Response = (Invoke-MgGraphRequest -Uri $Uri).value | Where-Object { $_.type -eq 'B2BManagementPolicy' } if ($Response) { $Definition = $Response.definition | ConvertFrom-Json $DomainsPolicy = $Definition.B2BManagementPolicy.InvitationsAllowedAndBlockedDomainsPolicy } else { Write-Output \"No policy found.\" return } $DomainsPolicy 3. Verify that the output includes an AllowedDomains property that either contains no domains or lists only organizationally approved domains. If a BlockedDomains property is present, the configuration is considered non-compliant. Example of a compliant output with AllowedDomains defined: AllowedDomains -------------- {cisecurity.org, contoso.com, example.com} Allowed with no domains allowed (also compliant): AllowedDomains -------------- {}", + "AdditionalInformation": "", + "DefaultValue": "Allow invitations to be sent to any domain (most inclusive)", + "References": "https://learn.microsoft.com/en-us/entra/external-id/allow-deny-list:https://learn.microsoft.com/en-us/entra/external-id/what-is-b2b" + } + ] + }, + { + "Id": "5.1.6.2", + "Description": "Microsoft Entra ID, part of Microsoft Entra, allows you to restrict what external guest users can see in their organization in Microsoft Entra ID. Guest users are set to a limited permission level by default in Microsoft Entra ID, while the default for member users is the full set of user permissions. These directory level permissions are enforced across Microsoft Entra services including Microsoft Graph, PowerShell v2, the Azure portal, and My Apps portal. Microsoft 365 services leveraging Microsoft 365 groups for collaboration scenarios are also affected, specifically Outlook, Microsoft Teams, and SharePoint. They do not override the SharePoint or Microsoft Teams guest settings. The recommended state is at least Guest users have limited access to properties and memberships of directory objects or more restrictive.", + "Checks": [ + "entra_policy_guest_users_access_restrictions" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.6 External Identities", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft Entra ID, part of Microsoft Entra, allows you to restrict what external guest users can see in their organization in Microsoft Entra ID. Guest users are set to a limited permission level by default in Microsoft Entra ID, while the default for member users is the full set of user permissions. These directory level permissions are enforced across Microsoft Entra services including Microsoft Graph, PowerShell v2, the Azure portal, and My Apps portal. Microsoft 365 services leveraging Microsoft 365 groups for collaboration scenarios are also affected, specifically Outlook, Microsoft Teams, and SharePoint. They do not override the SharePoint or Microsoft Teams guest settings. The recommended state is at least Guest users have limited access to properties and memberships of directory objects or more restrictive.", + "RationaleStatement": "By limiting guest access to the most restrictive state this helps prevent malicious group and user object enumeration in the Microsoft 365 environment. This first step, known as reconnaissance in The Cyber Kill Chain, is often conducted by attackers prior to more advanced targeted attacks.", + "ImpactStatement": "The default is Guest users have limited access to properties and memberships of directory objects. When using the 'most restrictive' setting, guests will only be able to access their own profiles and will not be allowed to see other users' profiles, groups, or group memberships. There are some known issues with Yammer that will prevent guests that are signed in from leaving the group.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > External Identities and select External collaboration settings. 3. Under Guest user access set Guest user access restrictions to one of the following: o Guest users have limited access to properties and memberships of directory objects o Guest user access is restricted to properties and memberships of their own directory objects (most restrictive) To remediate using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.ReadWrite.Authorization\" 2. Run the following command to set the guest user access restrictions to default: # Guest users have limited access to properties and memberships of directory objects Update-MgPolicyAuthorizationPolicy -GuestUserRoleId '10dae51f-b6af-4016-8d66- 8c2a99b929b3' 3. Or, run the following command to set it to the \"most restrictive\": # Guest user access is restricted to properties and memberships of their own directory objects (most restrictive) Update-MgPolicyAuthorizationPolicy -GuestUserRoleId '2af84b1e-32c8-42b7-82bc- daa82404023b' Note: Either setting allows for a passing state.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > External Identities and select External collaboration settings. 3. Under Guest user access verify that Guest user access restrictions is set to one of the following: o Guest users have limited access to properties and memberships of directory objects o Guest user access is restricted to properties and memberships of their own directory objects (most restrictive) To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.All\" 2. Run the following command: Get-MgPolicyAuthorizationPolicy | fl GuestUserRoleId 3. Verify that the value returned is 10dae51f-b6af-4016-8d66-8c2a99b929b3 or 2af84b1e-32c8-42b7-82bc-daa82404023b (most restrictive) Note: Either setting allows for a passing state. Note 2: The value of a0b1b346-4d3e-4e8b-98f8-753987be4970 is equal to Guest users have the same access as members (most inclusive) and should not be used.", + "AdditionalInformation": "", + "DefaultValue": "- UI: Guest users have limited access to properties and memberships of directory objects - PowerShell: 10dae51f-b6af-4016-8d66-8c2a99b929b3", + "References": "https://learn.microsoft.com/en-us/entra/identity/users/users-restrict-guest-permissions:https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html" + } + ] + }, + { + "Id": "5.1.6.3", + "Description": "By default, all users in the organization, including B2B collaboration guest users, can invite external users to B2B collaboration. The ability to send invitations can be limited by turning it on or off for everyone, or by restricting invitations to certain roles. The recommended state is Only users assigned to specific admin roles can invite guest users or No one in the organization can invite guest users including admins (most restrictive).", + "Checks": [ + "entra_policy_guest_invite_only_for_admin_roles" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.6 External Identities", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "By default, all users in the organization, including B2B collaboration guest users, can invite external users to B2B collaboration. The ability to send invitations can be limited by turning it on or off for everyone, or by restricting invitations to certain roles. The recommended state is Only users assigned to specific admin roles can invite guest users or No one in the organization can invite guest users including admins (most restrictive).", + "RationaleStatement": "Restricting who can invite guests limits the exposure the organization might face from unauthorized accounts. The default behavior allows anyone within the organization to invite guests and non-admins to the tenant, posing a security risk.", + "ImpactStatement": "This introduces an obstacle to collaboration by restricting who can invite guest users to the organization. Designated Guest Inviters must be assigned, and an approval process established and clearly communicated to all users.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > External Identities and select External collaboration settings. 3. Under Guest invite settings set Guest invite restrictions to one of the desired compliant states: o Only users assigned to specific admin roles can invite guest users o No one in the organization can invite guest users including admins (most restrictive) To remediate using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.ReadWrite.Authorization\" 2. Run one of the following PowerShell commands depending on the desired compliant state: To set to Only users assigned to specific admin roles can invite guest users: Update-MgPolicyAuthorizationPolicy -AllowInvitesFrom 'adminsAndGuestInviters' To set to No one in the organization can invite guest users including admins (most restrictive): Update-MgPolicyAuthorizationPolicy -AllowInvitesFrom \"none\"", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > External Identities and select External collaboration settings. 3. Under Guest invite settings verify that Guest invite restrictions is set to one of the following: o Only users assigned to specific admin roles can invite guest users o No one in the organization can invite guest users including admins (most restrictive) To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.All\" 2. Run the following command: Get-MgPolicyAuthorizationPolicy | fl AllowInvitesFrom 3. Verify the value returned is adminsAndGuestInviters or none.", + "AdditionalInformation": "", + "DefaultValue": "- UI: Anyone in the organization can invite guest users including guests and non-admins (most inclusive) - PowerShell: everyone", + "References": "https://learn.microsoft.com/en-us/entra/external-id/external-collaboration-settings-configure:https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#guest-inviter" + } + ] + }, + { + "Id": "5.1.8.1", + "Description": "Password Hash Synchronization is one of the sign-in methods used to enable hybrid identity authentication. With this method, Microsoft Entra Connect synchronizes a cryptographically derived representation of a user's on-premises Active Directory password to Microsoft Entra ID. The original NT password hash (MD4) is never transmitted to Entra ID. Instead, Entra Connect computes a SHA-256 hash of the original MD4 hash and synchronizes that value. Because only this secondary hash is stored in the cloud, the credential material in Entra ID cannot be reused for on-premises pass-the-hash attacks, even if compromised. Note: The audit and remediation procedures described in this recommendation are applicable only to Microsoft 365 tenants operating in a hybrid identity configuration using Microsoft Entra Connect. They do not apply to federated or cloud-only deployments.", + "Checks": [ + "entra_password_hash_sync_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.1.8 Hybrid management", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Password Hash Synchronization is one of the sign-in methods used to enable hybrid identity authentication. With this method, Microsoft Entra Connect synchronizes a cryptographically derived representation of a user's on-premises Active Directory password to Microsoft Entra ID. The original NT password hash (MD4) is never transmitted to Entra ID. Instead, Entra Connect computes a SHA-256 hash of the original MD4 hash and synchronizes that value. Because only this secondary hash is stored in the cloud, the credential material in Entra ID cannot be reused for on-premises pass-the-hash attacks, even if compromised. Note: The audit and remediation procedures described in this recommendation are applicable only to Microsoft 365 tenants operating in a hybrid identity configuration using Microsoft Entra Connect. They do not apply to federated or cloud-only deployments.", + "RationaleStatement": "Password hash synchronization helps by reducing the number of passwords your users need to maintain to just one and enables leaked credential detection for your hybrid accounts. Leaked credential protection is leveraged through Entra ID Protection and is a subset of that feature which can help identify if an organization's user account passwords have appeared on the dark web or public spaces. Using other options for your directory synchronization may be less resilient as Microsoft can still process sign-ins to 365 with Hash Sync even if a network connection to your on-premises environment is not available. This minimizes downtime and ensures business continuity.", + "ImpactStatement": "Compliance or regulatory restrictions may exist, depending on the organization's business sector, that preclude hashed versions of passwords from being securely transmitted to cloud data centers.", + "RemediationProcedure": "To remediate using the on-prem Microsoft Entra Connect tool: 1. Log in to the on premises server that hosts the Microsoft Entra Connect tool 2. Double-click the Azure AD Connect icon that was created on the desktop 3. Click Configure. 4. On the Additional tasks page, select Customize synchronization options and click Next. 5. Enter the username and password for your global administrator. 6. On the Connect your directories screen, click Next. 7. On the Domain and OU filtering screen, click Next. 8. On the Optional features screen, check Password hash synchronization and click Next. 9. On the Ready to configure screen click Configure. 10. Once the configuration completes, click Exit.", + "AuditProcedure": "To audit using the UI: Only Global Admin and Hybrid Identity Administrator roles have access to view the actual Password Hash Sync status message. Inadequate role access will result in a default message stating: \"Unable to retrieve your tenant's password hash sync information.\" 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Entra Connect. 3. Select Connect Sync. 4. Under Microsoft Entra Connect sync, verify the Password Hash Sync status message indicates that synchronization is occurring and no errors are present, with one of the following messages: o Password hash synchronization is enabled o Password hash synchronization cloud configuration is enabled o Password hash synchronization heartbeat detected To audit using the Microsoft Graph API: Permission required: OnPremDirectorySynchronization.Read.All 1. Execute a GET request to the following relative URI: v1.0/directory/onPremisesSynchronization 2. Verify that features.passwordSyncEnabled is true. To audit for the on-prem tool: 1. Log in to the server that hosts the Microsoft Entra Connect tool. 2. Run Azure AD Connect, and then click Configure and View or export current configuration. 3. Verify that PASSWORD HASH SYNCHRONIZATION is enabled on your tenant. To audit using PowerShell: 1. Open PowerShell on the on-premises server running Microsoft Entra Connect. 2. Run the following cmdlet: Get-ADSyncAADCompanyFeature 3. Verify that PasswordHashSync is True.", + "AdditionalInformation": "", + "DefaultValue": "- Microsoft Entra Connect sync disabled by default - Password Hash Sync is Microsoft's recommended setting for new deployments", + "References": "https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs:https://www.microsoft.com/en-us/download/details.aspx?id=47594:https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-staging-server:https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-password-hash-synchronization:https://learn.microsoft.com/en-us/graph/api/resources/onpremisesdirectorysynchronizationfeature?view=graph-rest-1.0" + } + ] + }, + { + "Id": "5.2.2.1", + "Description": "Multifactor authentication is a process that requires an additional form of identification during the sign-in process, such as a code from a mobile device or a fingerprint scan, to enhance security. Ensure users in administrator roles have MFA capabilities enabled.", + "Checks": [ + "entra_admin_users_mfa_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Multifactor authentication is a process that requires an additional form of identification during the sign-in process, such as a code from a mobile device or a fingerprint scan, to enhance security. Ensure users in administrator roles have MFA capabilities enabled.", + "RationaleStatement": "Multifactor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted. Multifactor authentication provides additional assurance that the individual attempting to gain access is who they claim to be. With multifactor authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk. Note: To ensure that accounts cannot be easily used to enumerate resources (reconnaissance) through Microsoft Admin Portals or through Microsoft Azure Service Management API, both MFA conditional access policies must target All Resources: - \"Ensure multifactor authentication is enabled for all users\" and - \"Ensure multifactor authentication is enabled for all users in administrative roles\" (this recommendation)", + "ImpactStatement": "Implementation of multifactor authentication for all users in administrative roles will necessitate a change to user routine. All users in administrative roles will be required to enroll in multifactor authentication using phone, SMS, or an authentication application. After enrollment, use of multifactor authentication will be required for future access to the environment.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Click New policy. o Under Users or agents (Preview) include Select users and groups and check Directory roles. o At a minimum, include the directory roles listed below in this section of the document. o Under Target resources include All resources (formerly 'All cloud apps') and do not create any exclusions. - Under Exclude exclude any break-glass accounts. o Under Grant select Grant Access and check either Require multifactor authentication or Require authentication strength. o Click Select at the bottom of the pane. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On. At minimum these directory roles should be included for MFA: - Application administrator - Authentication administrator - Billing administrator - Cloud application administrator - Conditional Access administrator - Exchange administrator - Global administrator - Global reader - Helpdesk administrator - Password administrator - Privileged authentication administrator - Privileged role administrator - Security administrator - SharePoint administrator - User administrator", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify Directory roles specific to administrators are included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify All resources (formerly 'All cloud apps') is selected with no exclusions. o Under Grant verify Grant Access is on and either Require multifactor authentication or Require authentication strength is checked. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. For each policy returned, verify the following criteria: o Conditions.Users.IncludeRoles contains the directory roles specific to administrators* o Conditions.Applications.IncludeApplications is All o GrantControls.BuiltInControls contains mfa OR GrantControls.AuthenticationStrength.id is defined o State is enabled 3. Compliance is met when at least one policy is found to meet all the criteria listed above. 4. Verify that any exclusions are documented and reviewed annually. Note: The Authentication Strength requirement is satisfied when any valid GUID is present in the authenticationStrength property of a matching policy. Because Authentication Strength configurations are inherently stronger than the built-in Require multifactor authentication control, the presence of a valid Authentication Strength also fulfills the MFA requirement for all users. Note: A list of Directory roles can be found in the Remediation section.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default.", + "References": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-admin-mfa:https://learn.microsoft.com/en-us/graph/api/conditionalaccessroot-list-policies?view=graph-rest-1.0" + } + ] + }, + { + "Id": "5.2.2.2", + "Description": "Enable multifactor authentication for all users in the Microsoft 365 tenant. Users will be prompted to authenticate with a second factor upon logging in to Microsoft 365 services. The second factor is most commonly a text message to a registered mobile phone number where they type in an authorization code, or with a mobile application like Microsoft Authenticator. Note: Since 2024, Microsoft has been rolling out mandatory multifactor authentication.", + "Checks": [ + "entra_users_mfa_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Enable multifactor authentication for all users in the Microsoft 365 tenant. Users will be prompted to authenticate with a second factor upon logging in to Microsoft 365 services. The second factor is most commonly a text message to a registered mobile phone number where they type in an authorization code, or with a mobile application like Microsoft Authenticator. Note: Since 2024, Microsoft has been rolling out mandatory multifactor authentication.", + "RationaleStatement": "Multifactor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted. Multifactor authentication provides additional assurance that the individual attempting to gain access is who they claim to be. With multifactor authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk. Note: To ensure that accounts cannot be easily used to enumerate resources (reconnaissance) through Microsoft Admin Portals or through Microsoft Azure Service Management API, both MFA conditional access policies must target All Resources: - \"Ensure multifactor authentication is enabled for all users in administrative roles\" and - \"Ensure multifactor authentication is enabled for all users\" (this recommendation)", + "ImpactStatement": "Implementation of multifactor authentication for all users will necessitate a change to user routine. All users will be required to enroll in multifactor authentication using phone, SMS, or an authentication application. After enrollment, use of multifactor authentication will be required for future authentication to the environment. External identities that attempt to access documents that utilize Purview Information Protection (Sensitivity Labels) will find their access disrupted. In order to mitigate this create an exclusion for Microsoft Rights Management Services ID: 00000012- 0000-0000-c000-000000000000 Note: Organizations that struggle to enforce MFA globally due to budget constraints preventing the provision of company-owned mobile devices to every user, or due to regulations, unions, or policies that prevent forcing end users to use their personal devices, have another option. FIDO2 security keys can be used as an alternative. They are more secure, phishing-resistant, and affordable for organizations to issue to every end user.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Click New policy. o Under Users or agents (Preview) include All users. o Under Target resources include All resources (formerly 'All cloud apps') and do not create any exclusions. - Under Exclude exclude any break-glass accounts. o Under Grant select Grant Access and check either Require multifactor authentication or Require authentication strength. o Click Select at the bottom of the pane. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify All users is included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify All resources (formerly 'All cloud apps') is selected with no exclusions. o Under Grant verify Grant Access and either Require multifactor authentication or Require authentication strength is checked. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. For each policy returned, verify the following criteria: o Conditions.Users.IncludeUsers is All o Conditions.Applications.IncludeApplications is All o GrantControls.BuiltInControls contains mfa OR GrantControls.AuthenticationStrength.id is defined o State is enabled 3. Compliance is met when at least one policy is found to meet all the criteria listed above. 4. Verify that any exclusions are documented and reviewed annually. Note: The Authentication Strength requirement is satisfied when any valid GUID is present in the authenticationStrength property of a matching policy. Because Authentication Strength configurations are inherently stronger than the built-in Require multifactor authentication control, the presence of a valid Authentication Strength also fulfills the MFA requirement for all users.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default. It may be present as a Microsoft-managed policy or created from a Conditional Access template.", + "References": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-all-users-mfa:https://learn.microsoft.com/en-us/graph/api/conditionalaccessroot-list-policies?view=graph-rest-1.0:https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication" + } + ] + }, + { + "Id": "5.2.2.3", + "Description": "Entra ID supports the most widely used authentication and authorization protocols including legacy authentication. This authentication pattern includes basic authentication, a widely used industry-standard method for collecting username and password information. The following messaging protocols support legacy authentication: - Authenticated SMTP - Used to send authenticated email messages. - Autodiscover - Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online. - Exchange ActiveSync (EAS) - Used to connect to mailboxes in Exchange Online. - Exchange Online PowerShell - Used to connect to Exchange Online with remote PowerShell. If you block Basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect. For instructions, see Connect to Exchange Online PowerShell using multifactor authentication. - Exchange Web Services (EWS) - A programming interface that's used by Outlook, Outlook for Mac, and third-party apps. - IMAP4 - Used by IMAP email clients. - MAPI over HTTP (MAPI/HTTP) - Primary mailbox access protocol used by Outlook 2010 SP2 and later. - Offline Address Book (OAB) - A copy of address list collections that are downloaded and used by Outlook. - Outlook Anywhere (RPC over HTTP) - Legacy mailbox access protocol supported by all current Outlook versions. - POP3 - Used by POP email clients. - Reporting Web Services - Used to retrieve report data in Exchange Online. - Universal Outlook - Used by the Mail and Calendar app for Windows 10. - Other clients - Other protocols identified as utilizing legacy authentication.", + "Checks": [ + "entra_legacy_authentication_blocked" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Entra ID supports the most widely used authentication and authorization protocols including legacy authentication. This authentication pattern includes basic authentication, a widely used industry-standard method for collecting username and password information. The following messaging protocols support legacy authentication: - Authenticated SMTP - Used to send authenticated email messages. - Autodiscover - Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online. - Exchange ActiveSync (EAS) - Used to connect to mailboxes in Exchange Online. - Exchange Online PowerShell - Used to connect to Exchange Online with remote PowerShell. If you block Basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect. For instructions, see Connect to Exchange Online PowerShell using multifactor authentication. - Exchange Web Services (EWS) - A programming interface that's used by Outlook, Outlook for Mac, and third-party apps. - IMAP4 - Used by IMAP email clients. - MAPI over HTTP (MAPI/HTTP) - Primary mailbox access protocol used by Outlook 2010 SP2 and later. - Offline Address Book (OAB) - A copy of address list collections that are downloaded and used by Outlook. - Outlook Anywhere (RPC over HTTP) - Legacy mailbox access protocol supported by all current Outlook versions. - POP3 - Used by POP email clients. - Reporting Web Services - Used to retrieve report data in Exchange Online. - Universal Outlook - Used by the Mail and Calendar app for Windows 10. - Other clients - Other protocols identified as utilizing legacy authentication.", + "RationaleStatement": "Legacy authentication protocols do not support multi-factor authentication. These protocols are often used by attackers because of this deficiency. Blocking legacy authentication makes it harder for attackers to gain access. Note: Basic authentication is now disabled in all tenants. Before December 31 2022, you could re-enable the affected protocols if users and apps in your tenant couldn't connect. Now no one (you or Microsoft support) can re-enable Basic authentication in your tenant.", + "ImpactStatement": "Enabling this setting will block legacy authentication, preventing access from older versions of Microsoft Office, Exchange ActiveSync, and protocols such as IMAP, POP, and SMTP. As a result, some users may need to upgrade to newer Office versions or use email clients that support modern authentication. This change may also affect multifunction devices (MFPs), such as printers using legacy authentication for scan-to-email. Microsoft provides mail flow best practices (linked below) to configure MFPs without relying on legacy authentication. https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a- multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Create a new policy by selecting New policy. o Under Users or agents (Preview) include All users. o Under Target resources include All resources (formerly 'All cloud apps'). - Under Exclude exclude any break-glass accounts. o Under Conditions select Client apps and check the boxes for Exchange ActiveSync clients and Other clients. o Under Grant select Block Access. o Click Select. 4. Set the policy On and click Create.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify All users is included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify All resources (formerly 'All cloud apps') is selected. o Verify that only documented resource exclusions exist and that they are reviewed annually. o Under Conditions select Client apps then verify Exchange ActiveSync clients and Other clients is checked. o Under Grant verify Block access is selected. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where Conditions.ClientAppTypes contains exchangeActiveSync OR other. 3. For each policy returned, verify the following criteria: o Conditions.Users.IncludeUsers is All o Conditions.Applications.IncludeApplications is All o Conditions.ClientAppTypes contains exchangeActiveSync o Conditions.ClientAppTypes contains other o GrantControls.BuiltInControls is block o State is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually.", + "AdditionalInformation": "", + "DefaultValue": "Basic authentication is disabled by default as of January 2023.", + "References": "https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online:https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365:https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online" + } + ] + }, + { + "Id": "5.2.2.4", + "Description": "In complex deployments, organizations might have a need to restrict authentication sessions. Conditional Access policies allow for the targeting of specific user accounts. Some scenarios might include: - Resource access from an unmanaged or shared device - Access to sensitive information from an external network - High-privileged users - Business-critical applications Note: This CA policy can be added to the previous CA policy in this benchmark \"Ensure multifactor authentication is enabled for all users in administrative roles\"", + "Checks": [ + "entra_admin_users_sign_in_frequency_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "In complex deployments, organizations might have a need to restrict authentication sessions. Conditional Access policies allow for the targeting of specific user accounts. Some scenarios might include: - Resource access from an unmanaged or shared device - Access to sensitive information from an external network - High-privileged users - Business-critical applications Note: This CA policy can be added to the previous CA policy in this benchmark \"Ensure multifactor authentication is enabled for all users in administrative roles\"", + "RationaleStatement": "Forcing a time out for MFA will help ensure that sessions are not kept alive for an indefinite period of time, ensuring that browser sessions are not persistent will help in prevention of drive-by attacks in web browsers, this also prevents creation and saving of session cookies leaving nothing for an attacker to take.", + "ImpactStatement": "Users with Administrative roles will be prompted at the frequency set for MFA.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Conditional Access and select Policies. 3. Click New policy. o Under Users or agents (Preview) include Select users and groups and check Directory roles. o At a minimum, include the directory roles listed below in this section of the document. o Under Target resources include All resources (formerly 'All cloud apps'). - Under Exclude exclude any break-glass accounts. o Under Grant select Grant Access and check Require multifactor authentication. o Under Session select Sign-in frequency select Periodic reauthentication and set it to 4 hours (or less). o Check Persistent browser session then select Never persistent in the drop-down menu. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On. At minimum these directory roles should be included in the policy: - Application administrator - Authentication administrator - Billing administrator - Cloud application administrator - Conditional Access administrator - Exchange administrator - Global administrator - Global reader - Helpdesk administrator - Password administrator - Privileged authentication administrator - Privileged role administrator - Security administrator - SharePoint administrator - User administrator", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify Directory roles specific to administrators are included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify All resources (formerly 'All cloud apps') is selected. o Verify that only documented resource exclusions exist and that they are reviewed annually. o Under Session verify Sign-in frequency is checked and set to Periodic reauthentication. o Verify the timeframe is set to the time determined by the organization. o Verify that Periodic reauthentication does not exceed 4 hours (or less). o Verify that Persistent browser session is set to Never persistent. 4. Verify that Enable policy is set to On To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where SessionControls.PersistentBrowser.IsEnabled is true. 3. For each policy returned, verify the following criteria: o Conditions.Users.IncludeRoles contains the directory roles specific to administrators* o Conditions.Applications.IncludeApplications is All o SessionControls.SignInFrequency.IsEnabled is true o SessionControls.SignInFrequency.FrequencyInterval is everyTime OR is timeBased AND does not exceed 4 hours. o SessionControls.PersistentBrowser.IsEnabled is true o SessionControls.PersistentBrowser.Mode is never o State is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually. Note: A list of directory roles applying to Administrators can be found in the remediation section.", + "AdditionalInformation": "", + "DefaultValue": "The default configuration for user sign-in frequency is a rolling window of 90 days.", + "References": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-session-lifetime" + } + ] + }, + { + "Id": "5.2.2.5", + "Description": "Authentication strength is a Conditional Access control that allows administrators to specify which combination of authentication methods can be used to access a resource. For example, they can make only phishing-resistant authentication methods available to access a sensitive resource. But to access a non-sensitive resource, they can allow less secure multifactor authentication (MFA) combinations, such as password + SMS. Microsoft has 3 built-in authentication strengths. MFA strength, Passwordless MFA strength, and Phishing-resistant MFA strength. Ensure administrator roles are using a CA policy with Phishing-resistant MFA strength. Administrators can then enroll using one of 3 methods: - FIDO2 Security Key - Windows Hello for Business - Certificate-based authentication (Multi-Factor) Note: Additional steps to configure methods such as FIDO2 keys are not covered here but can be found in related MS articles in the references section. The Conditional Access policy only ensures 1 of the 3 methods is used. Warning: Administrators should be pre-registered for a strong authentication mechanism before this Conditional Access Policy is enforced. Additionally, as stated elsewhere in the CIS Benchmark a break-glass administrator account should be excluded from this policy to ensure unfettered access in the case of an emergency.", + "Checks": [ + "entra_admin_users_phishing_resistant_mfa_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Authentication strength is a Conditional Access control that allows administrators to specify which combination of authentication methods can be used to access a resource. For example, they can make only phishing-resistant authentication methods available to access a sensitive resource. But to access a non-sensitive resource, they can allow less secure multifactor authentication (MFA) combinations, such as password + SMS. Microsoft has 3 built-in authentication strengths. MFA strength, Passwordless MFA strength, and Phishing-resistant MFA strength. Ensure administrator roles are using a CA policy with Phishing-resistant MFA strength. Administrators can then enroll using one of 3 methods: - FIDO2 Security Key - Windows Hello for Business - Certificate-based authentication (Multi-Factor) Note: Additional steps to configure methods such as FIDO2 keys are not covered here but can be found in related MS articles in the references section. The Conditional Access policy only ensures 1 of the 3 methods is used. Warning: Administrators should be pre-registered for a strong authentication mechanism before this Conditional Access Policy is enforced. Additionally, as stated elsewhere in the CIS Benchmark a break-glass administrator account should be excluded from this policy to ensure unfettered access in the case of an emergency.", + "RationaleStatement": "Sophisticated attacks targeting MFA are more prevalent as the use of it becomes more widespread. These 3 methods are considered phishing-resistant as they remove passwords from the login workflow. It also ensures that public/private key exchange can only happen between the devices and a registered provider which prevents login to fake or phishing websites.", + "ImpactStatement": "If administrators aren't pre-registered for a strong authentication method prior to a conditional access policy being created, then a condition could occur where a user can't register for strong authentication because they don't meet the conditional access policy requirements and therefore are prevented from signing in. Additionally, Internet Explorer based credential prompts in PowerShell do not support prompting for a security key. Implementing phishing-resistant MFA with a security key may prevent admins from running their existing sets of PowerShell scripts. Device Authorization Grant Flow can be used as a workaround in some instances.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Click New policy. o Under Users or agents (Preview) include Select users and groups and check Directory roles. o At a minimum, include the directory roles listed below in this section of the document. o Under Target resources include All resources (formerly 'All cloud apps') and do not create any exclusions other than break-glass accounts. o Under Grant select Grant Access and check Require authentication strength and set Phishing-resistant MFA in the dropdown box. o Click Select. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On. Warning: Ensure administrators are pre-registered with strong authentication before enforcing the policy. After which the policy must be set to On. At minimum these directory roles should be included for the policy: - Application administrator - Authentication administrator - Billing administrator - Cloud application administrator - Conditional Access administrator - Exchange administrator - Global administrator - Global reader - Helpdesk administrator - Password administrator - Privileged authentication administrator - Privileged role administrator - Security administrator - SharePoint administrator - User administrator", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify Directory roles specific to administrators are included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Directory Roles should include at minimum the roles listed in the remediation section. o Under Target resources verify All resources (formerly 'All cloud apps') is selected with no exclusions. o Under Grant verify Grant Access is selected and Require authentication strength is checked with Phishing-resistant MFA set as the value. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where GrantControls.AuthenticationStrength.Id contains any valid id. 3. For each policy returned, verify the following criteria: o Conditions.Users.IncludeRoles contains the directory roles specific to administrators* o Conditions.Applications.IncludeApplications is All o GrantControls.AuthenticationStrength.AllowedCombinations only contains windowsHelloForBusiness OR fido2 OR x509CertificateMultiFactor o State is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default. It can be created from a Conditional Access template.", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passwordless#fido2-security-keys:https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2:https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths:https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-mfa-policy" + } + ] + }, + { + "Id": "5.2.2.6", + "Description": "Microsoft Entra ID Protection user risk policies detect the probability that a user account has been compromised. Note: While Identity Protection also provides two risk policies with limited conditions, Microsoft highly recommends setting up risk-based policies in Conditional Access as opposed to the \"legacy method\" for the following benefits: - Enhanced diagnostic data - Report-only mode integration - Graph API support - Use more Conditional Access attributes like sign-in frequency in the policy", + "Checks": [ + "entra_identity_protection_user_risk_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft Entra ID Protection user risk policies detect the probability that a user account has been compromised. Note: While Identity Protection also provides two risk policies with limited conditions, Microsoft highly recommends setting up risk-based policies in Conditional Access as opposed to the \"legacy method\" for the following benefits: - Enhanced diagnostic data - Report-only mode integration - Graph API support - Use more Conditional Access attributes like sign-in frequency in the policy", + "RationaleStatement": "With the user risk policy turned on, Entra ID protection detects the probability that a user account has been compromised. Administrators can configure a user risk conditional access policy to automatically respond to a specific user risk level.", + "ImpactStatement": "Upon policy activation, account access will be either blocked or the user will be required to use multi-factor authentication (MFA) and change their password. Users without registered MFA will be denied access, necessitating an admin to recover the account. To avoid inconvenience, it is advised to configure the MFA registration policy for all users under the User Risk policy. Additionally, users identified in the Risky Users section will be affected by this policy. To gain a better understanding of the impact on the organization's environment, the list of Risky Users should be reviewed before enforcing the policy.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Create a new policy by selecting New policy. o Under Users or agents (Preview) choose All users o Under Target resources choose All resources (formerly 'All cloud apps') - Under Exclude exclude any break-glass accounts. o Under Conditions choose User risk then Yes and select the user risk level High. o Under Grant select Grant access then check Require multifactor authentication or Require authentication strength. Finally check Require password change. o Under Session set Sign-in frequency to Every time. o Click Select. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify All users is included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify All resources (formerly 'All cloud apps') is selected. o Under Conditions verify User risk is set to High. o Under Grant verify Grant access is selected and either Require multifactor authentication or Require authentication strength are checked. Then verify Require password change is checked. o Under Session ensure Sign-in frequency is set to Every time. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where Conditions.UserRiskLevels contains any string. 3. For each policy returned, verify the following criteria: o Conditions.Users.IncludeUsers is All o Conditions.Applications.IncludeApplications is All o Conditions.UserRiskLevels contains high o GrantControls.BuiltInControls contains passwordChange o GrantControls.BuiltInControls contains mfa OR GrantControls.AuthenticationStrength.id is any id o SessionControls.SignInFrequency.IsEnabled is true o SessionControls.SignInFrequency.FrequencyInterval is everyTime o State is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually. Note: If the UserRiskLevels array includes medium or low, this still qualifies as compliant, as these enforcement levels are considered more strict. However, it must always include high; omitting this level would exclude users who are classified as high risk.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default. It may be created from a Conditional Access template.", + "References": "https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-risk-feedback:https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks" + } + ] + }, + { + "Id": "5.2.2.7", + "Description": "Microsoft Entra ID Protection sign-in risk detects risks in real-time and offline. A risky sign-in is an indicator for a sign-in attempt that might not have been performed by the legitimate owner of a user account. Note: While Identity Protection also provides two risk policies with limited conditions, Microsoft highly recommends setting up risk-based policies in Conditional Access as opposed to the \"legacy method\" for the following benefits: - Enhanced diagnostic data - Report-only mode integration - Graph API support - Use more Conditional Access attributes like sign-in frequency in the policy", + "Checks": [ + "entra_identity_protection_sign_in_risk_enabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft Entra ID Protection sign-in risk detects risks in real-time and offline. A risky sign-in is an indicator for a sign-in attempt that might not have been performed by the legitimate owner of a user account. Note: While Identity Protection also provides two risk policies with limited conditions, Microsoft highly recommends setting up risk-based policies in Conditional Access as opposed to the \"legacy method\" for the following benefits: - Enhanced diagnostic data - Report-only mode integration - Graph API support - Use more Conditional Access attributes like sign-in frequency in the policy", + "RationaleStatement": "Turning on the sign-in risk policy ensures that suspicious sign-ins are challenged for multi-factor authentication.", + "ImpactStatement": "When the policy triggers, the user will need MFA to access the account. In the case of a user who hasn't registered MFA on their account, they would be blocked from accessing their account. It is therefore recommended that the MFA registration policy be configured for all users who are a part of the Sign-in Risk policy.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Create a new policy by selecting New policy. o Under Users or agents (Preview) choose All users. o Under Target resources choose All resources (formerly 'All cloud apps'). - Under Exclude exclude any break-glass accounts. o Under Conditions choose Sign-in risk then Yes and check the risk level boxes High and Medium. o Under Grant click Grant access then select Require multifactor authentication. o Under Session select Sign-in Frequency and set to Every time. o Click Select. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify All users is included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify All resources (formerly 'All cloud apps') is selected. o Under Conditions verify Sign-in risk is set to Yes ensuring High and Medium are selected. o Under Grant verify grant Grant access is selected and Require multifactor authentication checked. o Under Session verify Sign-in Frequency is set to Every time. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where Conditions.SignInRiskLevels contains any string. 3. For each policy returned, verify the following criteria: o Conditions.Users.IncludeUsers is All o Conditions.Applications.IncludeApplications is All o Conditions.SignInRiskLevels contains high o Conditions.SignInRiskLevels contains medium o GrantControls.BuiltInControls contains mfa OR GrantControls.AuthenticationStrength.id is any id o SessionControls.SignInFrequency.IsEnabled is true o SessionControls.SignInFrequency.FrequencyInterval is everyTime o State is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually. Note: If the SignInRiskLevels array includes low, this still qualifies as compliant, as these enforcement levels are considered more strict. However, it must always include high and medium; omitting these levels would exclude users who are classified as such. Note 2: If GrantControls.BuiltInControls is block then the Grant and Session controls are considered satisfied, as this is considered a more strict enforcement of sign-in risk control.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default. It may be created from a Conditional Access template.", + "References": "https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-risk-feedback:https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks" + } + ] + }, + { + "Id": "5.2.2.8", + "Description": "Microsoft Entra ID Protection sign-in risk detects risks in real-time and offline. A risky sign-in is an indicator for a sign-in attempt that might not have been performed by the legitimate owner of a user account. Note: While Identity Protection also provides two risk policies with limited conditions, Microsoft highly recommends setting up risk-based policies in Conditional Access as opposed to the \"legacy method\" for the following benefits: - Enhanced diagnostic data - Report-only mode integration - Graph API support - Use more Conditional Access attributes like sign-in frequency in the policy", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E5 Level 2", + "AssessmentStatus": "Automated", + "Description": "Microsoft Entra ID Protection sign-in risk detects risks in real-time and offline. A risky sign-in is an indicator for a sign-in attempt that might not have been performed by the legitimate owner of a user account. Note: While Identity Protection also provides two risk policies with limited conditions, Microsoft highly recommends setting up risk-based policies in Conditional Access as opposed to the \"legacy method\" for the following benefits: - Enhanced diagnostic data - Report-only mode integration - Graph API support - Use more Conditional Access attributes like sign-in frequency in the policy", + "RationaleStatement": "Sign-in risk is determined at the time of sign-in and includes criteria across both real- time and offline detections for risk. Blocking sign-in to accounts that have risk can prevent undesired access from potentially compromised devices or unauthorized users.", + "ImpactStatement": "Sign-in risk is heavily dependent on detecting risk based on atypical behaviors. Due to this it is important to run this policy in a report-only mode to better understand how the organization's environment and user activity may influence sign-in risk before turning the policy on. Once it's understood what actions may trigger a medium or high sign-in risk event I.T. can then work to create an environment to reduce false positives. For example, employees might be required to notify security personnel when they intend to travel with intent to access work resources.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Create a new policy by selecting New policy. o Under Users or agents (Preview) include All users. o Under Target resources include All resources (formerly 'All cloud apps') and do not set any exclusions. - Under Exclude exclude any break-glass accounts. o Under Conditions choose Sign-in risk values of High and Medium and click Done. o Under Grant choose Block access and click Select. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify All users is included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify All resources (formerly 'All cloud apps') is selected with no exclusions. o Under Conditions verify Sign-in risk values of High and Medium are selected. o Under Grant verify Block access is selected. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where Conditions.SignInRiskLevels contains any string. 3. For each policy returned, verify the following criteria: o Conditions.Users.IncludeUsers is All o Conditions.Applications.IncludeApplications is All o Conditions.Applications.ExcludeApplications is null or empty o Conditions.SignInRiskLevels contains high o Conditions.SignInRiskLevels contains medium o GrantControls.BuiltInControls is block o State is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually. Note: If the SignInRiskLevels array includes low, this still qualifies as compliant, as these enforcement levels are considered more strict. However, it must always include high and medium; omitting these levels would exclude users who are classified as such.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default.", + "References": "https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks#risk-detections-mapped-to-riskeventtype" + } + ] + }, + { + "Id": "5.2.2.9", + "Description": "Conditional Access (CA) can be configured to enforce access based on the device's compliance status or whether it is Entra hybrid joined. Collectively this allows CA to classify devices as managed or unmanaged, providing more granular control over authentication policies. When using Require device to be marked as compliant, the device must pass checks configured in compliance policies defined within Microsoft Intune. Before these checks can be applied, the device must first be enrolled in Intune MDM. By selecting Require Microsoft Entra hybrid joined device this means the device must first be synchronized from an on-premises Active Directory to qualify for authentication. When configured to the recommended state below only one condition needs to be met for the user to authenticate from the device. This functions as an \"OR\" operator. The recommended state for authentication is: - Require device to be marked as compliant - Require Microsoft Entra hybrid joined device (optional for hybrid environments) - Require one of the selected controls", + "Checks": [ + "entra_managed_device_required_for_authentication" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Conditional Access (CA) can be configured to enforce access based on the device's compliance status or whether it is Entra hybrid joined. Collectively this allows CA to classify devices as managed or unmanaged, providing more granular control over authentication policies. When using Require device to be marked as compliant, the device must pass checks configured in compliance policies defined within Microsoft Intune. Before these checks can be applied, the device must first be enrolled in Intune MDM. By selecting Require Microsoft Entra hybrid joined device this means the device must first be synchronized from an on-premises Active Directory to qualify for authentication. When configured to the recommended state below only one condition needs to be met for the user to authenticate from the device. This functions as an \"OR\" operator. The recommended state for authentication is: - Require device to be marked as compliant - Require Microsoft Entra hybrid joined device (optional for hybrid environments) - Require one of the selected controls", + "RationaleStatement": "\"Managed\" devices are considered more secure because they often have additional configuration hardening enforced through centralized management such as Intune or Group Policy. These devices are also typically equipped with MDR/EDR, managed patching and alerting systems. As a result, they provide a safer environment for users to authenticate and operate from. This policy also ensures that attackers must first gain access to a compliant or trusted device before authentication is permitted, reducing the risk posed by compromised account credentials. When combined with other distinct Conditional Access (CA) policies, such as requiring multi-factor authentication, this adds one additional factor before authentication is permitted. Note: Avoid combining these two settings with other Grant settings in the same policy. In a single policy you can only choose between Require all the selected controls or Require one of the selected controls, which limits the ability to integrate this recommendation with others in this benchmark. CA policies function as an \"AND\" operator across multiple policies. The goal here is to both (Require MFA for all users) AND (Require device to be marked as compliant OR Require Microsoft Entra hybrid joined device).", + "ImpactStatement": "Unmanaged devices will not be permitted as a valid authenticator. As a result this may require the organization to mature their device enrollment and management. The following devices can be considered managed: - Entra hybrid joined from Active Directory - Entra joined and enrolled in Intune, with compliance policies - Entra registered and enrolled in Intune, with compliance policies If Guest or external users are collaborating with the organization, they must either be excluded or onboarded with a compliant device to authenticate. Failure to adequately survey the environment and test the Conditional Access (CA) policy in the Report-only state could result in access disruptions for these guest users.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Create a new policy by selecting New policy. o Under Users or agents (Preview) include All users. o Under Target resources include All resources (formerly 'All cloud apps'). - Under Exclude exclude any break-glass accounts. o Under Grant select Grant access. o Select the checkbox Require device to be marked as compliant. o Optionally, also select Require Microsoft Entra hybrid joined device if the organization uses hybrid joined devices. o Choose Require one of the selected controls. o Click Select at the bottom. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On. Note: Guest user accounts, if collaborating with the organization, should be considered when testing this policy.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify All users is included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify All resources (formerly 'All cloud apps') is selected. o Verify that only documented resource exclusions exist and that they are reviewed annually. o Under Grant verify that Require device to be marked as compliant is checked. o Under Grant verify that no other controls are checked except, optionally, Require Microsoft Entra hybrid joined device. o Verify Require one of the selected controls is selected. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where GrantControls.BuiltInControls contains compliantDevice or domainJoinedDevice. 3. For each policy returned, verify the following criteria: o Conditions.Users.IncludeUsers is All o Conditions.Applications.IncludeApplications is All o GrantControls.BuiltInControls contains compliantDevice o GrantControls.BuiltInControls does not contain any values other than compliantDevice and domainJoinedDevice o GrantControls.Operator is OR o State is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default.", + "References": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-grant#require-device-to-be-marked-as-compliant:https://learn.microsoft.com/en-us/entra/identity/devices/concept-hybrid-join:https://learn.microsoft.com/en-us/mem/intune/fundamentals/deployment-guide-enrollment" + } + ] + }, + { + "Id": "5.2.2.10", + "Description": "Conditional Access (CA) can be configured to enforce access based on the device's compliance status or whether it is Entra hybrid joined. Collectively, this allows CA to classify devices as managed or unmanaged, providing more granular control over whether a user can register security information from a device. When using Require device to be marked as compliant, the device must pass checks configured in compliance policies defined within Microsoft Intune. Before these checks can be applied, the device must first be enrolled in Intune MDM. By selecting Require Microsoft Entra hybrid joined device this means the device must first be synchronized from an on-premises Active Directory to qualify. When configured to the recommended state below only one condition needs to be met for the user to authenticate from the device. This functions as an \"OR\" operator. The recommended state for registering security information is: - Require device to be marked as compliant - Require Microsoft Entra hybrid joined device (optional for hybrid environments) - Require one of the selected controls", + "Checks": [ + "entra_managed_device_required_for_mfa_registration" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Conditional Access (CA) can be configured to enforce access based on the device's compliance status or whether it is Entra hybrid joined. Collectively, this allows CA to classify devices as managed or unmanaged, providing more granular control over whether a user can register security information from a device. When using Require device to be marked as compliant, the device must pass checks configured in compliance policies defined within Microsoft Intune. Before these checks can be applied, the device must first be enrolled in Intune MDM. By selecting Require Microsoft Entra hybrid joined device this means the device must first be synchronized from an on-premises Active Directory to qualify. When configured to the recommended state below only one condition needs to be met for the user to authenticate from the device. This functions as an \"OR\" operator. The recommended state for registering security information is: - Require device to be marked as compliant - Require Microsoft Entra hybrid joined device (optional for hybrid environments) - Require one of the selected controls", + "RationaleStatement": "Requiring registration on a managed device significantly reduces the risk of bad actors using stolen credentials to register security information. Accounts that are created but never registered with an MFA method are particularly vulnerable to this type of attack. Enforcing this requirement will both reduce the attack surface for fake registrations and ensure that legitimate users register using trusted devices which typically have additional security measures in place already.", + "ImpactStatement": "The organization will be required to have a mature device management process. New devices provided to users will need to be pre-enrolled in Intune, auto-enrolled, or be Entra hybrid joined. Otherwise, the user will be unable to complete registration, requiring additional resources from I.T. This could be more disruptive in remote worker environments where the MDM maturity is low. Users who do not yet have access to a managed device, such as new hires, users with lost or replaced devices, or users registering MFA methods on personal mobile devices - will be unable to satisfy the device compliance grant control. To address this, organizations should configure a Temporary Access Pass (TAP) policy and issue a one- time TAP to these users. A one-time TAP satisfies multifactor authentication requirements and allows the user to register security information from any device or location. B2B collaboration users (guest accounts) will also be blocked by this policy, as their devices are not managed in the resource tenant. Organizations should consider excluding All guest and external users from this policy. Alternatively, organizations that trust partner device compliance claims can configure this through cross-tenant access settings.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Create a new policy by selecting New policy. o Under Users or agents (Preview) include All users. o Under Target resources select User actions and check Register security information. - Under Exclude exclude any break-glass accounts. o Under Grant select Grant access. o Select the checkbox Require device to be marked as compliant. o Optionally, also select Require Microsoft Entra hybrid joined device if the organization uses hybrid joined devices. o Choose Require one of the selected controls. o Click Select at the bottom. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify All users is included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify User actions is selected with Register security information checked. o Under Grant verify that Require device to be marked as compliant is checked. o Under Grant verify that no other controls are checked except, optionally, Require Microsoft Entra hybrid joined device. o Verify Require one of the selected controls is selected. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where Conditions.Applications.IncludeUserActions contains urn:user:registersecurityinfo. 3. For each policy returned, verify the following criteria: o Conditions.Users.IncludeUsers is All o Conditions.Applications.IncludeUserActions is urn:user:registersecurityinfo o GrantControls.BuiltInControls contains compliantDevice o GrantControls.BuiltInControls does not contain any values other than compliantDevice and domainJoinedDevice o GrantControls.Operator is OR o State is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default.", + "References": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-grant#require-device-to-be-marked-as-compliant:https://learn.microsoft.com/en-us/entra/identity/devices/concept-hybrid-join:https://learn.microsoft.com/en-us/mem/intune/fundamentals/deployment-guide-enrollment:https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-cloud-apps#user-actions:https://docs.azure.cn/en-us/entra/identity/authentication/concept-authentication-strength-how-it-works#how-multiple-authentication-strength-policies-are-evaluated-for-registering-security-info" + } + ] + }, + { + "Id": "5.2.2.11", + "Description": "Sign-in frequency defines the time period before a user is asked to sign in again when attempting to access a resource. The Microsoft Entra ID default configuration for user sign-in frequency is a rolling window of 90 days. The recommended state is a Sign-in frequency of Every time for Microsoft Intune Enrollment Note: Microsoft accounts for a five-minute clock skew when 'every time' is selected in a conditional access policy, ensuring that users are not prompted more frequently than once every five minutes.", + "Checks": [ + "entra_intune_enrollment_sign_in_frequency_every_time" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Sign-in frequency defines the time period before a user is asked to sign in again when attempting to access a resource. The Microsoft Entra ID default configuration for user sign-in frequency is a rolling window of 90 days. The recommended state is a Sign-in frequency of Every time for Microsoft Intune Enrollment Note: Microsoft accounts for a five-minute clock skew when 'every time' is selected in a conditional access policy, ensuring that users are not prompted more frequently than once every five minutes.", + "RationaleStatement": "Intune Enrollment is considered a sensitive action and should be safeguarded. An attack path exists that allows for a bypass of device compliance Conditional Access rule. This could allow compromised credentials to be used through a newly registered device enrolled in Intune, enabling persistence and privilege escalation. Setting sign-in frequency to every time limits the timespan an attacker could use fresh credentials to enroll a new device to Intune.", + "ImpactStatement": "New users enrolling into Intune through an automated process may need to sign-in again if the enrollment process goes on for too long.", + "RemediationProcedure": "Note: If the Microsoft Intune Enrollment cloud app isn't available then it must be created. To add the app for new tenants, a Microsoft Entra administrator must create a service principal object, with app ID d4ebce55-015a-49b5-a083-c84d1797ae8c, in PowerShell or Microsoft Graph. To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Create a new policy by selecting New policy. o Under Users or agents (Preview) include All users. o Under Target resources select Resources (formerly cloud apps), choose Select resources and add Microsoft Intune Enrollment to the list. - Under Exclude exclude any break-glass accounts. o Under Grant select Grant access. o Check either Require multifactor authentication or Require authentication strength. o Under Session check Sign-in frequency and select Every time. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify All users is included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify Resources (formerly cloud apps) includes Microsoft Intune Enrollment. o Under Grant verify Require multifactor authentication or Require authentication strength is checked. o Under Session verify Sign-in frequency is set to Every time. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: Note: The Authentication Strength requirement is satisfied when any valid GUID is present in the authenticationStrength property of a matching policy. Because Authentication Strength configurations are inherently stronger than the built-in Require multifactor authentication control, the presence of a valid Authentication Strength also fulfills the MFA requirement for all users. 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where Conditions.Applications.IncludeApplications contains d4ebce55-015a-49b5-a083-c84d1797ae8c. 3. For each policy returned, verify the following criteria: o Conditions.Users.IncludeUsers is All o Conditions.Applications.IncludeApplications contains d4ebce55- 015a-49b5-a083-c84d1797ae8c o GrantControls.BuiltInControls contains mfa OR GrantControls.AuthenticationStrength.id is defined o SessionControls.SignInFrequency.IsEnabled is true o SessionControls.SignInFrequency.FrequencyInterval is everyTime o State is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default. Sign-in frequency defaults to 90 days.", + "References": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-session-lifetime#require-reauthentication-every-time:https://www.blackhat.com/eu-24/briefings/schedule/#unveiling-the-power-of-intune-leveraging-intune-for-breaking-into-your-cloud-and-on-premise-42176:https://www.glueckkanja.com/blog/security/2025/01/compliant-device-bypass-en/" + } + ] + }, + { + "Id": "5.2.2.12", + "Description": "The Microsoft identity platform supports the device authorization grant, which allows users to sign in to input-constrained devices such as a smart TV, IoT device, or a printer. To enable this flow, the device has the user visit a webpage in a browser on another device to sign in. Once the user signs in, the device is able to get access tokens and refresh tokens as needed. The recommended state is to Block access for Device code flow in Conditional Access.", + "Checks": [ + "entra_conditional_access_policy_device_code_flow_blocked" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "The Microsoft identity platform supports the device authorization grant, which allows users to sign in to input-constrained devices such as a smart TV, IoT device, or a printer. To enable this flow, the device has the user visit a webpage in a browser on another device to sign in. Once the user signs in, the device is able to get access tokens and refresh tokens as needed. The recommended state is to Block access for Device code flow in Conditional Access.", + "RationaleStatement": "Since August 2024, Microsoft has observed threat actors, such as Storm-2372, employing \"device code phishing\" attacks. These attacks deceive users into logging into productivity applications, capturing authentication tokens to gain further access to compromised accounts. To mitigate this specific attack, block authentication code flows and permit only those from devices within trusted environments, identified by specific IP addresses.", + "ImpactStatement": "Some administrative overhead will be required for stricter management of these devices. Since exclusions do not violate compliance, this feature can still be utilized effectively within a controlled environment.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Create a new policy by selecting New policy. o Under Users or agents (Preview) include All users. o Under Target resources > Resources (formerly cloud apps) include All resources (formerly 'All cloud apps'). - Under Exclude exclude any break-glass accounts. o Under Conditions > Authentication flows set Configure to Yes and check Device code flow. o Click Save. o Under Grant select Block access and click Select. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to `On", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify All users is included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify Resources (formerly cloud apps) includes All resources (formerly 'All cloud apps') o Under Conditions > Authentication flows verify Configure is set to Yes and Device code flow is checked. o Under Grant verify Block access is selected. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where Conditions.AuthenticationFlows.TransferMethods contains deviceCodeFlow. 3. For each policy returned, verify the following criteria: o Conditions.Users.IncludeUsers is All o Conditions.Applications.IncludeApplications is All o Conditions.AuthenticationFlows.TransferMethods contains deviceCodeFlow o GrantControls.BuiltInControls is block o State is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default. It may be present as a Microsoft-managed policy.", + "References": "https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-device-code:https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows:https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/:https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows#device-code-flow-policies" + } + ] + }, + { + "Id": "5.2.2.13", + "Description": "Sign-in frequency defines the time period before a user is asked to sign in again when attempting to access a resource. The Microsoft Entra ID default configuration for user sign-in frequency is a rolling window of 90 days. The recommended state for all users is to enforce periodic reauthentication for 7 days or less.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Sign-in frequency defines the time period before a user is asked to sign in again when attempting to access a resource. The Microsoft Entra ID default configuration for user sign-in frequency is a rolling window of 90 days. The recommended state for all users is to enforce periodic reauthentication for 7 days or less.", + "RationaleStatement": "A 7-day interval balances security and user experience by reducing the maximum lifespan of compromised credentials or stolen tokens without introducing excessive reauthentication prompts that can increase phishing susceptibility and user fatigue.", + "ImpactStatement": "Most users will not find weekly reauthentication requirements disruptive. Organizations with legacy applications, custom authentication workflows, or users relying on long-running sessions (such as shared or kiosk devices) may need to evaluate compatibility and apply appropriate exclusions to prevent user disruption.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Create a new policy by selecting New policy. o Under Users or agents (Preview) include All users. o Under Target resources verify Resources (formerly cloud apps) include All resources (formerly 'All cloud apps'). - Under Exclude exclude any break-glass accounts. o Under Session select Sign-in frequency and set Periodic reauthentication to 7 days or less. 4. Under Enable policy set it to Report-only. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria and is set to On: o Under Users or agents (Preview) verify All users is included. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify Resources (formerly cloud apps) includes All resources (formerly 'All cloud apps') o Under Session ensure Sign-in frequency is checked, and Periodic reauthentication is set to 7 days or less. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where SessionControls.SignInFrequency.IsEnabled is true 3. Filter out policies where Conditions.signInRiskLevels and Conditions.userRiskLevels have values defined, excluding these from the assessment. 4. For each policy returned, verify the following criteria: o Conditions.Users.IncludeUsers is All o Conditions.Applications.IncludeApplications is All o SessionControls.SignInFrequency.frequencyInterval is timeBased o SessionControls.SignInFrequency.type is days* o SessionControls.SignInFrequency.value is 7 (or less)* o State is enabled 5. Compliance is met when at least one policy is found to meet all the criteria listed above. 6. Verify that any exclusions are documented and reviewed annually. Note: Any SignInFrequency type and value combination is considered compliant as long as the reauthentication interval is less than or equal to 7 days. For example, a policy applied to all users that requires reauthentication every 20 hours would still meet the requirement.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default.", + "References": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-session-lifetime" + } + ] + }, + { + "Id": "5.2.2.14", + "Description": "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. The recommended state is to define at least one trusted, IP range named location.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "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. The recommended state is to define at least one trusted, IP range named location.", + "RationaleStatement": "Defining trusted source IP addresses or ranges enables organizations to better tailor and enforce Conditional Access policies based on whether authentication attempts originate from trusted or untrusted network locations. Users signing in from trusted IP ranges can be granted reduced access requirements or fewer authentication prompts, while users coming from untrusted or unknown locations may face stricter controls. Additionally, marking named locations as trusted improves the accuracy of Microsoft Entra ID Protection's risk evaluations. When a user authenticates from a trusted location, their sign-in risk is appropriately lowered, helping reduce false positives and ensuring that risk-based policies trigger only when truly necessary.", + "ImpactStatement": "Configuring named locations by country cannot designate those locations as trusted, which means Conditional Access policies cannot use the \"All trusted locations\" option and must instead rely on explicitly selecting locations. This increases the administrative effort needed to configure and maintain these policies and requires more thorough testing to prevent unintended authentication blocks. Because Conditional Access policies can fully prevent users from signing in to Entra ID if misconfigured, organizations should maintain a dedicated break-glass Global Administrator account that is excluded from all Conditional Access policies and secured with a strong passphrase and hardware-based authentication. This account exists solely to recover access if all other administrators are locked out.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Under Manage, click Named locations. 4. Click on IP ranges location to add a new location. 5. Enter a name for this location setting in the Name field. 6. Click on the + icon. 7. Add only a trusted IP Address Range in CIDR notation inside the text box that appears. 8. Click on the Add button. 9. Repeat steps 6 through 8 for each additional IP range. 10. Select the Mark as trusted location checkbox. 11. Once finished, click on Create. Note: There is no single prescribed method for applying a named location to a Conditional Access policy, as the correct configuration depends on the specific access control requirements. Implementers should have a clear understanding of how named locations function before applying them to production policies.", + "AuditProcedure": "To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Under Manage, click Named locations. 4. For each named location with a Location type of IP ranges, verify there is one with the following criteria: o Trusted is set to Yes. o At least one IP Range is defined 5. Compliance is met when at least one named location is found to meet all the criteria listed above. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/namedLocations?$filter=isof('microsoft.graph. ipNamedLocation') 2. For each named location returned, verify the following criteria: o isTrusted is true o ipRanges contains at least one ipv4 or ipv6 range 3. Compliance is met when at least one named location is found to meet all the criteria listed above.", + "AdditionalInformation": "", + "DefaultValue": "Named locations are not configured by default.", + "References": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-assignment-network:https://learn.microsoft.com/en-us/entra/id-protection/concept-risk-detection-types#locations:https://learn.microsoft.com/en-us/graph/api/resources/conditionalaccesspolicy?view=graph-rest-1.0" + } + ] + }, + { + "Id": "5.2.2.15", + "Description": "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. The recommended state is to configure at least one policy to block access from untrusted locations.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "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. The recommended state is to configure at least one policy to block access from untrusted locations.", + "RationaleStatement": "Using Conditional Access as a deny list at the tenant or subscription level enables an organization to block inbound and outbound traffic from geographic locations that fall outside its operational scope (e.g., customers, suppliers) or legal jurisdiction. Restricting access to only required regions significantly reduces unnecessary exposure to international threat actors, including advanced persistent threats (APTs), and helps maintain a more controlled and defensible security posture. Note: Because the selection of allowed or blocked locations is unique to each organization, this control does not prescribe specific countries or regions. Each organization should determine its geographic access requirements based on operational needs, regulatory obligations, and risk tolerance.", + "ImpactStatement": "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. CAUTION: If these policies are created without first auditing and testing the result, misconfiguration can potentially lock out administrators or create undesired access issues.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Create a new policy by selecting New policy. o Under Users or agents (Preview) include All users o Under Target resources include All resources (formerly 'All cloud apps'). - Under Exclude exclude any break-glass accounts. o Under Network set Configure to Yes: - Select Include, then add entries for untrusted locations that should be blocked - Select Exclude, then add entries for trusted locations that should be allowed 4. Under Access Controls, select Grant select Block Access. 5. Under Enable policy set it to Report-only. 6. Click Create. 7. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria: o Under Users or agents (Preview) verify All users is included o Verify that only documented user exclusions exist and that they are reviewed annually o Under Target resources verify All resources (formerly 'All cloud apps') is selected o Under Network verify Include> Selected networks and locations contains at least one untrusted location o Under Network verify Exclude contains trusted locations through either All trusted networks and locations or Selected networks and locations o Under Grant verify Block access is selected 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. For each policy returned, verify the following criteria: o conditions.users.includeUsers is All o conditions.applications.includeApplications is All o conditions.locations.includeLocations contains at least one GUID of at least one untrusted location. o conditions.locations.excludeLocations is AllTrusted OR contains at least one GUID of at least one trusted location. o grantControls.builtInControls is block o state is enabled 3. Compliance is met when at least one policy is found to meet all the criteria listed above. 4. Verify that any exclusions are documented and reviewed annually.", + "AdditionalInformation": "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.", + "DefaultValue": "This policy does not exist by default.", + "References": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-by-location:https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-report-only" + } + ] + }, + { + "Id": "5.2.2.16", + "Description": "Token Protection is a Conditional Access session control that attempts to reduce token replay attacks by ensuring only device bound sign-in session tokens, like Primary Refresh Tokens (PRTs), are accepted by Microsoft Entra ID when applications request access to protected resources. When a user registers a supported device with Microsoft Entra, a PRT is issued and cryptographically bound to that device. This binding ensures that even if a threat actor steals the token, it can't be used from another device. With Token Protection enforced, Microsoft Entra validates that only these bound sign-in session tokens are used by supported applications. The recommended state is to enforce Token Protection for Office 365 Exchange Online, Office 365 SharePoint Online and Microsoft Teams Services.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Token Protection is a Conditional Access session control that attempts to reduce token replay attacks by ensuring only device bound sign-in session tokens, like Primary Refresh Tokens (PRTs), are accepted by Microsoft Entra ID when applications request access to protected resources. When a user registers a supported device with Microsoft Entra, a PRT is issued and cryptographically bound to that device. This binding ensures that even if a threat actor steals the token, it can't be used from another device. With Token Protection enforced, Microsoft Entra validates that only these bound sign-in session tokens are used by supported applications. The recommended state is to enforce Token Protection for Office 365 Exchange Online, Office 365 SharePoint Online and Microsoft Teams Services.", + "RationaleStatement": "When properly configured, Conditional Access can aid in preventing attacks involving token theft, via hijacking or replay, as part of the attack flow. Although currently considered a rare event, the impact from token impersonation can be severe.", + "ImpactStatement": "Token Protection currently supports native applications only. Browser-based applications are not supported. There are also many other known limitations documented in the link below: https://learn.microsoft.com/en-us/entra/identity/conditional-access/deployment-guide- token-protection-windows#known-limitations", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Select New policy. 4. Select Users or agents (Preview): 1. Under Include, select the users or groups to apply this policy. 2. Under Exclude exclude any break-glass accounts. 5. Select Target resources > Resources > Include > Select resources 1. Under Select specific resources, select the following applications: 1. Office 365 Exchange Online 2. Office 365 SharePoint Online 3. Microsoft Teams Services 2. Choose Select 6. Select Conditions: 1. Under Device platforms 1. Set Configure to Yes. 2. Include > Select device platforms > Windows. 3. Select Done. 2. Under Client apps: 1. Set Configure to Yes 2. Under Modern authentication clients, only select Mobile apps and desktop clients. 3. Select Done 7. Under Access controls > Session, select Require token protection for sign-in sessions (Generally available for Windows. Preview for MacOS, iOS) and click Select. 8. Under Enable policy set it to Report-only. 9. Click Create. 10. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access and select Policies. 3. Verify that a policy exists with the following criteria: o Under Users or agents (Preview) verify that None is not selected. o Verify that only documented exclusions exist and that they are reviewed annually o Under Target resources select Select resources and verify at minimum the following are checked: - Office 365 Exchange Online - Office 365 SharePoint Online - Microsoft Teams Services 4. Under Conditions > Device Platforms: verify that Configure is set to Yes and Include indicates Windows platforms. 5. Under Conditions > Client Apps: verify that Configure is set to Yes and only Mobile Apps and Desktop Clients is selected. 6. Under Access controls > Session, verify that Require token protection for sign-in sessions (Generally available for Windows. Preview for MacOS, iOS) is selected. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where sessionControls.secureSignInSession.isEnabled is true. 3. For each policy returned, verify the following criteria: o conditions.users.includeUsers is not None o conditions.applications.includeApplications contains at least the following GUIDs: - 00000002-0000-0ff1-ce00-000000000000 (Office 365 Exchange Online) - 00000003-0000-0ff1-ce00-000000000000 (Office 365 SharePoint Online) - cc15fd57-2c6c-4117-a88c-83b1d56b4bbe (Microsoft Teams Services) o conditions.platforms.includePlatforms contains windows o conditions.clientAppTypes is mobileAppsAndDesktopClients o sessionControls.secureSignInSession.isEnabled is true o State is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default.", + "References": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection:https://learn.microsoft.com/en-us/entra/identity/conditional-access/deployment-guide-token-protection-windows:https://learn.microsoft.com/en-us/entra/identity/devices/protecting-tokens-microsoft-entra-id" + } + ] + }, + { + "Id": "5.2.2.17", + "Description": "Authentication transfer is a flow that lets users seamlessly transfer authenticated state from one device to another. For example, users might see a QR code in the desktop version of Outlook that, when scanned on their mobile device, transfers their authenticated state to the mobile device. The recommended state is to block Authentication transfer.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.2 Conditional Access", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Authentication transfer is a flow that lets users seamlessly transfer authenticated state from one device to another. For example, users might see a QR code in the desktop version of Outlook that, when scanned on their mobile device, transfers their authenticated state to the mobile device. The recommended state is to block Authentication transfer.", + "RationaleStatement": "Blocking authentication transfer helps protect against token theft and replay attacks by preventing the use of device tokens to silently authenticate on other devices or browsers. When authentication transfer is enabled, a threat actor who gains access to one device can access resources to unapproved devices, bypassing standard authentication and device compliance checks. When administrators block this flow, organizations can ensure that each authentication request must originate from the original device, maintaining the integrity of the device compliance and user session context.", + "ImpactStatement": "Users will no longer be able to use authentication transfer to sign into mobile versions of Microsoft apps (e.g., scanning a QR code in Outlook desktop to sign into Outlook mobile). Each device will require independent, interactive sign-in subject to applicable Conditional Access policies.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access. 3. Create a new policy by selecting New policy. o Under Users or agents (Preview) include All users. o Under Target resources > Resources (formerly cloud apps) include All resources (formerly 'All cloud apps'). - Under Exclude exclude any break-glass accounts. o Under Conditions > Authentication flows set Configure to Yes and check Authentication transfer. - Click Save. o Under Grant select Block access and click Select. 4. Under Enable policy set it to Report-only until the organization is ready to enable it. 5. Click Create. 6. After allowing the policy to run in Report-only mode for at least one week, review the Sign-in logs for any unexpected impact, then return to the policy and set Enable policy to On.", + "AuditProcedure": "Note: Break-glass accounts should be excluded from all Conditional Access policies. To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Conditional Access. 3. Verify that a policy exists with the following criteria: o Under Users or agents (Preview) verify All users is selected. o Verify that only documented user exclusions exist and that they are reviewed annually. o Under Target resources verify Resources (formerly cloud apps) includes All resources (formerly 'All cloud apps') o Under Conditions > Authentication flows verify Configure is set to Yes and Authentication transfer is checked. o Under Grant verify Block access is selected. 4. Verify that Enable policy is set to On. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identity/conditionalAccess/policies 2. Filter to policies where conditions.authenticationFlows.transferMethods contains authenticationTransfer. 3. For each policy returned, verify the following criteria: o conditions.users.includeUsers is All o conditions.applications.includeApplications is All o conditions.authenticationFlows.transferMethods contains authenticationTransfer o grantControls.builtInControls is block o state is enabled 4. Compliance is met when at least one policy is found to meet all the criteria listed above. 5. Verify that any exclusions are documented and reviewed annually.", + "AdditionalInformation": "", + "DefaultValue": "This policy does not exist by default.", + "References": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows#authentication-transfer-policies:https://learn.microsoft.com/en-us/entra/fundamentals/zero-trust-protect-identities#authentication-transfer-is-blocked:https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows:https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-transfer" + } + ] + }, + { + "Id": "5.2.3.1", + "Description": "Microsoft provides supporting settings to enhance the configuration of the Microsoft Authenticator application. These settings provide users with additional information and context when they receive MFA passwordless and push requests, including the geographic location of the request, the requesting application, and a requirement for number matching. The recommended state is Enabled for the following: - Show application name in push and passwordless notifications - Show geographic location in push and passwordless notifications Note: On February 27, 2023 Microsoft started enforcing number matching tenant-wide for all users using Microsoft Authenticator.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.3 Authentication Methods", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft provides supporting settings to enhance the configuration of the Microsoft Authenticator application. These settings provide users with additional information and context when they receive MFA passwordless and push requests, including the geographic location of the request, the requesting application, and a requirement for number matching. The recommended state is Enabled for the following: - Show application name in push and passwordless notifications - Show geographic location in push and passwordless notifications Note: On February 27, 2023 Microsoft started enforcing number matching tenant-wide for all users using Microsoft Authenticator.", + "RationaleStatement": "As the use of strong authentication has become more widespread, attackers have started to exploit the tendency of users to experience \"MFA fatigue.\" This occurs when users are repeatedly asked to provide additional forms of identification, leading them to eventually approve requests without fully verifying the source. To counteract this, number matching can be employed to ensure the security of the authentication process. With this method, users are prompted to confirm a number displayed on their original device and enter it into the device being used for MFA. Additionally, other information such as geolocation and application details are displayed to enhance the end user's awareness. Among these 3 options, number matching provides the strongest net security gain.", + "ImpactStatement": "Additional interaction will be required by end users using number matching as opposed to simply pressing \"Approve\" for login attempts.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Click to expand Entra ID > Authentication methods and select Policies. 3. Select Microsoft Authenticator 4. Under Enable and Target ensure the setting is set to Enable. 5. Select Configure 6. Set the following Microsoft Authenticator settings: o Show application name in push and passwordless notifications Status is set to Enabled, Target All users o Show geographic location in push and passwordless notifications Status is set to Enabled, Target All users Note: Valid groups such as break glass accounts can be excluded per organization policy.", + "AuditProcedure": "To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Authentication methods and select Policies. 3. Under Method select Microsoft Authenticator. 4. Under Enable and Target verify the setting is set to Enable. 5. In the Include tab verify that All users is selected. 6. In the Exclude tab verify only valid groups are present (i.e. Break Glass accounts). 7. Select Configure 8. Verify the following Microsoft Authenticator settings: o Show application name in push and passwordless notifications Status is set to Enabled, Target All users o Show geographic location in push and passwordless notifications Status is set to Enabled, Target All users 9. In each setting select Exclude and verify only valid groups are present (i.e. Break Glass accounts). To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/ microsoftAuthenticator 2. Verify that the state is enabled. 3. Verify that includeTargets.id is all_users. 4. Verify that the excludeTargets only includes valid groups (i.e. Break Glass accounts). 5. Under featureSettings verify the following settings: o displayAppInformationRequiredState.state is enabled o displayAppInformationRequiredState.includeTarget.id is all_users o displayLocationInformationRequiredState.state is enabled o displayLocationInformationRequiredState.includeTarget.id is all_users 6. In each setting excludeTarget only includes a valid group (i.e. Break Glass accounts) or a target id of 00000000-0000-0000-0000-000000000000 Note: Compliance cannot be easily validated for exclusions so adding these to a report for human manual review is recommended. These should be reviewed annually.", + "AdditionalInformation": "", + "DefaultValue": "Microsoft-managed", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-default-enablement:https://techcommunity.microsoft.com/t5/microsoft-entra-blog/defend-your-users-from-mfa-fatigue-attacks/ba-p/2365677:https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match:https://learn.microsoft.com/en-us/graph/api/authenticationmethodspolicy-get?view=graph-rest-1.0" + } + ] + }, + { + "Id": "5.2.3.2", + "Description": "With Entra Password Protection, default global banned password lists are automatically applied to all users in an Entra ID tenant. To support business and security needs, custom banned password lists can be defined. When users change or reset their passwords, these banned password lists are checked to enforce the use of strong passwords. A custom banned password list should include some of the following examples: - Brand names - Product names - Locations, such as company headquarters - Company-specific internal terms - Abbreviations that have specific company meaning", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.3 Authentication Methods", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "With Entra Password Protection, default global banned password lists are automatically applied to all users in an Entra ID tenant. To support business and security needs, custom banned password lists can be defined. When users change or reset their passwords, these banned password lists are checked to enforce the use of strong passwords. A custom banned password list should include some of the following examples: - Brand names - Product names - Locations, such as company headquarters - Company-specific internal terms - Abbreviations that have specific company meaning", + "RationaleStatement": "Creating a new password can be difficult regardless of one's technical background. It is common to look around one's environment for suggestions when building a password, however, this may include picking words specific to the organization as inspiration for a password. An adversary may employ what is called a 'mangler' to create permutations of these specific words in an attempt to crack passwords or hashes making it easier to reach their goal.", + "ImpactStatement": "If a custom banned password list includes too many common dictionary words, or short words that are part of compound words, then perfectly secure passwords may be blocked. The organization should consider a balance between security and usability when creating a list.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand Entra ID > Authentication methods and select Password protection. 3. Set Enforce custom list to Yes 4. In Custom banned password list create a list using suggestions outlined in this document. 5. Click Save Note: Below is a list of examples that can be used as a starting place. The references section contains more suggestions. - Brand names - Product names - Locations, such as company headquarters - Company-specific internal terms - Abbreviations that have specific company meaning", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand Entra ID > Authentication methods and select Password protection. 3. Verify that Enforce custom list is set to Yes 4. Verify that Custom banned password list contains entries specific to the organization or matches a pre-determined list. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Directory.Read.All\" 2. Run the following commands: $PwRuleSettings = '5cf42378-d67d-4f36-ba46-e8b86229381d' Get-MgGroupSetting | Where-Object TemplateId -eq $PwRuleSettings | Select-Object -ExpandProperty Values 3. Verify that EnableBannedPasswordCheck is True and BannedPasswordList is populated.", + "AdditionalInformation": "Organization-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 terms - Abbreviations that have specific company meaning - Months and weekdays with your company's local languages The default global banned password list 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 space Characters 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 - Symbols Note: 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. Evaluation New passwords are evaluated for strength and complexity by validating against the combined list of terms from the global and custom banned password lists. Even if a user's password contains a banned password, the password may be accepted if the overall password is otherwise strong enough.", + "DefaultValue": "By default the custom banned password list is not 'Enabled'.", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad#custom-banned-password-list:https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-configure-custom-password-protection:https://www.microsoft.com/en-us/research/publication/password-guidance/:https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-identity-management#im-6-use-strong-authentication-controls" + } + ] + }, + { + "Id": "5.2.3.3", + "Description": "Microsoft Entra Password Protection provides a global and custom banned password list. A password change request fails if there's a match in these banned password list. To protect on-premises Active Directory Domain Services (AD DS) environment, install and configure Entra Password Protection. Note: This recommendation applies to Hybrid deployments only and will have no impact unless working with on-premises Active Directory.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.3 Authentication Methods", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft Entra Password Protection provides a global and custom banned password list. A password change request fails if there's a match in these banned password list. To protect on-premises Active Directory Domain Services (AD DS) environment, install and configure Entra Password Protection. Note: This recommendation applies to Hybrid deployments only and will have no impact unless working with on-premises Active Directory.", + "RationaleStatement": "This feature protects an organization by prohibiting the use of weak or leaked passwords. In addition, organizations can create custom banned password lists to prevent their users from using easily guessed passwords that are specific to their industry. Deploying this feature to Active Directory will strengthen the passwords that are used in the environment.", + "ImpactStatement": "The potential impact associated with implementation of this setting is dependent upon the existing password policies in place in the environment. For environments that have strong password policies in place, the impact will be minimal. For organizations that do not have strong password policies in place, implementation of Microsoft Entra Password Protection may require users to change passwords and adhere to more stringent requirements than they have been accustomed to.", + "RemediationProcedure": "To remediate using the UI: - Download and install the Azure AD Password Proxies and DC Agents from the following location: https://www.microsoft.com/download/details.aspx?id=57071 After installed follow the steps below. 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Password protection. 3. Set Enable password protection on Windows Server Active Directory to Yes and Mode to Enforced.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Password protection. 3. Verify that Enable password protection on Windows Server Active Directory is set to Yes and that Mode is set to Enforced. To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Directory.Read.All\" 2. Run the following command: (Get-MgGroupSetting | ? { $_.TemplateId -eq '5cf42378-d67d-4f36-ba46- e8b86229381d' }).Values 3. Verify that EnableBannedPasswordCheckOnPremises is set to True and BannedPasswordCheckOnPremisesMode is set to Enforce.", + "AdditionalInformation": "", + "DefaultValue": "Enable - Yes Mode - Audit", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/howto-password-ban-bad-on-premises-operations" + } + ] + }, + { + "Id": "5.2.3.4", + "Description": "Microsoft defines Multifactor authentication capable as being registered and enabled for a strong authentication method. The method must also be allowed by the authentication methods policy. Ensure all member users are MFA capable.", + "Checks": [ + "entra_users_mfa_capable" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.3 Authentication Methods", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft defines Multifactor authentication capable as being registered and enabled for a strong authentication method. The method must also be allowed by the authentication methods policy. Ensure all member users are MFA capable.", + "RationaleStatement": "Multifactor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted. Users who are not MFA Capable have never registered a strong authentication method for multifactor authentication that is within policy and may not be using MFA. This could be a result of having never signed in, exclusion from a Conditional Access (CA) policy requiring MFA, or a CA policy does not exist. Reviewing this list of users will help identify possible lapses in policy or procedure.", + "ImpactStatement": "When using the UI audit method guest users will appear in the report and unless the organization is applying MFA rules to guests then they will need to be manually filtered. Accounts that provide on-premises directory synchronization also appear in these reports.", + "RemediationProcedure": "Remediation steps will depend on the status of the personnel in question or configuration of Conditional Access policies and will not be covered in detail. Administrators should review each user identified on a case-by-case basis using the conditions below. User has never signed on: - Employment status should be reviewed, and appropriate action taken on the user account's roles, licensing and enablement. Conditional Access policy applicability: - Ensure a CA policy is in place requiring all users to use MFA. - Ensure the user is not excluded from the CA MFA policy. - Ensure the policy's state is set to On. - Use What if to determine applicable CA policies. (Protection > Conditional Access > Policies) - Review the user account in Sign-in logs. Under the Activity Details pane click the Conditional Access tab to view applied policies. Note: Conditional Access is covered step by step in section 5.2.2", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select User registration details. 3. Set the filter option Multifactor authentication capable to Not Capable. 4. Review the non-guest users in this list. 5. Excluding any exceptions users found in this report may require remediation. To audit using PowerShell: 1. Connect to Graph using Connect-MgGraph -Scopes \"UserAuthenticationMethod.Read.All,AuditLog.Read.All\" 2. Run the following: Get-MgReportAuthenticationMethodUserRegistrationDetail ` -Filter \"IsMfaCapable eq false and UserType eq 'Member'\" | ft UserPrincipalName,IsMfaCapable,IsAdmin 3. Verify that IsMfaCapable is set to True. 4. Excluding any exceptions users found in this report may require remediation. Note: The CA rule must be in place for a successful deployment of Multifactor Authentication. This policy is outlined in the conditional access section 5.2.2 Note 2: Possible exceptions include on-premises synchronization accounts.", + "AdditionalInformation": "", + "DefaultValue": "", + "References": "https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.reports/update-mgreportauthenticationmethoduserregistrationdetail?view=graph-powershell-0#-ismfacapable:https://learn.microsoft.com/en-us/entra/identity/monitoring-health/how-to-view-applied-conditional-access-policies:https://learn.microsoft.com/en-us/entra/identity/conditional-access/what-if-tool:https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-methods-activity" + } + ] + }, + { + "Id": "5.2.3.5", + "Description": "Authentication methods support a wide variety of scenarios for signing in to Microsoft 365 resources. Some of these methods are inherently more secure than others but require more investment in time to get users enrolled and operational. SMS and Voice Call rely on telephony carrier communication methods to deliver the authenticating factor. The recommended state is to Disable these methods: - SMS - Voice Call", + "Checks": [ + "entra_authentication_method_sms_voice_disabled" + ], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.3 Authentication Methods", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Authentication methods support a wide variety of scenarios for signing in to Microsoft 365 resources. Some of these methods are inherently more secure than others but require more investment in time to get users enrolled and operational. SMS and Voice Call rely on telephony carrier communication methods to deliver the authenticating factor. The recommended state is to Disable these methods: - SMS - Voice Call", + "RationaleStatement": "Traditional MFA methods such as SMS codes, email-based OTPs, and push notifications are becoming less effective against today's attackers. Sophisticated phishing campaigns have demonstrated that second factors can be intercepted or spoofed. Attackers now exploit social engineering, man-in-the-middle tactics, and user fatigue (e.g., MFA bombing) to bypass these mechanisms. These risks are amplified in distributed, cloud-first organizations with hybrid workforces and varied device ecosystems. The SMS and Voice call methods are vulnerable to SIM swapping which could allow an attacker to gain access to your Microsoft 365 account.", + "ImpactStatement": "There may be increased administrative overhead in adopting more secure authentication methods depending on the maturity of the organization.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Policies. 3. Inspect each method that is out of compliance and remediate: o Click on the method to open it. o Change the Enable toggle to the off position. o Click Save. Note: If the save button remains greyed out after toggling a method off, then first turn it back on and then change the position of the Target selection (all users or select groups). Turn the method off again and save. This was observed to be a bug in the UI at the time this document was published. To remediate using Powershell: 1. Connect to Graph using Connect-MgGraph -Scopes \"Policy.ReadWrite.AuthenticationMethod\" 2. Run the following to disable both authentication methods: $params = @( @{ Id = \"Sms\"; State = \"disabled\" }, @{ Id = \"Voice\"; State = \"disabled\" } ) Update-MgPolicyAuthenticationMethodPolicy -AuthenticationMethodConfigurations $params", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Policies. 3. Verify that the following methods in the Enabled column are set to No. o Method: SMS o Method: Voice call To audit using Powershell: 1. Connect to Graph using Connect-MgGraph -Scopes \"Policy.Read.All\" 2. Run the following: (Get-MgPolicyAuthenticationMethodPolicy).AuthenticationMethodConfigurations 3. Verify that Sms and Voice are disabled.", + "AdditionalInformation": "", + "DefaultValue": "- SMS : Disabled - Voice Call : Disabled", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods-manage:https://learn.microsoft.com/en-us/security/zero-trust/sfi/phishing-resistant-mfa#context-and-problem:https://www.microsoft.com/en-us/microsoft-365-life-hacks/privacy-and-safety/what-is-sim-swapping" + } + ] + }, + { + "Id": "5.2.3.6", + "Description": "System-preferred multifactor authentication (MFA) prompts users to sign in by using the most secure method they registered. The user is prompted to sign-in with the most secure method according to the below order. The order of authentication methods is dynamic. It's updated by Microsoft as the security landscape changes, and as better authentication methods emerge. 1. Temporary Access Pass 2. Passkey (FIDO2) 3. Microsoft Authenticator notifications 4. External authentication methods 5. Time-based one-time password (TOTP) 6. Telephony 7. Certificate-based authentication The recommended state is Enabled.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.3 Authentication Methods", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "System-preferred multifactor authentication (MFA) prompts users to sign in by using the most secure method they registered. The user is prompted to sign-in with the most secure method according to the below order. The order of authentication methods is dynamic. It's updated by Microsoft as the security landscape changes, and as better authentication methods emerge. 1. Temporary Access Pass 2. Passkey (FIDO2) 3. Microsoft Authenticator notifications 4. External authentication methods 5. Time-based one-time password (TOTP) 6. Telephony 7. Certificate-based authentication The recommended state is Enabled.", + "RationaleStatement": "Regardless of the authentication method enabled by an administrator or set as preferred by the user, the system will dynamically select the most secure option available at the time of authentication. This approach acts as an additional safeguard to prevent the use of weaker methods, such as voice calls, SMS, and email OTPs, which may have been inadvertently left enabled due to misconfiguration or lack of configuration hardening. Enforcing the default behavior also ensures the feature is not disabled.", + "ImpactStatement": "The Microsoft managed value of system-preferred MFA is Enabled and as such enforces the default behavior. No additional impact is expected. Note: Due to known issues with certificate-based authentication (CBA) and system- preferred MFA, Microsoft moved CBA to the bottom of the list. It is still considered a strong authentication method.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Settings. 3. Set the System-preferred multifactor authentication State to Enabled and include All users. 4. Any users exclusions should be documented and reviewed annually.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Settings. 3. Verify the System-preferred multifactor authentication State is set to Enabled and All users are included. 4. Verify that only documented exclusions exist and that they are reviewed annually To audit using PowerShell: 1. Connect to Microsoft Graph using Connect-MgGraph -Scopes \"Policy.Read.AuthenticationMethod\" 2. Run the following commands: $Uri = 'https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy' (Invoke-MgGraphRequest -Method GET -Uri $Uri).systemCredentialPreferences 3. Verify that includeTargets is set to all_users and state is set to enabled.", + "AdditionalInformation": "", + "DefaultValue": "Microsoft Managed (Enabled)", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/concept-system-preferred-multifactor-authentication:https://learn.microsoft.com/en-us/entra/identity/authentication/concept-system-preferred-multifactor-authentication#how-does-system-preferred-mfa-determine-the-most-secure-method" + } + ] + }, + { + "Id": "5.2.3.7", + "Description": "Authentication methods support a wide variety of scenarios for signing in to Microsoft 365 resources. Some of these methods are inherently more secure than others but require more investment in time to get users enrolled and operational. The email one-time passcode feature is a way to authenticate B2B collaboration users when they can't be authenticated through other means, such as Microsoft Entra ID, Microsoft account (MSA), or social identity providers. When a B2B guest user tries to redeem your invitation or sign in to your shared resources, they can request a temporary passcode, which is sent to their email address. Then they enter this passcode to continue signing in. The recommended state is to Disable email OTP.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.3 Authentication Methods", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Authentication methods support a wide variety of scenarios for signing in to Microsoft 365 resources. Some of these methods are inherently more secure than others but require more investment in time to get users enrolled and operational. The email one-time passcode feature is a way to authenticate B2B collaboration users when they can't be authenticated through other means, such as Microsoft Entra ID, Microsoft account (MSA), or social identity providers. When a B2B guest user tries to redeem your invitation or sign in to your shared resources, they can request a temporary passcode, which is sent to their email address. Then they enter this passcode to continue signing in. The recommended state is to Disable email OTP.", + "RationaleStatement": "Traditional MFA methods such as SMS codes, email-based OTPs, and push notifications are becoming less effective against today's attackers. Sophisticated phishing campaigns have demonstrated that second factors can be intercepted or spoofed. Attackers now exploit social engineering, man-in-the-middle tactics, and user fatigue (e.g., MFA bombing) to bypass these mechanisms. These risks are amplified in distributed, cloud-first organizations with hybrid workforces and varied device ecosystems.", + "ImpactStatement": "Disabling Email OTP will prevent one-time pass codes from being sent to unverified guest users accessing Microsoft 365 resources on the tenant such as \"@yahoo.com\". They will be required to use a personal Microsoft account, a managed Microsoft Entra account, be part of a federation or be configured as a guest in the host tenant's Microsoft Entra ID.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Policies. 3. Click on Email OTP. 4. Change the Enable toggle to the off position\\ 5. Click Save. Note: If the save button remains greyed out after toggling a method off, then first turn it back on and then change the position of the Target selection (all users or select groups). Turn the method off again and save. This was observed to be a bug in the UI at the time this document was published. To remediate using Powershell: 1. Connect to Graph using Connect-MgGraph -Scopes \"Policy.ReadWrite.AuthenticationMethod\" 2. Run the following: $params = @( @{ Id = \"Email\"; State = \"disabled\" } ) Update-MgPolicyAuthenticationMethodPolicy -AuthenticationMethodConfigurations $params", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Policies. 3. Verify that Email OTP is set to No in the Enabled column. To audit using Powershell: 1. Connect to Graph using Connect-MgGraph -Scopes \"Policy.Read.All\" 2. Run the following: (Get-MgPolicyAuthenticationMethodPolicy).AuthenticationMethodConfigurations 3. Verify the id type Email is set to disabled.", + "AdditionalInformation": "", + "DefaultValue": "- Email OTP : Enabled", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods-manage:https://learn.microsoft.com/en-us/entra/external-id/one-time-passcode:https://learn.microsoft.com/en-us/security/zero-trust/sfi/phishing-resistant-mfa#context-and-problem" + } + ] + }, + { + "Id": "5.2.3.8", + "Description": "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. The recommended Lockout threshold is 10 or less.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.3 Authentication Methods", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "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. The recommended Lockout threshold is 10 or less.", + "RationaleStatement": "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.", + "ImpactStatement": "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. In hybrid environments using pass-through authentication (PTA), the Microsoft Entra lockout threshold must be set lower than the AD DS account lockout threshold. If the AD DS threshold is equal to or lower than the Entra threshold, AD DS will lock the account before Entra smart lockout activates, bypassing the cloud-side protection and resulting in on-premises account lockouts that require manual administrator intervention to clear. Microsoft recommends configuring the AD DS lockout threshold to be at least two to three times greater than the Entra lockout threshold.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Password protection. 3. Set Lockout threshold to 10 or less. Note: In hybrid environments using pass-through authentication (PTA), Microsoft recommends to configure the AD DS account lockout threshold to be at least two to three times greater than the value set here to ensure Entra smart lockout activates before AD DS lockout.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Password protection. 3. Verify that Lockout threshold is set to 10 or less. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/groupSettings 2. Filter to Password Rule settings, where templateId is 5cf42378-d67d-4f36- ba46-e8b86229381d 3. Verify that LockoutThreshold is 10 or less.", + "AdditionalInformation": "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.", + "DefaultValue": "By default, Lockout threshold is set to 10.", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/howto-password-smart-lockout#manage-microsoft-entra-smart-lockout-values:https://learn.microsoft.com/en-us/graph/api/group-list-settings?view=graph-rest-0" + } + ] + }, + { + "Id": "5.2.3.9", + "Description": "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. The recommended state is Lockout duration in seconds is at least 60.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.3 Authentication Methods", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "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. The recommended state is Lockout duration in seconds is at least 60.", + "RationaleStatement": "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.", + "ImpactStatement": "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. In hybrid environments using pass-through authentication (PTA), the Microsoft Entra lockout duration must be set longer than the AD DS account lockout duration. Note that Entra lockout duration is configured in seconds while AD DS lockout duration is configured in minutes; verify the units when comparing the two values to ensure Entra smart lockout expires after AD DS lockout.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Password protection. 3. Set the Lockout duration in seconds to 60 or higher. 4. Click Save. Note: In hybrid environments using pass-through authentication (PTA), ensure the AD DS account lockout duration is shorter than the value set here. The Entra lockout duration is configured in seconds while AD DS lockout duration is configured in minutes; account for the unit difference when comparing the two values.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Authentication methods and select Password protection. 3. Verify that Lockout duration in seconds is set to 60 or higher. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/groupSettings 2. Filter to Password Rule settings, where templateId is 5cf42378-d67d-4f36- ba46-e8b86229381d 3. Verify that LockoutDurationInSeconds is greater than or equal to 60.", + "AdditionalInformation": "", + "DefaultValue": "By default, Lockout duration in seconds is set to 60.", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/howto-password-smart-lockout#manage-microsoft-entra-smart-lockout-values:https://learn.microsoft.com/en-us/graph/api/group-list-settings?view=graph-rest-0" + } + ] + }, + { + "Id": "5.2.3.10", + "Description": "Microsoft Entra ID includes a feature called Authenticator Lite, which embeds a subset of Microsoft Authenticator functionality into companion applications such as Outlook mobile. When enabled, users can satisfy MFA requirements using push notifications or time-based one-time passcodes (TOTP) directly from the companion application without installing the standalone Microsoft Authenticator app. The recommended state is Microsoft Authenticator on companion applications set to Disabled.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.3 Authentication Methods", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft Entra ID includes a feature called Authenticator Lite, which embeds a subset of Microsoft Authenticator functionality into companion applications such as Outlook mobile. When enabled, users can satisfy MFA requirements using push notifications or time-based one-time passcodes (TOTP) directly from the companion application without installing the standalone Microsoft Authenticator app. The recommended state is Microsoft Authenticator on companion applications set to Disabled.", + "RationaleStatement": "Authenticator Lite does not support application name or geographic location context in push notifications, regardless of tenant-wide Authenticator feature settings. These are key defenses against MFA fatigue attacks that are only available in the full Microsoft Authenticator app. Authenticator Lite also does not satisfy Conditional Access authentication strength requirements, does not support passwordless authentication, and does not support SSPR via push notifications. Disabling this feature ensures users authenticate through the full Microsoft Authenticator app where all available security protections are active.", + "ImpactStatement": "Users who have registered Authenticator Lite as their only MFA method will be unable to complete MFA until they install and register the standalone Microsoft Authenticator app. Administrators should communicate this change in advance and verify that affected users have registered an alternative MFA method before disabling this feature to avoid authentication lockouts.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Authentication methods and select Policies. 3. Under Method select Microsoft Authenticator. 4. Select Configure. 5. Set Microsoft Authenticator on companion applications: Status to Disabled. 6. Select Save.", + "AuditProcedure": "To audit using the UI: 1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com. 2. Expand Entra ID > Authentication methods and select Policies. 3. Under Method select Microsoft Authenticator. 4. Select Configure. 5. Verify that Microsoft Authenticator on companion applications: Status is set to Disabled. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/ microsoftAuthenticator 2. Verify that featureSettings.companionAppAllowedState.state is disabled.", + "AdditionalInformation": "", + "DefaultValue": "Microsoft managed (enabled as of June 26, 2023)", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-authenticator-lite:https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-default-enablement:https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-additional-context" + } + ] + }, + { + "Id": "5.2.4.1", + "Description": "Enabling self-service password reset allows users to reset their own passwords in Entra ID. When users sign in to Microsoft 365, they will be prompted to enter additional contact information that will help them reset their password in the future. If combined registration is enabled additional information, outside of multi-factor, will not be needed. The recommended state is All. Note: Effective Oct. 1st, 2022, Microsoft will begin to enable combined registration for all users in Entra ID tenants created before August 15th, 2020. Tenants created after this date are enabled with combined registration by default.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.4 Password reset", + "Profile": "E3 Level 1", + "AssessmentStatus": "Manual", + "Description": "Enabling self-service password reset allows users to reset their own passwords in Entra ID. When users sign in to Microsoft 365, they will be prompted to enter additional contact information that will help them reset their password in the future. If combined registration is enabled additional information, outside of multi-factor, will not be needed. The recommended state is All. Note: Effective Oct. 1st, 2022, Microsoft will begin to enable combined registration for all users in Entra ID tenants created before August 15th, 2020. Tenants created after this date are enabled with combined registration by default.", + "RationaleStatement": "Enabling Self-Service Password Reset (SSPR) significantly reduces helpdesk interactions, streamlining support operations and improving user experience. Traditional methods involving temporary passwords pose notable security risks-they are often weak, predictable, and susceptible to interception. This creates a window of opportunity for threat actors to compromise accounts before users can update their credentials. SSPR minimizes credential exposure and strengthens overall identity protection.", + "ImpactStatement": "Users will be required to provide additional contact information in order to enroll in SSPR. Some light user education may be necessary, particularly for individuals who are accustomed to contacting the help desk for password reset assistance. In hybrid environments, SSPR writeback must be enabled before users are able to reset their passwords through self-service.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Password reset and select Properties. 3. Set Self service password reset enabled to All", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Password reset and select Properties. 3. Verify that Self service password reset enabled is set to All", + "AdditionalInformation": "", + "DefaultValue": "", + "References": "https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/let-users-reset-passwords?view=o365-worldwide:https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr:https://learn.microsoft.com/en-us/entra/identity/authentication/howto-registration-mfa-sspr-combined:https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-writeback" + } + ] + }, + { + "Id": "5.2.4.2", + "Description": "Ensures that two alternate forms of identification are provided before allowing a password reset. The recommended state is Number of methods required to reset set to 2.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.4 Password reset", + "Profile": "E3 Level 2", + "AssessmentStatus": "Manual", + "Description": "Ensures that two alternate forms of identification are provided before allowing a password reset. The recommended state is Number of methods required to reset set to 2.", + "RationaleStatement": "Requiring Multi-factor Authentication (MFA) for Self-service Password Reset (SSPR) strengthens the password reset process by confirming the user's identity with two separate methods of authentication. With multiple methods required for password reset, an attacker would have to compromise multiple authentication methods before resetting a user's password.", + "ImpactStatement": "If multiple methods are required for password reset and a user has lost access to other authentication methods, the resetting user will need an administrator with permissions to remove the lost authentication method. Policy and training are recommended to teach administrators to verify the identity of the requesting user so that social engineering is not an effective vector of compromise. If multifactor authentication is not currently enabled for all users, users with only one registered form of authentication will not be able to reset their passwords through SSPR until another form of authentication is registered. If multifactor authentication is already enabled for all users, the impact of this recommendation should be minimal.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Password reset and select Authentication methods. 3. Set the Number of methods required to reset to 2 4. Click Save", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Password reset and select Authentication methods. 3. Verify that Number of methods required to reset is set to 2", + "AdditionalInformation": "", + "DefaultValue": "By default, the Number of methods required to reset is 1.", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr:https://learn.microsoft.com/en-us/entra/identity/authentication/concept-registration-mfa-sspr-combined:https://support.microsoft.com/en-us/account-billing/reset-your-work-or-school-password-using-security-info-23dde81f-08bb-4776-ba72-e6b72b9dda9e:https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods" + } + ] + }, + { + "Id": "5.2.4.3", + "Description": "The Require users to register when signing in? setting controls whether users are prompted to register their self-service password reset (SSPR) authentication methods at their next sign-in. When set to Yes, users who have not yet registered are prompted to do so upon signing in. The Number of days before users are asked to re-confirm their authentication information setting designates the period of time before registered users are prompted to re-confirm their existing authentication information is still valid, up to a maximum of 730 days. If set to 0 days, registered users will never be prompted to re-confirm their authentication information.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.4 Password reset", + "Profile": "E3 Level 1", + "AssessmentStatus": "Manual", + "Description": "The Require users to register when signing in? setting controls whether users are prompted to register their self-service password reset (SSPR) authentication methods at their next sign-in. When set to Yes, users who have not yet registered are prompted to do so upon signing in. The Number of days before users are asked to re-confirm their authentication information setting designates the period of time before registered users are prompted to re-confirm their existing authentication information is still valid, up to a maximum of 730 days. If set to 0 days, registered users will never be prompted to re-confirm their authentication information.", + "RationaleStatement": "Without requiring users to register, users may never establish SSPR authentication methods, rendering the re-confirmation setting ineffective regardless of the value it is set to. When users do register authentication methods for self-service password reset (SSPR), those methods may become stale over time as phone numbers, email addresses, or other contact information changes. If re-confirmation is disabled, outdated recovery information persists indefinitely. An attacker who gains access to a former phone number or email address associated with a user's account can exploit that stale recovery information to reset the user's password and take over the account. Requiring registration and periodic re-confirmation ensures that the authentication methods on record remain accurate and under the user's control.", + "ImpactStatement": "Because both settings default to the compliant state, organizations that have not altered them will experience no impact. Re-enabling registration prompts unregistered users to register at their next sign-in; re-enabling re-confirmation prompts registered users to verify their information on the configured interval. Organizations with large user populations and short re-confirmation intervals should expect increased SSPR support volume.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Password reset and select Registration. 3. Set Require users to register when signing in? to Yes. 4. Set Number of days before users are asked to re-confirm their authentication information to any organization-approved value other than 0. 5. Click Save.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Password reset and select Registration. 3. Verify that Require users to register when signing in? is set to Yes. 4. Verify that Number of days before users are asked to re-confirm their authentication information is not set to 0.", + "AdditionalInformation": "", + "DefaultValue": "- Require users to register when signing in?: Yes - Number of days before users are asked to re-confirm their authentication information: 180", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-howitworks#registration:https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods" + } + ] + }, + { + "Id": "5.2.4.4", + "Description": "This setting determines whether or not users receive an email to their primary and alternate email addresses notifying them when their own password has been reset via the Self-Service Password Reset portal. The recommended state is Notify users on password resets? is set to Yes.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.4 Password reset", + "Profile": "E3 Level 1", + "AssessmentStatus": "Manual", + "Description": "This setting determines whether or not users receive an email to their primary and alternate email addresses notifying them when their own password has been reset via the Self-Service Password Reset portal. The recommended state is Notify users on password resets? is set to Yes.", + "RationaleStatement": "User notification on password reset is a proactive way of confirming password reset activity. It helps the user to recognize unauthorized password reset activities.", + "ImpactStatement": "Users will receive emails alerting them to password changes to both their primary and alternate emails.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Password reset and select Notifications. 3. Set Notify users on password resets? to Yes 4. Click Save.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Password reset and select Notifications. 3. Verify that Notify users on password resets? is set to Yes.", + "AdditionalInformation": "", + "DefaultValue": "Yes", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr#set-up-notifications-and-customizations:https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-howitworks#notifications:https://support.microsoft.com/en-us/account-billing/reset-your-work-or-school-password-using-security-info-23dde81f-08bb-4776-ba72-e6b72b9dda9e" + } + ] + }, + { + "Id": "5.2.4.5", + "Description": "This setting determines whether or not all global administrators receive an email to their primary email address when other administrators reset their own passwords via the Self-Service Password Reset Portal. The recommended state is Notify all admins when other admins reset their password? is set to Yes.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.2.4 Password reset", + "Profile": "E3 Level 1", + "AssessmentStatus": "Manual", + "Description": "This setting determines whether or not all global administrators receive an email to their primary email address when other administrators reset their own passwords via the Self-Service Password Reset Portal. The recommended state is Notify all admins when other admins reset their password? is set to Yes.", + "RationaleStatement": "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.", + "ImpactStatement": "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.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Password reset and select Notifications. 3. Set Notify all admins when other admins reset their password? to Yes 4. Click Save", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Password reset and select Notifications. 3. Verify that Notify all admins when other admins reset their password? is set to Yes", + "AdditionalInformation": "", + "DefaultValue": "No", + "References": "https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-howitworks#notifications:https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr#set-up-notifications-and-customizations" + } + ] + }, + { + "Id": "5.3.1", + "Description": "Microsoft Entra Privileged Identity Management (PIM) provides just-in-time (JIT) activation workflows for privileged Entra ID and Microsoft 365 roles, enabling time- bound access with approval and justification requirements. Rather than holding permanent role assignments, users are made eligible for a role and must explicitly activate it when needed. PIM supports requiring multi-factor authentication at activation, mandatory justification, approval workflows, and configurable activation durations.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.3 ID Governance", + "Profile": "E5 Level 2", + "AssessmentStatus": "Automated", + "Description": "Microsoft Entra Privileged Identity Management (PIM) provides just-in-time (JIT) activation workflows for privileged Entra ID and Microsoft 365 roles, enabling time- bound access with approval and justification requirements. Rather than holding permanent role assignments, users are made eligible for a role and must explicitly activate it when needed. PIM supports requiring multi-factor authentication at activation, mandatory justification, approval workflows, and configurable activation durations.", + "RationaleStatement": "Permanent active role assignments expose privileged access continuously, regardless of whether a user is actively performing administrative tasks. If a permanently privileged account is compromised, an attacker immediately holds full role permissions with no time boundary. PIM eliminates standing privilege by requiring users to explicitly activate role assignments, scoping elevated access to a defined duration and requiring justification and, optionally, approval. This reduces the window of opportunity for both external attackers and insider threats to exploit privileged access.", + "ImpactStatement": "The implementation of Just in Time privileged access is likely to necessitate changes to administrator routine. Administrators will only be granted access to administrative roles when required. When administrators request role activation, they will need to document the reason for requiring role access, anticipated time required to have the access, and to reauthenticate to enable role access. Note: If all global admins become eligible then there will be no global admin to receive notifications, by default. Alerts are sent to TenantAdmins, including Global Administrators, by default. To ensure proper receipt, configure alerts to be sent to security or operations staff with valid email addresses or a security operations center. Otherwise, after adoption of this recommendation, alerts sent to TenantAdmins may go unreceived due to the lack of a licensed permanently active Global Administrator.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Roles & admins and select All roles. 3. For each user or group role assignment that is out of compliance: o Click on the role to open it in PIM. o Select the Active assignments tab. o Under action click Update or Remove. - If Update is selected, set the Assignment type to Eligible and click Save. - If Remove is selected, the assignment will be removed and the principal will no longer hold the role. 4. For each privileged role with a non-compliant service principal active assignment: 1. Open the Active assignments tab. 2. Click Update to modify the service principal assignment. 3. Uncheck Permanently assigned and set an appropriate end time to create a time-bound assignment based on business needs. 4. Click Save to apply the changes. 5. Repeat for any other privileged role assignments that are out of compliance. Note: CIS Safeguard 6.8, Define and Maintain Role-Based Access Control, recommends reviewing access on a recurring schedule, at least annually and more frequently as needed. This practice is strongly encouraged for service principals when defining time-bound assignments.", + "AuditProcedure": "Note: There is no programmatic way to reliably determine whether a principal is a designated break-glass account. Global Administrator assignments require manual review and judgment to confirm that any permanent assignments belong exclusively to the organization's two approved break-glass accounts. To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand Entra ID > Roles & admins and select All roles. 3. Select Add filters and apply the Privileged filter to scope the review to built- in and custom privileged roles. 4. For each PRIVILEGED role that has one or more assignments, perform the following review of active assignments: 1. Select the role to open it. 2. Open the Active assignments tab. 3. For each assignment where Type is User or Group, verify that State is Activated. - A State of Assigned is permitted only for approved break-glass accounts assigned to the Global Administrator role, and no more than 2 such accounts may hold this permanent assignment. 4. For each assignment where Type is Service principal, verify that State is Assigned and an End time is designated. 5. Compliance is met when all privileged role assignments meet the verification requirements in step 4. Usage of PIM for management of other administrator roles is recommended but not required for compliance. To audit using Microsoft Graph API: 1. Execute a GET request to the following relative URI to retrieve privileged roles (custom or built-in): beta/roleManagement/directory/roleDefinitions?$filter=isPrivileged eq true&$select=id,displayName,isPrivileged,isBuiltIn,isEnabled 2. Execute a GET request to the following relative URI to retrieve all instances of active role assignments: v1.0/roleManagement/directory/roleAssignmentScheduleInstances?$expand=princip al 3. Correlate by matching each assignment instance's roleDefinitionId to the privileged role list's id to produce a list of privileged role assignment instances. 4. For each privileged role assignment instance, verify the appropriate condition for the principal type: o For users and groups (principal@odata.type is #microsoft.graph.user or #microsoft.graph.group), verify that assignmentType is Activated. An assignmentType of Assigned is permitted only for approved break-glass accounts assigned to the Global Administrator role, and no more than 2 such accounts may hold this permanent assignment. o For service principals (principal@odata.type is #microsoft.graph.servicePrincipal), verify that assignmentType is Assigned and endDateTime is defined (time-bound assignment). 5. Compliance is met when all privileged role assignments meet the verification requirements in step 4. Usage of PIM for management of other administrator roles is recommended but not required for compliance.", + "AdditionalInformation": "In addition to enforcing just-in-time activation for active privileged role assignments, organizations are encouraged to periodically review eligible PIM role assignments to confirm ongoing business justification and remove stale entries. Annual review at minimum is recommended. This is a governance process that requires manual judgment and is outside the scope of the automated compliance check for this recommendation.", + "DefaultValue": "Without Privileged Identity Management configured, all privileged role assignments are permanent active assignments with no expiration or activation requirement.", + "References": "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure" + } + ] + }, + { + "Id": "5.3.2", + "Description": "Access reviews enable administrators to establish an efficient automated process for reviewing group memberships, access to enterprise applications, and role assignments. These reviews can be scheduled to recur regularly, with flexible options for delegating the task of reviewing membership to different members of the organization. When configured for guest users, access reviews can automatically remove access if no reviewer responds within the review period, enforcing a fail-closed posture for external identities.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.3 ID Governance", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "Access reviews enable administrators to establish an efficient automated process for reviewing group memberships, access to enterprise applications, and role assignments. These reviews can be scheduled to recur regularly, with flexible options for delegating the task of reviewing membership to different members of the organization. When configured for guest users, access reviews can automatically remove access if no reviewer responds within the review period, enforcing a fail-closed posture for external identities.", + "RationaleStatement": "Access to groups and applications for guests can change over time. If a guest user's access to a particular resource goes unnoticed, they may unintentionally gain access to sensitive data if a member adds new files or data to the resource. Access reviews can help reduce the risks associated with outdated assignments by requiring a member of the organization to conduct the reviews. Furthermore, these reviews can enable a fail- closed mechanism to remove access to the subject if the reviewer does not respond to the review.", + "ImpactStatement": "Legitimate guest users may lose access to resources if designated reviewers fail to respond within the review window, requiring re-invitation and re-provisioning of access. Organizations with a large number of Microsoft 365 groups may face significant reviewer workload from monthly review cycles, which can lead to approval fatigue. - Microsoft Entra ID Governance licensing (included in Microsoft 365 E5) is required to configure access reviews. - As of January 15, 2026, a linked Azure subscription is required to use Entra ID Governance features for guest users.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand ID Governance and select Access reviews 3. Click New access review. 4. In the Resource review box click Select. 5. In Review Type set the following: o Select what to review choose Teams + Groups. o Review Scope to All Microsoft 365 groups with guest users. o Scope to Guest users only then click Next: Reviews. 6. In Reviews set the following: o Select reviewers to Group members or Selected users and groups, ensuring that at least one reviewer is assigned and that the guest is not performing a self-review. o Duration (in days) to 14 days or less. o Review recurrence to Monthly or more frequent. o Start date for the review, ensuring the review becomes active before the next audit date. o End to Never, then click Next: Settings. 7. In Settings set the following: o Auto apply results to resource is checked. o If reviewers don't respond to Remove access o Justification required is checked. o E-mail notifications is checked. o Reminders is checked. o Click Next: Review + Create 8. Click Create. To remediate using the Microsoft Graph API: To create a new access review, execute a POST request to the following relative URI. To update an existing review, execute a PATCH request to the same URI appended with the review's id: v1.0/identityGovernance/accessReviews/definitions The request body must include properties that satisfy the audit criteria above. The Graph API documentation provides complete sample request bodies in multiple languages including HTTP, PowerShell, and Python. See Reference 3 for details.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand ID Governance and select Access reviews 3. Inspect the access reviews, and verify an access review is created with the following criteria: o Overview: Scope is set to Guest users only and Review status is Active o Reviewers: At least one reviewer is assigned, and the reviewer is not a guest user. o Settings > General: - Mail notifications is set to Enable - Reminders is set to Enable o Settings > Reviewers: - Require reason on approval is set to Enable o Settings > Scheduling: - Frequency is set to Monthly or more frequent - Duration (in days) does not exceed 14 days - End is set to Never o Settings > When completed: - Auto apply results to resource is set to Enable - If reviewers don't respond is set to Remove access 4. The control is compliant if there is at least one access review for guests that meets all criteria above. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identityGovernance/accessReviews/definitions 2. Apply the following filters to identify access reviews targeting guest users: o scope.resourceScopes.query matches the pattern userType eq 'Guest' OR o scope.query matches the pattern userType eq 'Guest' 3. For each review that passes the filters above, verify the following criteria: o Recurrence is configured as monthly or more frequent: - recurrence.pattern.type is absoluteMonthly OR - recurrence.pattern.type is weekly o reviewers is not empty o settings.mailNotificationsEnabled is true o settings.instanceDurationInDays is 14 days or less o settings.reminderNotificationsEnabled is true o settings.justificationRequiredOnApproval is true o settings.autoApplyDecisionsEnabled is true o settings.defaultDecision is Deny o settings.recurrence.range.type is noEnd 4. The control is compliant if there is at least one access review for guests that meets all criteria above.", + "AdditionalInformation": "", + "DefaultValue": "By default access reviews are not configured.", + "References": "https://learn.microsoft.com/en-us/entra/id-governance/access-reviews-overview:https://learn.microsoft.com/en-us/entra/id-governance/create-access-review:https://learn.microsoft.com/en-us/graph/api/resources/accessreviewscheduledefinition?view=graph-rest-1.0" + } + ] + }, + { + "Id": "5.3.3", + "Description": "Access reviews in Microsoft Entra Privileged Identity Management (PIM) enable administrators to periodically validate whether users still require their privileged role assignments. These reviews can be scheduled to recur on a regular cadence and can be delegated to reviewers other than the role holders themselves, such as security auditors.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.3 ID Governance", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "Access reviews in Microsoft Entra Privileged Identity Management (PIM) enable administrators to periodically validate whether users still require their privileged role assignments. These reviews can be scheduled to recur on a regular cadence and can be delegated to reviewers other than the role holders themselves, such as security auditors.", + "RationaleStatement": "Regular review of critical high privileged roles in Entra ID will help identify role drift, or potential malicious activity. This will enable the practice and application of \"separation of duties\" where even non-privileged users like security auditors can be assigned to review assigned roles in an organization. These reviews can optionally be configured to automatically remove access if a reviewer does not respond within the review window, though this recommendation conservatively sets non-response to result in no change to avoid inadvertent removal of privileged accounts including break-glass accounts.", + "ImpactStatement": "In order to avoid disruption reviewers who have the authority to revoke roles should be trusted individuals who understand the significance of access reviews. Additionally, the principle of separation of duties should be applied to ensure that no administrator is responsible for reviewing their own access levels. This will cause additional administrative overhead. If the reviews are configured to automatically revoke highly privileged roles like the Global Administrator role, then this could result in removing all Global Administrators from the organization. Care should be taken when configuring this setting especially in the case of break-glass accounts which would be included in the scope. - Microsoft Entra ID Governance licensing (included in Microsoft 365 E5) is required to configure access reviews.", + "RemediationProcedure": "Note: An access review is created for each role selected after completing the process. To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand ID Governance > Privileged Identity Management. 3. Select Microsoft Entra Roles under Manage. 4. Select Access reviews and click New. o Provide a name and description. o Set Frequency to Monthly or more frequently. o Set Duration (in days) to at most 14. o Set End to Never. o Set Users scope to All users and groups. o In Role select the directory roles outlined in the Additional Information section. o Set Assignment type to All active and eligible assignments. o Set Reviewers to member(s) responsible for this type of review, other than self. 5. In Upon completion settings set the following: o Auto apply results to resource to Enable. o If reviewers don't respond to No change. 6. In Advanced settings set the following: o Require reason on approval to Enable o Mail notifications to Enable o Reminders to Enable 7. Click Start to save and begin the review series. Warning: Care should be taken when configuring the If reviewers don't respond setting for Global Administrator reviews, if misconfigured break-glass accounts could automatically have roles revoked. Additionally, reviewers should be educated on the purpose of break-glass accounts to prevent accidental manual removal of roles. To remediate using the Microsoft Graph API: To create a new access review, execute a POST request to the following relative URI. To update an existing review, execute a PATCH request to the same URI appended with the review's id: v1.0/identityGovernance/accessReviews/definitions The request body must include properties that satisfy the audit criteria above. The Graph API documentation provides complete sample request bodies in multiple languages including HTTP, PowerShell, and Python. See Reference 3 for details", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/ 2. Expand ID Governance > Privileged Identity Management. 3. Select Microsoft Entra Roles under Manage. 4. Select Access reviews 5. For each privileged role listed in the Additional Information section, verify an access review exists that meets the following criteria: o Overview: - Role assignment type is set to Eligible and Active - Scope is set to Everyone - Review status is Active o Reviewers: At least one reviewer is assigned, and the reviewer is not self- reviewing. o Settings > General: - Mail notifications is set to Enable - Reminders is set to Enable o Settings > Reviewers: - Require reason on approval is set to Enable o Settings > Scheduling: - Frequency is set to Monthly or more frequently - Duration (in days) does not exceed 14 days - End is set to Never o Settings > When completed: - Auto apply results to resource is set to Enable - If reviewers don't respond is set to No change To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI: v1.0/identityGovernance/accessReviews/definitions 2. Apply the following filters to identify relevant access review definitions: o scope.resourceScopes.query matches the pattern /directory/roleDefinitions/ o scope.resourceScopes.query matches the GUID of one of the 6 privileged directory roles outlined in the Additional Information section. 3. For each review that passes the filters above, verify the following criteria: o Scoped to Eligible and Active role assignments: - scope.principalScopes.query contains /v1.0/users AND - scope.principalScopes.query contains /v1.0/groups o Recurrence is configured as monthly or more frequent: - recurrence.pattern.type is absoluteMonthly OR - recurrence.pattern.type is weekly - recurrence.range.startDate is in the past relative to the audit date o reviewers is not empty o settings.mailNotificationsEnabled is true o settings.reminderNotificationsEnabled is true o settings.justificationRequiredOnApproval is true o settings.instanceDurationInDays is less than or equal to 14 o settings.autoApplyDecisionsEnabled is true o settings.defaultDecision is None 4. The control is compliant when all 6 privileged directory roles have an associated access review definition that meets all the criteria listed above. Note: The 6 roles referenced and their associated GUIDs can be found in the Additional Information section.", + "AdditionalInformation": "The 6 privileged directory roles referenced in the audit and remediation procedures and their associated GUIDs are as follows: Role Name Role Definition GUID Global Administrator 62e90394-69f5-4237-9190-012177145e10 Privileged Role Administrator e8611ab8-c189-46e8-94e1-60213ab1f814 Exchange Administrator 29232cdf-9323-42fd-ade2-1d097af3e4de SharePoint Administrator f28a1f50-f6e7-4571-818b-6a12f2af6b6c Teams Administrator 69091246-20e8-4a56-aa4d-066075b2a7a8 Security Administrator 194ae4cb-b126-40b2-bd5b-6091b380977d", + "DefaultValue": "By default access reviews are not configured.", + "References": "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-create-roles-and-resource-roles-review:https://learn.microsoft.com/en-us/entra/id-governance/access-reviews-overview:https://learn.microsoft.com/en-us/graph/api/resources/accessreviewscheduledefinition?view=graph-rest-1.0" + } + ] + }, + { + "Id": "5.3.4", + "Description": "Microsoft Entra Privileged Identity Management can be used to audit roles, allow just in time activation of roles and allow for periodic role attestation. Requiring approval before activation allows one of the selected approvers to first review and then approve the activation prior to PIM granted the role. The approver doesn't have to be a group member or owner. The recommended state is Require approval to activate for the Global Administrator role.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.3 ID Governance", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft Entra Privileged Identity Management can be used to audit roles, allow just in time activation of roles and allow for periodic role attestation. Requiring approval before activation allows one of the selected approvers to first review and then approve the activation prior to PIM granted the role. The approver doesn't have to be a group member or owner. The recommended state is Require approval to activate for the Global Administrator role.", + "RationaleStatement": "Requiring approval for Global Administrator role activation enhances visibility and accountability every time this highly privileged role is used. This process reduces the risk of an attacker elevating a compromised account to the highest privilege level, as any activation must first be reviewed and approved by a trusted party. Note: This only acts as protection for eligible users that are activating a role. Directly assigning a role does not require an approval workflow so therefore it is important to implement and use PIM correctly.", + "ImpactStatement": "Approvers do not need to be assigned the same role or be members of the same group. It's important to have at least two approvers and an emergency access (break-glass) account to prevent a scenario where no Global Administrators are available. For example, if the last active Global Administrator leaves the organization, and only eligible but inactive Global Administrators remain, a trusted approver without the Global Administrator role or an emergency access account would be essential to avoid delays in critical administrative tasks.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand ID Governance > Privileged Identity Management. 3. Under Manage select Microsoft Entra Roles. 4. Under Manage select Roles. 5. Select Global Administrator in the list. 6. Select Role settings and click Edit. 7. Check the Require approval to activate box. 8. Add at least one approver. 9. Click Update.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand ID Governance > Privileged Identity Management. 3. Under Manage select Microsoft Entra Roles. 4. Under Manage select Roles. 5. Select Global Administrator in the list. 6. Select Role settings. 7. Verify that Require approval to activate is set to Yes. 8. Verify there is at least 1 approvers in the list. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI to retrieve the policyID for the Global Administrator-role: v1.0/policies/roleManagementPolicyAssignments?$filter=scopeId eq '/' and scopeType eq 'DirectoryRole' and roleDefinitionId eq '62e90394-69f5-4237- 9190-012177145e10'&$select=policyId 2. Execute a GET request to the following relative URI to retrieve the policy's Approval setting using the policyId from the previous call: v1.0/policies/roleManagementPolicies/{policyID}/rules/Approval_EndUser_Assign ment # Example https://graph.microsoft.com/v1.0/policies/roleManagementPolicies/DirectoryRol e_9c4d49a8-1f7a-4256-b1a2-b7cb0e7180f4_86522f3f-cfd0-4634-95a0- 38083127ca00/rules/Approval_EndUser_Assignment 3. Verify that isApprovalRequired is true. 4. Verify that approvalStages.primaryApprovers contains one or more valid users. Note: Approvers should be reviewed on a regular basis to ensure the members are active and valid.", + "AdditionalInformation": "", + "DefaultValue": "Require approval to activate : No.", + "References": "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure:https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/groups-role-settings#require-approval-to-activate" + } + ] + }, + { + "Id": "5.3.5", + "Description": "Microsoft Entra Privileged Identity Management can be used to audit roles, allow just in time activation of roles and allow for periodic role attestation. Requiring approval before activation allows one of the selected approvers to first review and then approve the activation prior to PIM granted the role. The approver doesn't have to be a group member or owner. The recommended state is Require approval to activate for the Privileged Role Administrator role.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Microsoft Entra admin center", + "SubSection": "5.3 ID Governance", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "Microsoft Entra Privileged Identity Management can be used to audit roles, allow just in time activation of roles and allow for periodic role attestation. Requiring approval before activation allows one of the selected approvers to first review and then approve the activation prior to PIM granted the role. The approver doesn't have to be a group member or owner. The recommended state is Require approval to activate for the Privileged Role Administrator role.", + "RationaleStatement": "This role grants the ability to manage assignments for all Microsoft Entra roles including the Global Administrator role. This role does not include any other privileged abilities in Microsoft Entra ID like creating or updating users. However, users assigned to this role can grant themselves or others additional privilege by assigning additional roles. Requiring approval for activation enhances visibility and accountability every time this highly privileged role is used. This process reduces the risk of an attacker elevating a compromised account to the highest privilege level, as any activation must first be reviewed and approved by a trusted party. Note: This only acts as protection for eligible users that are activating a role. Directly assigning a role does not require an approval workflow so therefore it is important to implement and use PIM correctly.", + "ImpactStatement": "Requiring approvers for automatic role assignment can slightly increase administrative overhead and add delays to tasks.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand ID Governance > Privileged Identity Management. 3. Under Manage select Microsoft Entra Roles. 4. Under Manage select Roles. 5. Select Privileged Role Administrator in the list. 6. Select Role settings and click Edit. 7. Check the Require approval to activate box. 8. Add at least one approver. 9. Click Update.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Entra admin center https://entra.microsoft.com/. 2. Expand ID Governance > Privileged Identity Management. 3. Under Manage select Microsoft Entra Roles. 4. Under Manage select Roles. 5. Select Privileged Role Administrator in the list. 6. Select Role settings. 7. Verify Require approval to activate is set to Yes. 8. Verify there is at least one approvers in the list. To audit using the Microsoft Graph API: 1. Execute a GET request to the following relative URI to retrieve the policyID for the Privileged Role Administrator-role: v1.0/policies/roleManagementPolicyAssignments?$filter=scopeId eq '/' and scopeType eq 'DirectoryRole' and roleDefinitionId eq 'e8611ab8-c189-46e8- 94e1-60213ab1f814'&$select=policyId 2. Execute a GET request to the following relative URI to retrieve the policy's Approval setting using the policyId from the previous call: v1.0/policies/roleManagementPolicies/{policyID}/rules/Approval_EndUser_Assign ment # Example https://graph.microsoft.com/v1.0/policies/roleManagementPolicies/DirectoryRol e_d1fdbf46-5729-4c53-a951-7ab677be380f_3679e0d0-412a-444d-b517- ab23973d6067/rules/Approval_EndUser_Assignment 3. Verify that isApprovalRequired is true. 4. Verify that approvalStages.primaryApprovers contains one or more valid users. Note: Approvers should be reviewed on a regular basis to ensure the members are active and valid.", + "AdditionalInformation": "", + "DefaultValue": "Require approval to activate : No.", + "References": "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure:https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/groups-role-settings#require-approval-to-activate" + } + ] + }, + { + "Id": "6.1.1", + "Description": "The value False indicates that mailbox auditing on by default is turned on for the organization. Mailbox auditing on by default in the organization overrides the mailbox auditing settings on individual mailboxes. For example, if mailbox auditing is turned off for a mailbox (the AuditEnabled property on the mailbox is False), the default mailbox actions are still audited for the mailbox, because mailbox auditing on by default is turned on for the organization. Turning off mailbox auditing on by default ($true) has the following results: - Mailbox auditing is turned off for your organization. - From the time you turn off mailbox auditing on by default, no mailbox actions are audited, even if mailbox auditing is enabled on a mailbox (the AuditEnabled property on the mailbox is True). - Mailbox auditing isn't turned on for new mailboxes and setting the AuditEnabled property on a new or existing mailbox to True is ignored. - Any mailbox audit bypass association settings (configured by using the Set- MailboxAuditBypassAssociation cmdlet) are ignored. - Existing mailbox audit records are retained until the audit log age limit for the record expires. The recommended state for this setting is False at the organization level. This will enable auditing and enforce the default.", + "Checks": [ + "exchange_organization_mailbox_auditing_enabled" + ], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.1 Audit", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "The value False indicates that mailbox auditing on by default is turned on for the organization. Mailbox auditing on by default in the organization overrides the mailbox auditing settings on individual mailboxes. For example, if mailbox auditing is turned off for a mailbox (the AuditEnabled property on the mailbox is False), the default mailbox actions are still audited for the mailbox, because mailbox auditing on by default is turned on for the organization. Turning off mailbox auditing on by default ($true) has the following results: - Mailbox auditing is turned off for your organization. - From the time you turn off mailbox auditing on by default, no mailbox actions are audited, even if mailbox auditing is enabled on a mailbox (the AuditEnabled property on the mailbox is True). - Mailbox auditing isn't turned on for new mailboxes and setting the AuditEnabled property on a new or existing mailbox to True is ignored. - Any mailbox audit bypass association settings (configured by using the Set- MailboxAuditBypassAssociation cmdlet) are ignored. - Existing mailbox audit records are retained until the audit log age limit for the record expires. The recommended state for this setting is False at the organization level. This will enable auditing and enforce the default.", + "RationaleStatement": "Enforcing the default ensures auditing was not turned off intentionally or accidentally. Auditing mailbox actions will allow forensics and IR teams to trace various malicious activities that can generate TTPs caused by inbox access and tampering.", + "ImpactStatement": "None - this is the default behavior as of 2019.", + "RemediationProcedure": "To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-OrganizationConfig -AuditDisabled $false", + "AuditProcedure": "To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-OrganizationConfig | Format-List AuditDisabled 3. Verify that AuditDisabled is set to False.", + "AdditionalInformation": "", + "DefaultValue": "False", + "References": "https://learn.microsoft.com/en-us/purview/audit-mailboxes?view=o365-worldwide:https://learn.microsoft.com/en-us/powershell/module/exchange/set-organizationconfig?view=exchange-ps#-auditdisabled" + } + ] + }, + { + "Id": "6.1.2", + "Description": "Mailbox audit logging is turned on by default in all organizations. This effort started in January 2019, and means that certain actions performed by mailbox owners, delegates, and admins are automatically logged. The corresponding mailbox audit records are available for admins to search in the mailbox audit log. Mailboxes and shared mailboxes have actions assigned to them individually in order to audit the data the organization determines valuable at the mailbox level. The recommended state per mailbox is AuditEnabled to True including all default audit actions with additional actions outlined below in the audit and remediation sections. Note: Audit (Standard) licensing allows for up to 180 days log retention as of October 2023.", + "Checks": [ + "exchange_user_mailbox_auditing_enabled" + ], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.1 Audit", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Mailbox audit logging is turned on by default in all organizations. This effort started in January 2019, and means that certain actions performed by mailbox owners, delegates, and admins are automatically logged. The corresponding mailbox audit records are available for admins to search in the mailbox audit log. Mailboxes and shared mailboxes have actions assigned to them individually in order to audit the data the organization determines valuable at the mailbox level. The recommended state per mailbox is AuditEnabled to True including all default audit actions with additional actions outlined below in the audit and remediation sections. Note: Audit (Standard) licensing allows for up to 180 days log retention as of October 2023.", + "RationaleStatement": "Whether it is for regulatory compliance or for tracking unauthorized configuration changes in Microsoft 365, enabling mailbox auditing and ensuring the proper mailbox actions are accounted for allows for Microsoft 365 teams to run security operations, forensics or general investigations on mailbox activities. The following mailbox types ignore the organizational default and must have AuditEnabled set to True at the mailbox level in order to capture relevant audit data. - Resource Mailboxes - Public Folder Mailboxes - DiscoverySearch Mailbox", + "ImpactStatement": "Adding additional audit action types and increasing the AuditLogAgeLimit from 90 to 180 days will have a limited impact on mailbox storage. Mailbox audit log records are stored in a subfolder (named Audits) in the Recoverable Items folder in each user's mailbox. - Mailbox audit records count against the storage quota of the Recoverable Items folder. - Mailbox audit records also count against the folder limit for the Recoverable Items folder. A maximum of 3 million items (audit records) can be stored in the Audits subfolder. The following cmdlet in Exchange Online PowerShell can be run to display the size and number of items in the Audits subfolder in the Recoverable Items folder: Get-MailboxFolderStatistics -Identity -FolderScope RecoverableItems | Where-Object {$_.Name -eq 'Audits'} | Format-List FolderPath,FolderSize,ItemsInFolder Note: It's unlikely that mailbox auditing on by default impacts the storage quota or the folder limit for the Recoverable Items folder.", + "RemediationProcedure": "For each UserMailbox ensure AuditEnabled is True and the following audit actions are included in addition to default actions of each sign-in type. - Admin actions: Copy, FolderBind and Move. - Delegate actions: FolderBind and Move. - Owner actions: Create, MailboxLogin and Move. Note: The defaults can be found in the Default Value section and the combined total can be found in the scripts of the Audit/Remediation sections. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell script to remediate every 'UserMailbox' in the organization: $AuditAdmin = @( \"ApplyRecord\", \"Copy\", \"Create\", \"FolderBind\", \"HardDelete\", \"MailItemsAccessed\", \"Move\", \"MoveToDeletedItems\", \"SendAs\", \"SendOnBehalf\", \"Send\", \"SoftDelete\", \"Update\", \"UpdateCalendarDelegation\", \"UpdateFolderPermissions\", \"UpdateInboxRules\" ) $AuditDelegate = @( \"ApplyRecord\", \"Create\", \"FolderBind\", \"HardDelete\", \"Move\", \"MailItemsAccessed\", \"MoveToDeletedItems\", \"SendAs\", \"SendOnBehalf\", \"SoftDelete\", \"Update\", \"UpdateFolderPermissions\", \"UpdateInboxRules\" ) $AuditOwner = @( \"ApplyRecord\", \"Create\", \"HardDelete\", \"MailboxLogin\", \"Move\", \"MailItemsAccessed\", \"MoveToDeletedItems\", \"Send\", \"SoftDelete\", \"Update\", \"UpdateCalendarDelegation\", \"UpdateFolderPermissions\", \"UpdateInboxRules\" ) $MBX = Get-EXOMailbox -ResultSize Unlimited | Where-Object { $_.RecipientTypeDetails -eq \"UserMailbox\" } $MBX | Set-Mailbox -AuditEnabled $true ` -AuditLogAgeLimit 180 -AuditAdmin $AuditAdmin -AuditDelegate $AuditDelegate ` -AuditOwner $AuditOwner 3. The script will apply the prescribed Audit Actions for each sign-in type (Owner, Delegate, Admin) and the AuditLogAgeLimit to each UserMailbox in the organization. Note: Mailboxes with Audit (Premium) licenses, which is included with E5, can retain audit logs beyond 180 days.", + "AuditProcedure": "Inspect each UserMailbox and ensure AuditEnabled is True and the following audit actions are included in addition to default actions of each sign-in type. - Admin actions: Copy, FolderBind and Move. - Delegate actions: FolderBind and Move. - Owner actions: Create, MailboxLogin and Move. Note: The defaults can be found in the Default Value section and the combined total can be found in the scripts of the Audit/Remediation sections. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell script: $AdminActions = @( \"ApplyRecord\", \"Copy\", \"Create\", \"FolderBind\", \"HardDelete\", \"MailItemsAccessed\", \"Move\", \"MoveToDeletedItems\", \"SendAs\", \"SendOnBehalf\", \"Send\", \"SoftDelete\", \"Update\", \"UpdateCalendarDelegation\", \"UpdateFolderPermissions\", \"UpdateInboxRules\" ) $DelegateActions = @( \"ApplyRecord\", \"Create\", \"FolderBind\", \"HardDelete\", \"Move\", \"MailItemsAccessed\", \"MoveToDeletedItems\", \"SendAs\", \"SendOnBehalf\", \"SoftDelete\", \"Update\", \"UpdateFolderPermissions\", \"UpdateInboxRules\" ) $OwnerActions = @( \"ApplyRecord\", \"Create\", \"HardDelete\", \"MailboxLogin\", \"Move\", \"MailItemsAccessed\", \"MoveToDeletedItems\", \"Send\", \"SoftDelete\", \"Update\", \"UpdateCalendarDelegation\", \"UpdateFolderPermissions\", \"UpdateInboxRules\" ) function VerifyActions { param ( [array]$ExpectedActions, [array]$ActualActions ) $Missing = $ExpectedActions | Where-Object { $_ -notin $ActualActions } return $Missing } $MBX = Get-EXOMailbox -PropertySets Audit, Minimum -ResultSize Unlimited | Where-Object { $_.RecipientTypeDetails -eq \"UserMailbox\" } $Results = foreach ($mailbox in $MBX) { $AdminMissing = VerifyActions -ExpectedActions $AdminActions ` -ActualActions $mailbox.AuditAdmin $DelegateMissing = VerifyActions -ExpectedActions $DelegateActions ` -ActualActions $mailbox.AuditDelegate $OwnerMissing = VerifyActions -ExpectedActions $OwnerActions ` -ActualActions $mailbox.AuditOwner $IsCompliant = $AdminMissing.Count -eq 0 -and $DelegateMissing.Count -eq 0 -and $OwnerMissing.Count -eq 0 -and $mailbox.AuditEnabled [PSCustomObject]@{ Mailbox = $mailbox.UserPrincipalName AuditEnabled = $mailbox.AuditEnabled AdminMissing = if ($AdminMissing.Count -gt 0) { $AdminMissing -join \", \" } else { \"None\" } DelegateMissing = if ($DelegateMissing.Count -gt 0) { $DelegateMissing -join \", \" } else { \"None\" } OwnerMissing = if ($OwnerMissing.Count -gt 0) { $OwnerMissing -join \", \" } else { \"None\" } ComplianceState = if ($IsCompliant) { \"Compliant\" } else { \"Non-Compliant\" } } } # Display results in table format $Results | Format-Table -AutoSize <# Optional: Export methods $Results | Out-GridView -Title \"Mailbox Audit Results\" $Results | Export-Csv -Path \"6.1.2.csv\" -NoTypeInformation $Results | ConvertTo-Json | Out-File -FilePath \"6.1.2.json\" #> 3. Inspect the results. Mailboxes will be labeled as either Compliant or Non- compliant, accompanied by supporting details that outline the missing actions for each type and the current state of AuditEnabled. Optional methods for exporting the data to CSV, JSON, or GridView are also shown at the end of the script. Note: Mailboxes with Audit (Premium) licenses, which is included with E5, can retain audit logs beyond 180 days.", + "AdditionalInformation": "", + "DefaultValue": "AuditEnabled: True for all mailboxes except below: - Resource Mailboxes - Public Folder Mailboxes - DiscoverySearch Mailbox AuditAdmin: ApplyRecord, Create, HardDelete, MailItemsAccessed, MoveToDeletedItems, Send, SendAs, SendOnBehalf, SoftDelete, Update, UpdateCalendarDelegation, UpdateFolderPermissions, UpdateInboxRules AuditDelegate: ApplyRecord, Create, HardDelete, MailItemsAccessed, MoveToDeletedItems, SendAs, SendOnBehalf, SoftDelete, Update, UpdateFolderPermissions, UpdateInboxRules AuditOwner: ApplyRecord, HardDelete, MailItemsAccessed, MoveToDeletedItems, Send, SoftDelete, Update, UpdateCalendarDelegation, UpdateFolderPermissions, UpdateInboxRules", + "References": "https://learn.microsoft.com/en-us/purview/audit-mailboxes?view=o365-worldwide" + } + ] + }, + { + "Id": "6.1.3", + "Description": "When configuring a user or computer account to bypass mailbox audit logging, the system will not record any access, or actions performed by the said user or computer account on any mailbox. Administratively this was introduced to reduce the volume of entries in the mailbox audit logs on trusted user or computer accounts. Ensure AuditBypassEnabled is not enabled on accounts without a written exception.", + "Checks": [ + "exchange_mailbox_audit_bypass_disabled" + ], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.1 Audit", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "When configuring a user or computer account to bypass mailbox audit logging, the system will not record any access, or actions performed by the said user or computer account on any mailbox. Administratively this was introduced to reduce the volume of entries in the mailbox audit logs on trusted user or computer accounts. Ensure AuditBypassEnabled is not enabled on accounts without a written exception.", + "RationaleStatement": "If a mailbox audit bypass association is added for an account, the account can access any mailbox in the organization to which it has been assigned access permissions, without generating any mailbox audit logging entries for such access or recording any actions taken, such as message deletions. Enabling this parameter, whether intentionally or unintentionally, could allow insiders or malicious actors to conceal their activity on specific mailboxes. Ensuring proper logging of user actions and mailbox operations in the audit log will enable comprehensive incident response and forensics.", + "ImpactStatement": "None - this is the default behavior.", + "RemediationProcedure": "To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. The following example PowerShell script will disable AuditBypass for all mailboxes which currently have it enabled: # Get mailboxes with AuditBypassEnabled set to $true $MBXAudit = Get-MailboxAuditBypassAssociation -ResultSize unlimited | Where- Object { $_.AuditBypassEnabled -eq $true } foreach ($mailbox in $MBXAudit) { $mailboxName = $mailbox.Name Set-MailboxAuditBypassAssociation -Identity $mailboxName - AuditBypassEnabled $false Write-Host \"Audit Bypass disabled for mailbox Identity: $mailboxName\" - ForegroundColor Green }", + "AuditProcedure": "To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: $MBXData = Get-MailboxAuditBypassAssociation -ResultSize unlimited $Report = $MBXData | ? {$_.AuditBypassEnabled -eq $true} | select Name,AuditBypassEnabled $Report <# Optional: Export methods $Report | Out-GridView -Title \"Mailbox Audit Bypass Association\" $Report | Export-Csv -Path \"6.1.3.csv\" -NoTypeInformation #> 3. If nothing is returned, then there are no accounts with Audit Bypass enabled. Note: The cmdlet Get-MailboxAuditBypassAssociation may display a WARNING on system objects that begin with \"Asc-2X1\", this is not part of the Audit procedure and can be ignored.", + "AdditionalInformation": "", + "DefaultValue": "AuditBypassEnabled False", + "References": "https://learn.microsoft.com/en-us/powershell/module/exchange/get-mailboxauditbypassassociation?view=exchange-ps" + } + ] + }, + { + "Id": "6.2.1", + "Description": "Exchange Online offers several methods of managing the flow of email messages. These are Remote domain, Transport Rules, and Anti-spam outbound policies. These methods work together to provide comprehensive coverage for potential automatic forwarding channels: - Outlook forwarding using inbox rules. - Outlook forwarding configured using OOF rule. - OWA forwarding setting (ForwardingSmtpAddress). - Forwarding set by the admin using EAC (ForwardingAddress). - Forwarding using Power Automate / Flow. Ensure a Transport rule and Anti-spam outbound policy are used to block mail forwarding. NOTE: Any exclusions should be implemented based on organizational policy.", + "Checks": [ + "exchange_transport_rules_mail_forwarding_disabled", + "defender_antispam_outbound_policy_forwarding_disabled" + ], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.2 Mail flow", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Exchange Online offers several methods of managing the flow of email messages. These are Remote domain, Transport Rules, and Anti-spam outbound policies. These methods work together to provide comprehensive coverage for potential automatic forwarding channels: - Outlook forwarding using inbox rules. - Outlook forwarding configured using OOF rule. - OWA forwarding setting (ForwardingSmtpAddress). - Forwarding set by the admin using EAC (ForwardingAddress). - Forwarding using Power Automate / Flow. Ensure a Transport rule and Anti-spam outbound policy are used to block mail forwarding. NOTE: Any exclusions should be implemented based on organizational policy.", + "RationaleStatement": "Attackers often create these rules to exfiltrate data from your tenancy, this could be accomplished via access to an end-user account or otherwise. An insider could also use one of these methods as a secondary channel to exfiltrate sensitive data.", + "ImpactStatement": "Care should be taken before implementation to ensure there is no business need for case-by-case auto-forwarding. Disabling auto-forwarding to remote domains will affect all users in an organization. Any exclusions should be implemented based on organizational policy.", + "RemediationProcedure": "Note: Remediation is a two step procedure as follows: STEP 1: Transport rules To remediate using the UI: 1. Select Exchange to open the Exchange admin center. 2. Select Mail Flow then Rules. 3. For each rule that redirects email to external domains, select the rule and click the 'Delete' icon. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Remove-TransportRule {RuleName} STEP 2: Anti-spam outbound policy To remediate using the UI: 1. Navigate to Microsoft 365 Defender https://security.microsoft.com/ 2. Expand E-mail & collaboration then select Policies & rules. 3. Select Threat policies > Anti-spam. 4. Select Anti-spam outbound policy (default) 5. Click Edit protection settings 6. Set Automatic forwarding rules dropdown to Off - Forwarding is disabled and click Save 7. Repeat steps 4-6 for any additional higher priority, custom policies. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-HostedOutboundSpamFilterPolicy -Identity {policyName} -AutoForwardingMode Off 3. To remove AutoForwarding from all outbound policies you can also run: Get-HostedOutboundSpamFilterPolicy | Set-HostedOutboundSpamFilterPolicy - AutoForwardingMode Off", + "AuditProcedure": "Note: Audit is a two step procedure as follows: STEP 1: Transport rules To audit using the UI: 1. Select Exchange to open the Exchange admin center. 2. Select Mail Flow then Rules. 3. Review the rules and verify that none of them are forwards or redirects e-mail to external domains. To audit using PowerShell: 1. Connect to Exchange online using Connect-ExchangeOnline. 2. Run the following PowerShell command to review the Transport Rules that are redirecting email: Get-TransportRule | Where-Object {$_.RedirectMessageTo -ne $null} | ft Name,RedirectMessageTo 3. Verify that none of the addresses listed belong to external domains outside of the organization. If nothing returns then there are no transport rules set to redirect messages. STEP 2: Anti-spam outbound policy To audit using the UI: 1. Navigate to Microsoft 365 Defender https://security.microsoft.com/ 2. Expand E-mail & collaboration then select Policies & rules. 3. Select Threat policies > Anti-spam. 4. Inspect Anti-spam outbound policy (default) and ensure Automatic forwarding is set to Off - Forwarding is disabled 5. Inspect any additional custom outbound policies and ensure Automatic forwarding is set to Off - Forwarding is disabled, in accordance with the organization's exclusion policies. To audit using PowerShell: 1. Connect to Exchange online using Connect-ExchangeOnline. 2. Run the following PowerShell cmdlet: Get-HostedOutboundSpamFilterPolicy | ft Name, AutoForwardingMode 3. In each outbound policy verify AutoForwardingMode is Off. Note: According to Microsoft if a recipient is defined in multiple policies of the same type (anti-spam, anti-phishing, etc.), only the policy with the highest priority is applied to the recipient. Any remaining policies of that type are not evaluated for the recipient (including the default policy). However, it is our recommendation to audit the default policy as well in the case a higher priority custom policy is removed. This will keep the organization's security posture strong.", + "AdditionalInformation": "", + "DefaultValue": "", + "References": "https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/mail-flow-rules:https://techcommunity.microsoft.com/t5/exchange-team-blog/all-you-need-to-know-about-automatic-email-forwarding-in/ba-p/2074888#:~:text=%20%20%20Automatic%20forwarding%20option%20%20,%:https://learn.microsoft.com/en-us/defender-office-365/outbound-spam-policies-external-email-forwarding?view=o365-worldwide" + } + ] + }, + { + "Id": "6.2.2", + "Description": "Mail flow rules (transport rules) in Exchange Online can be configured to set the spam confidence level (SCL) of a message to -1, which bypasses spam and phishing filtering. When a rule applies this action to messages based on the sender's domain, all mail from that domain is treated as trusted and skips anti-malware and anti-phishing evaluation regardless of message content.", + "Checks": [ + "exchange_transport_rules_whitelist_disabled" + ], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.2 Mail flow", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Mail flow rules (transport rules) in Exchange Online can be configured to set the spam confidence level (SCL) of a message to -1, which bypasses spam and phishing filtering. When a rule applies this action to messages based on the sender's domain, all mail from that domain is treated as trusted and skips anti-malware and anti-phishing evaluation regardless of message content.", + "RationaleStatement": "Whitelisting domains in transport rules bypasses regular malware and phishing scanning, which can enable an attacker to launch attacks against your users from a safe haven domain. Note: If an organization identifies a business need for an exception, the domain should only be whitelisted if inbound emails from that domain originate from a specific IP address. These exceptions should be documented and regularly reviewed.", + "ImpactStatement": "Removing SCL bypass rules will subject previously whitelisted domains to standard spam and phishing filtering. Mail from those domains that does not pass filtering may be quarantined or rejected, which could disrupt established business communications. Prior to removal, identify any rules in scope and coordinate with affected business owners. If a legitimate need exists, consider replacing domain-based whitelisting with approved sender lists at the connection level.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Exchange admin center https://admin.exchange.microsoft.com 2. Click to expand Mail Flow and then select Rules. 3. For each rule that sets the spam confidence level to -1 for a specific domain, select the rule and click Delete. To remediate using PowerShell: 1. Connect to Exchange online using Connect-ExchangeOnline. 2. To remove a specific non-compliant rule: Remove-TransportRule -Identity \"RuleName\" Note: If the rule serves a legitimate purpose beyond domain whitelisting, consider modifying it to remove the SenderDomainIs condition or the SetSCL -1 action rather than deleting it entirely.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Exchange admin center https://admin.exchange.microsoft.com 2. Click to expand Mail Flow and then select Rules. 3. Review each rule and ensure that a single rule does not contain both of these properties together: o Under Apply this rule if: Sender's address domain portion belongs to any of these domains: '' o Under Do the following: Set the spam confidence level (SCL) to '-1' Note: Setting the spam confidence level to -1 indicates the message is from a trusted sender, so the message bypasses spam filtering. The recommendation fails if any external domain has a SCL of -1. To audit using PowerShell: 1. Connect to Exchange online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-TransportRule | Where-Object { $_.setscl -eq -1 -and $_.SenderDomainIs - ne $null } | ft Name,SenderDomainIs,SetSCL 3. Transport rules that fail the audit will be shown. If no output is shown, the recommendation passes. To pass, all rules with SetSCL set to -1 must not include any domains in the SenderDomainIs property.", + "AdditionalInformation": "", + "DefaultValue": "No mail flow rules that set the SCL to -1 based on sender domain exist by default.", + "References": "https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/configuration-best-practices:https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/mail-flow-rules" + } + ] + }, + { + "Id": "6.2.3", + "Description": "External callouts provide a native experience to identify emails from senders outside the organization. This is achieved by presenting a new tag on emails called \"External\" (the string is localized based on the client language setting) and exposing related user interface at the top of the message reading view to see and verify the real sender's email address. The recommended state is ExternalInOutlook set to Enabled True", + "Checks": [ + "exchange_external_email_tagging_enabled" + ], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.2 Mail flow", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "External callouts provide a native experience to identify emails from senders outside the organization. This is achieved by presenting a new tag on emails called \"External\" (the string is localized based on the client language setting) and exposing related user interface at the top of the message reading view to see and verify the real sender's email address. The recommended state is ExternalInOutlook set to Enabled True", + "RationaleStatement": "Tagging emails from external senders helps to inform end users about the origin of the email. This can allow them to proceed with more caution and make informed decisions when it comes to identifying spam or phishing emails. Mail flow rules are often used by Exchange administrators to accomplish the External email tagging by appending a tag to the front of a subject line. There are limitations to this outlined here. The preferred method in the CIS Benchmark is to use the native experience. Note: Existing emails in a user's inbox from external senders are not tagged retroactively.", + "ImpactStatement": "Mail flow rules using external tagging must be disabled, along with third-party mail filtering tools that offer similar features, to avoid duplicate [External] tags. External tags can consume additional screen space on systems with limited real estate, such as thin clients or mobile devices. After enabling this feature via PowerShell, it may take 24-48 hours for users to see the External sender tag in emails from outside your organization. Rolling back the feature takes the same amount of time. Note: Third-party tools that provide similar functionality will also meet compliance requirements, although Microsoft recommends using the native experience for better interoperability.", + "RemediationProcedure": "To remediate using PowerShell: 1. Connect to Exchange online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-ExternalInOutlook -Enabled $true", + "AuditProcedure": "To audit using PowerShell: 1. Connect to Exchange online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-ExternalInOutlook 3. For each identity verify Enabled is set to True and the AllowList only contains email addresses the organization has permitted to bypass external tagging.", + "AdditionalInformation": "", + "DefaultValue": "Disabled (False)", + "References": "https://techcommunity.microsoft.com/t5/exchange-team-blog/native-external-sender-callouts-on-email-in-outlook/ba-p/2250098:https://learn.microsoft.com/en-us/powershell/module/exchange/set-externalinoutlook?view=exchange-ps" + } + ] + }, + { + "Id": "6.3.1", + "Description": "Role assignment policies in Exchange Online control whether users can install and manage add-ins for Outlook. Three management roles govern this capability: My Custom Apps allows users to sideload custom add-ins, My Marketplace Apps allows users to install add-ins from the marketplace, and My ReadWriteMailbox Apps allows users to install add-ins that request read/write mailbox permissions. When these roles are assigned to a user's role assignment policy, users can self-install add-ins in both Outlook desktop and Outlook on the web, granting those add-ins access to mailbox data. This recommendation applies to the default role assignment policy, which is automatically assigned to new mailboxes unless a custom policy is specified.", + "Checks": [ + "exchange_roles_assignment_policy_addins_disabled" + ], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.3 Roles", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Role assignment policies in Exchange Online control whether users can install and manage add-ins for Outlook. Three management roles govern this capability: My Custom Apps allows users to sideload custom add-ins, My Marketplace Apps allows users to install add-ins from the marketplace, and My ReadWriteMailbox Apps allows users to install add-ins that request read/write mailbox permissions. When these roles are assigned to a user's role assignment policy, users can self-install add-ins in both Outlook desktop and Outlook on the web, granting those add-ins access to mailbox data. This recommendation applies to the default role assignment policy, which is automatically assigned to new mailboxes unless a custom policy is specified.", + "RationaleStatement": "Attackers exploit vulnerable or malicious add-ins to read, exfiltrate, or modify mailbox content including email, calendar items, and contacts. Restricting user-installed add-ins reduces this attack surface and centralizes add-in approval with administrators.", + "ImpactStatement": "End users will be unable to self-install third-party Outlook add-ins. Administrators may receive requests to evaluate and deploy add-ins on behalf of users. Organizations that rely on user-deployed add-ins for business workflows should inventory those add-ins and deploy them centrally via Centralized Deployment before implementing this recommendation.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Exchange admin center https://admin.exchange.microsoft.com. 2. Click to expand Roles and select User roles. 3. Select Default Role Assignment Policy. 4. In the properties pane on the right click on Manage permissions. 5. Under Other roles uncheck any non-compliant roles: My Custom Apps, My Marketplace Apps, and My ReadWriteMailbox Apps. 6. Click Save changes. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following script: $TargetRoles = @( \"My Custom Apps\", \"My Marketplace Apps\", \"My ReadWriteMailbox Apps\" ) $DefaultPolicy = Get-RoleAssignmentPolicy | Where-Object { $_.IsDefault -eq $true } $Assignments = Get-ManagementRoleAssignment -RoleAssignee $DefaultPolicy.Identity | Where-Object { $_.Role -in $TargetRoles } foreach ($Assignment in $Assignments) { Remove-ManagementRoleAssignment -Identity $Assignment.Identity - Confirm:$false }", + "AuditProcedure": "To audit using the UI: 1. Navigate to Exchange admin center https://admin.exchange.microsoft.com. 2. Expand Roles and select User roles. 3. Select Default Role Assignment Policy. 4. In the properties pane on the right click on Manage permissions. 5. Under Other roles verify that My Custom Apps, My Marketplace Apps, and My ReadWriteMailbox Apps are not checked. Note: As of this release of the Benchmark the manage permissions link no longer displays anything when a user assigned the Global Reader role clicks on it. As an alternative, users assigned the Global Reader directory role can inspect the Roles column or use the PowerShell method to perform the audit. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following script: $RoleList = @( \"My Custom Apps\", \"My Marketplace Apps\", \"My ReadWriteMailbox Apps\" ) $DefaultPolicy = Get-RoleAssignmentPolicy | Where-Object { $_.IsDefault -eq $true } $NonCompliantRoles = $DefaultPolicy.AssignedRoles | Where-Object { $_ -in $RoleList } Write-Host \"Checking Default Role Assignment Policy: $($DefaultPolicy.Name)\" if ($NonCompliantRoles) { \"Non-compliant - the following roles are assigned: \" + ($NonCompliantRoles -join \", \") } else { \"Compliant - no add-in roles are assigned to the default policy.\" } 3. Verify that the output indicates compliance. If My Custom Apps, My Marketplace Apps, or My ReadWriteMailbox Apps are listed, the default policy is non-compliant.", + "AdditionalInformation": "", + "DefaultValue": "UI - My Custom Apps, My Marketplace Apps, and My ReadWriteMailbox Apps are checked. PowerShell - My Custom Apps, My Marketplace Apps, and My ReadWriteMailbox Apps are assigned.", + "References": "https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/add-ins-for-outlook/specify-who-can-install-and-manage-add-ins?source=recommendations:https://learn.microsoft.com/en-us/exchange/permissions-exo/role-assignment-policies" + } + ] + }, + { + "Id": "6.3.2", + "Description": "Outlook on the web (OWA) mailbox policies include two settings that control personal account integration in Outlook. PersonalAccountsEnabled controls whether users can add personal email accounts (e.g., Outlook.com, Gmail, Yahoo) in the new Outlook for Windows. PersonalAccountCalendarsEnabled controls whether users can connect personal Outlook.com or Google calendars in Outlook on the web. Neither setting applies to classic Outlook for Windows, Outlook for Mac, or Outlook mobile apps. The recommended state for the default OWA Mailbox Policy is: - PersonalAccountsEnabled is set to False - PersonalAccountCalendarsEnabled is set to False", + "Checks": [], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.3 Roles", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Outlook on the web (OWA) mailbox policies include two settings that control personal account integration in Outlook. PersonalAccountsEnabled controls whether users can add personal email accounts (e.g., Outlook.com, Gmail, Yahoo) in the new Outlook for Windows. PersonalAccountCalendarsEnabled controls whether users can connect personal Outlook.com or Google calendars in Outlook on the web. Neither setting applies to classic Outlook for Windows, Outlook for Mac, or Outlook mobile apps. The recommended state for the default OWA Mailbox Policy is: - PersonalAccountsEnabled is set to False - PersonalAccountCalendarsEnabled is set to False", + "RationaleStatement": "Personal email accounts are not subject to corporate security controls such as anti- malware scanning, data loss prevention (DLP), Safe Links, or audit logging. Allowing personal accounts alongside the corporate mailbox enables side-channel data exfiltration (e.g., forwarding sensitive content to a personal inbox) and creates an ingress path for malware and phishing payloads that bypass tenant mail-flow protections.", + "ImpactStatement": "This control does not apply to classic Outlook for Windows, Outlook for Mac, or Outlook mobile apps. Organizations requiring broader coverage should evaluate additional controls like application management policies to restrict personal account usage on those clients. This also does not block users from accessing personal accounts via other email clients or web browsers. Changes to OWA mailbox policies may take up to 60 minutes to take effect. If users previously added personal accounts before this policy was applied, those accounts will be disabled once the policy is detected, and affected users will see a message advising them to remove the personal account from Outlook, which may generate helpdesk inquiries. The audit only applies to the default OWA mailbox policy. Users assigned to a non- default OWA mailbox policy are not covered; optionally, custom policies can be reviewed separately to ensure a level of enforcement beyond the compliance requirements of this control.", + "RemediationProcedure": "To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following: $DefaultPolicy = Get-OwaMailboxPolicy | Where-Object { $_.IsDefault } Set-OwaMailboxPolicy -Identity $DefaultPolicy.Identity - PersonalAccountsEnabled $false -PersonalAccountCalendarsEnabled $false", + "AuditProcedure": "Note: The default OWA Mailbox Policy is the only policy required for compliance with this control. Other mailbox policies are discretionary and left up to the organization to audit as needed. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following: Get-OwaMailboxPolicy | Where-Object { $_.IsDefault } | Format-List PersonalAccountsEnabled, PersonalAccountCalendarsEnabled 3. Verify the output matches the following: PersonalAccountsEnabled : False PersonalAccountCalendarsEnabled : False", + "AdditionalInformation": "", + "DefaultValue": "- PersonalAccountsEnabled is True. - PersonalAccountCalendarsEnabled is True.", + "References": "https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-owamailboxpolicy?view=exchange-ps#-personalaccountsenabled:https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/get-started/supported-account-types#prevent-adding-personal-accounts:https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/manage/policy-management" + } + ] + }, + { + "Id": "6.5.1", + "Description": "Modern authentication in Microsoft 365 enables authentication features like multifactor authentication (MFA) using smart cards, certificate-based authentication (CBA), and third-party SAML identity providers. When you enable modern authentication in Exchange Online, Outlook 2016 and Outlook 2013 use modern authentication to log in to Microsoft 365 mailboxes. When you disable modern authentication in Exchange Online, Outlook 2016 and Outlook 2013 use basic authentication to log in to Microsoft 365 mailboxes. When users initially configure certain email clients, like Outlook 2013 and Outlook 2016, they may be required to authenticate using enhanced authentication mechanisms, such as multifactor authentication. Other Outlook clients that are available in Microsoft 365 (for example, Outlook Mobile and Outlook for Mac 2016) always use modern authentication to log in to Microsoft 365 mailboxes.", + "Checks": [ + "exchange_organization_modern_authentication_enabled" + ], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.5 Settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Modern authentication in Microsoft 365 enables authentication features like multifactor authentication (MFA) using smart cards, certificate-based authentication (CBA), and third-party SAML identity providers. When you enable modern authentication in Exchange Online, Outlook 2016 and Outlook 2013 use modern authentication to log in to Microsoft 365 mailboxes. When you disable modern authentication in Exchange Online, Outlook 2016 and Outlook 2013 use basic authentication to log in to Microsoft 365 mailboxes. When users initially configure certain email clients, like Outlook 2013 and Outlook 2016, they may be required to authenticate using enhanced authentication mechanisms, such as multifactor authentication. Other Outlook clients that are available in Microsoft 365 (for example, Outlook Mobile and Outlook for Mac 2016) always use modern authentication to log in to Microsoft 365 mailboxes.", + "RationaleStatement": "Strong authentication controls, such as the use of multifactor authentication, may be circumvented if basic authentication is used by Exchange Online email clients such as Outlook 2016 and Outlook 2013. Enabling modern authentication for Exchange Online ensures strong authentication mechanisms are used when establishing sessions between email clients and Exchange Online.", + "ImpactStatement": "Users of older email clients, such as Outlook 2013 and Outlook 2016, will no longer be able to authenticate to Exchange using Basic Authentication, which will necessitate migration to modern authentication practices.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings and select Org Settings. 3. Select Modern authentication. 4. Check Turn on modern authentication for Outlook 2013 for Windows and later (recommended) to enable modern authentication. To remediate using PowerShell: 1. Run the Microsoft Exchange Online PowerShell Module. 2. Connect to Exchange Online using Connect-ExchangeOnline. 3. Run the following PowerShell command: Set-OrganizationConfig -OAuth2ClientProfileEnabled $True", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft 365 admin center https://admin.microsoft.com. 2. Expand Settings and select Org Settings. 3. Select Modern authentication. 4. Verify that Turn on modern authentication for Outlook 2013 for Windows and later (recommended) is checked. To audit using PowerShell: 1. Run the Microsoft Exchange Online PowerShell Module. 2. Connect to Exchange Online using Connect-ExchangeOnline. 3. Run the following PowerShell command: Get-OrganizationConfig | Format-Table -Auto Name, OAuth* 4. Verify that OAuth2ClientProfileEnabled is True.", + "AdditionalInformation": "", + "DefaultValue": "True", + "References": "https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-modern-authentication-in-exchange-online" + } + ] + }, + { + "Id": "6.5.2", + "Description": "MailTips are informative messages displayed to users while they're composing a message. While a new message is open and being composed, Exchange analyzes the message (including recipients). If a potential problem is detected, the user is notified with a MailTip prior to sending the message. Using the information in the MailTip, the user can adjust the message to avoid undesirable situations or non-delivery reports (also known as NDRs or bounce messages).", + "Checks": [ + "exchange_organization_mailtips_enabled" + ], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.5 Settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "MailTips are informative messages displayed to users while they're composing a message. While a new message is open and being composed, Exchange analyzes the message (including recipients). If a potential problem is detected, the user is notified with a MailTip prior to sending the message. Using the information in the MailTip, the user can adjust the message to avoid undesirable situations or non-delivery reports (also known as NDRs or bounce messages).", + "RationaleStatement": "Setting up MailTips gives a visual aid to users when they send emails to large groups of recipients or send emails to recipients not within the tenant.", + "ImpactStatement": "Not applicable.", + "RemediationProcedure": "To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: $TipsParams = @{ MailTipsAllTipsEnabled = $true MailTipsExternalRecipientsTipsEnabled = $true MailTipsGroupMetricsEnabled = $true MailTipsLargeAudienceThreshold = '25' } Set-OrganizationConfig @TipsParams", + "AuditProcedure": "To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-OrganizationConfig | fl MailTips* 3. Verify the values for MailTipsAllTipsEnabled, MailTipsExternalRecipientsTipsEnabled, and MailTipsGroupMetricsEnabled are set to True and MailTipsLargeAudienceThreshold is set to an acceptable value; 25 is the default value.", + "AdditionalInformation": "", + "DefaultValue": "MailTipsAllTipsEnabled: True MailTipsExternalRecipientsTipsEnabled: False MailTipsGroupMetricsEnabled: True MailTipsLargeAudienceThreshold: 25", + "References": "https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/mailtips/mailtips:https://learn.microsoft.com/en-us/powershell/module/exchange/set-organizationconfig?view=exchange-ps" + } + ] + }, + { + "Id": "6.5.3", + "Description": "This setting allows users to open certain external files while working in Outlook on the web. If allowed, keep in mind that Microsoft doesn't control the use terms or privacy policies of those third-party services. Ensure AdditionalStorageProvidersAvailable is restricted on the default OWA policy.", + "Checks": [ + "exchange_mailbox_policy_additional_storage_restricted" + ], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.5 Settings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "This setting allows users to open certain external files while working in Outlook on the web. If allowed, keep in mind that Microsoft doesn't control the use terms or privacy policies of those third-party services. Ensure AdditionalStorageProvidersAvailable is restricted on the default OWA policy.", + "RationaleStatement": "By default, additional storage providers are allowed in Office on the Web (such as Box, Dropbox, Facebook, Google Drive, OneDrive Personal, etc.). This could lead to information leakage and additional risk of infection from organizational non-trusted storage providers. Restricting this will inherently reduce risk as it will narrow opportunities for infection and data leakage.", + "ImpactStatement": "The impact associated with this change is highly dependent upon current practices in the tenant. If users do not use other storage providers, then minimal impact is likely. However, if users do regularly utilize providers outside of the tenant this will affect their ability to continue to do so.", + "RemediationProcedure": "To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default - AdditionalStorageProvidersAvailable $false", + "AuditProcedure": "To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command to audit the default OWA policy: Get-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default | fl AdditionalStorageProvidersAvailable 3. Verify that AdditionalStorageProvidersAvailable is False.", + "AdditionalInformation": "", + "DefaultValue": "AdditionalStorageProvidersAvailable : True", + "References": "https://learn.microsoft.com/en-us/powershell/module/exchange/set-owamailboxpolicy?view=exchange-ps:https://support.microsoft.com/en-us/topic/3rd-party-cloud-storage-services-supported-by-office-apps-fce12782-eccc-4cf5-8f4b-d1ebec513f72" + } + ] + }, + { + "Id": "6.5.4", + "Description": "This setting enables or disables authenticated client SMTP submission (SMTP AUTH) at an organization level in Exchange Online. The recommended state is Turn off SMTP AUTH protocol for your organization (checked).", + "Checks": [ + "exchange_transport_config_smtp_auth_disabled" + ], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.5 Settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting enables or disables authenticated client SMTP submission (SMTP AUTH) at an organization level in Exchange Online. The recommended state is Turn off SMTP AUTH protocol for your organization (checked).", + "RationaleStatement": "SMTP AUTH is a legacy protocol. Disabling it at the organization level supports the principle of least functionality and serves to further back additional controls that block legacy protocols, such as in Conditional Access. Virtually all modern email clients that connect to Exchange Online mailboxes in Microsoft 365 can do so without using SMTP AUTH.", + "ImpactStatement": "This enforces the default behavior, so no impact is expected unless the organization is using it globally. A per-mailbox setting exists that overrides the tenant-wide setting, allowing an individual mailbox SMTP AUTH capability for special cases.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Exchange admin center https://admin.exchange.microsoft.com. 2. Expand Settings and select Mail flow. 3. Check Turn off SMTP AUTH protocol for your organization to disable the protocol. To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-TransportConfig -SmtpClientAuthenticationDisabled $true", + "AuditProcedure": "To audit using the UI: 1. Navigate to Exchange admin center https://admin.exchange.microsoft.com. 2. Expand Settings and select Mail flow. 3. Ensure Turn off SMTP AUTH protocol for your organization is checked. To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled 3. Verify that the value returned is True.", + "AdditionalInformation": "", + "DefaultValue": "SmtpClientAuthenticationDisabled : True", + "References": "https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission" + } + ] + }, + { + "Id": "6.5.5", + "Description": "Direct Send is a method used to send emails directly to an Exchange Online customer's hosted mailboxes from on-premises devices, applications, or third-party cloud services using the customer's own accepted domain. This method does not require any form of authentication because, by its nature, it mimics incoming anonymous emails from the internet, apart from the sender domain. The recommended state is to configure RejectDirectSend to True.", + "Checks": [], + "Attributes": [ + { + "Section": "6 Exchange admin center", + "SubSection": "6.5 Settings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Direct Send is a method used to send emails directly to an Exchange Online customer's hosted mailboxes from on-premises devices, applications, or third-party cloud services using the customer's own accepted domain. This method does not require any form of authentication because, by its nature, it mimics incoming anonymous emails from the internet, apart from the sender domain. The recommended state is to configure RejectDirectSend to True.", + "RationaleStatement": "Direct Send allows devices and applications to transmit unauthenticated email directly to Exchange Online. While this method may support legacy systems such as printers or scanners, it introduces significant security risks: - Unauthenticated Email Delivery: Direct Send does not require authentication, making it an attractive vector for threat actors to deliver spoofed or malicious emails that appear to originate from trusted internal sources. - Phishing and Spoofing Risks: Because these emails bypass standard authentication mechanisms, they can easily impersonate internal users or services, increasing the likelihood of successful phishing attacks. - Lack of Visibility and Control: Emails sent via Direct Send may not be subject to the same security policies, logging, or filtering as authenticated traffic, reducing the organization's ability to monitor and respond to threats effectively. Threat research from Varonis has shown that attackers are actively exploiting Direct Send to impersonate internal accounts and distribute malicious content without needing to compromise any credentials. These campaigns have successfully targeted organizations by leveraging predictable infrastructure and public user data to craft convincing phishing emails. Because these messages originate from outside the tenant but appear internal, they often evade detection and filtering mechanisms.", + "ImpactStatement": "Per Microsoft, there is a forwarding scenario that could be affected by this feature. It is possible that someone in your organization sends a message to a 3rd party and they in turn forward it to another mailbox in your organization. If the 3rd party's email provider does not support Sender Rewriting Scheme (SRS), the message will return with the original sender's address. Prior to this feature being enabled, those messages will already be punished by SPF failing but could still end up in inboxes. Enabling the Reject Direct Send feature without a partner mail flow connector being set up will lead to these messages being rejected outright.", + "RemediationProcedure": "To remediate using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Set-OrganizationConfig -RejectDirectSend $true", + "AuditProcedure": "To audit using PowerShell: 1. Connect to Exchange Online using Connect-ExchangeOnline. 2. Run the following PowerShell command: Get-OrganizationConfig | fl RejectDirectSend 3. Verify that the value returned for RejectDirectSend is True.", + "AdditionalInformation": "", + "DefaultValue": "RejectDirectSend : False", + "References": "https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790?WT.mc_id=M365-MVP-9501:https://techcommunity.microsoft.com/blog/exchange/direct-send-vs-sending-directly-to-an-exchange-online-tenant/4439865:https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-organizationconfig?view=exchange-ps:https://www.varonis.com/blog/direct-send-exploit:https://techcommunity.microsoft.com/discussions/microsoft-365/disable-direct-send-in-exchange-online-to-mitigate-ongoing-phishing-threats/4434649" + } + ] + }, + { + "Id": "7.2.1", + "Description": "Modern authentication in Microsoft 365 enables authentication features like multifactor authentication (MFA) using smart cards, certificate-based authentication (CBA), and third-party SAML identity providers.", + "Checks": [ + "sharepoint_modern_authentication_required" + ], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.2 Policies", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Modern authentication in Microsoft 365 enables authentication features like multifactor authentication (MFA) using smart cards, certificate-based authentication (CBA), and third-party SAML identity providers.", + "RationaleStatement": "Strong authentication controls, such as the use of multifactor authentication, may be circumvented if basic authentication is used by SharePoint applications. Requiring modern authentication for SharePoint applications ensures strong authentication mechanisms are used when establishing sessions between these applications, SharePoint, and connecting users.", + "ImpactStatement": "Implementation of modern authentication for SharePoint will require users to authenticate to SharePoint using modern authentication. This may cause a minor impact to typical user behavior. This may also prevent third-party apps from accessing SharePoint Online resources. Also, this will also block apps using the SharePointOnlineCredentials class to access SharePoint Online resources.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint. 2. Expand Policies and select Access control. 3. Select Apps that don't use modern authentication. 4. Select the radio button for Block access. 5. Click Save. To remediate using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService -Url https://tenant-admin.sharepoint.com replacing tenant with your value. 2. Run the following SharePoint Online PowerShell command: Set-SPOTenant -LegacyAuthProtocolsEnabled $false", + "AuditProcedure": "To audit using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint. 2. Expand Policies and select Access control. 3. Select Apps that don't use modern authentication and ensure that it is set to Block access. To audit using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService -Url https://tenant-admin.sharepoint.com replacing tenant with your value. 2. Run the following SharePoint Online PowerShell command: Get-SPOTenant | ft LegacyAuthProtocolsEnabled 3. Verify that the returned value is False.", + "AdditionalInformation": "", + "DefaultValue": "True (Apps that don't use modern authentication are allowed)", + "References": "https://learn.microsoft.com/en-us/powershell/module/sharepoint-online/set-spotenant?view=sharepoint-ps" + } + ] + }, + { + "Id": "7.2.2", + "Description": "Entra ID B2B provides authentication and management of guests. Authentication happens via one-time passcode when they don't already have a work or school account or a Microsoft account. Integration with SharePoint and OneDrive allows for more granular control of how guest user accounts are managed in the organization's AAD, unifying a similar guest experience already deployed in other Microsoft 365 services such as Teams. Note: Global Reader role currently can't access SharePoint using PowerShell.", + "Checks": [], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.2 Policies", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Entra ID B2B provides authentication and management of guests. Authentication happens via one-time passcode when they don't already have a work or school account or a Microsoft account. Integration with SharePoint and OneDrive allows for more granular control of how guest user accounts are managed in the organization's AAD, unifying a similar guest experience already deployed in other Microsoft 365 services such as Teams. Note: Global Reader role currently can't access SharePoint using PowerShell.", + "RationaleStatement": "External users assigned guest accounts will be subject to Entra ID access policies, such as multi-factor authentication. This provides a way to manage guest identities and control access to SharePoint and OneDrive resources. Without this integration, files can be shared without account registration, making it more challenging to audit and manage who has access to the organization's data.", + "ImpactStatement": "After enabling Microsoft Entra B2B integration, external users attempting to access previously shared links (One Time Passcode) will encounter access issues. They receive error 'This organization has updated its guest access settings'. To restore access, your users need to reshare files/folders/sites to external users.", + "RemediationProcedure": "To remediate using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService 2. Run the following command: Set-SPOTenant -EnableAzureADB2BIntegration $true", + "AuditProcedure": "To audit using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService 2. Run the following command: Get-SPOTenant | ft EnableAzureADB2BIntegration 3. Verify that the returned value is True.", + "AdditionalInformation": "", + "DefaultValue": "False", + "References": "https://learn.microsoft.com/en-us/sharepoint/sharepoint-azureb2b-integration#enabling-the-integration:https://learn.microsoft.com/en-us/entra/external-id/what-is-b2b:https://learn.microsoft.com/en-us/powershell/module/sharepoint-online/set-spotenant?view=sharepoint-ps" + } + ] + }, + { + "Id": "7.2.3", + "Description": "The external sharing settings govern sharing for the organization overall. Each site has its own sharing setting that can be set independently, though it must be at the same or more restrictive setting as the organization. The new and existing guests option requires people who have received invitations to sign in with their work or school account (if their organization uses Microsoft 365) or a Microsoft account, or to provide a code to verify their identity. Users can share with guests already in your organization's directory, and they can send invitations to people who will be added to the directory if they sign in. The recommended state is New and existing guests or less permissive.", + "Checks": [ + "sharepoint_external_sharing_restricted" + ], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.2 Policies", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "The external sharing settings govern sharing for the organization overall. Each site has its own sharing setting that can be set independently, though it must be at the same or more restrictive setting as the organization. The new and existing guests option requires people who have received invitations to sign in with their work or school account (if their organization uses Microsoft 365) or a Microsoft account, or to provide a code to verify their identity. Users can share with guests already in your organization's directory, and they can send invitations to people who will be added to the directory if they sign in. The recommended state is New and existing guests or less permissive.", + "RationaleStatement": "Forcing guest authentication on the organization's tenant enables the implementation of controls and oversight over external file sharing. When a guest is registered with the organization, they now have an identity which can be accounted for. This identity can also have other restrictions applied to it through group membership and conditional access rules.", + "ImpactStatement": "When using B2B integration, Entra ID external collaboration settings, such as guest invite settings and collaboration restrictions apply.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Locate the External sharing section. 4. Under SharePoint, move the slider bar to New and existing guests or a less permissive level. o OneDrive will also be moved to the same level and can never be more permissive than SharePoint. To remediate using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following cmdlet to establish the minimum recommended state: Set-SPOTenant -SharingCapability ExternalUserSharingOnly Note: Other acceptable values for this parameter that are more restrictive include: Disabled and ExistingExternalUserSharingOnly.", + "AuditProcedure": "To audit using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Locate the External sharing section. 4. Under SharePoint, verify that the slider bar is set to New and existing guests or a less permissive level. To audit using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following cmdlet: Get-SPOTenant | fl SharingCapability 3. Verify that SharingCapability is set to one of the following values: o ExternalUserSharingOnly o ExistingExternalUserSharingOnly o Disabled", + "AdditionalInformation": "", + "DefaultValue": "Anyone (ExternalUserAndGuestSharing)", + "References": "https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off:https://learn.microsoft.com/en-us/powershell/module/sharepoint-online/set-spotenant?view=sharepoint-ps" + } + ] + }, + { + "Id": "7.2.4", + "Description": "This setting governs the global permissiveness of OneDrive content sharing in the organization. OneDrive content sharing can be restricted independent of SharePoint but can never be more permissive than the level established with SharePoint. The recommended state is Only people in your organization.", + "Checks": [], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.2 Policies", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "This setting governs the global permissiveness of OneDrive content sharing in the organization. OneDrive content sharing can be restricted independent of SharePoint but can never be more permissive than the level established with SharePoint. The recommended state is Only people in your organization.", + "RationaleStatement": "OneDrive, designed for end-user cloud storage, inherently provides less oversight and control compared to SharePoint, which often involves additional content overseers or site administrators. This autonomy can lead to potential risks such as inadvertent sharing of privileged information by end users. Restricting external OneDrive sharing will require users to transfer content to SharePoint folders first which have those tighter controls.", + "ImpactStatement": "Users will be required to take additional steps to share OneDrive content or use other official channels.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Locate the External sharing section. 4. Under OneDrive, set the slider bar to Only people in your organization. To remediate using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following cmdlet: Set-SPOTenant -OneDriveSharingCapability Disabled Alternative remediation method using PowerShell: 1. Connect to SharePoint Online. 2. Run one of the following: # Replace [tenant] with your tenant id Set-SPOSite -Identity https://[tenant]-my.sharepoint.com/ -SharingCapability Disabled # Or run this to filter to the specific site without supplying the tenant name. $OneDriveSite = Get-SPOSite -Filter { Url -like \"*-my.sharepoint.com/\" } Set-SPOSite -Identity $OneDriveSite -SharingCapability Disabled", + "AuditProcedure": "To audit using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Locate the External sharing section. 4. Under OneDrive, verify that the slider bar is set to Only people in your organization. To audit using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following cmdlet: Get-SPOTenant | fl OneDriveSharingCapability 3. Verify that the returned value is Disabled. Alternative audit method using PowerShell: 1. Connect to SharePoint Online. 2. Use one of the following methods: # Replace [tenant] with your tenant id Get-SPOSite -Identity https://[tenant]-my.sharepoint.com/ | fl Url,SharingCapability # Or run this to filter to the specific site without supplying the tenant name. $OneDriveSite = Get-SPOSite -Filter { Url -like \"*-my.sharepoint.com/\" } Get-SPOSite -Identity $OneDriveSite | fl Url,SharingCapability 2. Verify that the returned value for SharingCapability is Disabled Note: As of March 2024, using Get-SPOSite with Where-Object or filtering against the entire site and then returning the SharingCapability parameter can result in a different value as opposed to running the cmdlet specifically against the OneDrive specific site using the -Identity switch as shown in the example. Note 2: The parameter OneDriveSharingCapability may not be yet fully available in all tenants. It is demonstrated in official Microsoft documentation as linked in the references section but not in the Set-SPOTenant cmdlet itself. If the parameter is unavailable, then either use the UI method or alternative PowerShell audit method.", + "AdditionalInformation": "", + "DefaultValue": "Anyone (ExternalUserAndGuestSharing)", + "References": "https://learn.microsoft.com/en-us/powershell/module/sharepoint-online/set-spotenant?view=sharepoint-ps#-onedrivesharingcapability" + } + ] + }, + { + "Id": "7.2.5", + "Description": "SharePoint gives users the ability to share files, folders, and site collections. Internal users can share with external collaborators, and with the right permissions could share to other external parties.", + "Checks": [ + "sharepoint_guest_sharing_restricted" + ], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.2 Policies", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "SharePoint gives users the ability to share files, folders, and site collections. Internal users can share with external collaborators, and with the right permissions could share to other external parties.", + "RationaleStatement": "Sharing and collaboration are key; however, file, folder, or site collection owners should have the authority over what external users get shared with to prevent unauthorized disclosures of information.", + "ImpactStatement": "The impact associated with this change is highly dependent upon current practices. If users do not regularly share with external parties, then minimal impact is likely. However, if users do regularly share with guests/externally, minimum impacts could occur as those external users will be unable to 're-share' content.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Expand More external sharing settings, uncheck Allow guests to share items they don't own. 4. Click Save. To remediate using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following SharePoint Online PowerShell command: Set-SPOTenant -PreventExternalUsersFromResharing $True", + "AuditProcedure": "To audit using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Expand More external sharing settings, verify that Allow guests to share items they don't own is unchecked. To audit using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following SharePoint Online PowerShell command: Get-SPOTenant | ft PreventExternalUsersFromResharing 3. Verify that the returned value is True.", + "AdditionalInformation": "", + "DefaultValue": "Checked (False)", + "References": "https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off:https://learn.microsoft.com/en-us/sharepoint/external-sharing-overview" + } + ] + }, + { + "Id": "7.2.6", + "Description": "The external sharing features of SharePoint and OneDrive let users in the organization share content with people outside the organization (such as partners, vendors, clients, or customers). It can also be used to share between licensed users on multiple Microsoft 365 subscriptions if your organization has more than one subscription. The recommended state is Limit external sharing by domain > Allow only specific domains", + "Checks": [ + "sharepoint_external_sharing_managed" + ], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.2 Policies", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "The external sharing features of SharePoint and OneDrive let users in the organization share content with people outside the organization (such as partners, vendors, clients, or customers). It can also be used to share between licensed users on multiple Microsoft 365 subscriptions if your organization has more than one subscription. The recommended state is Limit external sharing by domain > Allow only specific domains", + "RationaleStatement": "Attackers will often attempt to expose sensitive information to external entities through sharing, and restricting the domains that users can share documents with will reduce that surface area.", + "ImpactStatement": "Users will be unable to initiate new shares with parties whose domains are not on the approved allowlist, which may require administrative action before collaboration with new partners or vendors can begin. Administrators must keep the allowlist current to reflect active business relationships; an outdated list can block legitimate sharing and generate support requests. Note that existing shares to domains not on the allowlist are not revoked when this setting is configured.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint. 2. Expand Policies > Sharing. 3. Expand More external sharing settings and check Limit external sharing by domain. 4. Select Add domains, choose Allow only specific domains, enter the list of approved domain names, and select Done. 5. Click Save at the bottom of the page. To remediate using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService. 2. Run the following PowerShell command: Set-SPOTenant -SharingDomainRestrictionMode AllowList - SharingAllowedDomainList \"domain1.com domain2.com\"", + "AuditProcedure": "Note: If the SharePoint external sharing slider is set to Only people in your organization, this recommendation is compliant regardless of the configured value for Limit external sharing by domain. To audit using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Locate the External sharing section. 4. If the SharePoint slider is set to Only people in your organization, this recommendation is compliant. 5. Otherwise, expand More external sharing settings and confirm that Limit external sharing by domain is checked. 6. Verify that Allow only specific domains is selected and that domains listed are approved by the organization. To audit using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService. 2. Run the following PowerShell command: Get-SPOTenant | fl SharingCapability,SharingDomainRestrictionMode,SharingAllowedDomainList 3. Verify that one of the following conditions is true: o SharingCapability is Disabled, OR o SharingDomainRestrictionMode is AllowList and SharingAllowedDomainList contains domains trusted by the organization for external sharing.", + "AdditionalInformation": "", + "DefaultValue": "Limit external sharing by domain is unchecked SharingDomainRestrictionMode: None SharingAllowedDomainList: (empty)", + "References": "https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off?WT.mc_id=365AdminCSH_spo#more-external-sharing-settings" + } + ] + }, + { + "Id": "7.2.7", + "Description": "This setting sets the default link type that a user will see when sharing content in OneDrive or SharePoint. It does not restrict or exclude any other options. The recommended state is Specific people (only the people the user specifies) or Only people in your organization.", + "Checks": [], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.2 Policies", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting sets the default link type that a user will see when sharing content in OneDrive or SharePoint. It does not restrict or exclude any other options. The recommended state is Specific people (only the people the user specifies) or Only people in your organization.", + "RationaleStatement": "By defaulting to specific people, the user will first need to consider whether or not the content being shared should be accessible by the entire organization versus select individuals. This aids in reinforcing the concept of least privilege.", + "ImpactStatement": "Changing the default sharing link type influences the user experience when sharing files and folders in SharePoint and OneDrive. The configured default option will appear pre- selected in the sharing dialog, guiding users toward the organization's preferred sharing method.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Scroll to File and folder links. 4. Set Choose the type of link that's selected by default when users share files and folders in SharePoint and OneDrive to Specific people (only the people the user specifies) or Only people in your organization. To remediate using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService. 2. Run one of the following PowerShell commands depending on the desired compliant state: To set the default sharing link to specific people: Set-SPOTenant -DefaultSharingLinkType Direct To set the default sharing link to people in the organization: Set-SPOTenant -DefaultSharingLinkType Internal", + "AuditProcedure": "To audit using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Scroll to File and folder links. 4. Verify that the setting Choose the type of link that's selected by default when users share files and folders in SharePoint and OneDrive is set to Specific people (only the people the user specifies) or Only people in your organization. To audit using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService. 2. Run the following PowerShell command: Get-SPOTenant | fl DefaultSharingLinkType 3. Verify that the returned value is Direct or Internal.", + "AdditionalInformation": "", + "DefaultValue": "Only people in your organization (Internal)", + "References": "https://learn.microsoft.com/en-us/powershell/module/sharepoint-online/set-spotenant?view=sharepoint-ps" + } + ] + }, + { + "Id": "7.2.8", + "Description": "External sharing of content can be restricted to specific security groups. This setting is global, applies to sharing in both SharePoint and OneDrive and cannot be set at the site level in SharePoint.", + "Checks": [], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.2 Policies", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "External sharing of content can be restricted to specific security groups. This setting is global, applies to sharing in both SharePoint and OneDrive and cannot be set at the site level in SharePoint.", + "RationaleStatement": "Without restricting external sharing to designated security groups, any user in the organization can share SharePoint or OneDrive content with external recipients. A compromised or insider-threat account can exfiltrate sensitive data by sharing files externally without additional authorization controls. Limiting external sharing to members of specific Entra ID security groups ensures that only reviewed and authorized users have this capability, reducing the attack surface for data exfiltration through sharing.", + "ImpactStatement": "Users who are not members of the designated security groups will lose the ability to create new external shares or invite new external guests. Existing sharing links they previously established will remain active for current recipients. Organizations should ensure the security groups are populated with appropriate members before enabling this setting to avoid inadvertently blocking all external sharing. Helpdesk volume may increase as users in non-designated groups encounter sharing restrictions.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Scroll to and expand More external sharing settings. 4. Set the following: o Check Allow only users in specific security groups to share externally o Click Manage security groups, then add at least one security group authorized for external sharing. To remediate using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService. 2. Run the following command, replacing with the GUID of the security group to be authorized for external sharing: Set-SPOTenant -WhoCanShareAuthenticatedGuestAllowList \"\" Note: To authorize multiple security groups, provide a comma-delimited list of Object IDs: \"\",\"\". Note: Users in the designated security groups must also be permitted to invite guests in Microsoft Entra. Verify this at Identity > External Identities > External collaboration settings.", + "AuditProcedure": "To audit using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Locate the External sharing section. 4. If the SharePoint slider is set to Only people in your organization, this recommendation is compliant. 5. Otherwise, scroll to and expand More external sharing settings. 6. Verify the following: o Allow only users in specific security groups to share externally is checked o Manage security groups contains at least one security group. To audit using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService. 2. Run the following PowerShell command: Get-SPOTenant | fl SharingCapability, WhoCanShareAuthenticatedGuestAllowList 3. Verify the output using the following logic: o If SharingCapability is Disabled, the recommendation is compliant regardless of the value of WhoCanShareAuthenticatedGuestAllowList. o Otherwise, verify that WhoCanShareAuthenticatedGuestAllowList contains at least one security group GUID. If the value is empty or $null, the recommendation is not compliant.", + "AdditionalInformation": "", + "DefaultValue": "By default, this restriction is not in place, allowing any user in the organization to share content externally, subject only to the top-level sharing slider.", + "References": "https://learn.microsoft.com/en-us/sharepoint/manage-security-groups:https://learn.microsoft.com/en-us/powershell/module/microsoft.online.sharepoint.powershell/set-spotenant?view=sharepoint-ps" + } + ] + }, + { + "Id": "7.2.9", + "Description": "This policy setting configures the expiration time for each guest that is invited to the SharePoint site or with whom users share individual files and folders with. Expiration can be a number 30 to 730. The recommended state is 30.", + "Checks": [], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.2 Policies", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This policy setting configures the expiration time for each guest that is invited to the SharePoint site or with whom users share individual files and folders with. Expiration can be a number 30 to 730. The recommended state is 30.", + "RationaleStatement": "This setting ensures that guests who no longer need access to the site or link no longer have access after a set period of time. Allowing guest access for an indefinite amount of time could lead to loss of data confidentiality and oversight. Note: Guest membership applies at the Microsoft 365 group level. Guests who have permission to view a SharePoint site or use a sharing link may also have access to a Microsoft Teams team or security group.", + "ImpactStatement": "Site collection administrators will have to renew access to guests who still need access after 30 days. They will receive an e-mail notification once per week about guest access that is about to expire. Note: The guest expiration policy only applies to guests who use sharing links or guests who have direct permissions to a SharePoint site after the guest policy is enabled. The guest policy does not apply to guest users that have pre-existing permissions or access through a sharing link before the guest expiration policy is applied.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Scroll to and expand More external sharing settings. 4. Set Guest access to a site or OneDrive will expire automatically after this many days to 30 To remediate using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following cmdlet: Set-SPOTenant -ExternalUserExpireInDays 30 -ExternalUserExpirationRequired $True", + "AuditProcedure": "To audit using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Scroll to and expand More external sharing settings. 4. Verify that Guest access to a site or OneDrive will expire automatically after this many days is checked and set to 30. To audit using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following cmdlet: Get-SPOTenant | fl ExternalUserExpirationRequired,ExternalUserExpireInDays 3. Verify the following values are returned: o ExternalUserExpirationRequired is True. o ExternalUserExpireInDays is 30.", + "AdditionalInformation": "", + "DefaultValue": "ExternalUserExpirationRequired $false ExternalUserExpireInDays 60 days", + "References": "https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off#change-the-organization-level-external-sharing-setting:https://learn.microsoft.com/en-us/microsoft-365/community/sharepoint-security-a-team-effort" + } + ] + }, + { + "Id": "7.2.10", + "Description": "This setting configures if guests who use a verification code to access the site or links are required to reauthenticate after a set number of days. The recommended state is 15 or less.", + "Checks": [], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.2 Policies", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting configures if guests who use a verification code to access the site or links are required to reauthenticate after a set number of days. The recommended state is 15 or less.", + "RationaleStatement": "By increasing the frequency of times guests need to reauthenticate this ensures guest user access to data is not prolonged beyond an acceptable amount of time.", + "ImpactStatement": "Guests who use Microsoft 365 in their organization can sign in using their work or school account to access the site or document. After the one-time passcode for verification has been entered for the first time, guests will authenticate with their work or school account and have a guest account created in the host's organization. Note: If OneDrive and SharePoint integration with Entra ID B2B is enabled as per the CIS Benchmark the one-time-passcode experience will be replaced. Please visit Secure external sharing in SharePoint - SharePoint in Microsoft 365 | Microsoft Learn for more information.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Scroll to and expand More external sharing settings. 4. Set People who use a verification code must reauthenticate after this many days to 15 or less. To remediate using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following cmdlet: Set-SPOTenant -EmailAttestationRequired $true -EmailAttestationReAuthDays 15", + "AuditProcedure": "To audit using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Scroll to and expand More external sharing settings. 4. Verify that People who use a verification code must reauthenticate after this many days is set to 15 or less. To audit using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following cmdlet: Get-SPOTenant | fl EmailAttestationRequired,EmailAttestationReAuthDays 3. Verify that the following values are returned: o EmailAttestationRequired True o EmailAttestationReAuthDays 15 or less days.", + "AdditionalInformation": "", + "DefaultValue": "EmailAttestationRequired : False EmailAttestationReAuthDays : 30", + "References": "https://learn.microsoft.com/en-us/sharepoint/what-s-new-in-sharing-in-targeted-release:https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off#change-the-organization-level-external-sharing-setting:https://learn.microsoft.com/en-us/entra/external-id/one-time-passcode" + } + ] + }, + { + "Id": "7.2.11", + "Description": "This setting configures the permission that is selected by default for sharing link from a SharePoint site. The recommended state is View.", + "Checks": [], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.2 Policies", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting configures the permission that is selected by default for sharing link from a SharePoint site. The recommended state is View.", + "RationaleStatement": "Setting the view permission as the default ensures that users must deliberately select the edit permission when sharing a link. This approach reduces the risk of unintentionally granting edit privileges to a resource that only requires read access, supporting the principle of least privilege.", + "ImpactStatement": "Not applicable.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Scroll to File and folder links. 4. Set Choose the permission that's selected by default for sharing links to View. To remediate using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following cmdlet: Set-SPOTenant -DefaultLinkPermission View", + "AuditProcedure": "To audit using the UI: 1. Navigate to SharePoint admin center https://admin.microsoft.com/sharepoint 2. Expand Policies > Sharing. 3. Scroll to File and folder links. 4. Verify that Choose the permission that's selected by default for sharing links is set to View. To audit using PowerShell: 1. Connect to SharePoint Online service using Connect-SPOService. 2. Run the following cmdlet: Get-SPOTenant | fl DefaultLinkPermission 3. Verify that the returned value is View.", + "AdditionalInformation": "", + "DefaultValue": "DefaultLinkPermission : Edit", + "References": "https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off#file-and-folder-links" + } + ] + }, + { + "Id": "7.3.1", + "Description": "By default, SharePoint online allows files that Defender for Office 365 has detected as infected to be downloaded.", + "Checks": [], + "Attributes": [ + { + "Section": "7 SharePoint admin center", + "SubSection": "7.3 Settings", + "Profile": "E5 Level 2", + "AssessmentStatus": "Automated", + "Description": "By default, SharePoint online allows files that Defender for Office 365 has detected as infected to be downloaded.", + "RationaleStatement": "Defender for Office 365 for SharePoint, OneDrive, and Microsoft Teams protects your organization from inadvertently sharing malicious files. When an infected file is detected that file is blocked so that no one can open, copy, move, or share it until further actions are taken by the organization's security team.", + "ImpactStatement": "The only potential impact associated with implementation of this setting is potential inconvenience associated with the small percentage of false positive detections that may occur.", + "RemediationProcedure": "To remediate using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService -Url https://tenant-admin.sharepoint.com, replacing \"tenant\" with the appropriate value. 2. Run the following PowerShell command to set the recommended value: Set-SPOTenant -DisallowInfectedFileDownload $true Note: The Global Reader role cannot access SharePoint using PowerShell according to Microsoft. See the reference section for more information.", + "AuditProcedure": "To audit using PowerShell: 1. Connect to SharePoint Online using Connect-SPOService -Url https://tenant-admin.sharepoint.com, replacing \"tenant\" with the appropriate value. 2. Run the following PowerShell command: Get-SPOTenant | Select-Object DisallowInfectedFileDownload 3. Ensure that the DisallowInfectedFileDownload is set to True. Note: According to Microsoft, SharePoint cannot be accessed through PowerShell by users with the Global Reader role. For further information, please refer to the reference section.", + "AdditionalInformation": "", + "DefaultValue": "False", + "References": "https://learn.microsoft.com/en-us/defender-office-365/safe-attachments-for-spo-odfb-teams-configure?view=o365-worldwide:https://learn.microsoft.com/en-us/defender-office-365/anti-malware-protection-for-spo-odfb-teams-about?view=o365-worldwide:https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#global-reader" + } + ] + }, + { + "Id": "8.1.1", + "Description": "Microsoft Teams enables collaboration via file sharing. This file sharing is conducted within Teams, using SharePoint Online, by default; however, third-party cloud services are allowed as well. Note: Skype for business is deprecated as of July 31, 2021 although these settings may still be valid for a period of time. See the link in the references section for more information.", + "Checks": [ + "teams_external_file_sharing_restricted" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.1 Teams", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Microsoft Teams enables collaboration via file sharing. This file sharing is conducted within Teams, using SharePoint Online, by default; however, third-party cloud services are allowed as well. Note: Skype for business is deprecated as of July 31, 2021 although these settings may still be valid for a period of time. See the link in the references section for more information.", + "RationaleStatement": "Ensuring that only authorized cloud storage providers are accessible from Teams will help to dissuade the use of non-approved storage providers.", + "ImpactStatement": "The impact associated with this change is highly dependent upon current practices in the tenant. If users do not use other storage providers, then minimal impact is likely. However, if users do regularly utilize providers outside of the tenant this will affect their ability to continue to do so.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Select Settings & policies > Global (Org-wide default) settings. 3. Click Teams to open the Teams settings section. 4. Under files set storages providers to Off unless they have first been authorized by the organization. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams 2. Run the following PowerShell command to disable external providers that are not authorized. (the example disables Citrix Files, DropBox, Box, Google Drive and Egnyte) $Params = @{ Identity = 'Global' AllowGoogleDrive = $false AllowShareFile = $false AllowBox = $false AllowDropBox = $false AllowEgnyte = $false } Set-CsTeamsClientConfiguration @Params", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Select Settings & policies > Global (Org-wide default) settings. 3. Click Teams to open the Teams settings section. 4. Under files verify that only organizationally authorized cloud storage options are set to On and all others Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams 2. Run the following to verify the recommended state: $Params = @( 'AllowDropbox' 'AllowBox' 'AllowGoogleDrive' 'AllowShareFile' 'AllowEgnyte' ) Get-CsTeamsClientConfiguration -Identity Global | fl $Params 3. Verify that only authorized providers are set to True and all others False.", + "AdditionalInformation": "", + "DefaultValue": "AllowDropBox : True AllowBox : True AllowGoogleDrive : True AllowShareFile : True AllowEgnyte : True", + "References": "https://learn.microsoft.com/en-us/microsoftteams/teams-powershell-managing-teams" + } + ] + }, + { + "Id": "8.1.2", + "Description": "This setting controls whether Teams channels are allowed to receive emails sent to their unique email addresses. When enabled, emails sent to a channel's address will be delivered and appear in the channel's conversation thread; when disabled, the channel will reject incoming emails, preventing them from being posted. The recommended state is Off.", + "Checks": [ + "teams_email_sending_to_channel_disabled" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.1 Teams", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting controls whether Teams channels are allowed to receive emails sent to their unique email addresses. When enabled, emails sent to a channel's address will be delivered and appear in the channel's conversation thread; when disabled, the channel will reject incoming emails, preventing them from being posted. The recommended state is Off.", + "RationaleStatement": "Channel email addresses are not under the tenant's domain and organizations do not have control over the security settings for this email address. An attacker could email channels directly if they discover the channel email address.", + "ImpactStatement": "Depending on the organization's adoption, disabling this may disrupt workflows that rely on email-to-channel communication, particularly in environments where email is used to bridge external systems or vendors into Teams. This could include reduced visibility of important updates or alerts that were previously routed into Teams channels via email.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Select Settings & policies > Global (Org-wide default) settings. 3. Click Teams to open the Teams settings section. 4. Under email integration set Users can send emails to a channel email address to Off. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to set the recommended state: Set-CsTeamsClientConfiguration -Identity Global -AllowEmailIntoChannel $false", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Select Settings & policies > Global (Org-wide default) settings. 3. Click Teams to open the Teams settings section. 4. Under email integration verify that Users can send emails to a channel email address is Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to verify the recommended state: Get-CsTeamsClientConfiguration -Identity Global | fl AllowEmailIntoChannel 3. Ensure the returned value is False.", + "AdditionalInformation": "", + "DefaultValue": "On (True)", + "References": "https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/step-by-step-guides/reducing-attack-surface-in-microsoft-teams?view=o365-worldwide#restricting-channel-email-messages-to-approved-domains:https://learn.microsoft.com/en-us/microsoftteams/settings-policies-reference#email-integration:https://support.microsoft.com/en-us/office/send-an-email-to-a-channel-in-microsoft-teams-d91db004-d9d7-4a47-82e6-fb1b16dfd51e" + } + ] + }, + { + "Id": "8.2.1", + "Description": "This policy controls whether external domains are allowed, blocked or permitted based on an allowlist or denylist. When external domains are allowed, users in your organization can chat, add users to meetings, and use audio video conferencing with users in external organizations. The recommended state is Off on the Global (Org-wide default) policy.", + "Checks": [ + "teams_external_domains_restricted" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.2 Users", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "This policy controls whether external domains are allowed, blocked or permitted based on an allowlist or denylist. When external domains are allowed, users in your organization can chat, add users to meetings, and use audio video conferencing with users in external organizations. The recommended state is Off on the Global (Org-wide default) policy.", + "RationaleStatement": "Unrestricted external federation allows any Teams user from any organization to initiate contact with your users, making them susceptible to social engineering, phishing, and malware delivery via Teams chat. Restricting external domains to an allowlist or blocking them entirely eliminates this unsolicited contact vector. Real-world attacks and exploits delivered via Teams over external access channels include: - DarkGate malware - Social engineering / phishing attacks by \"Midnight Blizzard\" - GIFShell - Username enumeration", + "ImpactStatement": "Restricting external domains will limit users' ability to collaborate with individuals outside the organization unless their domain is explicitly allowlisted or they are invited as a guest in Microsoft Entra ID. Administrators choosing an allowlist approach will incur ongoing overhead to manage approved domains as external collaboration needs evolve. Note: Organizations may create custom external access policies with federation enabled and assign them to specific users or groups requiring external access, while keeping the Global (Org-wide default) policy restrictive.", + "RemediationProcedure": "Note: Configuring this setting at the organization level in Organization settings to either Off, Block all external domains or Allow only specific external domains is also a compliant remediation for this control. To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com/. 2. Expand External collaboration and select External access. 3. Open the Policies tab. 4. Click on the Global (Org-wide default) settings policy. 5. Set Manage external domains for this policy to Off. 6. Click Save. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams 2. Run the following command to configure the Global (Org-wide default) policy. Set-CsExternalAccessPolicy -Identity Global -EnableFederationAccess $false", + "AuditProcedure": "Note: The focus of this control at a minimum is the Global (Org-wide default) policy. If the organization-wide setting is configured to Allow only specific external domains or Block all external domains, then this is also considered a passing state due to its increased restrictiveness. To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com/. 2. Expand External collaboration and select External access. 3. Open the Policies tab. 4. Click on the Global (Org-wide default) settings policy. 5. Verify that Manage external domains for this policy is set to Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams 2. Run the following command: Get-CsExternalAccessPolicy -Identity Global 3. Verify that EnableFederationAccess is False. Organization settings: Optional passing state 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com/. 2. Expand External collaboration and select External access. 3. Open the Organization settings tab. 4. Verify that Manage external domains for this organization is set to one of the following: o Off o On with Allow or block external domains set to Allow only specific external domains o On with Allow or block external domains set to Block all external domains To audit using PowerShell: 1. Run the following command: Get-CsTenantFederationConfiguration | fl AllowFederatedUsers,AllowedDomains 2. Verify the output meets one of the following compliant conditions: o Off: AllowFederatedUsers is False o Block all external domains: AllowFederatedUsers is True and AllowedDomains is empty o Allow only specific external domains: AllowFederatedUsers is True and AllowedDomains contains only authorized domain names", + "AdditionalInformation": "", + "DefaultValue": "EnableFederationAccess - $True", + "References": "https://learn.microsoft.com/en-us/microsoftteams/trusted-organizations-external-meetings-chat?tabs=organization-settings:https://www.microsoft.com/en-us/security/blog/2023/08/02/midnight-blizzard-conducts-targeted-social-engineering-over-microsoft-teams/:https://www.bitdefender.com/blog/hotforsecurity/gifshell-attack-lets-hackers-create-reverse-shell-through-microsoft-teams-gifs/" + } + ] + }, + { + "Id": "8.2.2", + "Description": "This policy setting controls chats and meetings initiated through the external access channel with unmanaged Teams users (those not managed by an organization, such as Microsoft Teams (free)). This does not govern anonymous meeting join via shared link, which is controlled separately. The recommended state is: People in my org can chat and have meetings with external users who have unmanaged Microsoft accounts set to Off.", + "Checks": [ + "teams_unmanaged_communication_disabled" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.2 Users", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This policy setting controls chats and meetings initiated through the external access channel with unmanaged Teams users (those not managed by an organization, such as Microsoft Teams (free)). This does not govern anonymous meeting join via shared link, which is controlled separately. The recommended state is: People in my org can chat and have meetings with external users who have unmanaged Microsoft accounts set to Off.", + "RationaleStatement": "Allowing users to communicate with unmanaged Teams users presents a potential security threat as little effort is required by threat actors to gain access to a trial or free Microsoft Teams account. Real-world attacks and exploits delivered via Teams over external access channels include: - DarkGate malware - Social engineering / Phishing attacks by \"Midnight Blizzard\" - GIFShell - Username enumeration", + "ImpactStatement": "Users will be unable to communicate with Teams users who are not managed by an organization. Organizations may choose to create additional policies for specific groups needing to communicate with unmanaged external users. Note: The settings that govern chats and meetings with external unmanaged Teams users aren't available in GCC, GCC High, or DOD deployments, or in private cloud environments.", + "RemediationProcedure": "Note: Configuring this setting at the organization level in Organization settings to Off is also a compliant remediation for this control. To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com/. 2. Expand External collaboration and select External access. 3. Open the Policies tab. 4. Click on the Global (Org-wide default) settings policy. 5. Set People in my org can chat and have meetings with external users who have unmanaged Microsoft accounts to Off. 6. Click Save. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams 2. Run the following command: Set-CsExternalAccessPolicy -Identity Global -EnableTeamsConsumerAccess $false", + "AuditProcedure": "Note: The focus of this control at a minimum is the Global (Org-wide default) policy. If the organization-wide setting is configured to Off, then this is also considered a passing state due to its increased restrictiveness. To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com/. 2. Expand External collaboration and select External access. 3. Open the Policies tab. 4. Click on the Global (Org-wide default) settings policy. 5. Verify that People in my org can chat and have meetings with external users who have unmanaged Microsoft accounts is set to Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams 2. Run the following command: Get-CsExternalAccessPolicy -Identity Global Verify that EnableTeamsConsumerAccess is set to False. Organization settings: Optional passing state 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com/. 2. Expand External collaboration and select External access. 3. Open the Organization settings tab. 4. Verify that People in my org can chat and have meetings with external users who have unmanaged Microsoft accounts is set to Off. To audit using PowerShell: 1. Run the following command: Get-CsTenantFederationConfiguration | fl AllowTeamsConsumer 2. Verify that AllowTeamsConsumer is False.", + "AdditionalInformation": "", + "DefaultValue": "- EnableTeamsConsumerAccess (Global policy): True - AllowTeamsConsumer (Organization settings): True", + "References": "https://learn.microsoft.com/en-us/microsoftteams/trusted-organizations-external-meetings-chat?tabs=organization-settings:https://www.microsoft.com/en-us/security/blog/2023/08/02/midnight-blizzard-conducts-targeted-social-engineering-over-microsoft-teams/:https://www.bitdefender.com/blog/hotforsecurity/gifshell-attack-lets-hackers-create-reverse-shell-through-microsoft-teams-gifs/" + } + ] + }, + { + "Id": "8.2.3", + "Description": "This setting prevents external users who are not managed by an organization from initiating contact with users in the protected organization. The recommended state is to uncheck People in my org can chat and have meetings with external users who have unmanaged Microsoft accounts. Note: Disabling this setting is used as an additional stop gap for the parent setting which disables communication with unmanaged Teams users entirely. If an organization chooses to have an exception to Ensure communication with unmanaged Teams users is disabled they can do so while also disabling the ability for the same group of users to initiate contact. Disabling communication entirely will also disable the ability for unmanaged users to initiate contact.", + "Checks": [ + "teams_external_users_cannot_start_conversations" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.2 Users", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting prevents external users who are not managed by an organization from initiating contact with users in the protected organization. The recommended state is to uncheck People in my org can chat and have meetings with external users who have unmanaged Microsoft accounts. Note: Disabling this setting is used as an additional stop gap for the parent setting which disables communication with unmanaged Teams users entirely. If an organization chooses to have an exception to Ensure communication with unmanaged Teams users is disabled they can do so while also disabling the ability for the same group of users to initiate contact. Disabling communication entirely will also disable the ability for unmanaged users to initiate contact.", + "RationaleStatement": "Allowing users to communicate with unmanaged Teams users presents a potential security threat as little effort is required by threat actors to gain access to a trial or free Microsoft Teams account. Real-world attacks and exploits delivered via Teams over external access channels include: - DarkGate malware - Social engineering / Phishing attacks by \"Midnight Blizzard\" - GIFShell - Username enumeration", + "ImpactStatement": "Unmanaged Teams users (those using personal Microsoft accounts or free Teams) will be unable to initiate new chats or meeting invitations with members of the organization. Organization members may still be able to join externally-initiated meetings depending on the configuration of the parent setting. Organizations that need to allow inbound contact from specific external users can assign a custom external access policy to those users that has EnableTeamsConsumerInbound enabled. Note: Chats and meetings with external unmanaged Teams users isn't available in GCC, GCC High, or DOD deployments, or in private cloud environments.", + "RemediationProcedure": "Note: Configuring this setting at the organization level in Organization settings to Off is also a compliant remediation for this control. To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com/. 2. Expand External collaboration and select External access. 3. Open the Policies tab. 4. Click on the Global (Org-wide default) settings policy. 5. Locate the parent setting People in my org can chat and have meetings with external users who have unmanaged Microsoft accounts. 6. Uncheck People in my org can join external meetings and receive new chats from users who have unmanaged Microsoft accounts. 7. Click Save. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams 2. Run the following command: Set-CsExternalAccessPolicy -Identity Global -EnableTeamsConsumerInbound $false", + "AuditProcedure": "Note: The focus of this control at a minimum is the Global (Org-wide default) policy. If the equivalent organization-wide setting is disabled, then this is also considered a passing state due to its increased restrictiveness. To audit using the UI: Note: If the parent setting People in my org can chat and have meetings with external users who have unmanaged Microsoft accounts is already set to Off then this setting will not be visible in the UI. 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com/. 2. Expand External collaboration and select External access. 3. Open the Policies tab. 4. Click on the Global (Org-wide default) settings policy. 5. Locate the parent setting People in my org can chat and have meetings with external users who have unmanaged Microsoft accounts. 6. Verify that People in my org can join external meetings and receive new chats from users who have unmanaged Microsoft accounts is not checked. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams 2. Run the following command: Get-CsExternalAccessPolicy -Identity Global Verify that EnableTeamsConsumerInbound is False Organization settings: Optional passing state 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com/. 2. Expand External collaboration and select External access. 3. Select the Organization settings tab. 4. Locate the parent setting People in my org can chat and have meetings with external users who have unmanaged Microsoft accounts. 5. Verify that People in my org can join external meetings and receive new chats from users who have unmanaged Microsoft accounts is not checked. To audit using PowerShell: 1. Run the following command: Get-CsTenantFederationConfiguration | fl AllowTeamsConsumerInbound Verify that AllowTeamsConsumerInbound is False", + "AdditionalInformation": "", + "DefaultValue": "- EnableTeamsConsumerInbound (Global policy) : True - AllowTeamsConsumerInbound (Organization settings) : True", + "References": "https://learn.microsoft.com/en-us/microsoftteams/trusted-organizations-external-meetings-chat?tabs=organization-settings:https://www.microsoft.com/en-us/security/blog/2023/08/02/midnight-blizzard-conducts-targeted-social-engineering-over-microsoft-teams/:https://www.bitdefender.com/blog/hotforsecurity/gifshell-attack-lets-hackers-create-reverse-shell-through-microsoft-teams-gifs/" + } + ] + }, + { + "Id": "8.2.4", + "Description": "This setting controls the organization's external access with Teams \"trial-only\" tenants. These are tenants that don't have any purchased seats. When set to Blocked, users from these trial-only tenants aren't able to search and contact your users via chats, Teams calls, and meetings (using the users' authenticated identities) and your users aren't able to reach users in these trial-only tenants. Users from the trial-only tenant are also removed from existing chats. The recommended state for People in my organization can communicate with accounts in trial Teams tenant is Off.", + "Checks": [], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.2 Users", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting controls the organization's external access with Teams \"trial-only\" tenants. These are tenants that don't have any purchased seats. When set to Blocked, users from these trial-only tenants aren't able to search and contact your users via chats, Teams calls, and meetings (using the users' authenticated identities) and your users aren't able to reach users in these trial-only tenants. Users from the trial-only tenant are also removed from existing chats. The recommended state for People in my organization can communicate with accounts in trial Teams tenant is Off.", + "RationaleStatement": "Microsoft introduced this setting as Off by default on July 29, 2024 in order to block attack vectors being exploited by threat actors who have abused trial tenants. Enforcing the default ensures the setting is not reenabled for any reason. Allowing users to communicate with unmanaged Teams users presents a potential security threat as little effort is required by threat actors to gain access to a trial or free Microsoft Teams account. Real-world attacks and exploits delivered via Teams over external access channels include: - DarkGate malware - Social engineering / Phishing attacks by \"Midnight Blizzard\" - GIFShell - Username enumeration", + "ImpactStatement": "Users currently in chat conversations with accounts from trial tenants will be removed from those existing chats when this setting is disabled. Organizations that have established communication with external contacts who are using trial tenants will need to use alternative channels (such as email) until those contacts migrate to a licensed tenant.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com/. 2. Expand External collaboration and select External access. 3. Select the Organization settings tab. 4. Set People in my organization can communicate with accounts in trial Teams tenant to Off. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams 2. Run the following command: Set-CsTenantFederationConfiguration -ExternalAccessWithTrialTenants \"Blocked\"", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com/. 2. Expand External collaboration and select External access. 3. Select the Organization settings tab. 4. Verify that People in my organization can communicate with accounts in trial Teams tenant is set to Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams 2. Run the following command: Get-CsTenantFederationConfiguration Verify that ExternalAccessWithTrialTenants is set to Blocked.", + "AdditionalInformation": "", + "DefaultValue": "- Off (UI) - Blocked (PowerShell)", + "References": "https://learn.microsoft.com/en-us/microsoftteams/trusted-organizations-external-meetings-chat?tabs=organization-settings#block-federation-with-teams-trial-only-tenants:https://www.microsoft.com/en-us/security/blog/2023/08/02/midnight-blizzard-conducts-targeted-social-engineering-over-microsoft-teams/:https://www.bitdefender.com/en-us/blog/hotforsecurity/gifshell-attack-lets-hackers-create-reverse-shell-through-microsoft-teams-gifs" + } + ] + }, + { + "Id": "8.4.1", + "Description": "This policy setting controls which class of apps are available for users to install.", + "Checks": [], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.4 Teams apps", + "Profile": "E3 Level 1", + "AssessmentStatus": "Manual", + "Description": "This policy setting controls which class of apps are available for users to install.", + "RationaleStatement": "Allowing users to install third-party or unverified apps poses a potential risk of introducing malicious software to the environment.", + "ImpactStatement": "Users will only be able to install approved classes of apps.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Expand Teams apps and select Manage apps. 3. In the upper right click Actions > Org-wide app settings. 4. For Third-party apps set Let users install and use available apps by default to Off. 5. For Custom apps set Let users install and use available apps by default to Off. 6. For Custom apps set Let users interact with custom apps in preview to Off.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Expand Teams apps and select Manage apps. 3. In the upper right click Actions > Org-wide app settings. 4. For Third-party apps verify Let users install and use available apps by default is Off. 5. For Custom apps verify Let users install and use available apps by default is Off. 6. For Custom apps verify Let users interact with custom apps in preview is Off.", + "AdditionalInformation": "", + "DefaultValue": "- Third-party apps: On - Custom apps: On", + "References": "https://learn.microsoft.com/en-us/microsoftteams/app-centric-management:https://learn.microsoft.com/en-us/defender-office-365/step-by-step-guides/reducing-attack-surface-in-microsoft-teams?view=o365-worldwide#disabling-third-party--custom-apps" + } + ] + }, + { + "Id": "8.5.1", + "Description": "Anonymous users are users whose identity can't be verified. They may be logged in to an organization without a mutual trust relationship or they may not have an account (guest or user). Anonymous participants appear with \"(Unverified)\" appended to their name in meetings. These users could include: - Users who aren't logged in to Teams with a work or school account. - Users from non-trusted organizations (as configured in external access) and from organizations that you trust but which don't trust your organization. When defining trusted organizations for external meetings and chat, ensure both organizations allow each other's domains. Meeting organizers and participants should have user policies that allow external access. These settings prevent attendees from being considered anonymous due to external access settings. For details, see IT Admins - Manage external meetings and chat with people and organizations using Microsoft identities The recommended state is Anonymous users can join a meeting unverified set to Off.", + "Checks": [ + "teams_meeting_anonymous_user_join_disabled" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.5 Meetings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Anonymous users are users whose identity can't be verified. They may be logged in to an organization without a mutual trust relationship or they may not have an account (guest or user). Anonymous participants appear with \"(Unverified)\" appended to their name in meetings. These users could include: - Users who aren't logged in to Teams with a work or school account. - Users from non-trusted organizations (as configured in external access) and from organizations that you trust but which don't trust your organization. When defining trusted organizations for external meetings and chat, ensure both organizations allow each other's domains. Meeting organizers and participants should have user policies that allow external access. These settings prevent attendees from being considered anonymous due to external access settings. For details, see IT Admins - Manage external meetings and chat with people and organizations using Microsoft identities The recommended state is Anonymous users can join a meeting unverified set to Off.", + "RationaleStatement": "For meetings that could contain sensitive information, it is best to allow the meeting organizer to vet anyone not directly sent an invite before admitting them to the meeting. This will also prevent the anonymous user from using the meeting link to have meetings at unscheduled times. Note: Those companies that don't normally operate at a Level 2 environment, but do deal with sensitive information, may want to consider this policy setting.", + "ImpactStatement": "Individuals who were not sent or forwarded a meeting invite will not be able to join the meeting automatically.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under meeting join & lobby set Anonymous users can join a meeting unverified to Off. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams 2. Run the following command to set the recommended state: Set-CsTeamsMeetingPolicy -Identity Global -AllowAnonymousUsersToJoinMeeting $false", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under meeting join & lobby verify that Anonymous users can join a meeting unverified is set to Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to verify the recommended state: Get-CsTeamsMeetingPolicy -Identity Global | fl AllowAnonymousUsersToJoinMeeting 3. Verify that the returned value is False.", + "AdditionalInformation": "", + "DefaultValue": "On (True)", + "References": "https://learn.microsoft.com/en-us/defender-office-365/step-by-step-guides/reducing-attack-surface-in-microsoft-teams?view=o365-worldwide#configure-meeting-settings:https://learn.microsoft.com/en-us/microsoftteams/settings-policies-reference?WT.mc_id=TeamsAdminCenterCSH#meeting-join--lobby:https://learn.microsoft.com/en-us/MicrosoftTeams/configure-meetings-sensitive-protection:https://learn.microsoft.com/en-us/microsoftteams/anonymous-users-in-meetings:https://learn.microsoft.com/en-us/microsoftteams/plan-meetings-external-participants" + } + ] + }, + { + "Id": "8.5.2", + "Description": "This policy setting controls if an anonymous participant can start a Microsoft Teams meeting without someone in attendance. Anonymous users and dial-in callers must wait in the lobby until the meeting is started by someone in the organization or an external user from a trusted organization. Anonymous participants are classified as: - Participants who are not logged in to Teams with a work or school account. - Participants from non-trusted organizations (as configured in external access). - Participants from organizations where there is not mutual trust. Note: This setting only applies when Who can bypass the lobby is set to Everyone. If the anonymous users can join a meeting organization-level setting or meeting policy is Off, this setting only applies to dial-in callers.", + "Checks": [ + "teams_meeting_anonymous_user_start_disabled" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.5 Meetings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This policy setting controls if an anonymous participant can start a Microsoft Teams meeting without someone in attendance. Anonymous users and dial-in callers must wait in the lobby until the meeting is started by someone in the organization or an external user from a trusted organization. Anonymous participants are classified as: - Participants who are not logged in to Teams with a work or school account. - Participants from non-trusted organizations (as configured in external access). - Participants from organizations where there is not mutual trust. Note: This setting only applies when Who can bypass the lobby is set to Everyone. If the anonymous users can join a meeting organization-level setting or meeting policy is Off, this setting only applies to dial-in callers.", + "RationaleStatement": "Not allowing anonymous participants to automatically join a meeting reduces the risk of meeting spamming.", + "ImpactStatement": "Anonymous participants will not be able to start a Microsoft Teams meeting.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under meeting join & lobby set Anonymous users and dial-in callers can start a meeting to Off. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to set the recommended state: Set-CsTeamsMeetingPolicy -Identity Global -AllowAnonymousUsersToStartMeeting $false", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under meeting join & lobby verify that Anonymous users and dial-in callers can start a meeting is set to Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to verify the recommended state: Get-CsTeamsMeetingPolicy -Identity Global | fl AllowAnonymousUsersToStartMeeting 3. Verify that the returned value is False.", + "AdditionalInformation": "", + "DefaultValue": "Off (False)", + "References": "https://learn.microsoft.com/en-us/microsoftteams/anonymous-users-in-meetings:https://learn.microsoft.com/en-us/microsoftteams/who-can-bypass-meeting-lobby#overview-of-lobby-settings-and-policies" + } + ] + }, + { + "Id": "8.5.3", + "Description": "This policy setting controls who can join a meeting directly and who must wait in the lobby until they're admitted by an organizer, co-organizer, or presenter of the meeting. The recommended state is People who were invited, People in my org or Only organizers and co-organizers.", + "Checks": [ + "teams_meeting_external_lobby_bypass_disabled" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.5 Meetings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This policy setting controls who can join a meeting directly and who must wait in the lobby until they're admitted by an organizer, co-organizer, or presenter of the meeting. The recommended state is People who were invited, People in my org or Only organizers and co-organizers.", + "RationaleStatement": "For meetings that could contain sensitive information, it is best to allow the meeting organizer to vet anyone not directly sent an invite before admitting them to the meeting. This will also prevent the anonymous user from using the meeting link to have meetings at unscheduled times.", + "ImpactStatement": "Individuals who are not part of the organization will have to wait in the lobby until they're admitted by an organizer, co-organizer, or presenter of the meeting. Any individual who dials into the meeting regardless of status will also have to wait in the lobby. This includes internal users who are considered unauthenticated when dialing in.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under meeting join & lobby set Who can bypass the lobby to one of the following: o People who were invited o People in my org o Only organizers and co-organizers To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run one of the following PowerShell commands depending on the desired compliant state: To set to People who were invited: Set-CsTeamsMeetingPolicy -Identity Global -AutoAdmittedUsers \"InvitedUsers\" To set to People in my org: Set-CsTeamsMeetingPolicy -Identity Global -AutoAdmittedUsers \"EveryoneInCompanyExcludingGuests\" To set to Only organizers and co-organizers: Set-CsTeamsMeetingPolicy -Identity Global -AutoAdmittedUsers \"OrganizerOnly\"", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under meeting join & lobby verify Who can bypass the lobby is set to one of the following: o People who were invited o People in my org o Only organizers and co-organizers To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to verify the recommended state: Get-CsTeamsMeetingPolicy -Identity Global | fl AutoAdmittedUsers 3. Verify that the returned value is one of the following strings: o InvitedUsers o EveryoneInCompanyExcludingGuests o OrganizerOnly", + "AdditionalInformation": "", + "DefaultValue": "People in my org and guests (EveryoneInCompany)", + "References": "https://learn.microsoft.com/en-us/microsoftteams/who-can-bypass-meeting-lobby#overview-of-lobby-settings-and-policies:https://learn.microsoft.com/en-us/powershell/module/skype/set-csteamsmeetingpolicy?view=skype-ps" + } + ] + }, + { + "Id": "8.5.4", + "Description": "This policy setting controls if users who dial in by phone can join the meeting directly or must wait in the lobby. Admittance to the meeting from the lobby is authorized by the meeting organizer, co-organizer, or presenter of the meeting.", + "Checks": [ + "teams_meeting_dial_in_lobby_bypass_disabled" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.5 Meetings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This policy setting controls if users who dial in by phone can join the meeting directly or must wait in the lobby. Admittance to the meeting from the lobby is authorized by the meeting organizer, co-organizer, or presenter of the meeting.", + "RationaleStatement": "For meetings that could contain sensitive information, it is best to allow the meeting organizer to vet anyone not directly from the organization.", + "ImpactStatement": "Individuals who are dialing in to the meeting must wait in the lobby until a meeting organizer, co-organizer, or presenter admits them.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under meeting join & lobby set People dialing in can bypass the lobby to Off. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to set the recommended state: Set-CsTeamsMeetingPolicy -Identity Global -AllowPSTNUsersToBypassLobby $false", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under meeting join & lobby verify that People dialing in can bypass the lobby is set to Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to verify the recommended state: Get-CsTeamsMeetingPolicy -Identity Global | fl AllowPSTNUsersToBypassLobby 3. Verify that the value is False.", + "AdditionalInformation": "", + "DefaultValue": "Off (False)", + "References": "https://learn.microsoft.com/en-us/microsoftteams/who-can-bypass-meeting-lobby#overview-of-lobby-settings-and-policies:https://learn.microsoft.com/en-us/powershell/module/skype/set-csteamsmeetingpolicy?view=skype-ps" + } + ] + }, + { + "Id": "8.5.5", + "Description": "This policy setting controls who has access to read and write chat messages during a meeting.", + "Checks": [ + "teams_meeting_chat_anonymous_users_disabled" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.5 Meetings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "This policy setting controls who has access to read and write chat messages during a meeting.", + "RationaleStatement": "Ensuring that only authorized individuals can read and write chat messages during a meeting reduces the risk that a malicious user can inadvertently show content that is not appropriate or view sensitive information.", + "ImpactStatement": "Only authorized individuals will be able to read and write chat messages during a meeting.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under meeting engagement set Meeting chat to On for everyone but anonymous users. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to set the minimum recommended state: Set-CsTeamsMeetingPolicy -Identity Global -MeetingChatEnabledType \"EnabledExceptAnonymous\" Note: The audit section outlines additional compliant states which are more restrictive than the recommended state.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under meeting engagement verify that Meeting chat is set to On for everyone but anonymous users or a more restrictive value: In-meeting only except anonymous or Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to verify the recommended state: Get-CsTeamsMeetingPolicy -Identity Global | fl MeetingChatEnabledType 3. Verify that the returned value is EnabledExceptAnonymous or a more restrictive value EnabledInMeetingOnlyForAllExceptAnonymous or Disabled.", + "AdditionalInformation": "", + "DefaultValue": "On for everyone (Enabled)", + "References": "https://learn.microsoft.com/en-us/powershell/module/skype/set-csteamsmeetingpolicy?view=skype-ps#-meetingchatenabledtype" + } + ] + }, + { + "Id": "8.5.6", + "Description": "This policy setting controls who can present in a Teams meeting. Note: Organizers and co-organizers can change this setting when the meeting is set up.", + "Checks": [ + "teams_meeting_presenters_restricted" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.5 Meetings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "This policy setting controls who can present in a Teams meeting. Note: Organizers and co-organizers can change this setting when the meeting is set up.", + "RationaleStatement": "Ensuring that only authorized individuals are able to present reduces the risk that a malicious user can inadvertently show content that is not appropriate.", + "ImpactStatement": "Only organizers and co-organizers will be able to present without being granted permission.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under content sharing set Who can present to Only organizers and co- organizers. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to set the recommended state: Set-CsTeamsMeetingPolicy -Identity Global -DesignatedPresenterRoleMode \"OrganizerOnlyUserOverride\"", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under content sharing verify Who can present is set to Only organizers and co-organizers. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to verify the recommended state: Get-CsTeamsMeetingPolicy -Identity Global | fl DesignatedPresenterRoleMode 3. Verify that the returned value is OrganizerOnlyUserOverride.", + "AdditionalInformation": "", + "DefaultValue": "Everyone (EveryoneUserOverride)", + "References": "https://learn.microsoft.com/en-US/microsoftteams/meeting-who-present-request-control:https://learn.microsoft.com/en-us/microsoftteams/meeting-who-present-request-control#manage-who-can-present:https://learn.microsoft.com/en-us/defender-office-365/step-by-step-guides/reducing-attack-surface-in-microsoft-teams?view=o365-worldwide#configure-meeting-settings-restrict-presenters:https://learn.microsoft.com/en-us/powershell/module/skype/set-csteamsmeetingpolicy?view=skype-ps" + } + ] + }, + { + "Id": "8.5.7", + "Description": "This policy setting allows control of who can present in meetings and who can request control of the presentation while a meeting is underway.", + "Checks": [ + "teams_meeting_external_control_disabled" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.5 Meetings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This policy setting allows control of who can present in meetings and who can request control of the presentation while a meeting is underway.", + "RationaleStatement": "Ensuring that only authorized individuals and not external participants are able to present and request control reduces the risk that a malicious user can inadvertently show content that is not appropriate. External participants are categorized as follows: external users, guests, and anonymous users.", + "ImpactStatement": "External participants will not be able to present or request control during the meeting. Warning: This setting also affects webinars. Note: At this time, to give and take control of shared content during a meeting, both parties must be using the Teams desktop client. Control isn't supported when either party is running Teams in a browser.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under content sharing set External participants can give or request control to Off. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to set the recommended state: Set-CsTeamsMeetingPolicy -Identity Global - AllowExternalParticipantGiveRequestControl $false", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under content sharing verify that External participants can give or request control is Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to verify the recommended state: Get-CsTeamsMeetingPolicy -Identity Global | fl AllowExternalParticipantGiveRequestControl 3. Verify that the returned value is False.", + "AdditionalInformation": "", + "DefaultValue": "Off (False)", + "References": "https://learn.microsoft.com/en-us/microsoftteams/meeting-who-present-request-control:https://learn.microsoft.com/en-us/powershell/module/skype/set-csteamsmeetingpolicy?view=skype-ps" + } + ] + }, + { + "Id": "8.5.8", + "Description": "This meeting policy setting controls whether users can read or write messages in external meeting chats with untrusted organizations. If an external organization is on the list of trusted organizations this setting will be ignored.", + "Checks": [ + "teams_meeting_external_chat_disabled" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.5 Meetings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "This meeting policy setting controls whether users can read or write messages in external meeting chats with untrusted organizations. If an external organization is on the list of trusted organizations this setting will be ignored.", + "RationaleStatement": "Restricting access to chat in meetings hosted by external organizations limits the opportunity for an exploit like GIFShell or DarkGate malware from being delivered to users.", + "ImpactStatement": "When joining external meetings users will be unable to read or write chat messages in Teams meetings with organizations that they don't have a trust relationship with. This will completely remove the chat functionality in meetings. From an I.T. perspective both the upkeep of adding new organizations to the trusted list and the decision-making process behind whether to trust or not trust an external partner will increase time expenditure.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab.. 3. Select Meetings to open the meeting settings section. 4. Under meeting engagement set External meeting chat to Off. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to set the recommended state: Set-CsTeamsMeetingPolicy -Identity Global -AllowExternalNonTrustedMeetingChat $false", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under meeting engagement verify that External meeting chat is set to Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to verify the recommended state: Get-CsTeamsMeetingPolicy -Identity Global | fl AllowExternalNonTrustedMeetingChat 3. Verify that the returned value is False.", + "AdditionalInformation": "", + "DefaultValue": "On(True)", + "References": "https://learn.microsoft.com/en-us/microsoftteams/settings-policies-reference#meeting-engagement" + } + ] + }, + { + "Id": "8.5.9", + "Description": "This setting controls the ability for a user to initiate a recording of a meeting in progress. The recommended state is Off for the Global (Org-wide default) meeting policy.", + "Checks": [ + "teams_meeting_recording_disabled" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.5 Meetings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "This setting controls the ability for a user to initiate a recording of a meeting in progress. The recommended state is Off for the Global (Org-wide default) meeting policy.", + "RationaleStatement": "Disabling meeting recordings in the Global meeting policy ensures that only authorized users, such as organizers, co-organizers, and leads, can initiate a recording. This measure helps safeguard sensitive information by preventing unauthorized individuals from capturing and potentially sharing meeting content. Restricting recording capabilities to specific roles allows organizations to exercise greater control over what is recorded, aligning it with the meeting's confidentiality requirements. Note: Creating a separate policy for users or groups who are allowed to record is expected and in compliance. This control is only for the default meeting policy.", + "ImpactStatement": "If there are no additional policies allowing anyone to record, then recording will effectively be disabled.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under Recording & transcription set Meeting recording to Off. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to set the recommended state: Set-CsTeamsMeetingPolicy -Identity Global -AllowCloudRecording $false", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Meetings to open the meeting settings section. 4. Under Recording & transcription verify that Meeting recording is set to Off. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following command to verify the recommended state: Get-CsTeamsMeetingPolicy -Identity Global | fl AllowCloudRecording 3. Verify that the returned value is False.", + "AdditionalInformation": "", + "DefaultValue": "On (True)", + "References": "https://learn.microsoft.com/en-us/microsoftteams/settings-policies-reference#recording--transcription" + } + ] + }, + { + "Id": "8.6.1", + "Description": "User reporting settings allow a user to report a message as malicious for further analysis. This recommendation is composed of 3 different settings and all must be configured for compliance: - In the Teams admin center: On by default and controls whether users are able to report messages from Teams. When this setting is turned off, users can't report messages within Teams, so the corresponding setting in the Microsoft 365 Defender portal is irrelevant. - In the Microsoft 365 Defender portal: On by default for new tenants. Existing tenants need to enable it. If user reporting of messages is turned on in the Teams admin center, it also needs to be turned on the Defender portal for user reported messages to show up correctly on the User reported tab on the Submissions page. - Defender - Report message destinations: This applies to more than just Microsoft Teams and allows for an organization to keep their reports contained. Due to how the parameters are configured on the backend it is included in this assessment as a requirement.", + "Checks": [ + "teams_security_reporting_enabled", + "defender_chat_report_policy_configured" + ], + "Attributes": [ + { + "Section": "8 Microsoft Teams admin center", + "SubSection": "8.6 Messaging", + "Profile": "E5 Level 1", + "AssessmentStatus": "Automated", + "Description": "User reporting settings allow a user to report a message as malicious for further analysis. This recommendation is composed of 3 different settings and all must be configured for compliance: - In the Teams admin center: On by default and controls whether users are able to report messages from Teams. When this setting is turned off, users can't report messages within Teams, so the corresponding setting in the Microsoft 365 Defender portal is irrelevant. - In the Microsoft 365 Defender portal: On by default for new tenants. Existing tenants need to enable it. If user reporting of messages is turned on in the Teams admin center, it also needs to be turned on the Defender portal for user reported messages to show up correctly on the User reported tab on the Submissions page. - Defender - Report message destinations: This applies to more than just Microsoft Teams and allows for an organization to keep their reports contained. Due to how the parameters are configured on the backend it is included in this assessment as a requirement.", + "RationaleStatement": "Users will be able to more quickly and systematically alert administrators of suspicious malicious messages within Teams. The content of these messages may be sensitive in nature and therefore should be kept within the organization and not shared with Microsoft without first consulting company policy. Note: - The reported message remains visible to the user in the Teams client. - Users can report the same message multiple times. - The message sender isn't notified that messages were reported.", + "ImpactStatement": "Enabling message reporting has an impact beyond just addressing security concerns. When users of the platform report a message, the content could include messages that are threatening or harassing in nature, possibly stemming from colleagues. Due to this the security staff responsible for reviewing and acting on these reports should be equipped with the skills to discern and appropriately direct such messages to the relevant departments, such as Human Resources (HR).", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Messaging to open the messaging settings section. 4. Set Report a security concern to On. 5. Next, navigate to Microsoft 365 Defender https://security.microsoft.com/ 6. Expand System > Settings and select Email & collaboration. 7. Click on User reported settings. 8. Under Microsoft Teams check the box for Monitor reported items in Microsoft Teams and click Save. 9. Set Send reported messages to: to My reporting mailbox only with reports configured to be sent to authorized staff. To remediate using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Connect to Exchange Online PowerShell using Connect-ExchangeOnline. 3. Run the following cmdlet: Set-CsTeamsMessagingPolicy -Identity Global -AllowSecurityEndUserReporting $true 4. To configure the Defender reporting policies, edit and run this script: $usersub = \"userreportedmessages@fabrikam.com\" # Change this. $params = @{ Identity = \"DefaultReportSubmissionPolicy\" EnableReportToMicrosoft = $false ReportChatMessageEnabled = $false ReportChatMessageToCustomizedAddressEnabled = $true ReportJunkToCustomizedAddress = $true ReportNotJunkToCustomizedAddress = $true ReportPhishToCustomizedAddress = $true ReportJunkAddresses = $usersub ReportNotJunkAddresses = $usersub ReportPhishAddresses = $usersub } Set-ReportSubmissionPolicy @params New-ReportSubmissionRule -Name DefaultReportSubmissionRule - ReportSubmissionPolicy DefaultReportSubmissionPolicy -SentTo $usersub", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Teams admin center https://admin.teams.microsoft.com. 2. Click Settings & policies and select the Global (Org-wide default) settings tab. 3. Select Messaging to open the messaging settings section. 4. Verify that Report a security concern is On. 5. Next, navigate to Microsoft 365 Defender https://security.microsoft.com/ 6. Expand System > Settings and select Email & collaboration. 7. Click on User reported settings. 8. Under Microsoft Teams verify that Monitor reported items in Microsoft Teams is checked. 9. Verify that Send reported messages to: is set to My reporting mailbox only with report email addresses defined for authorized staff. To audit using PowerShell: 1. Connect to Teams PowerShell using Connect-MicrosoftTeams. 2. Run the following cmdlet for to assess Teams: Get-CsTeamsMessagingPolicy -Identity Global | fl AllowSecurityEndUserReporting 3. Verify that the value returned is True. 4. Connect to Exchange Online PowerShell using Connect-ExchangeOnline. 5. Run this cmdlet to assess Defender: Get-ReportSubmissionPolicy | fl Report* 6. Verify that the output matches the following values with organization specific email addresses: ReportJunkToCustomizedAddress : True ReportNotJunkToCustomizedAddress : True ReportPhishToCustomizedAddress : True ReportJunkAddresses : {SOC@contoso.com} ReportNotJunkAddresses : {SOC@contoso.com} ReportPhishAddresses : {SOC@contoso.com} ReportChatMessageEnabled : False ReportChatMessageToCustomizedAddressEnabled : True", + "AdditionalInformation": "", + "DefaultValue": "On (True) Report message destination: Microsoft Only", + "References": "https://learn.microsoft.com/en-us/defender-office-365/submissions-teams?view=o365-worldwide" + } + ] + }, + { + "Id": "9.1.1", + "Description": "This setting allows business-to-business (B2B) guests access to Microsoft Fabric, and contents that they have permissions to. With the setting turned off, B2B guest users receive an error when trying to access Power BI. The recommended state is Enabled for a subset of the organization or Disabled.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting allows business-to-business (B2B) guests access to Microsoft Fabric, and contents that they have permissions to. With the setting turned off, B2B guest users receive an error when trying to access Power BI. The recommended state is Enabled for a subset of the organization or Disabled.", + "RationaleStatement": "Establishing and enforcing a dedicated security group prevents unauthorized access to Microsoft Fabric for guests collaborating in Azure that are new or assigned guest status from other applications. This upholds the principle of least privilege and uses role-based access control (RBAC). These security groups can also be used for tasks like conditional access, enhancing risk management and user accountability across the organization.", + "ImpactStatement": "Security groups will need to be more closely tended to and monitored.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Set Guest users can access Microsoft Fabric to one of these states: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Verify that Guest users can access Microsoft Fabric is set to one of the following: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled. To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName AllowGuestUserToAccessSharedContent in the output. 3. Verify that the properties adhere to one of the following compliant configurations: o enabled is false. o enabled is true AND enabledSecurityGroups contains at least one security group. 4. If neither condition is met, the setting is non-compliant. Note: If the Specific security groups setting is not enabled then the enabledSecurityGroups property does not appear in the output.", + "AdditionalInformation": "", + "DefaultValue": "Enabled for the entire organization", + "References": "https://learn.microsoft.com/en-us/fabric/admin/service-admin-portal-export-sharing" + } + ] + }, + { + "Id": "9.1.2", + "Description": "This setting helps organizations choose whether new external users can be invited to the organization through Power BI sharing, permissions, and subscription experiences. This setting only controls the ability to invite through Power BI. The recommended state is Enabled for a subset of the organization or Disabled. Note: To invite external users to the organization, the user must also have the Microsoft Entra Guest Inviter role.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting helps organizations choose whether new external users can be invited to the organization through Power BI sharing, permissions, and subscription experiences. This setting only controls the ability to invite through Power BI. The recommended state is Enabled for a subset of the organization or Disabled. Note: To invite external users to the organization, the user must also have the Microsoft Entra Guest Inviter role.", + "RationaleStatement": "Establishing and enforcing a dedicated security group prevents unauthorized access to Microsoft Fabric for guests collaborating in Azure that are new or assigned guest status from other applications. This upholds the principle of least privilege and uses role-based access control (RBAC). These security groups can also be used for tasks like conditional access, enhancing risk management and user accountability across the organization.", + "ImpactStatement": "Guest user invitations will be limited to only specific employees.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Set Users can invite guest users to collaborate through item sharing and permissions to one of these states: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Verify that Users can invite guest users to collaborate through item sharing and permissions is set to one of the following: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled. To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName ExternalSharingV2 in the output. 3. Verify that the properties adhere to one of the following compliant configurations: o enabled is false. o enabled is true AND enabledSecurityGroups contains at least one security group. 4. If neither condition is met, the setting is non-compliant. Note: If the Specific security groups setting is not enabled then the enabledSecurityGroups property does not appear in the output.", + "AdditionalInformation": "", + "DefaultValue": "Enabled for the entire organization", + "References": "https://learn.microsoft.com/en-us/fabric/admin/service-admin-portal-export-sharing:https://learn.microsoft.com/en-us/power-bi/enterprise/service-admin-azure-ad-b2b#invite-guest-users" + } + ] + }, + { + "Id": "9.1.3", + "Description": "This setting allows Microsoft Entra B2B guest users to have full access to the browsing experience using the left-hand navigation pane in the organization. Guest users who have been assigned workspace roles or specific item permissions will continue to have those roles and/or permissions, even if this setting is disabled. The recommended state is Enabled for a subset of the organization or Disabled.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting allows Microsoft Entra B2B guest users to have full access to the browsing experience using the left-hand navigation pane in the organization. Guest users who have been assigned workspace roles or specific item permissions will continue to have those roles and/or permissions, even if this setting is disabled. The recommended state is Enabled for a subset of the organization or Disabled.", + "RationaleStatement": "Establishing and enforcing a dedicated security group prevents unauthorized access to Microsoft Fabric for guests collaborating in Entra that are new or assigned guest status from other applications. This upholds the principle of least privilege and uses role-based access control (RBAC). These security groups can also be used for tasks like conditional access, enhancing risk management and user accountability across the organization.", + "ImpactStatement": "Security groups will need to be more closely tended to and monitored.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Set Guest users can browse and access Fabric content to one of these states: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Verify that Guest users can browse and access Fabric content is set to one of the following: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled. To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName ElevatedGuestsTenant in the output. 3. Verify that the properties adhere to one of the following compliant configurations: o enabled is false. o enabled is true AND enabledSecurityGroups contains at least one security group. 4. If neither condition is met, the setting is non-compliant. Note: If the Specific security groups setting is not enabled then the enabledSecurityGroups property does not appear in the output.", + "AdditionalInformation": "", + "DefaultValue": "Disabled", + "References": "https://learn.microsoft.com/en-us/fabric/admin/service-admin-portal-export-sharing" + } + ] + }, + { + "Id": "9.1.4", + "Description": "Power BI enables users to share reports and materials directly on the internet from both the application's desktop version and its web user interface. This functionality generates a publicly reachable web link that doesn't necessitate authentication or the need to be an Entra ID user in order to access and view it. The recommended state is Enabled for a subset of the organization or Disabled.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Power BI enables users to share reports and materials directly on the internet from both the application's desktop version and its web user interface. This functionality generates a publicly reachable web link that doesn't necessitate authentication or the need to be an Entra ID user in order to access and view it. The recommended state is Enabled for a subset of the organization or Disabled.", + "RationaleStatement": "When using Publish to Web anyone on the Internet can view a published report or visual. Viewing requires no authentication. It includes viewing detail-level data that your reports aggregate. By disabling the feature, restricting access to certain users and allowing existing embed codes organizations can mitigate the exposure of confidential or proprietary information.", + "ImpactStatement": "Depending on the organization's utilization administrators may experience more overhead managing embed codes, and requests.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Set Publish to web to one of these states: o Disabled o Enabled with Choose how embed codes work set to Only allow existing codes AND Specific security groups selected and defined Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Verify that Publish to web is set to one of the following: o Disabled o Enabled with Choose how embed codes work set to Only allow existing codes AND Specific security groups selected and defined Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled. To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName PublishToWeb in the output. 3. Verify that the properties adhere to one of the following compliant configurations: o enabled is false. o enabled is true AND createP2w is false AND enabledSecurityGroups contains at least one security group. 4. If neither condition is met, the setting is non-compliant. Note: The createP2w property can be found nested under properties.", + "AdditionalInformation": "", + "DefaultValue": "Enabled for the entire organization Only allow existing codes", + "References": "https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-publish-to-web:https://learn.microsoft.com/en-us/fabric/admin/service-admin-portal-export-sharing#publish-to-web" + } + ] + }, + { + "Id": "9.1.5", + "Description": "Power BI allows the integration of R and Python scripts directly into visuals. This feature allows data visualizations by incorporating custom calculations, statistical analyses, machine learning models, and more using R or Python scripts. Custom visuals can be created by embedding them directly into Power BI reports. Users can then interact with these visuals and see the results of the custom code within the Power BI interface.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 2", + "AssessmentStatus": "Automated", + "Description": "Power BI allows the integration of R and Python scripts directly into visuals. This feature allows data visualizations by incorporating custom calculations, statistical analyses, machine learning models, and more using R or Python scripts. Custom visuals can be created by embedding them directly into Power BI reports. Users can then interact with these visuals and see the results of the custom code within the Power BI interface.", + "RationaleStatement": "Disabling this feature can reduce the attack surface by preventing potential malicious code execution leading to data breaches, or unauthorized access. The potential for sensitive or confidential data being leaked to unintended users is also increased with the use of scripts.", + "ImpactStatement": "Use of R and Python scripting will require exceptions for developers, along with more stringent code review.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to R and Python visuals settings. 4. Set Interact with and share R and Python visuals to Disabled", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to R and Python visuals settings. 4. Verify that Interact with and share R and Python visuals is set to Disabled To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName RScriptVisual in the output. 3. Verify that enabled is false.", + "AdditionalInformation": "", + "DefaultValue": "Enabled", + "References": "https://learn.microsoft.com/en-us/fabric/admin/service-admin-portal-r-python-visuals:https://learn.microsoft.com/en-us/power-bi/visuals/service-r-visuals:https://www.r-project.org/" + } + ] + }, + { + "Id": "9.1.6", + "Description": "Information protection tenant settings help to protect sensitive information in the Power BI tenant. Allowing and applying sensitivity labels to content ensures that information is only seen and accessed by the appropriate users. The recommended state is Enabled or Enabled for a subset of the organization. Note: Sensitivity labels and protection are only applied to files exported to Excel, PowerPoint, or PDF files, that are controlled by \"Export to Excel\" and \"Export reports as PowerPoint presentation or PDF documents\" settings. All other export and sharing options do not support the application of sensitivity labels and protection. Note 2: There are some prerequisite steps that need to be completed in order to fully utilize labeling. See here.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Information protection tenant settings help to protect sensitive information in the Power BI tenant. Allowing and applying sensitivity labels to content ensures that information is only seen and accessed by the appropriate users. The recommended state is Enabled or Enabled for a subset of the organization. Note: Sensitivity labels and protection are only applied to files exported to Excel, PowerPoint, or PDF files, that are controlled by \"Export to Excel\" and \"Export reports as PowerPoint presentation or PDF documents\" settings. All other export and sharing options do not support the application of sensitivity labels and protection. Note 2: There are some prerequisite steps that need to be completed in order to fully utilize labeling. See here.", + "RationaleStatement": "Establishing data classifications and affixing labels to data at creation enables organizations to discern the data's criticality, sensitivity, and value. This initial identification enables the implementation of appropriate protective measures, utilizing technologies like Data Loss Prevention (DLP) to avert inadvertent exposure and enforcing access controls to safeguard against unauthorized access. This practice can also promote user awareness and responsibility in regard to the nature of the data they interact with. Which in turn can foster awareness in other areas of data management across the organization.", + "ImpactStatement": "Additional license requirements like Power BI Pro are required, as outlined in the Licensed and requirements page linked in the description and references sections.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Information protection. 4. Set Allow users to apply sensitivity labels for content to one of these states: o Enabled o Enabled with Specific security groups selected and defined.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Information protection. 4. Verify that Allow users to apply sensitivity labels for content is set to one of the following: o Enabled o Enabled with Specific security groups selected and defined. To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName EimInformationProtectionEdit in the output. 3. Verify that the properties adhere to one of the following compliant configurations: o enabled is true. o enabled is true AND enabledSecurityGroups contains at least one security group. 4. If neither condition is met, the setting is non-compliant. Note: If the Specific security groups setting is not enabled then the enabledSecurityGroups property does not appear in the output.", + "AdditionalInformation": "", + "DefaultValue": "Disabled", + "References": "https://learn.microsoft.com/en-us/power-bi/enterprise/service-security-enable-data-sensitivity-labels:https://learn.microsoft.com/en-us/fabric/governance/data-loss-prevention-overview:https://learn.microsoft.com/en-us/power-bi/enterprise/service-security-enable-data-sensitivity-labels#licensing-and-requirements" + } + ] + }, + { + "Id": "9.1.7", + "Description": "Creating a shareable link allows a user to create a link to a report or dashboard, then add that link to an email or another messaging application. There are 3 options that can be selected when creating a shareable link: - People in your organization - People with existing access - Specific people This setting solely deals with restrictions to People in the organization. External users by default are not included in any of these categories, and therefore cannot use any of these links regardless of the state of this setting. The recommended state is Enabled for a subset of the organization or Disabled.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Creating a shareable link allows a user to create a link to a report or dashboard, then add that link to an email or another messaging application. There are 3 options that can be selected when creating a shareable link: - People in your organization - People with existing access - Specific people This setting solely deals with restrictions to People in the organization. External users by default are not included in any of these categories, and therefore cannot use any of these links regardless of the state of this setting. The recommended state is Enabled for a subset of the organization or Disabled.", + "RationaleStatement": "While external users are unable to utilize shareable links, disabling or restricting this feature ensures that a user cannot generate a link accessible by individuals within the same organization who lack the necessary clearance to the shared data. For example, a member of Human Resources intends to share sensitive information with a particular employee or another colleague within their department. The owner would be prompted to specify either People with existing access or Specific people when generating the link requiring the person clicking the link to pass a first layer access control list. This measure along with proper file and folder permissions can help prevent unintended access and potential information leakage.", + "ImpactStatement": "If the setting is Enabled then only specific people in the organization would be allowed to create general links viewable by the entire organization.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Set Allow shareable links to grant access to everyone in your organization to one of these states: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Verify that Allow shareable links to grant access to everyone in your organization is set to one of the following: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled. To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName ShareLinkToEntireOrg in the output. 3. Verify that the properties adhere to one of the following compliant configurations: o enabled is set to false. o enabled is set to true AND enabledSecurityGroups contains at least one security group. 4. If neither condition is met, the setting is non-compliant. Note: If the Specific security groups setting is not enabled then the enabledSecurityGroups property does not appear in the output.", + "AdditionalInformation": "", + "DefaultValue": "Enabled for the entire organization", + "References": "https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-share-dashboards?wt.mc_id=powerbi_inproduct_sharedialog#link-settings:https://learn.microsoft.com/en-us/fabric/admin/service-admin-portal-export-sharing" + } + ] + }, + { + "Id": "9.1.8", + "Description": "Power BI admins can specify which users or user groups can share datasets externally with guests from a different tenant through the in-place mechanism. Disabling this setting prevents any user from sharing datasets externally by restricting the ability of users to turn on external sharing for datasets they own or manage. The recommended state is Enabled for a subset of the organization or Disabled.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Power BI admins can specify which users or user groups can share datasets externally with guests from a different tenant through the in-place mechanism. Disabling this setting prevents any user from sharing datasets externally by restricting the ability of users to turn on external sharing for datasets they own or manage. The recommended state is Enabled for a subset of the organization or Disabled.", + "RationaleStatement": "Establishing and enforcing a dedicated security group prevents unauthorized access to Microsoft Fabric for guests collaborating in Azure that are new or from other applications. This upholds the principle of least privilege and uses role-based access control (RBAC). These security groups can also be used for tasks like conditional access, enhancing risk management and user accountability across the organization.", + "ImpactStatement": "Security groups will need to be more closely tended to and monitored.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Set Allow specific users to turn on external data sharing to one of these states: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Export and Sharing settings. 4. Verify that Allow specific users to turn on external data sharing is set to one of the following: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled. To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName EnableDatasetInPlaceSharing in the output. 3. Verify that the properties adhere to one of the following compliant configurations: o enabled is set to false. o enabled is set to true AND enabledSecurityGroups contains at least one security group. 4. If neither condition is met, the setting is non-compliant. Note: If the Specific security groups setting is not enabled then the enabledSecurityGroups property does not appear in the output.", + "AdditionalInformation": "", + "DefaultValue": "Enabled for the entire organization", + "References": "https://learn.microsoft.com/en-us/fabric/admin/service-admin-portal-export-sharing" + } + ] + }, + { + "Id": "9.1.9", + "Description": "This setting blocks the use of resource key based authentication. The Block ResourceKey Authentication setting applies to streaming and PUSH datasets. If blocked users will not be allowed to send data to streaming and PUSH datasets using the API with a resource key. The recommended state is Enabled.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "This setting blocks the use of resource key based authentication. The Block ResourceKey Authentication setting applies to streaming and PUSH datasets. If blocked users will not be allowed to send data to streaming and PUSH datasets using the API with a resource key. The recommended state is Enabled.", + "RationaleStatement": "Resource keys are a form of authentication that allows users to access Power BI resources (such as reports, dashboards, and datasets) without requiring individual user accounts. While convenient, this method bypasses the organization's centralized identity and access management controls. Enabling ensures that access to Power BI resources is tied to the organization's authentication mechanisms, providing a more secure and controlled environment.", + "ImpactStatement": "Developers will need to request a special exception in order to use this feature.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Developer settings. 4. Set Block ResourceKey Authentication to Enabled", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Developer settings. 4. Verify that Block ResourceKey Authentication is set to Enabled. To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName BlockResourceKeyAuthentication in the output. 3. Verify that enabled is set to true. Note: If the Specific security groups setting is not enabled then the enabledSecurityGroups property does not appear in the output.", + "AdditionalInformation": "", + "DefaultValue": "Disabled for the entire organization", + "References": "https://learn.microsoft.com/en-us/fabric/admin/service-admin-portal-developer:https://learn.microsoft.com/en-us/power-bi/connect-data/service-real-time-streaming" + } + ] + }, + { + "Id": "9.1.10", + "Description": "Use a service principal to access Fabric public APIs that include create, read, update, and delete (CRUD) operations, and are protected by a Fabric permission model. To allow an app to use service principal authentication, its service principal must be included in an allowed security group. You can control who can access service principals by creating dedicated security groups and using these groups in other tenant settings. The recommended state is Enabled for a subset of the organization or Disabled.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Use a service principal to access Fabric public APIs that include create, read, update, and delete (CRUD) operations, and are protected by a Fabric permission model. To allow an app to use service principal authentication, its service principal must be included in an allowed security group. You can control who can access service principals by creating dedicated security groups and using these groups in other tenant settings. The recommended state is Enabled for a subset of the organization or Disabled.", + "RationaleStatement": "Leaving API access unrestricted increases the attack surface in the event an adversary gains access to a Service Principal. APIs are a feature-rich method for programmatic access to many areas of Power Bi and should be guarded closely.", + "ImpactStatement": "Service principals will need to be members of specific security groups in order to perform public API calls.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Developer settings. 4. Set Service principals can call Fabric public APIs to one of the following: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Developer settings. 4. Verify that Service principals can call Fabric public APIs is set to one of the following: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled. To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName ServicePrincipalAccessPermissionAPIs in the output. 3. Verify that the properties adhere to one of the following compliant configurations: o enabled is set to false. o enabled is set to true AND enabledSecurityGroups contains at least one security group. 4. If neither condition is met, the setting is non-compliant. Note: If the Specific security groups setting is not enabled then the enabledSecurityGroups property does not appear in the output.", + "AdditionalInformation": "", + "DefaultValue": "Enabled for the entire organization", + "References": "https://learn.microsoft.com/en-us/fabric/admin/service-admin-portal-developer" + } + ] + }, + { + "Id": "9.1.11", + "Description": "Service principal profiles provide a flexible solution for apps used in a multitenancy deployment. The profiles enable customer data isolation and tighter security boundaries between customers that are utilizing the app. The recommended state is Enabled for a subset of the organization or Disabled.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Service principal profiles provide a flexible solution for apps used in a multitenancy deployment. The profiles enable customer data isolation and tighter security boundaries between customers that are utilizing the app. The recommended state is Enabled for a subset of the organization or Disabled.", + "RationaleStatement": "Service Principals should be restricted to a security group to limit which Service Principals can interact with profiles. This supports the principle of least privilege.", + "ImpactStatement": "Disabled is the default behavior.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Developer settings. 4. Set Allow service principals to create and use profiles to one of the following: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Developer settings. 4. Verify that Allow service principals to create and use profiles is set to one of the following: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled. To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName AllowServicePrincipalsCreateAndUseProfiles in the output. 3. Verify that the properties adhere to one of the following compliant configurations: o enabled is set to false. o enabled is set to true AND enabledSecurityGroups contains at least one security group. 4. If neither condition is met, the setting is non-compliant. Note: If the Specific security groups setting is not enabled then the enabledSecurityGroups property does not appear in the output.", + "AdditionalInformation": "", + "DefaultValue": "Disabled for the entire organization", + "References": "https://learn.microsoft.com/en-us/fabric/admin/service-admin-portal-developer:https://learn.microsoft.com/en-us/power-bi/developer/embedded/embed-multi-tenancy" + } + ] + }, + { + "Id": "9.1.12", + "Description": "Use a service principal to access these Fabric APIs that aren't protected by a Fabric permission model. - Create Workspace - Create Connection - Create Deployment Pipeline To allow an app to use service principal authentication, its service principal must be included in an allowed security group. You can control who can access service principals by creating dedicated security groups and using these groups in other tenant settings. The recommended state is Enabled for a subset of the organization or Disabled.", + "Checks": [], + "Attributes": [ + { + "Section": "9 Microsoft Fabric", + "SubSection": "9.1 Tenant settings", + "Profile": "E3 Level 1", + "AssessmentStatus": "Automated", + "Description": "Use a service principal to access these Fabric APIs that aren't protected by a Fabric permission model. - Create Workspace - Create Connection - Create Deployment Pipeline To allow an app to use service principal authentication, its service principal must be included in an allowed security group. You can control who can access service principals by creating dedicated security groups and using these groups in other tenant settings. The recommended state is Enabled for a subset of the organization or Disabled.", + "RationaleStatement": "Leaving API access unrestricted increases the attack surface in the event an adversary gains access to a Service Principal. APIs are a feature-rich method for programmatic access to many areas of Power Bi and should be guarded closely.", + "ImpactStatement": "Service principals will need to be members of specific security groups in order to perform public API calls.", + "RemediationProcedure": "To remediate using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Developer settings. 4. Set Service principals can create workspaces, connections, and deployment pipelines to one of the following: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled.", + "AuditProcedure": "To audit using the UI: 1. Navigate to Microsoft Fabric https://app.powerbi.com/admin-portal 2. Select Tenant settings. 3. Scroll to Developer settings. 4. Verify that Service principals can create workspaces, connections, and deployment pipelines is set to one of the following: o Disabled o Enabled with Specific security groups selected and defined. Important: If the organization doesn't actively use this feature it is recommended to keep it Disabled. To audit using PowerShell: 1. Inspect the results of the Get-CISFabricTenantSettings function from the section overview. 2. Locate the settingName ServicePrincipalAccessGlobalAPIs in the output. 3. Verify that the properties adhere to one of the following compliant configurations: o enabled is set to false. o enabled is set to true AND enabledSecurityGroups contains at least one security group. 4. If neither condition is met, the setting is non-compliant. Note: If the Specific security groups setting is not enabled then the enabledSecurityGroups property does not appear in the output.", + "AdditionalInformation": "", + "DefaultValue": "Disabled for the entire organization", + "References": "https://learn.microsoft.com/en-us/fabric/admin/service-admin-portal-developer" + } + ] + } + ] +} \ No newline at end of file diff --git a/tests/lib/outputs/compliance/cis/cis_7_0_m365_test.py b/tests/lib/outputs/compliance/cis/cis_7_0_m365_test.py new file mode 100644 index 0000000000..4fbebb49f6 --- /dev/null +++ b/tests/lib/outputs/compliance/cis/cis_7_0_m365_test.py @@ -0,0 +1,65 @@ +import json +from pathlib import Path + +from prowler.lib.check.compliance_models import ( + CIS_Requirement_Attribute_AssessmentStatus, + CIS_Requirement_Attribute_Profile, + Compliance, +) + +PROWLER_ROOT = Path(__file__).parents[5] / "prowler" +FRAMEWORK_PATH = PROWLER_ROOT / "compliance" / "m365" / "cis_7.0_m365.json" +M365_SERVICES_PATH = PROWLER_ROOT / "providers" / "m365" / "services" + +VALID_PROFILES = {p.value for p in CIS_Requirement_Attribute_Profile} +VALID_STATUSES = {s.value for s in CIS_Requirement_Attribute_AssessmentStatus} + + +def _existing_m365_checks() -> set: + return { + metadata.stem.replace(".metadata", "") + for metadata in M365_SERVICES_PATH.rglob("*.metadata.json") + } + + +class TestCIS7_0_M365: + def test_framework_is_discoverable(self): + frameworks = Compliance.get_bulk("m365") + assert "cis_7.0_m365" in frameworks + + def test_framework_metadata(self): + framework = Compliance.get_bulk("m365")["cis_7.0_m365"] + assert framework.Framework == "CIS" + assert framework.Provider == "M365" + assert framework.Version == "7.0" + assert framework.Name == "CIS Microsoft 365 Foundations Benchmark v7.0.0" + assert len(framework.Requirements) == 160 + + def test_requirement_ids_are_unique(self): + framework = Compliance.get_bulk("m365")["cis_7.0_m365"] + ids = [req.Id for req in framework.Requirements] + assert len(ids) == len(set(ids)) + + def test_each_requirement_has_one_attribute_with_section(self): + framework = Compliance.get_bulk("m365")["cis_7.0_m365"] + for req in framework.Requirements: + assert len(req.Attributes) == 1, f"{req.Id} must have exactly one attribute" + attribute = req.Attributes[0] + assert attribute.Section, f"{req.Id} has an empty Section" + assert attribute.Profile in VALID_PROFILES + assert attribute.AssessmentStatus in VALID_STATUSES + + def test_all_mapped_checks_exist(self): + # Every check referenced by the framework must resolve to a real M365 check, + # otherwise the requirement would never be evaluated. + existing = _existing_m365_checks() + framework = json.loads(FRAMEWORK_PATH.read_text()) + unknown = { + check + for req in framework["Requirements"] + for check in req["Checks"] + if check not in existing + } + assert ( + not unknown + ), f"Framework references unknown M365 checks: {sorted(unknown)}"