TEST NAME

Ensure Administrative accounts are separate and cloud-only

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`.

Rationale

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.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure that between two and four global admins are designated

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.

Rationale

If there is only one global administrator, they could perform malicious activities without being detected by another admin. Designating multiple global administrators eliminates this risk and ensures redundancy if the sole remaining global administrator leaves the organization.

However, to minimize the attack surface, there should be no more than four global admins set for any tenant. A large number of global admins increases the likelihood of a successful account breach by an external attacker.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure administrative accounts use licenses with a reduced application footprint

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`.

Rationale

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.

Impact

Administrative users will have to switch accounts and utilize login/logout functionality when performing administrative tasks, as well as not benefiting from SSO.

**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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure two emergency access accounts have been defined

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.

Rationale

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.

Impact

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.

Recommendation and Steps

**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:
 - Name the account in a way that does NOT identify it with a particular person.
 - Assign the account to the default `.onmicrosoft.com` domain and not the organization's.
 - The password must be at least 16 characters and generated randomly.
 - Do not assign a license.
 - 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 `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 on 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](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/admin-units-restricted-management).

**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.

Associated Items

Affected Objects

TEST NAME

Ensure that only organizationally managed-approved public groups exist

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. While there are several different group types this recommendation concerns **Microsoft 365 Groups**.

In the Administration panel, when a group is created, the default privacy value is Public.

Rationale

Ensure that only organizationally managed and approved public groups exist. When a group has a public privacy, users may access data related to this group (e.g. SharePoint), through three methods:

- By using the Azure portal, and adding themselves into the public group
- By requesting access to the group from the Group application of the Access Panel
- By accessing the SharePoint URL

Administrators are notified when a user uses the Azure Portal. Requesting access to the group forces users to send a message to the group owner, but they still have immediate access to the group. The SharePoint URL is usually guessable and can be found from the Group application of the Access Panel. If group privacy is not controlled, any user may access sensitive information, according to the group they try to access.

**Note:** Public in this case means public to the identities within the organization.

Impact

If the recommendation is applied, group owners could receive more access requests than usual, especially regarding groups originally meant to be public.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft 365 admin center` https://admin.microsoft.com.
2. Click to expand `Teams & groups` select `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`.

Associated Items

Affected Objects

TEST NAME

Ensure sign-in to shared mailboxes is blocked

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`.

Rationale

The intent of the shared mailbox is the 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.

Impact

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Idle session timeout is set to 3 hours (or less) for unmanaged devices

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.

Rationale

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.

Impact

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 kind of devices, not just unmanaged. See : [change the directory timeout setting admin](https://learn.microsoft.com/en-us/azure/azure-portal/set-preferences#change-the-directory-timeout-setting-admin)

Recommendation and Steps

**Step 1 - Configure Idle session timeout:**

1. Navigate to the `Microsoft 365 admin center` https://admin.microsoft.com/.
2. Click to expand `Settings` Select `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:**

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.
 - Select `Users` > `All users`.
 - Select `Cloud apps or actions` > `Select apps` and select `Office 365`
 - Select `Conditions` > `Client apps` > `Yes` check only `Browser` unchecking all other boxes.
 - 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.

Associated Items

Affected Objects

TEST NAME

Ensure External sharing of calendars is not available

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.

Rationale

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.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft 365 admin center` https://admin.microsoft.com.
2. Click to 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
```

Associated Items

Affected Objects

TEST NAME

Ensure third-party storage services are restricted in Microsoft 365 on the web

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.

Rationale

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.

Impact

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.

Recommendation and Steps

**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
```

Associated Items

Affected Objects

TEST NAME

Ensure the customer lockbox feature is enabled

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.

Rationale

Enabling this feature protects organizational data against data spillage and exfiltration.

Impact

Administrators will need to grant Microsoft access to the tenant environment prior to a Microsoft engineer accessing the environment for support or troubleshooting.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft 365 admin center` https://admin.microsoft.com.
2. Click to expand `Settings` then select `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
```

Associated Items

Affected Objects

TEST NAME

Ensure the Password expiration policy is set to Set passwords to never expire (recommended)

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 whether passwords expire at all.

Rationale

Organizations such as NIST and Microsoft have updated their password policy recommendations to not arbitrarily require users to change their passwords after a specific amount of time, unless there is evidence that the password is compromised, or the user forgot it. They suggest this even for single factor (Password Only) use cases, with a reasoning that forcing arbitrary password changes on users actually make the passwords less secure. Other recommendations within this Benchmark suggest the use of MFA authentication for at least critical accounts (at minimum), which makes password expiration even less useful as well as password protection for Entra ID.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure User owned apps and services is restricted

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.

Rationale

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.

Disable future user's ability to install add-ins in Microsoft Word, Excel, or PowerPoint helps reduce your threat-surface and mitigate this risk.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure internal phishing protection for Forms is enabled

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.

Rationale

Enabling internal phishing protection for Microsoft Forms will prevent attackers using forms for phishing attacks by asking personal or other sensitive information and URLs.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure that Sways cannot be shared with people outside of your organization

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.

Rationale

Disable external sharing of Sway documents that can contain sensitive information to prevent accidental or arbitrary data leaks.

Impact

Interactive reports, presentations, newsletters, and other items created in Sway will not be shared outside the organization by users.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft 365 admin center` https://admin.microsoft.com.
2. Click to expand `Settings` then select `Org settings`.
3. Under Services select `Sway`
 - Uncheck: `Let people in your organization share their sways with people outside your organization`.
4. Click `Save`.

Associated Items

Affected Objects

TEST NAME

Ensure Safe Links for Office Applications is Enabled

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 Build-in Policies provided by MS. In order to **Pass** the highest priority policy must match all settings recommended.

Rationale

Safe Links for Office applications extends phishing protection to documents and emails that contain hyperlinks, even after they have been delivered to a user.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft 365 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** 
 - Checked `On: Safe Links checks a list of known, malicious links when users click links in email. URLs are rewritten by default`
 - Checked `Apply Safe Links to email messages sent within the organization`
 - Checked `Apply real-time URL scanning for suspicious links and links that point to files`
 - Checked `Wait for URL scanning to complete before delivering the message`
 - Unchecked `Do not rewrite URLs, do checks via Safe Links API only.`

 **Teams** 
 - 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** 
 - 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**
 - Checked `Track user clicks`
 - Unchecked `Let users click through the original URL`
 - 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
```

