eDiscovery Compliance boundaries in Office 365
This year will probably be known as the “year of GDPR”, and understandably so. Compliance with this seminal regulation requires that organizations dedicate significant time and effort examining their processes and implementing safeguards and strategies to protect PII (Personally Identifiable Information). Of course, Office 365 should be a big area of focus in any GDPR compliance strategy, your organization’s tenant contains huge amounts of personal data: belonging to your employees, customers, vendors perhaps – the list goes on. In this blog, and across future posts, we will try to make the process of meeting the GDPR requirements seem less painful, by introducing you to different functionalities in the Office 365 suite that relate to these data protection requirements, and in general, compliance.
What are Compliance boundaries
First, we’ll take a look at eDiscovery Compliance boundaries, which first appeared on the Office 365 Roadmap back in June 2017. Here’s the feature description:
Segment eDiscovery searches and results by users as defined by your organization to allow compliance boundaries between business units, geographic location, or other divisions. This also includes full support of Compliance Security Filters for OneDrive for Business.
Albeit a bit short, the description explains what the feature is about – limiting access to the eDiscovery functionality so that the designated people will only be able to run searches against a subset of the data stored in Office 365. Being able to control who can use the eDiscovery functionality is of course very important by itself as eDiscovery is one of the most sensitive features. Thanks to Role Groups, we have been able to control access to eDiscovery functionality for years now. On the other hand, even if you can limit eDiscovery functionalities to specific people only via Role Groups, said people will still be able to search all data across all Office 365 workloads. This could be an issue, especially for large multi-national companies, which means that more granular controls are required.
Enter Compliance Security Filters. First introduced back in the beginning of 2017, Compliance Security Filters allow you to control what content will be exposed at a granular level, as well as which eDiscovery features will be available to the person executing the query. For example, you can limit the eDiscovery Manager ‘John’ so that he is only able to execute searches against users from a particular Department, and prevent him from exporting or purging results. Let’s see how these filters work.
Compliance Security Filters
As the eDiscovery Compliance boundaries description hints, this feature relies on the Compliance Security Filters functionality. Now, the bad news – the feature is only configurable via PowerShell. More specifically, you need to use the New-ComplianceSecurityFilter cmdlet. The cmdlet itself is fairly easy to use, you just need to provide a Name for the Filter, specify which Actions it will apply to, and designate the Users that the restrictions will apply to. Finally, using the Filters parameter, you can specify which data will be under the scope of the Filter. This can include all or specific mailboxes or sites, designated by one or more attributes, or even individual items with content matching a keyword. This is what makes this feature so powerful. For example, a Compliance Security Filter that limits our eDiscovery Manager ‘John’ so that he can only search mailboxes in the Sales department will take advantage of the Department property for the recipient object in Exchange and will look something like this:
New-ComplianceSecurityFilter -FilterName SalesUsers -Users John@domain.com -Filters “Mailbox_Department -eq ‘Sales'” -Action Search
Many of the other important mailbox properties are also supported, which makes the feature very robust. In general, any supported filterable recipient property can be used, you can find a full list in this article. When it comes to SharePoint Online or OneDrive for Business however, the set of properties is limited (especially for the latter). This is actually one of the reasons why the Compliance boundaries feature is touted as something new – an improvement to the underlying Security Compliance Filters functionality has been made to better support ODFB.
The list of attributes supported by ODFB is very small, it only includes Company, Department, CountryCode and Office, as well as any of the CustomAttributeXX. What’s even more limiting, at least for the time being, is the need to open a support ticket in order to get the attribute intended for use with the Security Compliance Filters feature synchronized to ODFB, and therefore make the feature work. This will change in the near future though, so stay tuned.
More fun with Filters
Before diving deeper into additional examples of how Compliance Security Filters can be utilized to build Compliance boundaries within your tenant, it’s worth spending a minute to try and explain the terms used in the documentation. As seen from the above examples, the actual Compliance Security Filter object has a property named filters and thus it can sometimes be hard to distinguish which “filter” we are referring to. To avoid any confusion, upper-case Filters will refer to the full object, while lower-case filter to the individual filters stored within the filters property (of the Filters object).
OK, now back to more examples. The initial release of the Compliance Security Filters feature only allowed you to include filters from the same workload. In other words, a single Filter could not contain both a mailbox and a site criteria, which in turn meant that even if you restricted a user to only search specific mailboxes, like in the example we used above, this would still allow him to search all the SharePoint Online content. This mean that you then had to create another Filter to make sure no SharePoint Online content will be returned in any eDiscovery searches initiated by that user.
Luckily, with the introduction of Compliance boundaries, we can now combine filters for different workloads in the same Compliance Security Filter instance. The following filter will ensure that our friend John only has access to “Sales” data across all worloads:
New-ComplianceSecurityFilter -FilterName “SalesUsersAllWorkloads” -Users firstname.lastname@example.org -Filters “Mailbox_Department -eq ‘Sales'”, “Site_ComplianceAttribute -eq ‘Sales’ -or Site_Path -like ‘https://tenantname.sharepoint.com/sites/Sales*'” -Action ALL
On the other hand, you can specify multiple filters for the same workload and combine them with either the –and or the –or operator to fine tune the filter. As an example, you can exclude specific mailboxes from the Sales department, say the Chief Sales Officer:
New-ComplianceSecurityFilter -FilterName “SalesUsersNoCSO” -Users email@example.com -Filters “Mailbox_Department -eq ‘Sales’ -and Mailbox_PrimarySmtpAddress -ne ‘CSO@domain.com'” -Action Search
Now, things start to get more interesting when you combine multiple Filters. Because of the way the feature is designed, Filters are applied in a logical AND configuration to an eDiscovery search query. This means that the set of results returned from the query will always be equal or less than what the Filter allows (equal to only when no keywords are used in the search query, meaning the user wants all the results returned). Multiple Filters are applied in a logical OR configuration, meaning that the set of results will be larger – if any of the Filters evaluate to true, the resulting subset of results will be added to the end result.
As an example, consider a scenario where our designated Compliance officer John is asked to temporarily step in and take care of the eDiscovery needs for another team. This team however is virtual, composed of members across different departments, thus adjusting the Department criteria in the above Filter examples will not help. Instead, the administrator decided to populate a custom property in order to designate the users in question, say CustomAttribute10. Then, we can simply create another Filter, such as:
New-ComplianceSecurityFilter -FilterName “TeamPhoenix” -Users firstname.lastname@example.org -Filters “Mailbox_CustomAttribute10 -eq ‘TeamPhoenix'” -Action Search
Because we have already created a Filter that limits John to just querying users from the Sales department, the question is what happens now? Well, the feature is designed in a way that will ensure the two Filter objects will not clash with each other – any additional Filters are applied in a logical OR configuration, as a result John will now be able to search all Sales users mailboxes and any mailbox that has a matching value for CustomAttribute10. A more detailed description on how Filters work and interact with each other, as well as examples, can be found in this documentation.
A quick look at the other parameters
While the filters parameter is certainly the most interesting one, you should not overlook the importance of the other parameters, and you should spend some time familiarizing yourself with their intended use and restrictions. The Users parameter for example can accept multiple values, separated by comma. Alternatively, you can specify a Role Group created in the Security and Compliance Center, for example the ‘eDiscovery Managers group’. Lastly, if you want a Filter to apply to all users, simply specify the value All.
For the Actions parameter, the acceptable values are Search, Preview, Purge, Export, reflecting on the corresponding eDiscovery operations. Providing multiple values is not supported, although the cmdlet will not throw an error. You can however specify All to include any actions.
Lastly, some additional important information. The feature does not support Public folders, so you cannot use it to restrict eDiscovery operations against those. Inactive mailboxes are supported on the other hand, which is good news for anyone relying on them to preserve data for company employees. It is also important to understand that the feature only applies to eDiscovery searches, and not to any type of Hold functionality (including eDiscovery case holds, retention policies, etc).