Welcome to Part 3 of this blog series. First I want to apologize for the delay in getting this Part 3 published, my day job got in the way a bit! If you have not already read the first two parts I recommend it prior to reading this one. In Part 1 we discussed why a company would want to use EDM and the benefits it provides. We also began the setup of EDM in our tenant. Part 2 finished up the overall configuration of EDM, specifically the rule pack file. We ended Part 2 with the upload of our datastore. We are now ready to work on the DLP Policies that will utilize the EDM sensitive info types we created.
To start creating the DLP Policies, go to the new Compliance Center, compliance.microsoft.com. This site is not 100% completed with the move away from the Security and Compliance Center (SCC), protection.office.com, but is making great progress. Once in the Compliance Center, we can check on the new Sensitive Info Types that were created as part of the EDM setup. To do this go to the Data Classification blade in the left-hand menu. Select Sensitive Info Types from the top menu and you should then be able to find the four new types we created. Two of them we already went over when setting up the Rule Pack, and the two newer ones were created once the rule pack was uploaded.
Now that we have verified the new ExactMatch custom Sensitive info types, we can build a DLP policy using them. If you do not see “Data loss prevention” on the left-hand menu, scroll all the way down to the bottom and select “Show all” Once you do this you will see all the menu items, select Data loss prevention.
Note: If you want an option to always be present in the navigation, click on “Show in Navigation” in the upper right of the screen. Now the item will always be visible in the navigation without the need to select “Show all” first.
- From the Data Loss Prevention blade, select Create policy
- Keep custom policy selected and press Next
- Give the policy a name and description. Click Next
- Select Let me choose specific locations, click Next
- De-select SharePoint Sites (currently EDM does not work with SharePoint Sites, but will support soon), click Next
- Select Use advanced settings, click Next
- Select New Rule
- Give the rule a name and description
- Click Add Condition then Content Contains in the Conditions section
- Select Add then Sensitive Info Type
- Select Add then locate and select the Superhero-SRN-EDM and Superhero-Nickname-EDM sensitive info types, click Add
- Click done
- I then modified the Match Accuracy to be between the Confidence Levels set within the Rulepack for just finding the SRN and Nickname without any other fields. Also be sure that Any of These is present, this results in an OR situation, where the service can find an SRN or Nickname, but both do not need to be present. Editing the fields by just selecting the numbers and changing them.
Note: You could use the Add group button to add more Sensitive info types and require either an AND or OR criteria with the first set of sensitive info types.
- Click add a condition and content is shared and then choose with people outside my organization.
Note: you can add additional conditions if you wish, but for this rule I only am configuring the Content is shared condition
- For this rule I am not going to have any actions taken, just notify the user, the next rules will have actions.
- Within User Notifications, turn them on and then you can configure what notifications are sent to whom and customize the messages if you would like. I have elected to notify the user who sent, shared, or last modified the content and I also customized the email and policy tip for the rule.
- Because we do not have any actions on this rule, I do not have to configure User overrides, we will do this in later rules
- Next configure Incidents Reports, for this low rule condition I might not normally configure this but will for this demo. I am specifically keeping the severity for this rule as low and just including the Admin for both alert and incident report notification.
- After setting up Incident reports, you can click Save. Will discuss rule priority later
20. That will bring you back to the Policy settings page again, select New rule again and give the rule a name and description
- For Conditions add the same two sensitive info types as the previous rule, but this time I am going to change the match accuracy to match on the SRN and Nickname with supporting info. For SRN this is 75-84, which means the system will have found the SRN and 2 other fields of data. For Nickname it will be 75-84, which means the system will have found Nickname with 2 other fields. I am taking these ranges from the rulepack file created in Part 2 again.
- Add in the same condition as the previous rule, Content is shared with people outside my organization
- For this rule we will add an action “Restrict or encrypt the content” keep the defaults to “block people from sharing…and Only people outside your organization…”
- The User actions section is like the last rule, just changed the wording in the email and policy tip
- For this rule will allow User Overrides, I am setting it to require a business justification. If you are familiar with DLP, this will require the user to give justification for overriding a policy and will become an auditable entry as well.
- Incident reports section will be the same as the first rule except will raise the severity of this alert to medium.
- Options will remain unchanged, click save.
- From the Customize Type of content to protect screen click on New rule one last time
- Name the Rule
- Add the same two sensitive info types as the previous two rules for the condition. This time I am raising the Match accuracy to match additional criteria found as configured in the rulepack. Also set the same condition as the 2nd rule for sharing with people outside my organization.
- In Actions I am setting the same action as rule two, block people from sharing with people outside my organization.
- User notifications are like the last two rules
- No User overrides, this requires that the data be removed before the action attempted (sharing, sending email) can be completed
- Incident reports, only change it to set the sensitivity as High
- Click save and done creating the rules for the Policy
- Back at Policy settings, you can turn rules on or off as well as select the 3 dots you can move the priority of the rule up or down. Click Next
- Select to turn the policy on or put it in test mode first. Since I am working in a demo lab I will turn in on, click Next
- Review the settings and click Create
- I changed the order so my new Superhero Secret Identity Protection Policy would be set at 0 or the first policy evaluated. In my lab it did not matter much as I only have 1 active Policy. But you will want to pay attention to Order when you have multiple policies and specifically if you select the “Stop processing additional DLP Policies and rules if this rule matches” option
Next step is to test out the Policy and the Rules! Best to let the policy replicate for a couple hours before testing to ensure it will be fully enabled.
For testing the Policy and rules I am going to switch to login as Megan Bowen to do the test. I have logged into Office 365 as Megan and going to start by showing the Policy and rules in action via email.
- Now I am going to compose an email to Adele Vance, another internal SIPA employee, and provide information about Superman
- I have highlighted the data that is present in the email that is also in the datastore CSV that we uploaded. Why did I not get a Policy tip for finding this data in the email? I did not get a policy tip because Adele, as mentioned, is an internal employee and my rules only apply to sharing with people outside my organization. Now I will add an additional recipient to someone outside the organization and see what happens, lets try sending to Lex Luthor of Legion of Doom.
- Now see the highlighted Policy tip, this is the policy tip from our 3rd rule we created within the DLP Policy. Let’s examine the show details
Now I see the reason for the alert is that Lex.firstname.lastname@example.org is not authorized to receive this type of info. I also see what sensitive message type was found.
- If I try to send the email without removing Lex or the sensitive data then this pops up, not allowing the email to be sent.
5. When I attempt to share a file that contains Sensitive Info to someone outside my organization, I am blocked from doing so as well
The above shows how the Office 365 DLP policy uses EDM data. What about Microsoft Cloud App Security (MCAS)? It is just as easy. For MCAS I will create a simple File Policy, here are the steps
- Login to the MCAS Admin portal at Portal.cloudappsecurity.com, select Control and Policies on the left-hand menu and then select Create Policy
- Select File Policy from the drop-down menu
- Give the policy a name and description. For this policy I will not use any filters as I want to include all files.
- Now select Data Classification for the Inspection method and the choose to add the two EDM Sensitive Information type created previously, set the Alerting you wish
- You can elect to provide Governance Actions if you want. Once the policy is completed, sit back, and wait for the alerts to come in
I can see alerts show up in the Alerts Area
Clicking on the Top alert allows me to review the information
Clicking on the 1 Policy Match I can see the actual data the caused the file to be alerted.
This is going to wrap up the blog series. Hope you found this informative and useful when you look to integrate EDM into your DLP solution!