Associated Items

Affected Objects

TEST NAME

Ensure the Common Attachment Types Filter is enabled

Description

The Common Attachment Types Filter lets a user block known and custom malicious file types from being attached to emails.

Rationale

Blocking known malicious file types can help prevent malware-infested files from infecting a host.

Impact

Blocking common malicious file types should not cause an impact in modern computing environments.

Recommendation and Steps

**To remediate using the UI:** 

1. Navigate to `Microsoft 365 Defender` https://security.microsoft.com.
2. Click to expand `Email & collaboration` select `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`.
6. Click Save.

**To remediate using PowerShell:**

1. Connect to Exchange Online using `Connect-ExchangeOnline`.
2. Run the following Exchange Online PowerShell command:

```
Set-MalwareFilterPolicy -Identity Default -EnableFileFilter $true
```

**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.

Associated Items

Affected Objects

TEST NAME

Ensure notifications for internal users sending malware is Enabled

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.

Rationale

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.

Impact

Notification of account with potential issues should not have an impact on the user.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft 365 Defender` https://security.microsoft.com.
2. Click to expand `E-mail & Collaboration` select `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 {[email protected]}
```

**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.

Associated Items

Affected Objects

TEST NAME

Ensure Exchange Online Spam Policies are set correctly

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.

Rationale

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.

Impact

Notification of users that have been blocked should not cause an impact to the user.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft 365 Defender` https://security.microsoft.com.
2. Click to expand `Email & collaboration` select `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.

Associated Items

Affected Objects

TEST NAME

Ensure that DKIM is enabled for all Exchange Online Domains

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, its 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.

Rationale

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.

Impact

There should be no impact of setting up DKIM however, organizations should ensure appropriate setup to ensure continuous mail-flow.

Recommendation and Steps

**To remediate using a DNS Provider:**

1. For each accepted domain in Exchange Online, two DNS entries are required.

```
Host name: selector1._domainkey
Points to address or value: selector1-._domainkey. 
TTL: 3600
Host name: selector2._domainkey
Points to address or value: selector2-._domainkey. 
TTL: 3600
```

For Office 365, the selectors will always be `selector1` or `selector2`.

domainGUID is the same as the domainGUID in the customized MX record for your custom domain that appears before mail.protection.outlook.com. For example, in the following MX record for the domain contoso.com, the domainGUID is contoso-com:

```
contoso.com. 3600 IN MX 5 contoso-com.mail.protection.outlook.com
```

The initial domain is the domain that you used when you signed up for Office 365. Initial domains always end with on.microsoft.com.

1. After the DNS records are created, enable DKIM signing in Defender.
2. Navigate to `Microsoft 365 Defender` https://security.microsoft.com/
3. Expand `Email & collaboration` > `Policies & rules` > `Threat policies`.
4. Under `Rules` section click `Email authentication settings`.
5. Select `DKIM`
6. Click on each domain and click `Enable` next to `Sign messages for this domain with DKIM signature`.

**Final remediation step using the Exchange Online PowerShell Module:**

1. Connect to Exchange Online service using `Connect-ExchangeOnline`.
2. Run the following Exchange Online PowerShell command:

```
Set-DkimSigningConfig -Identity < domainName > -Enabled $True
```

Associated Items

Affected Objects

TEST NAME

Ensure DMARC Records for all Exchange Online domains are published

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.

Rationale

DMARC strengthens the trustworthiness of messages sent from an organization's domain to destination email systems. By integrating DMARC with SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail), organizations can significantly enhance their defenses against email spoofing and phishing attempts.

Leaving a DMARC policy set to `p=none` can result in failed action when a spear phishing email fails DMARC but passes SPF and DKIM checks. Having DMARC fully configured is a critical part in preventing business email compromise.

Impact

There should be no impact of setting up DMARC however, organizations should ensure appropriate setup to ensure continuous mail-flow.

Recommendation and Steps

**To remediate using a DNS Provider:**

1. For each Exchange Online Accepted Domain, 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:
```

**Also remediate the MOREA 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.

**Note:** The remediation portion involves a multi-staged approach over a period of 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.

