Configuring a Safe Attachments policy

To configure a Safe Attachments policy, you must be a member of the Organization Management or the Security Administrator role groups configured in the Permissions & Roles section of the Microsoft 365 Security Portal (https://security.microsoft.com).

Use the following steps to configure a Safe Attachment policy:

1. Log in to https://security.microsoft.com with the required permissions.

2. Under Email & Collaboration, click Policies & Rules > Threat Policies.

3. In Threat Policies, under Policies, click the Safe Attachments icon.

4. Click Create to start the Create A New Safe Attachments Policy wizard shown in Figure 1-10.

   

5. On the Name Your Policy screen, enter a Name for the policy and add a Description. You can have more than one policy that targets specific users in your organization, so keep this in mind when choosing your naming scheme. Click Next to advance to the Settings page shown in Figure 1-11.

   

6. The Safe Attachments Unknown Malware Response setting controls how the Safe Attachments feature will interact with an email containing a file attachment.

   • Off—Attachment Will Not Be Scanned For Malware This setting essentially disables Safe Attachments.

   • Monitor—Continue Delivering The Message After Malware Is Detected; Track Scan Results This setting is an “audit mode” that allows you to do a what-if analysis of attachments that would be blocked without actually blocking the attachments.

   • Block—Block The Current And Future Email And Attachments With Detected Malware This is the most intrusive Safe Attachments mode. If an email contains an attachment that is found to be malicious by Safe Attachments, the email and the attachment will not be delivered to the recipient(s). This is the default and recommended setting.

   • Replace—Block The Attachments With Detected Malware, Continue To Deliver The Message In this mode, Safe Attachments will deliver the email, but the attachment will be replaced with a text file indicating the file was infected and was removed.

   • Dynamic Delivery (Preview Feature)—Deliver The Message Without Attachments Immediately And Reattach Once Scan Is Complete This setting delivers the email body while the attachment is scanned. A preview of the attachment is provided until the Safe Attachments analysis is complete. If the attachment is found to be malicious, a text file will instead be placed in the message indicating the file was infected and removed.

7. The last few options on the settings page are seen in Figure 1-12.

   

8. If the Redirect Attachment On Detection option is selected, the detected malicious files will be sent to a mailbox that you configure, so you can collect these samples for further analysis.

9. Selecting the Apply The Above Selection If Malware Scanning For Attachment Times Out Or Errors Occur option ensures that files that time out or error out during scanning are treated the same as what you configured in the policy. Be sure to select the Redirect Attachment On Detection if a file is not malicious so that you can recover the file for the user.

10. Once you have the options configured to meet your needs, click Next to show the Applied To page shown in Figure 1-13.

    

11. The Applied To page is where you configure which groups, users, or domains this Safe Attachments policy will apply to. In this example, the policy will apply to all users with email addresses with the domains fespiresec.mail.onmicrosoft.com and fespiresec.onmicrosoft.com. Combinations of conditions can be used to include specific users and groups of users. Exceptions can be used to exclude specific users, groups, or domains from this Safe Attachments policy. Click Next.

12. The Review Your Settings page lists all the configuration settings made so far in the Safe Attachments configuration wizard. You can edit any of the settings from this screen. When the settings are configured as desired, click Finish to create the Safe Attachments policy.

Multiple Safe Attachments policies can be created, as shown in Figure 1-14.

Safe Attachments policies can be enabled or disabled using the slider under Status. The Priority determines the order in which the policies are applied. The policy with Priority 0 is applied first, followed by the policy with Priority 1, and so on. Once a policy’s Applied To condition is met, no additional policies are processed.

Clicking Global Settings opens a side menu, as shown in Figure 1-15.

These Global settings apply to files stored on SharePoint, OneDrive, and Microsoft Teams and prevent users from accessing malicious files in these locations tenant wide. The key difference between these settings and Safe Attachments policies are that these setting focus on files outside of emails. Here are the protections you can enable in Global Settings:

• Turn On Defender For Office 365 For Sharepoint, OneDrive, And Microsoft Teams applies Safe Attachments’ malicious file-detection capabilities for files stored in these locations. With this option enabled, if a malicious file is stored in these locations, the user would be unable to open the file. This option should be set to Enabled.

• Turn On Safe Documents For Office Clients enables the files opened by Office 365 apps to be scanned by Cloud Protection, a component of Microsoft Defender for Endpoint that provides an added layer of protection on top of Safe Attachments protection. This option should be set to Enabled.

• Allow People To Click Through Protected View Even If Safe Documents Identified The File As Malicious would allow users to override Safe Documents’ verdict of a file. We recommend that you do not enable this option.

Impersonation protection

Impersonation protection applies to two types of impersonation: user impersonation and domain impersonation. User impersonation occurs when an attacker sends an email where the user portion of an email address mimics a user who is credible to the recipient. In the previous spear phishing example, the attacker used Bob Smith as the sender’s name to mimic the Contoso CEO. The attacker could have further impersonated Bob Smith by creating the email account [email protected] to increase the chances of the recipient responding to the message.

With domain impersonation, an attacker registers a domain that closely resembles a legitimate domain. For example, instead of contoso.com, the attacker could register consoto.com, which means at first glance, the recipient would recognize the Contoso name and interact with the message. Combinations of symbols and numbers are also used in this technique, such as [email protected]. (A zero is used instead of the first letter ‘O’ in CONTOSO.)

Configurable advanced phishing thresholds

Advanced phishing thresholds allow you to define how aggressive the machine learning models should be when determining if an email is a phish. The machine learning models driving the phishing detection in Defender for Office 365 have the ability score on a scale of low, medium, high, or very-high confidence levels. The more aggressive you configure this setting, the higher the chances of false positives. False positives occur when a legitimate email is falsely determined to be a phishing email and is kept out of the recipient’s inbox. False negatives can occur if the setting is not aggressive enough, so this setting is a double-edged sword. Each organization is different in terms of how much risk they are willing to accept, which will drive the decision when setting this threshold.

Below are the advanced phishing thresholds available:

• 1—Standard The machine learning model will treat phish based on the determined confidence level. This is the default setting.

• 2—Aggressive High-confidence phish and above will be treated like very high–confidence phish.

• 3—More aggressive Medium-confidence phish and above will be treated like very high–confidence phish.

• 4—Most aggressive All emails determined to be any level of phish will be treated like very-high-confidence phish.

Configuring an anti-phishing policy

To configure a Safe Links policy, you must be a member of the Organization Management or the Security Administrator role groups configured in the Permissions & Roles section of the Microsoft 365 Security Portal (https://security.microsoft.com). For read-only access to Safe Link policies, you must be a member of either the Global Reader or Security Reader role groups.

Use the following steps to configure an anti-phishing policy:

1. Log in to https://security.microsoft.com.

2. Under Email & Collaboration, click Policies & Rules > Threat Policies.

3. In Threat Policies, under Policies, click the Anti-Phishing icon.

4. Click Create to start the Create A New Anti-phishing Policy wizard and display the Name Your Policy screen, as shown in Figure 1-16.

   

5. Type in a Name and a Description for the policy. You can have more than one policy that targets specific users in your organization, so keep this in mind when choosing your naming scheme. Click Next to advance to the Applied To page shown in Figure 1-17.

   

6. The Applied To page is where you configure which groups, users, or domains this anti-phishing policy will apply to. The policy will apply to all users with email addresses with the domains fespiresec.mail.onmicrosoft.com and fespiresec.onmicrosoft.com. Combinations of conditions can be used to include specific users and groups of users. Exceptions can be used to exclude specific users, groups, or domains from this anti-phishing policy. Click Next.

7. The Review Your Settings page lists the configurations made so far in the anti-phishing configuration wizard. You can edit any of the settings from this screen. When the settings are configured as desired, click Create This Policy, which will create the policy with default settings.

8. On the Anti-Phishing Policy screen, click the anti-phishing policy you just created. This will open a fly-out menu where you configure the Impersonation settings and Advanced Settings, as shown in Figure 1-18.

   

9. Click Edit next to the Impersonation settings to open the Edit Impersonation Policy wizard; the wizard starts with the Editing Add Users To Protect page shown in Figure 1-19.

   

10. Click the toggle button to On. This will expose a section where you can add users who you want to protect from user impersonation. You can add up to 60 email accounts to this list. Typically, you want to add users with high public visibility, such as the CEO, as well as external users associated with your company, such as board members. Bob Smith was added because he is the Contoso CEO. When finished adding email accounts, click Add Domains To Protect, shown in Figure 1-20.

    

11. On the Add Domains To Protect page of the wizard, enter the domains you want to protect from domain impersonation. You can add up to 50 domains to protect. To add the domains configured in your Office 365 tenant, click the toggle switch under Automatically Include The Domains I Own to On. To enter email domains that are external to your company that you normally do business with, click the toggle switch under the Include Custom Domains to On. Tailspintoys.com was entered under Add Domains because they are a major supplier to Contoso. When you are finished adding domains, click the Actions option on the left, as shown in Figure 1-21.

    

12. The Actions wizard page is where you configure what action you want performed when an email is believed to be impersonating a user or domain. Both cases are set to Move Message To The Recipients’ Junk Email Folders. You can set the same action on both user and domain impersonation, or you can set a different action for each. The choices for Actions include:

    • Redirect Message To Other Email Addresses

    • Move Message To The Recipients’ Junk Email Folders

    • Quarantine The Message

    • Deliver The Message And Add Other Addresses To The BCC Line

    • Delete The Message Before It’s Delivered

    • Don’t Apply Any Action

    The Turn On Impersonation Safety Tips text is a clickable link that when clicked opens the Safety Tips configuration window shown in Figure 1-22.

    

    These options allow a banner to be added to emails when a user or domain is impersonated or when unusual characters are present in the sender email address, such as [email protected] (where a zero is used instead of the first O in CONTOSO). Set the toggle switch to On for each of these settings and click Save when you are finished. This will return you to the Actions wizard page.

    When you have the options set on the Actions wizard page, click the Mailbox Intelligence option on the left, as shown in Figure 1-23.

    

13. Mailbox Intelligence is an additional layer of artificial intelligence–driven protection that learns the sending and receiving patterns of the users configured to be protected by the impersonation policy. This pattern learning improves the efficacy of the impersonation policy and should be turned on. If Mailbox Intelligence is what catches the impersonation, the action configured under If Email Is Sent By An Impersonated User is taken. The actions are configurable as follows:

    • Redirect Message To Other Email Addresses

    • Move Message To The Recipients’ Junk Email Folders

    • Quarantine The Message

    • Deliver The Message And Add Other Addresses To The Bcc Line

    • Delete The Message Before It’s Delivered

    • Don’t Apply Any Action

    Once you have the action configured, click the Add Trusted Senders And Domains option on the left, as shown in Figure 1-24.

    

14. Adding sender email addresses and domains to exempt them from the impersonation policy should only be used for reoccurring false positives. Exempting too many domains increases your exposure to impersonation. It is best to start out with no exceptions if possible. Click the Review Your Settings text on the left.

15. The Review Your Settings page lists all the configuration settings made so far in the Edit Impersonation Policy Configuration wizard. You can edit any of the settings from this screen. When the settings are configured as desired, click Save to apply the impersonation settings to the anti-phishing policy and return you to the Edit Your Policy Standard Anti-Phishing page shown in Figure 1-25.

    

16. Lastly, you need to configure the Advanced Settings of the Anti-Phishing Policy. Click Edit next to Advanced Settings to open the Editing Advanced Phishing Thresholds window shown in Figure 1-26.

    

17. Depending on the tolerance for false positives (in other words, emails not reaching the attended recipients), set this policy to the appropriate aggressiveness. One approach is to leave the settings at the default setting—1-Standard—and increase aggressiveness if there are false negatives. Repeat this process until the efficacy is acceptable. After setting the aggressiveness, click the Review Your Settings option on the left.

18. The Review Your Settings page lists all the configuration settings made so far in the Advanced Settings wizard. You can edit any of the settings from this screen. When the settings are configured as desired, click Save to apply the Advanced Settings to the anti-phishing policy.

19. Click Close to complete the configuration of the anti-phishing policy.

20. Multiple anti-phishing policies can be created, as shown in Figure 1-27.

    

21. Anti-phishing policies can be enabled or disabled using the slider under Status. The Priority determines in what order the policies are applied. The policy with priority 0 is applied first, followed by the policy with priority 1, and so on. Once a policy’s Applied To condition is met, no additional policies are processed.

Launching a simulation

To create a new attack training simulation, you must be a member of one of the following roles:

• Organization Management

• Security Administrator

• Attack Simulator Administrators

Follow these steps to create a new simulation:

1. Log in to https://security.microsoft.com.

2. Under Email & Collaboration, click Attack Simulation Training, as shown in Figure 1-28.

   

3. Click Simulations > Launch A Simulation, which brings up the Select Technique step in the attack simulation creation wizard shown in Figure 1-29.

   

4. Under Select Technique, choose the simulation technique you want to run against your users. For this simulation, choose Credential Harvest and click Next to bring up the Name Simulation page shown in Figure 1-30.

   

5. Enter a name for the simulation under Simulation Name and enter a Description. Click Next to advance to the Select Payload page shown in Figure 1-31.

   

6. Select a payload for the simulation. This is what will be used to bait the user for the Credential Harvest technique. You can sort the payloads by the Predicted Compromise Rate (%) column, which is calculated based on the compromised percentage of all Microsoft Defender for Office 365 customers. You can click Send A Test to the currently logged-in user to see the payload sample before you commit. Based on the 42 percent predicted compromise rate, select Payroll Work File Sharing and then click Next.

7. In the Target Users page, you can choose to Include All Users In My Organization or Include Only Specific Users And Groups. In this case, select Include Only Specific Users And Groups and click Add Users to open the Add Users fly-out pane, as shown in Figure 1-32.

   

8. In the Add Users fly-out pane, there are some thoughtful suggestions on which users to target. For example, you can target Users Not Targeted By A Simulation In The Last Three Months or Repeat Offenders, which are users who continue to fall for the simulations. In this case, there is a user group created in Azure Active Directory to run the first simulation on pilot users. Once the desired user group is selected, click Add User(s) and then click Next to advance to the Assign Training page as shown in Figure 1-33.

   

9. Assign Training is a welcome addition to the Attack Simulation Training feature. You can assign training to users who fall for the simulations by interacting with the email and/or payload. You can choose to use the Microsoft Training Experience, Redirect To A Custom URL (handy if you have a Learning Management System, or LMS), or No Training. For the Microsoft Training Experience option, you can then choose to allow the system to Assign Training For Me based on the technique and payload used or Select Training Courses And Modules Myself. A Due Date can also be set for when the training must be completed by the user. Click Next.

10. On the Training Landing Page, you can see the text the user will see if they fall for the simulation. You can customize the Header and Body of the page and view a preview. Type the text you want the user to see and click Next.

11. The last options to configure are the Launch Details for when you want the simulation to launch and when you want it to end. You can also select the option to Enable Region Aware Timezone Delivery so the simulation does not deliver to users outside your time zone during off-work hours, which might cause them to miss the email. Click Next to advance to the Review Simulation page, as seen in Figure 1-34.

    

12. Review Simulation allows you to edit the settings you have configured thus far in the simulation. You can also choose Send A Test to ensure the simulation operates as you expect before unleashing it on your users. Once you are satisfied with the configuration, click Submit to finalize the simulation.

Reviewing the Attack Simulation Training results

You can track how the simulation is playing out by clicking the simulation name on the main page of the Attack Simulation Training dashboard. Figure 1-35 shows one user who was tricked into interacting with the payload by clicking the link and supplying their credentials.

Attack Simulation Training settings

The Attack Simulation Training feature settings are largely configured as part of the simulations, however there are some overall settings that are important to mention.

In the Attack Simulation Training section, clicking Settings shows the following options, which are also shown in Figure 1-36.

• Repeat Offender Threshold is the number of consecutive simulations a user must fall for to be classified as a repeat offender. These users can be specifically targeted for simulations as mentioned previously.

• Enable User Training Reminders periodically emails users who have training due because they fell for a simulation and interacted with the simulation payload.

• Because you cannot delete simulations, Simulations Excluded From Reporting comes in handy if you have a simulation that is tainted for some reason (such as the URL was blocked by proxy) and you do not want this simulation to skew the reporting.

Sensitivity labels

Sensitivity labels allow for users to label their data according to company data handling policies. You can also auto label documents with a sensitivity label if they match your defined criteria.

Follow these steps to create a sensitivity label:

1. Log in to https://compliance.microsoft.com as a member of the Global Administrator role in Azure Active Directory. You can also use an account that is a member of the Compliance Data Administrator, Compliance Administrator, or Security Administrator role groups. Note these are Office 365 role groups, and they are separate from Azure Active Directory roles.

2. In the menu on the left side of the page, click Show All.

3. Under Solutions, click Information Protection.

4. On the Labels page, click Create A Label, which opens the New Sensitivity Label wizard shown in Figure 1-37.

5. In the New Sensitivity Label wizard, provide a Name, Display Name, Description For Users, and Description For Admins.

6. Select Files & Emails and click Next.

   

7. Select Mark The Content Of Files and click Next.

8. Select the content marking options you want to appear on files and emails classified with this sensitivity label and click Next.

9. When auto-labeling files and emails, you want users to be able to choose their labels at first, so leave the auto-labeling option unselected and click Next.

10. On the Define Protection Settings For Groups And Sites page, click Next.

11. On Review Your Settings And Finish page, make sure the options are configured to your specifications, and then click Create Label.

12. Click Done once the label is created.

Before users can use the labels, you need to publish the label using Label policies.

1. Select the label you created and click the Publish Labels button shown in Figure 1-38.

   

2. On the Choose Sensitivity Labels To Publish page, make sure your label is listed and click Next.

3. On the Publish To Users And Groups page, leave the default of All Users And groups, and click Next to open the Policy Settings page shown in Figure 1-39.

   

4. On the Policy Settings page there are three options:

   • Users Must Provide A Justification To Remove A Label Or Lower Its Classification This setting is meant to force the user to type in a justification if they set the classification of the document to a less sensitive label or remove the label entirely.

   • Require Users To Apply A Label To Their Emails And Documents Before users can save documents or send emails, this option forces them to set a label.

   • Provide Users With A Link To A Custom Help Page This setting allows you to set up a help page for users to explain the various sensitivity labels and how to use them.

5. Once you select the options desired, click Next.

6. Under Apply This Label As The Default Label To Documents And Emails, choose the label you created. This ensures all emails and documents are labeled.

7. On the Name Your Policy page, provide a Name and Description for the label policy, and then click Next.

8. On the Review And Finish page, ensure the settings are as you want them and click Submit to create the label policy.

9. Once the policy is created, click Done.

Users can now use the sensitivity label you created to label their documents and emails.

Managing data loss prevention alerts

One of the responsibilities of a data loss prevention administrator is to respond to alerts indicating sensitive data, such as customer credit card numbers, were exposed to parties unintentionally.

Follow these steps to review data loss prevention alerts:

1. Log in to https://compliance.microsoft.com as a member of the Global Administrator role in Azure Active Directory. You can also use an account that is a member of the Compliance Data Administrator, Compliance Administrator, or Security Administrator role groups. Note these are role groups in Office 365 and are separate from Azure Active Directory roles.

2. In the menu on the far-left side of the page, under Solutions, click Data Loss Prevention.

3. At the top of the page, click the Alerts tab (see Figure 1-40).

   

4. In Figure 1-40, high-severity alerts are shown, indicating a DLP policy match. Click the first alert, and then click View Details to open the alert page shown in Figure 1-41.

   

   This alert indicates that Sam Tarley shared a file named Book.xlsx from One Drive for Business. This file contains U.S. financial data in the form of credit card numbers. Under Other Alerts For This User, it appears that Sam has shared several other files with sensitive data in them. Once you have spoken to Sam, you can close this alert out.

5. Under Manage Alert, set the Status to Resolved, assign the alert to yourself, and provide comments in the Comments text box; click Save.

Insider risk

Data leakage can also occur because of an insider threat. Insider threats are when a user with access to company data assets purposefully steals these assets for personal gain. The motivations of these individuals vary. Following are some examples:

• A disgruntled employee looking to embarrass the company publicly

• An employee who feels they are underpaid and who seeks to make money from selling company intellectual property to the highest bidder

You can use insider risk management policies to generate alerts when activity is detected per the policy settings. Follow these steps to create an insider risk policy:

1. Log in to https://compliance.microsoft.com as a member of the Global Administrator role in Azure Active Directory. You can also use an account that is a member of the Compliance Data Administrator, Compliance Administrator, or Security Administrator role groups. Note these are role groups in Office 365 and are separate from Azure Active Directory roles.

2. In the menu on the far-left side of the page, under Solutions, click Insider Risk Management.

3. Click Policies > Create Policy.

4. Under Choose A Policy Template, under Categories, select Data Leaks. Under Templates, select General Data Leaks and click Next.

5. On the Name Your Policy page, provide a Name and Description for your policy, and then click Next.

6. On the Choose Users And Groups page, select Include All Users And Groups and click Next.

7. On the Specify Content To Prioritize page, leave the I Want To Specify Sharepoint Sites, Sensitivity Lables, And/Or Sensitive Info Types As Priority Content option at its default setting and click Next.

8. On the SharePoint Sites To Prioritize (Optional) page, click Next.

9. On the Sensitive Info Types To Prioritize (Optional) page, click Next.

10. On the Sensitivity Labels To Prioritize (Optional) page, click Add Or Edit Sensitivity Label. Select the sensitivity label you created earlier and click Next.

11. On the Indicators And Triggering Event For This Policy page, under Choose Triggering Event, select User Performs An Exfiltration Activity. Under Policy Indicators, select all the indicators in each section and click Next.

12. On the Decide Whether To Use Default Or Custom Indicator Thresholds page, select Use Default Thresholds For All Indicators, click Next.

13. On the Review Settings And Finish page, ensure the selections made are as you need them and then click Submit.

This policy will begin to assess the indicators configured in the policy and raise an alert if a user performs an exfiltration activity, such as downloading files from SharePoint or emailing a significant number of attachments outside the organization.

Setting up the Microsoft Defender for Endpoint subscription

There are two critical settings to take note of when performing the initial subscription configuration of Microsoft Defender for Endpoint. These settings include:

• Data location

• Data retention period

Data location is selected during the initial subscription configuration and cannot be changed without offboarding all your endpoints and losing all your data. At the time of this writing the regions available are:

• United States

• European Union

• United Kingdom

You should check with your privacy officer to ensure you select the correct region to store your data. This list is for commercial offerings and does not include government offerings.

The data retention period is also selected during initial subscription configuration. Unlike the data location, the retention period can be changed at any time, even after completing the subscription configuration wizard. The default retention period is 180 days (6 months) and can be changed to 30, 60, 90, 120, or 150 days.

Once the subscription configuration wizard is complete, you can change the data retention period by performing the following steps:

1. Log in to https://security.microsoft.com as a member of the Global Administrator or Security Administrator Azure Active Directory roles.

2. In the menu on the left, click Settings > Endpoints.

3. Under General, click Data Retention, as shown in Figure 1-51.

4. Note that you cannot change the Data Storage location as previously mentioned (selections are unavailable). To change the Data Retention period, click the drop-down menu and select the number of days that is appropriate to your environment.

5. When you are finished, click Save Preferences.

Role-Based Access Control

Like all Microsoft enterprise Software as a Service (SaaS) offerings, Microsoft Defender for Endpoint uses Azure Active Directory for authentication and authorization. Initial configuration provides the following Azure Active Directory built-in roles access to the endpoint-specific data and settings in the Microsoft 365 Security portal:

• The Global Administrators and Security Administrators roles have full access.

• The Security Reader role has read-only access.

Typically, this model is too rigid for larger companies, especially those with multi-tiered security operations teams. In these companies, each tier has set responsibilities and needs to have the least amount of privilege to carry out those responsibilities. Thankfully, Microsoft Defender for Endpoint’s role-based security model was designed for various sizes of security teams.

Roles in Microsoft Defender for Endpoint consist of two major parts:

• Roles that provide Azure Active Directory groups with specific rights to Microsoft Defender for Endpoint data and settings.

• Device Groups are used to segment enrolled devices so they can have Azure Active Directory groups and their roles assigned to them.

This model allows for least privilege access to only the devices that the security analyst should possess.

To enable roles, follow these steps:

1. Log in to https://security.microsoft.com as a member of the Global Administrator or Security Administrator Azure Active Directory roles.

2. In the menu on the left, click Settings > Endpoints.

3. Under Permissions, click Roles, as shown in Figure 1-52.

   

4. Note the Users With Read-Only Permissions Will Lose Access To The Portal Until They Are Assigned One Of The New Roles Through Their Azure AD Groups warning. These are users who gained access via the Azure Active Directory Security Readers role. If you have users in this situation, you should create an Azure Active Directory group for these read-only users before you enable roles to get them back to being operational as quickly as possible. When you are ready, click Turn On Roles.

Now that roles are enabled, the Microsoft Defender For Endpoint Administrator (Default) role is automatically created, which provides full rights to the endpoint data and settings (see Figure 1-53).

This role can be used instead of the built-in Azure Active Directory Global Administrator or Security Administrator roles, which is ideal because these Azure Active Directory roles provide access beyond endpoint data and should be used sparingly. If a user needs full permissions to manage the endpoint data and related settings, they can be placed in this role.

To provide read-only rights to the endpoint data, create a role with read-only access using the following steps:

1. Log in to https://security.microsoft.com as a member of the Global Administrator or Security Administrator Azure Active Directory roles.

2. In the menu on the left, click Settings > Endpoints.

3. Under Permissions, click Roles.

4. Click the Add Item button and the fly-out menu will appear, as shown in Figure 1-54.

   

5. Provide a Role Name and Description.

6. For Permissions, notice you can provide the View Data permission for either Security Operations data, Threat And Vulnerability Management data, or both. This is important if your security operations team is separate from your threat and vulnerability management team. In this case, you want to allow both types of data, so leave them both selected.

7. Click Assigned User Groups, as shown in Figure 1-55.

   

8. Because you likely have many security groups, you can type the partial name of the group in the text field, which will filter the list below. Secops was entered into this text box to filter the list for all groups containing “Secops” in the group title. Once you find the group or groups you need, select the box next to the Azure Active Directory group you want to assign the role to and then click the Add Selected Groups button. When you are finished, click the Save button.

Secops-Tier1 user named Ryker now has read-only access to the endpoint data in the Microsoft 365 Security portal. Note in Figure 1-56, Ryker can view data for the computer win10-1 but cannot perform any actions.

Under Device Groups, notice there are no groups currently, as shown in Figure 1-57.

This is because no device groups have been created yet. Once we create a device group, a default group will be created in addition to the group we create.

Without device groups, everyone who has permissions via a role will have those permissions over all onboarded devices. This may not be desirable, especially with sensitive devices, such as devices operated by executives of the company. Contoso has an executive support staff consisting of Mikey, Zach, and Dylan. They require access to the executive machines and should be the only ones with access. Because of this, you need to keep Ryker in Tier 1 from having access to these endpoints. You have already created the Executive Support role for the three executive support staff members and added the Azure Active Directory group. Now you need to create a device group for these executive devices.

To create a device group, follow these steps:

1. Log in to https://security.microsoft.com as a member of the Global Administrator or Security Administrator Azure Active Directory roles.

2. In the menu on the left, click Settings > Endpoints.

3. Under Permissions, click Device Group, and then click Add Device Group to open the fly-out menu shown in Figure 1-58.

   

4. In the Add Device Group fly-out menu, type a Device Group Name, choose an Automation Level, and type a Description.

5. In the Members section, devices can automatically be placed in this device group based on these values:

   • Name Name of the device

   • Domain Active Directory domain name the device is a member of

   • Tag A label that is assigned to the device

   • OS Operating system that runs on the device

   The Name, Domain, and Tag values support Starts With, Ends With, Equals, and Contains operators. Note these conditions are Boolean AND conditions. For the device to be placed in this Device group, it must meet all the conditions you specify in the Value text box. You can use the Executive value for Tag.

6. Preview Of Members allows you to see up to 10 devices that will be placed in this device group based on the Members logic.

7. Click the User Access tab at the top of the Add Device Group fly-out menu, as shown in Figure 1-59.

   

8. Click the check box next to Executive Support, click the Add Selected Groups button, and then click Done.

9. You should now be on the Device Groups page shown in Figure 1-60.

   

10. You will see a warning at the top of the page indicating that you need to Apply Changes or Discard Changes. Click Apply Changes.

Once you click Apply Changes, a message with a green background appears where the warning was once located indicating that it will take a bit of time to apply the changes; once the changes are complete, the message disappears. You should now see two device groups—the one you created for Executive Machines and one you did not create called Ungrouped Devices (Default). They are ranked 1 and Last, respectively, as seen in Figure 1-61.

Devices are placed in device groups starting with groups with the lowest rank then working their way down. Once the device meets the criteria for a device group per its criteria, the device becomes a member of that group, and processing for that device stops. Therefore, it is important to put the most specific device group (such as those that match tags) at the top and place less-specific device groups (such as those that match domains) toward the bottom. The Ungrouped Devices (Default) is the “catch-all” device group that is created by default once you create a device group. This device group contains all devices that do not match a criterion in the device groups you create. You can change the rank of the device groups by selecting the device group you want to change and clicking either the Promote Rank or Demote Rank buttons shown in Figure 1-62.

With the changes complete, Mikey, Zach, and Dylan on the executive support staff are the only users with access to the executive devices.

Alert notifications

It is assumed that the security operations team has better things to do than to stare at a dashboard all day, waiting for something to happen. So how will they know when alerts are triggered in Microsoft Defender for Endpoint that need their attention? The Email notifications feature in Microsoft Defender for Endpoint can send emails based on alerts that are generated. These notifications are created through rules which can be customized to send alerts to different email addresses based on their severity and Device group affected.

To receive Alert notifications, follow these steps:

1. Log in to https://security.microsoft.com as a member of the Azure Active Directory Global Administrator or Security Administrator roles or as a member of an Endpoint role with the Manage Security Settings permission.

2. In the menu on the left, click Settings > Endpoints.

3. Under General, click Email Notifications.

4. On the Alerts page, click Add Item to bring up the New Notification Rule fly-out menu shown in Figure 1-63.

   

5. In the Rule Name field, type Tier 1 Alerts.

6. Options for Include Organization Name, Include Organization-Specific Portal Link, and Include Device Information allow you to choose what items you want to appear in the email body. While you might wonder why you wouldn’t include this information by default, you might want to limit this information for privacy reasons given that emails can be forwarded.

7. Under Devices, select Notify For Alerts On All Devices, though if you plan to notify different email addresses based on different device groups, choose Notify For Alerts On Selected Device Group and choose the device group(s) to use for this notification rule. Also, select Notify For Alerts On All Devices since this is going to the Tier 1 security operators.

8. Alert Severity allows you to choose what severity the alert must be to trigger this rule. Click Check/Uncheck All to select all severities and click Next to advance to the Recipients settings shown in Figure 1-64.

   

9. On the Recipients tab, in the Recipient Email Address field, type in the email addresses that you want to be emailed with this alert notification rule is matched and click Add. Also, you can also click Send Test Email to preview your settings for the rule.

10. When you are finished, click Save. This returns you to the Email Notifications page. Note there is also a Vulnerabilities page where you can add notification rules when new vulnerabilities are found in the endpoint environment.

Advanced settings

Microsoft Defender for Endpoint’s sensor is used for more than just Endpoint Detection and Response (EDR). Features are being added constantly, and they can be enabled or disabled based on your needs. To enable or disable the advanced capabilities, follow these steps:

1. Log in to https://security.microsoft.com as a member of the Global Administrator or Security Administrator Azure Active Directory roles or as a member of a Microsoft Defender for Endpoint role with the Manage Security Settings permission.

2. In the menu on the left, click Settings > Endpoints.

3. Under General, click Advanced Features.

There are two types of advanced features:

• Endpoint features Enable or disable Microsoft Defender for Endpoint capabilities.

• Integration features Allow for data sharing between other Microsoft products, such as Intune, Microsoft Cloud App Security, and the like.

Following are examples of Endpoint features:

• Automated investigation The auto-remediation capability that responds to alerts and attempts to return the endpoint back to a healthy state.

• Automatically resolve alerts If automated investigation can return an endpoint to a healthy state, it will automatically mark the alert as being resolved, so incident responders know it was dealt with.

• EDR in block mode Enables Defender to block attacks even when there is a third-party anti-virus agent installed.

• Live Response and Live Response for Servers Allows for an incident responder to open a limited interactive shell with an endpoint.

• Allow or block file Uses cloud Protection to allow or block files on endpoints.

• Preview features Allows your subscription to receive features before they become generally available.

• Microsoft threat experts Allows Microsoft human hunters pseudonymized access to your endpoint data, so that in the event of a breach, these hunters can send targeted attack notifications (TANs) alerts into your tenant to draw your security operations team’s attention to the incident.

Examples of integration features include the following:

• Show user details Allows Microsoft Defender for Endpoint to call into Azure Active Directory to fill out user information such as job title, department, name, and so on.

• Microsoft Cloud App Security Network data relating to the cloud application access can be shared with Cloud App Security for discovery. Also, it allows for blocking unsanctioned cloud apps.

• Microsoft Defender for Identity integration Shares Endpoint data with Microsoft Defender for Identity to improve detections, enhance identity pages, and provide additional evidence in incidents.

• Share Endpoint alerts with Microsoft Compliance Center Allows risk officers to view Endpoint alerts in the Microsoft 365 Compliance portal and enhances insider risk insights.

• Microsoft Intune Connection This setting shares the onboarding information with Microsoft Intune to onboard devices into Microsoft Defender for Endpoint, as well as shares the device’s risk score. Intune uses this risk score to mark a device as being compliant or not compliant, based on your risk compliance policy settings in Intune.

Custom detection rules using Advanced Hunting

Advanced Hunting is one of the most popular features in Microsoft Defender for Endpoint. It provides lightning-fast query response time against up to 30 days of data, even in environments with millions of endpoints onboarded. The query language you use to search your data in Advanced Hunting is called Kusto Query Language, or KQL. If you have used Azure services such as Log Analytics in the past, you already have some exposure to KQL. Advanced Hunting can be used for ad-hoc queries against your data, which is typically how custom detections start out.

At this Advanced Hunting GitHub, there is a KQL query we can use to detect WMI deletions of shadow-copy snapshots. This is a technique usually seen in correlation with Ransomware. Shadow-copy snapshots are removed prior to encryption so that recovery using these snapshots is not possible. Here is the KQL query:

Click here to view code image

DeviceProcessEvents
| where FileName =~ "wmic.exe"
| where ProcessCommandLine has "shadowcopy" and ProcessCommandLine has "delete"
| project DeviceId, Timestamp, InitiatingProcessFileName, FileName,
ProcessCommandLine, InitiatingProcessIntegrityLevel, InitiatingProcessParentFileName

This query is explained by the following pseudocode:

Click here to view code image

"Check the DeviceProcessEvents table for event entries where the process file name is
like wmic.exe and where the process command line has the strings shadowcopy and delete.
Once this data is found, show the DeviceID, Timestamp, InitiatingProcessFileName,
FileName, ProcessCommandLine, InitiatingProcessIntegrityLevel, and
InitiatingProcessParentFileName."

Now that you understand what this query is doing, you will create a custom detection using this query and by following these steps:

1. Log in to https://security.microsoft.com as a member of the Azure Active Directory Global Administrator or Security Administrator roles or as a member of an Endpoint role with the Manage Security Settings permission.

2. In the menu on the left, click Hunting > Advanced Hunting.

3. By default, the Get Started section is shown on the right. You can go through the exercises or click the Query section to change to the query editor. On the left is the schema for advanced hunting, as shown in Figure 1-82.

   

   The three dots next to each table opens the schema reference for that table. Hovering over the fields pops up a description for the field.

4. Type the following query into the query window. Note KQL is a case-sensitive language.

   Click here to view code image

   DeviceProcessEvents
   | where FileName =~ "wmic.exe"
   | where ProcessCommandLine has "shadowcopy" and ProcessCommandLine has "delete"
   | project DeviceId, Timestamp, InitiatingProcessFileName, FileName,
   ProcessCommandLine, InitiatingProcessIntegrityLevel,
   InitiatingProcessParentFileName

   Notice when you type, you are assisted by autocomplete.

5. To make sure the query syntax is error free, click Run Query.

   You probably will not get any results in your environment, which is okay. To create a custom detection, the query does not need to return results initially.

   Tip Don’t Query Too Often

   You do not want a query to return results too often because the custom detection will generate too many alerts.

6. Click the Create Detection Rule option in the upper-right corner of the query window, which displays the error shown in Figure 1-83.

   

7. This happened because we did not add the ReportId field to the project statement in the query, which is required to be in the returned fields for a custom detection. Timestamp, ReportId, and a field that represents a specific device, user, or mailbox are all required for custom detections.

8. Modify your query to add ReportId to the project line, as shown below:

   Click here to view code image

   DeviceProcessEvents
   | where FileName =~ "wmic.exe"
   | where ProcessCommandLine has "shadowcopy" and ProcessCommandLine has "delete"
   | project ReportId, DeviceId, Timestamp, InitiatingProcessFileName, FileName,
   ProcessCommandLine, InitiatingProcessIntegrityLevel,
   InitiatingProcessParentFileName

9. Click Run Query to make sure you do not have syntax errors and then click Create Detection Rule.

10. The following fields are shown in the Create Detection Rule wizard, as well as in Figure 1-84.

    

    • Detection Name A name for the detection.

    • Frequency This is how often the custom detection rule will run. The choices are Every 24 Hours, Every 12 Hours, Every 3 Hours, or Every Hour. The more often your custom detection rule runs, the smaller the window of time it will look back. In Figure 1-84, Every Hour has been chosen.

    • Alert Title This is the title of the alert you will see in the alert view.

    • Severity This is the severity of the alert. The choices are High, Medium, Low, and Informational. Choose High because this is ransomware-related and needs to be triaged as fast as possible.

    • Category This is the type of activity that best matches this alert. Choose Ransomware.

    • Description This is a description for the custom detection rule.

    • Recommended Actions This instructs the incident responder regarding the steps to take for triaging and resolving this alert.

11. Click Next to advance to the Impacted Entities page shown in Figure 1-85.

    

12. Only the Device option will be available because the device info will be returned in this query. Select the Device option and select DeviceId from the drop-down menu. Click Next to open the Actions page shown in Figure 1-86.

    

13. From this screen, you can trigger a response action on the device that triggers the custom detection. These actions are the same as covered previously. Select Isolate Device and make sure Full is selected because you do not want to allow Outlook, Skype, or Teams to have access while isolated. Then click Next to open the Scope page shown in Figure 1-87.

    

14. The Scope page lets you select which device group you want to target with the custom detection rule. Select All Devices and click Next.

15. The Summary page lists all the configuration settings made so far in the Create Detection Rule wizard. You can edit any of the settings from this screen. When the settings are configured as desired, click Create to create the custom detection rule.

To test the custom detection rule, follow these steps:

1. Run the following command on an onboarded endpoint using an elevated command prompt or PowerShell:

   WMIC.exe shadowcopy delete /nointeractive

2. Wait for about 5 minutes for the data to reach the tenant.

3. Log in to https://security.microsoft.com as a member of the Global Administrator or Security Administrator Azure AD roles or as a member of an Endpoint role with the Manage Security Settings permission.

4. In the menu on the left, expand Hunting and click Custom Detection Rules.

5. You should see the custom detection rule you created in previous steps. Click the bubble next to the custom detection rule. A fly-out menu for the rule will appear, as shown in Figure 1-88:

   

6. In this fly-out menu, you can see the Last Run and Next Run of this custom detection rule. To see the full details of this rule, click Open Detection Rule Page to open the page shown in Figure 1-89.

   

7. On this page, you can fully manage the custom detection rule and see any Triggered Alerts and Triggered Actions. If you do not see a triggered alert and the Last Run Time field has not been populated, click Run in the top-right corner of the page.

8. If the data reached the tenant from the onboarded device, this should generate the custom detection alert shown in Figure 1-90.

   

9. Note the fields in the details on the right reflect the information provided when you created the custom detection rule.

10. Click the ellipsis (…) next to the Device Name at the top of the alert. You should see the Release From Isolation option at the bottom right (see Figure 1-91).

    

11. This indicates the machine is currently isolated because that was the action you specified to occur when activity on a device matched the custom detection rule question. Click Release From Isolation.

Custom indicators

Indicators are another way to generate custom alerts, as well as block activity based on files, IP addresses, URLs, domains, and certificates. While you could create custom detection rules for these types of indicator-based detections, custom indicators are a much better-suited tool for non-logic-based detections, and they have the additional benefit of being able to block the file.

You receive some Indicators of compromise (IOCs) from a threat intel feed, which contains an SHA256 hash. If this hash is seen in your environment, you want Microsoft Defender for Endpoint to raise an alert. To accomplish this, you need to create a custom alert based on a file indicator by following these steps:

1. Log in to https://security.microsoft.com as a member of the Global Administrator or Security Administrator Azure Active Directory roles or as a member of an Endpoint role with the Manage Security Settings permission.

2. In the menu on the left, click Settings.

3. On the Settings page, click Endpoints.

4. On the Endpoints settings page under Rules, click Indicators.

5. Under File Hashes, click the Add Item option, which opens the Add File Hash Indicator menu shown in Figure 1-92.

   

   Note Importing Lists of Indicators

   You can also import lists of indicators by using the Import option. A template is provided in the Import Option menu.

6. On the Add File Hash Indicator fly-out menu on the Indicator page, in the File Hash text box, type the following SHA256 hash. (This hash is from a benign text file generated for the purposes of this book. You can generate your own text file and use the Get-FileHash PowerShell command to test it in your environment.)

   Click here to view code image

   0296F272170F18B0A04760DE5DBA41029F74B3247F0609CBAA8858B4DB1C4333

7. Set Expires On (UTC) to Never, as previously shown in Figure 1-92, then click Next to advance to the Action page shown in Figure 1-93.

   

8. Select Alert Only and provide an Alert Title, Alert Severity, Category, Recommended Actions, and Description. Notice these are all the same fields you set in custom detections rules. This is because we are configuring an alert to generate when this indicator is seen. Click Next to move to the Scope page shown in Figure 1-94.

   

9. Use the Scope page to configure what device group this indicator and alert will target. Choose All Devices In My Scope and click Next.

10. The Summary page allows you to see all your choices. If everything looks good, click the Save button. The next time this file hash is needed on any onboarded endpoint, an alert will be raised with the previously entered information.

Threat & Vulnerability Dashboard

You need to have a quick and clear view of the weaknesses and vulnerabilities that are present across your organization. The Threat & Vulnerability Dashboard is a great way to get this comprehensive, high-level assessment. Follow these steps to familiarize yourself with the dashboard.

1. Log in to https://security.microsoft.com as a member of the Global Administrator or Security Administrator Azure Active Directory roles or as a member of an Endpoint role with the View Data—Threat And Vulnerability Management permission.

2. Under Endpoints, expand Vulnerability Management and click Dashboard.

3. The following tiles are shown in the dashboard shown in Figure 1-95.

   • Exposure Score This shows the amount of exposure affecting devices in your organization. Ideally, you want the score to be as low as possible.

   • Top Security Recommendations This is a list of actions you can take to lower your Exposure Score. They are ordered by Impact, which is the measure of the number of points by which your Exposure Score will be lowered by remediating that action

   • Microsoft Secure Score For Devices This rates the security posture of your environment based on Application, OS, Network, Accounts, and Security Controls. A higher percentage indicates a better security posture.

   • Exposure Distribution This shows the number of devices that are susceptible to attacks, which are ranked as High, Medium, and Low.

   • Remediation Activities This is a list of activities to remediate vulnerabilities and configuration weaknesses.

   • Top Vulnerable Software This is a list of software with vulnerabilities that is intelligently ranked on factors such as number of vulnerabilities, threats, and number of affected devices.

   • Top Exposed Devices This is a list of devices with the most exposure that is intelligently ranked on factors such as number of vulnerabilities, threats, and security recommendations.

     

Remediation activities and exceptions

Now that you have your security recommendations ranked intelligently and dynamically, you need to assign remediation activities to the individual or teams responsible for patch management. The Threat & Vulnerability Management Dashboard tells you which actions to take first that will have the greatest impact in lowering the risk in your environment.

Follow these steps to create a remediation activity:

1. Log in to https://security.microsoft.com as a member of the Global Administrator or Security Administrator Azure Active Directory roles or as a member of an Endpoint role with the Active Remediation Actions: Threat And Vulnerability Management—Exception Handling And Remediation Handling role.

2. Under Endpoints, expand Vulnerability Management and click Recommendations to open the view shown in Figure 1-96.

   

3. Just remediating the Update Microsoft 10 (OS And Built-In Applications) line item will result in the Exposure Score lowering by 30.65 points. One of the reasons this action will lower the score is because there is a verified, public exploit available for some of the vulnerabilities that these two devices are affected by.

4. You can tell if there is an exploit available for one or more of these vulnerabilities by looking at the icons under Threats. These threats indicate the following:

   • Threat insights As shown in Figure 1-97, when this icon is red, there is a publicly available exploit for one or more vulnerabilities.

     

   • Breach insights If this icon is red, there is an active alert attributed to the vulnerability, as shown in Figure 1-98.

     

5. Click Update Microsoft Windows 10 (OS And Built-In Applications) in the list of security recommendations.

6. Click Request Remediation to open the view shown in Figure 1-99.

   

7. Select Software Update (Recommended) under Remediation Options.

8. Select the Open A Ticket In Microsoft Endpoint Manager (For AAD Joined Devices) check box.

   Tip Enable Microsoft Intune Connection

   If you do not see the Open A Ticket In Microsoft Endpoint Manager (For AAD Joined Devices) option, you need to turn on the Microsoft Intune Connection in the Endpoint Advanced Features settings.

9. Select a Remediation Due Date.

10. Under Priority, select High.

11. Type some notes under Add Notes and click Next to open the Review And Finish screen shown in Figure 1-100.

    

12. Select Export All Remediation Request Data To CSV. This creates a CSV file that you can provide with your change management request because it contains the remediation action and a list of the machines requiring the remediation.

13. Click Submit.

14. Once the remediation request is created, click Done.

Now that you have a remediation request created, you can track the request in the Remediation menu item under Vulnerability Management. Your patch management team should now see the remediation request in Microsoft Endpoint Manager under Security Tasks, as shown in Figure 1-101.

In some cases, you need to create an exception for security recommendations. For example, machines that do not support the hardware requirements for Credential Guard. Follow these steps to create an exception for these machines:

1. Log in to https://security.microsoft.com as a member of the Global Administrator or Security Administrator Azure Active Directory roles or as a member of an Endpoint role with the Active Remediation Actions: Threat And Vulnerability Management—Exception Handling And Remediation Handling.

2. In the menu on the left, under Endpoints, expand Vulnerability Management and click Recommendations.

3. In the Search option in the upper-right of the window, type credential guard. This should filter the security recommendation list as shown in Figure 1-102.

   

4. Click the Turn On Microsoft Defender Credential Guard security recommendation. This will open a window with a description of the recommendation. Click the Exception Options button at the bottom of the window to open the Create Exception screen shown in Figure 1-103.

   

5. This screen allows you to set the Exception Scope to a device group. Under Justification And Duration, select Planned Remediation (Grace) to indicate that this is a temporary exception. The Provide Justification Context text box allows you to enter notes for the exception reason, which in this case is that because the hardware is old and does not support Credential Guard, it will be replaced. The Exception Duration allows you to set a fixed time length (30, 60, or 90 days), or you can select a custom date up to 1 year beyond the current date.

6. Once you select your options, click Submit.

7. When the Exception is created, click Done.

You now have an exception created for the Turn On Microsoft Defender Credential Guard security recommendation.

Configuring users at risk alerts

You need to be alerted when a risky user or sign-in is detected. To be notified via email alerts when this type of risky activity occurs, follow these steps:

1. Log in to https://portal.azure.com as a Global Administrator or Security Administrator.

2. Using the Search bar at the top of the portal, type identity protection and click Azure AD Identity Protection.

3. Under Notify, click Users At Risk Detected Alerts, as shown in Figure 1-108.

   

4. Here, you can type email addresses to be notified when user’s risk level reaches or exceeds Low, Medium, or High levels. You want to be alerted any time any risk is detected, so select Low and click Save.

5. Weekly Digest is a weekly email containing risky sign-ins, users, and links to the related reports to users you specify. Configure the users you for whom you want to receive the weekly digest and click Save.

Configuring multifactor authentication and risk policies

To improve your defenses against identity compromise such as what happened to Paul’s user account, you can configure policies to make it harder for attackers to use compromised accounts if they have the username and password for the account. A multifactor authentication (MFA) registration policy allows you to add a third form of authentication in addition to the username and password required when a user logs in. In the previous example with Paul’s account, the attacker had the username and password and could log in. Once MFA is added to Paul’s account, when Azure AD Identity Protection detects a risky sign-in for Paul, Azure AD could then challenge him to use a third form of authentication, such as a rotating cipher on his cell phone, before granting him access.

To require users to register for MFA, follow these steps to set an MFA registration policy:

1. Log in to https://portal.azure.com as a Global Administrator or Security Administrator.

2. Using the Search bar at the top of the portal, type identity protection and click Azure AD Identity Protection.

3. Under Protect, click MFA Registration Policy, as shown in Figure 1-109.

   

4. Under Assignments, choose the users or groups to target for this policy. In this example, the finance department that Paul is a member of is targeted.

5. Under Enforce Policy, click to activate the policy, and then click Save.

Now that an MFA registration policy is configured, you can configure an MFA challenge if Azure AD Identity Protection suspects a sign-in is risky. Follow these steps to configure a sign-in risk policy.

1. Log in to https://portal.azure.com as a Global Administrator or Security Administrator.

2. Using the Search bar at the top of the portal, type identity protection and click Azure AD Identity Protection.

3. Under Protect, click Sign-In Risk Policy, as shown in Figure 1-110.

4. Under Users, select the desired users or groups. In this example, we have chosen the finance department.

5. Under Sign-In Risk, specify the risk level that will trigger the policy. Select Low And Above to trigger an alert on any indication that the sign-in is risky.

   

6. Under Controls, select Allow Access, select Require Multi-Factor Authentication, and click Done.

7. Click the Enforce Policy slider to the On position, and then click Save.

Next, you configure a user risk policy that will take action when a user is marked as being at risk. Follow these steps:

1. Log in to https://portal.azure.com as a Global Administrator or Security Administrator.

2. Using the Search bar at the top of the portal, type identity protection and click Azure AD Identity Protection.

3. Under Protect, click User Risk Policy, as shown in Figure 1-111.

   

4. Under Users, select the desired users or groups. In this example, we have chosen the finance department.

5. Under User Risk, specify the risk level that will trigger the policy. Select High to trigger on users who are marked as high risk.

6. Under Controls, select Allow Access, select the Require Password Change box, and click Done.

7. Click the Enforce Policy slider to toggle it On, and then click Save.

Investigating an alert in Microsoft Defender for Identity

An example of a technique in the reconnaissance stage is when an attacker explores Server Message Block (SMB) sessions from a server, such as a file server or domain controller, to find user accounts and the IP addresses they originate from. This allows the attacker to map out what accounts they need to compromise to gain access to the systems with those IP addresses. The User And IP Address Reconnaissance (SMB) alert in the Defender for Identity portal shows this attack. You will use this alert to train your security operations team on how to triage alerts in the Microsoft Defender for Identity portal.

Follow these steps to triage this alert:

1. Log in to the Microsoft Defender for Identity portal at https://portal.atp.azure.com as a member of the Global Administrator or Security Administrator Azure AD role. You can also log in as a lower-privileged user if they are a member of the Azure ATP (instance name) Administrators, Azure ATP (Instance Name) Users, or Azure ATP (Instance Name) Viewers Azure AD groups. This opens the Timeline view shown in Figure 1-112.

   

2. The Timeline shows alerts generated by Defender for Identity in chronological order. Click the User And IP Address Reconnaissance (SMB) alert to open the alert shown in Figure 1-113.

   

3. The alert tells you that two different accounts from WIN10-1 enumerated SMB sessions on the domain controller named DC1. Hovering the mouse over DC1 shows the operating system, when the machine was first seen, and the domain it is a member of. Also, you can see that it is marked as a Sensitive object because it is a domain controller.

4. Under Evidence, you can see the accounts and IP addresses that were exposed because of this enumeration, which can help you in your investigation into suspicious activities involving these accounts.

5. You can also search for a user account and see details about the alert. In the Search box located in the upper-right portion of the screen, type helpdesk1 and press Enter to bring up the helpdesk1 user page shown in Figure 1-114.

   

6. The user account helpdesk1 has five open security alerts and is logged into two different computers. Also, you can access a timeline view of the activities performed by helpdesk1. Click Directory Data on the left to display the view shown in Figure 1-115.

   

7. This view shows information from Active Directory about the user, such as group memberships, account info, and user account control features, such as Password Never Expires. Note this account is also marked Sensitive because it is a member of a sensitive group, Domain Admins And Administrators.

8. Note the profile picture of helpdesk1 is a bee. This is because helpdesk1 is configured as a Honeytoken account, as shown in Figure 1-116.

   

9. An account can be configured as Honeytoken account so that an alert will generate when the user account authenticates to Active Directory. This can serve as a trap for attackers to signal they are in your environment.

You can learn more about the Defender for Identity portal at https://aka.ms/sc200_mdiportal.

Configure threat detection policies in MCAS

MCAS has several threat-detection policies for discovering and alerting on suspicious and malicious activities occurring in cloud applications. One of the built-in anomaly detection policies is the Impossible Travel Policy. The Impossible Travel Policy raises an alert when a user performs actions in a cloud application from two physical locations during a time interval that is shorter than the time it would take someone to travel between these two locations.

Let’s say you suspect that there are anomalous user log-in activities occurring in your environment, such as user accounts being used from disparate locations. Follow these steps to examine the Impossible Travel Policy that can detect these threats:

1. Log in to https://portal.cloudappsecurity.com as a member of the Global Administrator or Security Administrator Azure AD roles.

   More Info Manage Admin Access

   MCAS supports role-based access controls. Learn more at https://aka.ms/sc200_mcasrbac.

2. Under Control, click Policies.

3. Click the Threat Detection tab at the top of the main page.

4. Scroll down and click Impossible Travel Policy to open the Edit Anomaly Detection Policy page shown in Figure 1-117.

   

5. In the Edit Anomaly Detection Policy page for the Impossible Travel Policy, you can target specific users or groups for the policy and adjust the Sensitivity of the policy. For example, if most of your users travel frequently, you can set the Sensitivity to Low. However, because your finance department users do not travel and the group contains users with access to sensitive data, you need the policy to be more sensitive for those users.

6. Find the Scope section of the policy page shown in Figure 1-118.

   

7. Select Set Sensitivity To Specific Users And Groups.

8. Under Filters, select User Groups Equals Finance Department.

9. Slide the Sensitivity bar under the filter to High. This will increase the sensitivity for finance department users for this policy.

10. You can configure Alerts from this policy to be sent via email or text message. Because you are using Microsoft 365 Defender, these alerts will appear in the Microsoft 365 Security portal (https://security.microsoft.com), so there is no need to configure an Alert here.

11. Scroll down to see the Governance Actions shown in Figure 1-119.

    

12. You can select actions to apply to all cloud apps or to specific actions for specific cloud apps when the policy is matched by an activity. Under Office 365, select the Confirm User Compromised option. This will flag the user to be challenged for MFA, and if successful, the user will be required to change their password per your sign-in and user risk policy settings defined in Skill 1-2.

13. Once finished, click Update to save your changes to the policy.

Respond to alerts in MCAS

When policies are matched, alerts will be generated for investigation and response. You configured the Impossible Travel Threat detection policy, so now you will investigate the generated alerts. Follow these steps to investigate an Impossible travel alert:

1. Log in to https://portal.cloudappsecurity.com as a member of the Global Administrator or Security Administrator Azure AD roles.

2. Click the Alerts option in the menu on the left.

3. At the top of the Alerts page, click the Category Filter drop-down menu and select Threat Detection.

4. Click the Impossible Travel Activity alert to open the alerts shown in Figure 1-120.

   

5. The alert indicates that Paul DePaul had activities originating from the Netherlands and Russia within a 4-minute period, which is what triggered the alert. A subset of the activities performed using Paul’s account are shown in the Activity Log sections. All activities can be seen by clicking the Investigate In Activity Log option.

   Exam Tip

   You must enable File Monitoring in the MCAS settings under Information Protection to see file activity store in cloud apps.

6. Click the drop-down menu next to Resolution Options, as shown in Figure 1-121.

   

7. Because it appears that Paul’s account is compromised, click Confirm User Compromised.

8. Click Confirm User Compromised again on the confirmation pop-up window.

9. Because you have taken steps to mitigate this alert, click the Close Alert button shown in Figure 1-122.

   

10. Click True Positive.

11. The Close Alert As True Positive pop-up window offers these options: Comment, Send Feedback, and Opt-In To Share Your Email Address. The latter option allows the MCAS development team to contact you for more information if required.