MICROSOFT PURVIEW - INFORMATION BARRIERS
#Office 356 #MicrosoftPurview #Information Barriers
About the author: Elliot Dunn
This article will provide a brief overview of Microsoft’s Information Barriers solution which I recently explored to fully understand what it has to offer.
The ever-changing line-up of solutions sitting within Microsoft’s Purview compliance portal vary widely in scope and functionality they provide. These solutions can generate significant value to organisations and bring them closer to compliance by improving governance over their information landscape. There is little doubt in the value that Information Protection services such as Sensitivity Labels, Data Loss Prevention and Retention Labelling bring to the table.
However, solutions sitting under the Insider Risk service umbrella can be highly targeted for specific use-cases and many small-medium sized organisations and public sector agencies in New Zealand may struggle to understand the immediate value.
History
Originating in the financial services industry to manage conflicts of interest, the concept of information barriers had a limited scope. Now, Microsoft promotes the use of Information Barriers for meeting regulatory requirements and protecting sensitive information across several industries.
What are Information Barriers?
Active Directory attributes (properties) are used to create segments of users. These segments are then applied to policies to block or allow a particular communication channel or collaboration activity. Whether that be through Exchange, Teams, SharePoint or OneDrive, the policy will prevent (or allow) that communication or collaboration from happening.
For example, if a segment was added to a policy to block communication and collaboration, the users within that segment would not be able to see a user exists, let alone communicate with them via Exchange or Teams. Segments can also be added to SharePoint sites to give an additional layer of security. It’s important to note that Information Barriers do not impact SharePoint permissions, the users will still need to have access to the site to see content.
Helpful elements
When creating a segment, there are a range of properties that can be used to filter for specific users. ‘Member Of’ is by far the most useful property available as this allows you to point to an existing M365 group or security group. This becomes particularly useful when this security group is dynamic so that the segment doesn’t have to be maintained and membership will update based on the mapped dynamic security groups existing rules.
Not so helpful elements
There are a range of limitations to the solution which casts doubt over its usefulness. For example:
A user can only be in one segment.
Each segment can have only one policy applied to it.
Certain properties such as ‘Location’ cannot be used to define segments.
Recent changes
Version 2 of Information Barriers was recently announced which addresses some of the limitations mentioned.
Users can now be assigned up to 10 segments compared to being limited to just the one. It is positive to see the scope of information barriers expanding and by increasing the number of segments a user can be a member of, there is potentially some added flexibility and sophistication to the policies that can be created. However, limitations around a segment being used in a single policy still exist.
Another notable change is allowing for user discovery while still adhering to existing communication/collaboration policies. The demand organisations are placing on transparency and clear visibility of people across their digital working environment is being heard and improving these discoverability features is testament to that.
Potential use-cases
Managing a conflict of interest seems like the most likely use case for information barriers. If communication between an individual or group of individuals and a conflicted party needed to be prevented, this toolset can help organisations get part of the way there. In saying that, common COI scenarios I have seen recently are typically at a more granular level, such as on a specific procurement process or investigation. These situations would be better handled with SharePoint permissions, where the access to the documents in question can be restricted. It is only when the requirement to prohibit communication between two parties comes into play that Information Barriers may want to be considered.
Another situation that comes to mind is when an organisation is going through a merger or acquisition process. Certain staff may need to be kept separated across various platforms while being hosted on the same tenancy and environment. Using large scale and clearly defined segments would help block any interaction between the groups until the merger process was completed.
The Verdict
The complexity involved in mapping segments to policies to ensure an appropriate coverage of users while also attempting to avoid any unnecessary overlaps is likely going to be a timely and headache-inducing exercise.
There aren’t a whole lot of reasons why I would recommend implementing Information Barriers as they are currently. However, if a clearly defined use-case presents itself to your organisation, it may be worth exploring.
Resources:
About the author: Elliot Dunn