Microsoft has a list of [best practices for implementing DMARC](https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dmarc-configure?view=o365-worldwide#best-practices-for-implementing-dmarc-in-microsoft-365) that cover these steps in detail.

Associated Items

Affected Objects

TEST NAME

Ensure comprehensive attachment filtering is applied

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 184 extensions provided in this recommendation is comprehensive but not exhaustive.

Rationale

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.

Impact

For file types that are business necessary users will need to use other organizationally approved methods to transfer blocked extension types between business partners.

Recommendation and Steps

**To Remediate using PowerShell:**

1. Connect to Exchange Online using `Connect-ExchangeOnline`.
2. Run the following script:
```
# 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 = '[email protected]' # 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`.

Associated Items

Affected Objects

TEST NAME

Ensure that SPF records are published for all Exchange Domains

Description

For each domain that is configured in Exchange, a corresponding Sender Policy Framework (SPF) record should be created.

Rationale

SPF records allow Exchange Online Protection and other mail systems to know where messages from domains are allowed to originate. This information can be used by that system to determine how to treat the message based on if it is being spoofed or is valid.

Impact

There should be minimal impact of setting up SPF records however, organizations should ensure proper SPF record setup as email could be flagged as spam if SPF is not setup appropriately.

Recommendation and Steps

**To remediate using a DNS Provider:**

1. If all email in your domain is sent from and received by Exchange Online, add the following TXT record for each Accepted Domain:

```
v=spf1 include:spf.protection.outlook.com -all
```

2. If there are other systems that send email in the environment, refer to this article for the proper SPF configuration: [https://docs.microsoft.com/en-us/office365/SecurityCompliance/set-up-spf-in-office-365-to-help-prevent-spoofing](https://docs.microsoft.com/en-us/office365/SecurityCompliance/set-up-spf-in-office-365-to-help-prevent-spoofing).

Associated Items

Affected Objects

TEST NAME

Ensure Safe Attachments policy is enabled

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.

Rationale

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.

Impact

Delivery of email with attachments may be delayed while scanning is occurring.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure that an anti-phishing policy has been created

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.

Rationale

Protects users from phishing attacks (like impersonation and spoofing) and uses safety tips to warn users about potentially harmful messages.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure the connection filter IP allow list is not used

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.

Rationale

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.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure the connection filter safe list is off

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`

Rationale

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 sender are included. Incoming messages from email servers on the safe list bypass spam filtering.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure inbound anti-spam policies do not contain allowed domains

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`

Rationale

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.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Safe Attachments for SharePoint-OneDrive-Microsoft Teams is Enabled

Description

Safe Attachments for SharePoint, OneDrive, and Microsoft Teams scans these services for malicious files.

Rationale

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.

Impact

Impact associated with Safe Attachments is minimal, and equivalent to impact associated with anti-virus scanners in an environment.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft 365 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
```

Associated Items

Affected Objects

TEST NAME

Ensure emergency access account activity is monitored

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.

Rationale

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.

Impact

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.

Recommendation and Steps

**To remediate using the UI:** 

1. Navigate to `Microsoft 365 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:
 - Policy severity to `High severity`.
 - Category to `Privileged accounts`.
 - Act on `Single activity`.
 - Click `Select a filter` -> `Activity type` `equals` `Log on`.
 - Click `Add a filter` -> `User` `Name` `equals`  as `Any role`.
 - Ensure all emergency access accounts are added to this policy or another.
 - Select an alert method such as `Send alert as email`.

**Note:** Multiple accounts can be monitored by a single policy or by separate policies.

Associated Items

Affected Objects

TEST NAME

Ensure Priority account protection is enabled and configured

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.

Rationale

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.

Impact

Recommendation and Steps

_Remediate with a 3-step process_

**Step 1: Enable Priority account protection in Microsoft 365 Defender:**

1. Navigate to `Microsoft 365 Defender` https://security.microsoft.com/
2. Click to expand `System` select `Settings`.
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.

Associated Items

Affected Objects

TEST NAME

Ensure Zero-hour auto purge for Microsoft Teams is on

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.

Rationale

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.

Impact

As with any anti-malware or anti-phishing product, false positives may occur.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure the Account Provisioning Activity report is reviewed and actioned

Description

Rationale

Impact

Auditing Process needs to be created and followed.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure non-global administrator role group assignments are reviewed and actioned

Description

Rationale

Impact

Auditing Process needs to be created and followed.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Microsoft Defender for Cloud Apps is Enabled

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

Rationale

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.

Impact

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft 365 Defender` https://security.microsoft.com/
2. Click to expand `System` select `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.

Associated Items

Affected Objects

TEST NAME

Ensure user role group changes are reviewed and actioned

Description

Rationale

Impact

By performing regular reviews, the Administrators assigning rights to users will need to inevitably provide justification for those changes to security auditors. Documentation that includes detailed policies, procedures, and change requests will need to be considered in order to keep a secure organization functioning within its planned operational level.

Recommendation and Steps

Role-Based Access Control allows for permissions to be assigned to users based on their roles within an organization. It is a more manageable form of access control that is less prone to errors. These user roles can be audited inside of Microsoft Purview to provide a security auditor insight into user privilege change.

Associated Items

Affected Objects

TEST NAME

Ensure Microsoft 365 audit log search is Enabled

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.

Rationale

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.

Impact

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure DLP policies are enabled

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.

Rationale

Enabling DLP policies alerts users and administrators that specific types of data should not be exposed, helping to protect the data from accidental exposure.

Impact

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.

Recommendation and Steps

**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.

Associated Items

Affected Objects

TEST NAME

Ensure DLP policies are enabled for Microsoft Teams

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.

Rationale

Enabling the default Teams DLP policy rule in Microsoft 365 helps protect an organization's sensitive information by preventing accidental sharing or leakage 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.

Impact

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.

Recommendation and Steps

**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.
9. On the Policy mode page, select the radial for `Turn it on right away` and click Next.
10. Review all the settings for the created policy on the Review your policy and create it page, and then click submit.
11. 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.

Associated Items

Affected Objects

TEST NAME

Ensure DLP Policy is enabled for OneDrive

Description

Rationale

Impact

Data Loss Prevention (DLP) capabilities protect your data where it is stored, when it is moved, and when it is shared.

Recommendation and Steps

It is recommended to enable DLP for OneDrive.

Associated Items

Affected Objects

TEST NAME

Ensure DLP Policy is configured for SharePoint

Description

Rationale

Impact

As businesses continue to digitize their operations, data protection has become a top priority. Microsoft SharePoint Online, a cloud-based collaboration and document management solution, offers a built-in Data Loss Prevention (DLP) solution to help safeguard sensitive information. DLP in SharePoint Online is important because it helps organizations protect their sensitive information from being shared with unauthorized parties. This is especially critical in industries that are highly regulated, such as healthcare and finance. 

Recommendation and Steps

It is recommended to enable DLP Policy for SharePoint.

Associated Items

Affected Objects

TEST NAME

Ensure Custom Anti-Malware Policy is Present

Description

Rationale

Impact

It is possible to create custom anti-malware policies in Exchange Online to provide additional protection against threats that may be received via email. No anti-malware policy besides the Microsoft Default Anti-Malware Policy was detected in the O365 Tenant. Although the default anti-malware policy can provide some protection, each organization should consider creating an anti-malware policy that is customized to suit the nature of their day-to-day activities.

Recommendation and Steps

Follow the 'Configure anti-malware policies in Exchange Online Protection' guide below for a full introduction to creating a custom anti-malware policy. It is possible to create an anti-malware policy and enable it through the Exchange administration center or via Exchange Online PowerShell using the Set-MalwareFilterPolicy or New-MalwareFilterPolicy commands.

Associated Items

Affected Objects

TEST NAME

Ensure Custom Anti-Phishing Policy is Present

Description

Rationale

Impact

It is possible to create custom Anti-Phishing Policies in Exchange Online to provide additional protection against threats that may be received via email. No Anti-Phishing Policy besides the Microsoft Default Anti-Phishing Policy was detected in the O365 tenant. Although the default Anti-Phishing Policy can provide some protection, each organization should consider creating an Anti-Phishing Policy that is customized to suit the nature of their day-to-day activities.

Recommendation and Steps

Follow the 'Anti-Phishing Policies in Microsoft 365' article below to begin constructing a custom Anti-Phishing Policy.

Associated Items

Affected Objects

TEST NAME

Ensure Custom DLP Policies are Present

Description

Rationale

Impact

Organizations have sensitive information under their control such as financial data, proprietary data, credit card numbers, health records, or social security numbers. To help protect this sensitive data and reduce risk, they need a way to prevent their users from inappropriately sharing it with people who should not have it. Default configurations may not meet the business needs, or compliance requirements of the organization. Custom policies can be configured to address any gaps that default settings do not remediate.

Recommendation and Steps

Determine if a custom DLP policy is beneficial for the Tenant, identify any gaps between desired end state and default policy configurations, and implement any new policies as needed.

Associated Items

Affected Objects

TEST NAME

Ensure Custom DLP Sensitive Information Types are Defined

Description

Rationale

Impact

Organizations have sensitive information under their control such as financial data, proprietary data, credit card numbers, health records, or social security numbers. Default configurations may not meet the business needs, or compliance requirements of the organization. Custom-defined information types may be configured to mitigate any gaps that default settings do not address.

Recommendation and Steps

Determine if there is a need for custom DLP Sensitive Information types and add as needed.

Associated Items

Affected Objects

TEST NAME

Ensure Information Protection sensitivity label policies are published

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

Rationale

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.

Impact

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).

Recommendation and Steps

**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.

Associated Items

Affected Objects

TEST NAME

Ensure devices without a compliance policy are marked not compliant

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`

Rationale

Implementing this setting is a first step in adopting compliance policies for devices. When used in 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.

Impact

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.

Recommendation and Steps

**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
```

Associated Items

Affected Objects

TEST NAME

Ensure Security Defaults is disabled on Azure Active Directory

Description

Rationale

Impact

The potential impact associated with disabling of Security Defaults is dependent upon the security controls implemented in the environment. It is likely that most organizations disabling Security Defaults plan to implement equivalent controls to replace Security Defaults. It may be necessary to check settings in other Microsoft products, such as Azure, to ensure settings and functionality are as expected when disabling security defaults for MS365.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Restrict non-admin users from creating tenants is set to Yes

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.

Rationale

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.

Impact

Non-admin users will need to contact I.T. if they have a valid reason to create a tenant.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/
2. Click to expand `Identity`> `Users` > `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
```

Associated Items

Affected Objects

TEST NAME

Ensure Per-user MFA is disabled

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).

