This year will probably be known as the “year of GDPR”, and understandably a lot of effort goes into examining and implementing features related to this seminal regulation. We at Cogmotive 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 said requirements, and in general, compliance.
What are Compliance boundaries
One such example is the eDiscovery Compliance boundaries feature, 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. In turn, this can be an issue, especially for large multi-national companies, thus more granular controls are required.
Enter Compliance Security Filters. First introduced back in the beginning of 2017, Compliance Security Filters allow you to granularly control what content will be exposed and which eDiscovery features will be available to the person executing the query. For example, you can limit the eDiscovery Manager John to be only able to execute searches against users from a particular Department, and prevent him from Exporting or Purging results. Let’s see how they work.
Compliance Security Filters
As hinted from the eDiscovery Compliance boundaries description, the 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 to which Actions it will apply to, and designate the Users that the restrictions will apply to. Finally, using the Filters parameter, one specifies 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. And this is what makes this feature so powerful.
For example, a Compliance Security Filter that limits our eDiscovery Manager John to only being able to 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, for a full list see for example this article. When it comes to SharePoint Online or OneDrive for Business however, the set of properties is limited, especially when the latter is concerned. 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 thus 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 on 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 to which “filter” we are referring. 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 let’s get 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. Thus, 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 John only has access to “Sales” data across all worloads:
New-ComplianceSecurityFilter -FilterName "SalesUsersAllWorkloads" -Users john@domain.com -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 john@domain.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 temporary 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 john@domain.com -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 Filers work and interact with each other, as well as examples, are given in the 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 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, or any copy of it. 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).