Rationale

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.

Impact

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](https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-getstarted#convert-users-from-per-user-mfa-to-conditional-access-based-mfa)

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure third party integrated applications are not allowed

Description

App registration allows users to register custom-developed applications for use within the directory.

Rationale

Third-party integrated applications connection to services should be disabled unless there is a very clear value and robust security controls are in place. While there are legitimate uses, attackers can grant access from breached accounts to third party applications to exfiltrate data from your tenancy without having to maintain the breached account.

Impact

The implementation of this change will impact both end users and administrators. End users will not be able to integrate third-party applications that they may wish to use. Administrators are likely to receive requests from end users to grant them permission to the necessary third-party applications.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure access to the Entra admin center is restricted

Description

Restrict non-privileged users from signing into the Microsoft Entra admin center.

**Note:** This recommendation only affects access to the web portal. It does not prevent privileged users from using other methods such as Rest API or PowerShell to obtain information. Those channels are addressed elsewhere in this document.

Rationale

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 that could result in increased administrative overhead. Additionally, a compromised end user account could be used by a malicious attacker as a means to gather additional information and escalate an attack.

**Note:** Users will still be able to sign into Microsoft Entra admin center but will be unable to see directory information.

Impact

In the event there are resources a user owns that need to be changed in the Entra Admin center, then an administrator would need to make those changes.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/
2. Click to expand `Identity`> `Users` > `User settings`.
3. Set `Restrict access to Microsoft Entra admin center` to `Yes` then `Save`.

Associated Items

Affected Objects

TEST NAME

Ensure the option to remain signed in is hidden

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.

Rationale

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.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Identity`> `Users` > `User settings`.
3. Set `Show keep user signed in` to `No`.
4. Click `Save`.

Associated Items

Affected Objects

TEST NAME

Ensure LinkedIn account connections is disabled

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.

Rationale

Disabling LinkedIn integration prevents potential phishing attacks and risk scenarios where an external party could accidentally disclose sensitive information.

Impact

Users will not be able to sync contacts or use LinkedIn integration.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Identity` > `Users` select `User settings`.
3. Under `LinkedIn account connections` select `No`.
4. Click `Save`.

Associated Items

Affected Objects

TEST NAME

Ensure a dynamic group for guest users is created

Description

A dynamic group is a dynamic configuration of security group membership for Microsoft Entra ID. Administrators can set rules to populate groups that are created in Entra ID based on user attributes (such as userType, department, or country/region). Members can be automatically added to or removed from a security group based on their attributes.

The recommended state is to create a dynamic group that includes guest accounts.

Rationale

Dynamic groups allow for an automated method to assign group membership.

Guest user accounts will be automatically added to this group and through this existing conditional access rules, access controls and other security measures will ensure that new guest accounts are restricted in the same manner as existing guest accounts.

Impact

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Identity` > `Groups` select `All groups`.
3. Select `New group` and assign the following values:
 - Group type: `Security`
 - Microsoft Entra roles can be assigned to the group: `No`
 - Membership type: `Dynamic User`
4. Select `Add dynamic query`.
5. Above the `Rule syntax` text box, select `Edit`. 
6. Place the following expression in the box:
```
(user.userType -eq Guest)
```
7. Select `OK` and `Save`

**To remediate using PowerShell:**

1. Connect to Microsoft Graph using `Connect-MgGraph -Scopes Group.ReadWrite.All`
2. In the script below edit `DisplayName` and `MailNickname` as needed and run:

```
$params = @{
 DisplayName = Dynamic Test Group
 MailNickname = DynGuestUsers
 MailEnabled = $false
 SecurityEnabled = $true
 GroupTypes = DynamicMembership
 MembershipRule = '(user.userType -eq Guest)'
 MembershipRuleProcessingState = On
}

New-MgGroup @params
```

Associated Items

Affected Objects

TEST NAME

Ensure user consent to apps accessing company data on their behalf is not allowed

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.

Rationale

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.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Identity` > `Applications` select `Enterprise applications`.
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.

Associated Items

Affected Objects

TEST NAME

Ensure the admin consent workflow is enabled

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.

Rationale

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.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure guest user invitations are limited to the Guest Inviter role

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 for guest invite restrictions is `Only users assigned to specific admin roles can invite guest users`.

Rationale

Restricting who can invite guests limits the exposure the organization might face from unauthorized accounts.

Impact

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.

Recommendation and Steps

**To remediate using the UI:** 

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Identity` > `External Identities` select `External collaboration settings`.
3. Under **Guest invite settings** set `Guest invite restrictions` to `Only users assigned to specific admin roles can invite guest users`.

**To remediate using PowerShell:**

1. Connect to Microsoft Graph using `Connect-MgGraph -Scopes Policy.ReadWrite.Authorization`
2. Run the following command:
```
Update-MgPolicyAuthorizationPolicy -AllowInvitesFrom 'adminsAndGuestInviters'
```

**Note:** The more restrictive position of the value will also pass audit, it is however not required.

Associated Items

Affected Objects

TEST NAME

Ensure that guest user access is restricted

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.

Rationale

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.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure that collaboration invitations are sent to allowed domains only

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.

Rationale

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.

Impact

This could make collaboration more difficult if the setting is not quickly updated when a new domain is identified as allowed.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Identity` > `External Identities` 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`.

Associated Items

Affected Objects

TEST NAME

Ensure that password hash sync is enabled for hybrid deployments

Description

Password hash synchronization is one of the sign-in methods used to accomplish hybrid identity synchronization. Microsoft Entra Connect synchronizes a hash, of the hash, of a user's password from an on-premises Active Directory instance to a cloud-based Entra ID instance.

**Note:** Audit and remediation procedures in this recommendation only apply to Microsoft 365 tenants operating in a hybrid configuration using Entra Connect sync, and do not apply to federated domains.

Rationale

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.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure multifactor authentication is enabled for all users in administrative roles

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.

Rationale

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.

Impact

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.

Recommendation and Steps

**To remediate using the UI:** 

1. Navigate to the `Microsoft Entra admin center` https://entra.microsoft.com.
2. Click expand `Protection` > `Conditional Access` select `Policies`.
3. Click `New policy`.
 - Under `Users` include `Select users and groups` and check `Directory roles`.
 - At a minimum, include the directory roles listed below in this section of the document.
 - Under `Target resources` include `All resources (formerly 'All cloud apps')` and do not create any exclusions.
 - Under `Grant` select `Grant Access` and check either `Require multifactor authentication` or `Require authentication strength`.
 - Click `Select` at the bottom of the pane.
4. Under `Enable policy` set it to `Report-only` until the organization is ready to enable it.
5. Click `Create`.

**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

**Note:** Report-only is an acceptable first stage when introducing any CA policy. The control, however, is not complete until the policy is on.

Associated Items

Affected Objects

TEST NAME

Ensure multifactor authentication is enabled for all users

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.

Rationale

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.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to the `Microsoft Entra admin center` https://entra.microsoft.com.
2. Click expand `Protection` > `Conditional Access` select `Policies`.
3. Click `New policy`.
 - Under `Users` include `All users`.
 - Under `Target resources` include `All resources (formerly 'All cloud apps')` and do not create any exclusions.
 - Under `Grant` select `Grant Access` and check either `Require multifactor authentication` or `Require authentication strength`.
 - Click `Select` at the bottom of the pane.
4. Under `Enable policy` set it to `Report-only` until the organization is ready to enable it.
5. Click `Create`.

**Note:** Break-glass accounts should be excluded from all Conditional Access policies.

Associated Items

Affected Objects

TEST NAME

Enable Conditional Access policies to block legacy authentication

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.

Rationale

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.

Impact

Enabling this setting will prevent users from connecting with older versions of Office, ActiveSync or using protocols like IMAP, POP or SMTP and may require upgrades to older versions of Office, and use of mobile mail clients that support modern authentication.

This will also cause multifunction devices such as printers from using scan to e-mail function if they are using a legacy authentication method. Microsoft has mail flow best practices in the link below which can be used to configure a MFP to work with modern 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

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to the `Microsoft Entra admin center` https://entra.microsoft.com.
2. Click expand `Protection` > `Conditional Access` select `Policies`.
3. Create a new policy by selecting `New policy`.
 - Under `Users` include `All users`.
 - Under `Target resources` include `All resources (formerly 'All cloud apps')`.
 - Under `Conditions` select `Client apps` and check the boxes for `Exchange ActiveSync clients` and `Other clients`.
 - Under `Grant` select `Block Access`.
 - Click `Select`.
4. Set the policy `On` and click `Create`.

**Note:** Break-glass accounts should be excluded from all Conditional Access policies.

Associated Items

Affected Objects

TEST NAME

Ensure Sign-in frequency is enabled and browser sessions are not persistent for Administrative users

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

Rationale

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.

Impact

Users with Administrative roles will be prompted at the frequency set for MFA.

Recommendation and Steps

**To remediate using the UI:** 

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Protection` > `Conditional Access` Select `Policies`.
3. Click `New policy`.
 - Under `Users` include `Select users and groups` and check `Directory roles`.
 - At a minimum, include the directory roles listed below in this section of the document.
 - Under `Target resources` include `All resources (formerly 'All cloud apps')`.
 - Under `Grant` select `Grant Access` and check `Require multifactor authentication`.
 - Under `Session` select `Sign-in frequency` select `Periodic reauthentication` and set it to `4` `hours` (or less).
 - Check `Persistent browser session` then select `Never persistent` in the drop-down menu.
4. Under `Enable policy` set it to `Report-only` until the organization is ready to enable it.

**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

**Note:** Break-glass accounts should be excluded from all Conditional Access policies.

Associated Items

Affected Objects

TEST NAME

Ensure Phishing-resistant MFA strength is required for Administrators

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.

Rationale

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.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to the `Microsoft Entra admin center` https://entra.microsoft.com.
2. Click expand `Protection` > `Conditional Access` select `Policies`.
3. Click `New policy`.
 - Under `Users` include `Select users and groups` and check `Directory roles`.
 - At a minimum, include the directory roles listed below in this section of the document.
 - Under `Target resources` include `All resources (formerly 'All cloud apps')` and do not create any exclusions.
 - Under `Grant` select `Grant Access` and check `Require authentication strength` and set `Phishing-resistant MFA` in the dropdown box.
 - Click `Select`.
4. Under `Enable policy` set it to `Report-only` until the organization is ready to enable it.
5. Click `Create`.

**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

**Warning:** Ensure administrators are pre-registered with strong authentication before enforcing the policy. After which the policy must be set to `On`.

Associated Items

Affected Objects

TEST NAME

Ensure Microsoft Azure Management is limited to administrative roles

Description

Rationale

Impact

The Microsoft Azure Management application governs various Azure services and can be secured through the implementation of a Conditional Access policy. This policy can restrict specific user accounts from accessing the related portals and applications.

When Conditional Access policy is targeted to the Microsoft Azure Management application, within the Conditional Access policy app picker the policy will be enforced for tokens issued to application IDs of a set of services closely bound to the portal.

- Azure Resource Manager
- Azure portal, which also covers the Microsoft Entra admin center
- Azure Data Lake
- Application Insights API
- Log Analytics API

Microsoft Azure Management should be restricted to specific pre-determined administrative roles.

NOTE: Blocking Microsoft Azure Management will prevent non-privileged users from signing into most portals other than Microsoft 365 Defender and Microsoft Purview.
Blocking sign-in to Azure Management applications and portals enhances security of sensitive data by restricting access to privileged users. This mitigates potential exposure due to administrative errors or software vulnerabilities, as well as acting as a defense in depth measure against security breaches.
PIM functionality will be impacted unless non-privileged users are first assigned to a permanent group or role that is excluded from this policy. When attempting to checkout a role in the Entra ID PIM area they will receive the message  

Because the policy is applied to the Azure management portal and API, services, or clients with an Azure API service dependency, can indirectly be impacted:

Classic deployment model APIs
Azure PowerShell
Azure CLI
Azure DevOps
Azure Data Factory portal
Azure Event Hubs
Azure Service Bus
Azure SQL Database
SQL Managed Instance
Azure Synapse
Visual Studio subscriptions administrator portal
Microsoft IoT Central

Recommendation and Steps

To enable Microsoft Azure Management restrictions:

1. Navigate to the Microsoft Entra admin center https://entra.microsoft.com.
2. Click expand Protection > Conditional Access select Policies.
3. Click New Policy and then name the policy.
4. Select Users > Include > All Users
5. Select Users > Exclude > Directory roles and select only administrative roles. See audit section for more information.
6. Select Cloud apps or actions > Select apps > Select then click the box next to Microsoft Azure Management.
7. Click Select.
8. Select Grant > Block access and click Select.
9. Ensure Enable Policy is On then click Create.

WARNING: Exclude Global Administrator at a minimum to avoid being locked out. Report-only is a good option to use when testing any Conditional Access policy for the first time.

Associated Items

Affected Objects

TEST NAME

Enable Identity Protection user risk policies

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

Rationale

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.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Enable Identity Protection sign-in risk policies

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

Rationale

Turning on the sign-in risk policy ensures that suspicious sign-ins are challenged for multi-factor authentication.

Impact

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.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure sign-in risk is blocked for medium and high risk

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

Rationale

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.

Impact

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.

**Note:** Break-glass accounts should always be excluded from risk detection.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure a managed device is required for authentication

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 Intune (Endpoint Manager). 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 is:
- `Require device to be marked as compliant`
- `Require Microsoft Entra hybrid joined device`
- `Require one of the selected controls`

Rationale

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).

Impact

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 compliances 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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to the `Microsoft Entra admin center` https://entra.microsoft.com.
2. Click expand `Protection` > `Conditional Access` select `Policies`.
3. Create a new policy by selecting `New policy`.
 - Under `Users` include `All users`.
 - Under `Target resources` include `All resources (formerly 'All cloud apps')`.
 - Under `Grant` select `Grant access`.
 - Select only the checkboxes `Require device to be marked as compliant` and `Require Microsoft Entra hybrid joined device`.
 - Choose `Require one of the selected controls` and click `Select` at the bottom.
4. Under `Enable policy` set it to `Report-only` until the organization is ready to enable it.
5. Click `Create`.

**Note:** Guest user accounts, if collaborating with the organization, should be considered when testing this policy.

Associated Items

Affected Objects

TEST NAME

Ensure a managed device is required to register security information

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 not, providing more granular control over whether or not a user can register MFA on a device.

When using `Require device to be marked as compliant`, the device must pass checks configured in **Compliance** policies defined within Intune (Endpoint Manager). 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 register MFA from the device. This functions as an OR operator.

The recommended state is to restrict `Register security information` to a device that is marked as compliant or Entra hybrid joined.

Rationale

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.

Impact

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.

In these cases where the person enrolling in MFA (enrollee) doesn't have physical access to a managed device, a help desk process can be created using a Teams meeting to complete enrollment using: 1) a durable process to verify the enrollee's identity including government identification with a photograph held up to the camera, information only the enrollee should know, and verification by the enrollee's direct manager in the same meeting; 2) complete enrollment in the same Teams meeting with the enrollee being granted screen and keyboard access to the help desk person's InPrivate Edge browser session.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to the `Microsoft Entra admin center` https://entra.microsoft.com.
2. Click expand `Protection` > `Conditional Access` select `Policies`.
3. Create a new policy by selecting `New policy`.
 - Under `Users` include `All users`.
 - Under `Target resources` select `User actions` and check `Register security information`.
 - Under `Grant` select `Grant access`.
 - Check only `Require multifactor authentication` and `Require Microsoft Entra hybrid joined device`.
 - Choose `Require one of the selected controls` and click `Select` at the bottom.
4. Under `Enable policy` set it to `Report-only` until the organization is ready to enable it.
5. Click `Create`.

**Note:** Break-glass accounts should be excluded from all Conditional Access policies.

Associated Items

Affected Objects

TEST NAME

Ensure sign-in frequency for Intune Enrollment is set to Every time

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.

Rationale

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.

Impact

New users enrolling into Intune through an automated process may need to sign-in again if the enrollment process goes on for too long.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to the `Microsoft Entra admin center` https://entra.microsoft.com.
2. Click expand `Protection` > `Conditional Access` select `Policies`.
3. Create a new policy by selecting `New policy`.
 - Under `Users` include `All users`.
 - Under `Target resources` select `Resources (formerly cloud apps)`, choose `Select resources` and add `Microsoft Intune Enrollment` to the list.
 - Under `Grant` select `Grant access`.
 - Check either `Require multifactor authentication` or `Require authentication strength`.
 - Under `Session` check `Sign-in frequency` and select `Every time`.
4. Under `Enable policy` set it to `Report-only` until the organization is ready to enable it.
5. Click `Create`.

**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.

**Note:** Break-glass accounts should be excluded from all Conditional Access policies.

Associated Items

Affected Objects

TEST NAME

Ensure the device code sign-in flow is blocked

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.

Rationale

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.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to the `Microsoft Entra admin center` https://entra.microsoft.com.
2. Click expand `Protection` > `Conditional Access` select `Policies`.
3. Create a new policy by selecting `New policy`.
 - Under `Users` include `All users`.
 - Under `Target resources` > `Resources (formerly cloud apps)` include `All resources (formerly 'All cloud apps')`.
 - Under `Conditions` > `Authentication flows` set `Configure` is set to `Yes`, select `Device code flow` and click `Save`.
 - 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`.

**Note:** Break-glass accounts should be excluded from all Conditional Access policies.

Associated Items

Affected Objects

TEST NAME

Ensure Microsoft Authenticator is configured to protect against MFA fatigue

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.

Ensure the following are `Enabled`.
- `Require number matching for push notifications`
- `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.

Rationale

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.

Impact

Additional interaction will be required by end users using number matching as opposed to simply pressing Approve for login attempts.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to the `Microsoft Entra admin center` https://entra.microsoft.com.
2. Click to expand `Protection` > `Authentication methods` 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:
 - `Require number matching for push notifications` Status is set to `Enabled`, Target `All users`
 - `Show application name in push and passwordless notifications` is set to `Enabled`, Target `All users`
 - `Show geographic location in push and passwordless notifications` is set to `Enabled`, Target `All users`

**Note:** Valid groups such as break glass accounts can be excluded per organization policy.

Associated Items

Affected Objects

TEST NAME

Ensure custom banned passwords lists are used

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

Rationale

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.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/
2. Click to expand `Protection` > `Authentication methods`
3. Select `Password protection`
4. Set `Enforce custom list` to `Yes`
5. In `Custom banned password list` create a list using suggestions outlined in this document.
6. 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

Associated Items

Affected Objects

TEST NAME

Ensure all member users are MFA capable

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`.

Rationale

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.

Impact

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.

Recommendation and Steps

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

Associated Items

Affected Objects

TEST NAME

Ensure weak authentication methods are disabled

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 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` these methods:
- SMS
- Voice Call
- Email OTP

Rationale

The SMS and Voice call methods are vulnerable to SIM swapping which could allow an attacker to gain access to your Microsoft 365 account.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Protection` select `Authentication methods`.
3. Select `Policies`.
4. Inspect each method that is out of compliance and remediate:
 - Click on the method to open it.
 - Change the `Enable` toggle to the off position.
 - 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 all three authentication methods:
```
$params = @(
 @{ Id = Sms; State = disabled },
 @{ Id = Voice; State = disabled },
 @{ Id = Email; State = disabled }
)

Update-MgPolicyAuthenticationMethodPolicy -AuthenticationMethodConfigurations $params
```

Associated Items

Affected Objects

TEST NAME

Ensure that password protection is enabled for Active Directory

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.

Rationale

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.

Impact

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.

Recommendation and Steps

**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. Click to expand `Protection` select `Authentication methods`.
3. Select `Password protection` and set `Enable password protection on Windows Server Active Directory` to `Yes` and `Mode` to `Enforced`.

Associated Items

Affected Objects

TEST NAME

Ensure system-preferred multifactor authentication is enabled

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`.

Rationale

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.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Protection` select `Authentication methods`.
3. Select `Settings`.
4. Set the **System-preferred multifactor authentication** `State` to `Enabled` and include `All users`.
5. Any users exclusions should be documented and reviewed annually.

Associated Items

Affected Objects

TEST NAME

Ensure Self service password reset enabled is set to All

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. 

**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.

Rationale

Users will no longer need to engage the helpdesk for password resets, and the password reset mechanism will automatically block common, easily guessable passwords.

Impact

Users will be required to provide additional contact information to enroll in self-service password reset. Additionally, minor user education may be required for users that are used to calling a help desk for assistance with password resets. 

**Note:** This is unavailable if using Entra Connect / Sync in a hybrid environment.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Protection` > `Password reset` select `Properties`.
3. Set `Self service password reset enabled` to `All`

Associated Items

Affected Objects

TEST NAME

Ensure the self-service password reset activity report is reviewed and actioned

Description

Rationale

Impact

Auditing Process needs to be created and followed.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure the Azure AD Risky sign-ins report is reviewed at least weekly

Description

Rationale

Impact

Auditing Process needs to be created and followed.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Privileged Identity Management is used to manage roles

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. Organizations should remove permanent members from privileged Office 365 roles and instead make them eligible, through a JIT activation workflow.

Rationale

Organizations want to minimize the number of people who have access to secure information or resources, because that reduces the chance of a malicious actor getting that access, or an authorized user inadvertently impacting a sensitive resource. However, users still need to carry out privileged operations in Entra ID. Organizations can give users just-in-time (JIT) privileged access to roles. There is a need for oversight for what those users are doing with their administrator privileges. PIM helps to mitigate the risk of excessive, unnecessary, or misused access rights.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Identity Governance` select `Privileged Identity Management`.
3. Under **Manage** select `Microsoft Entra Roles`.
4. Under **Manage** select `Roles`.
5. Inspect at a minimum the following sensitive roles. For each of the members that have an `ASSIGNMENT TYPE` of `Permanent`, click on the `...` and choose `Make eligible`:
- `Application Administrator`
- `Authentication Administrator`
- `Azure Information Protection Administrator`
- `Billing Administrator`
- `Cloud Application Administrator`
- `Cloud Device Administrator`
- `Compliance Administrator`
- `Customer LockBox Access Approver`
- `Exchange Administrator`
- `Fabric Administrator`
- `Global Administrator`
- `HelpDesk Administrator`
- `Intune Administrator`
- `Kaizala Administrator`
- `License Administrator`
- `Microsoft Entra Joined Device Local Administrator`
- `Password Administrator`
- `Privileged Authentication Administrator`
- `Privileged Role Administrator`
- `Security Administrator`
- `SharePoint Administrator`
- `Skype for Business Administrator`
- `Teams Administrator`
- `User Administrator`

Associated Items

Affected Objects

TEST NAME

Ensure Access reviews for Guest Users are configured

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.

Ensure `Access reviews` for Guest Users are configured to be performed no less frequently than `monthly`.

Rationale

Access to groups and applications for guests can change over time. If a guest user's access to a particular folder goes unnoticed, they may unintentionally gain access to sensitive data if a member adds new files or data to the folder or application. 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.

Impact

Access reviews that are ignored may cause guest users to lose access to resources temporarily.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Access reviews for high privileged Azure AD roles are configured

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.

Ensure `Access reviews` for high privileged Entra ID roles are done `monthly` or more frequently. These reviews should include **at a minimum** the roles listed below:

- Global Administrator
- Exchange Administrator
- SharePoint Administrator
- Teams Administrator
- Security Administrator

**Note:** An access review is created for each role selected after completing the process.

Rationale

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. Furthermore, if configured these reviews can enable a fail-closed mechanism to remove access to the subject if the reviewer does not respond to the review.

Impact

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 by association.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure approval is required for Global Administrator role activation

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.

Rationale

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 require an approval workflow so therefore it is important to implement and use PIM correctly.

Impact

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.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Identity Governance` select `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 two approvers.
9. Click `Update`.

Associated Items

Affected Objects

TEST NAME

Ensure approval is required for Privileged Role Administrator activation

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.

Rationale

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 require an approval workflow so therefore it is important to implement and use PIM correctly.

Impact

Requiring approvers for automatic role assignment can slightly increase administrative overhead and add delays to tasks.

Recommendation and Steps

**To remediate using the UI:**

1. Navigate to `Microsoft Entra admin center` https://entra.microsoft.com/.
2. Click to expand `Identity Governance` select `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 two approvers.
9. Click `Update`.

Associated Items

Affected Objects

TEST NAME

Use Just In Time privileged access to Microsoft 365 roles

Description

Rationale

Impact

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.

Recommendation and Steps

Azure Active Directory Privileged Identity Management can be used to audit roles, allow just in time activation of roles and allow for periodic role attestation. Organizations should remove permanent members from privileged Microsoft 365 roles and instead make them eligible, through a JIT activation workflow. Organizations want to minimize the number of people who have access to secure information or resources, because that reduces the chance of a malicious actor getting that access, or an authorized user inadvertently impacting a sensitive resource. However, users still need to carry out privileged operations in Azure AD and Microsoft 365. Organizations can give users just-in-time (JIT) privileged access to roles.

Associated Items

Affected Objects

TEST NAME

Ensure AuditBypassEnabled is not enabled on mailboxes

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.

Rationale

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.

Impact

None - this is the default behavior.

Recommendation and Steps

Disable Audit Bypass on all mailboxes 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  -ForegroundColor Green
}

Associated Items

Affected Objects

TEST NAME

Ensure AuditBypassEnabled is not enabled on mailboxes

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.

Rationale

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.

Impact

None - this is the default behavior.

Recommendation and Steps

Disable Audit Bypass on all mailboxes 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  -ForegroundColor Green
}

Associated Items

Affected Objects

TEST NAME

Ensure AuditDisabled organizationally is set to False

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.

Rationale

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.

**Note:** Without advanced auditing (E5 function) the logs are limited to 90 days.

Impact

None - this is the default behavior as of 2019.

Recommendation and Steps

Associated Items