Define policies for information barriers

Overview

With information barriers, you can define policies that are designed to prevent certain segments of users from communicating with each other, or allow specific segments to communicate only with certain other segments. Information barrier policies can help your organization maintain compliance with relevant industry standards and regulations, and avoid potential conflicts of interest. To learn more, see Information barriers.

This article describes how to plan, define, implement, and manage information barrier policies. Several steps are involved, and the work flow is divided into several parts. Make sure to read through the prerequisites and the entire process before you begin defining (or editing) information barrier policies.

Tip

This article includes an example scenario and a downloadable Excel workbook to help you plan and define your information barrier policies.

Concepts of information barrier policies

When you define policies for information barriers, you'll work with user account attributes, segments, "block" and/or "allow" policies, and policy application.

  • User account attributes are defined in Azure Active Directory (or Exchange Online). These attributes can include department, job title, location, team name, and other job profile details.

  • Segments are sets of users that are defined in the Office 365 Security & Compliance Center using a selected user account attribute. (See the list of supported attributes.)

  • Information barrier policies determine communication limits or restrictions. When you define information barrier policies, you choose from two kinds of policies:

    • "Block" policies prevent one segment from communicating with another segment.
    • "Allow" policies allow one segment to communicate with only certain other segments.
  • Policy application is done after all information barrier policies are defined, and you are ready to apply them in your organization.

The work flow at a glance

Phase What's involved
Make sure prerequisites are met - Verify that you have the required licenses and permissions
- Verify that your directory includes data for segmenting users
- Enable scoped directory search for Microsoft Teams
- Make sure audit logging is turned on
- Make sure no Exchange address book policies are in place
- Use PowerShell (examples are provided)
- Provide admin consent for Microsoft Teams (steps are included)
Part 1: Segment users in your organization - Determine what policies are needed
- Make a list of segments to define
- Identify which attributes to use
- Define segments in terms of policy filters
Part 2: Define information barrier policies - Define your policies (do not apply yet)
- Choose from two kinds (block or allow)
Part 3: Apply information barrier policies - Set policies to active status
- Run the policy application
- View policy status
(As needed) Edit a segment or a policy - Edit a segment
- Edit or remove a policy
- Rerun the policy application
- View policy status
(As needed) Troubleshooting - Take action when things are not working as expected

Prerequisites

In addition to the required licenses and permissions, make sure that the following requirements are met:

  • Directory data. Make sure that your organization's structure is reflected in directory data. To do this, make sure that user account attributes, such as group membership, department name, etc. are populated correctly in Azure Active Directory (or Exchange Online). To learn more, see the following resources:

  • Scoped directory search. Before you define your organization's first information barrier policy, you must enable scoped directory search in Microsoft Teams. Wait at least 24 hours after enabling scoped directory search before you set up or define information barrier policies.

  • Audit logging. In order to look up the status of a policy application, audit logging must be turned on. We recommend doing this before you begin to define segments or policies. To learn more, see Turn Office 365 audit log search on or off.

  • No address book policies. Before you define and apply information barrier policies, make sure no Exchange address book policies are in place. (Information barriers are based on address book policies, but the two kinds of policies are not interchangeable.) If you do have such policies, make sure to remove your address book policies first.

  • PowerShell. Currently, information barrier policies are defined and managed in the Office 365 Security & Compliance Center using PowerShell cmdlets. Although several examples are provided in this article, you'll need to be familiar with PowerShell cmdlets and parameters. You will also need the AzureRM module.

  • Admin consent for information barriers in Microsoft Teams. When your policies are in place, information barriers can remove people from chat sessions they are not supposed to be in. This helps ensure your organization remains compliant with policies and regulations. Use the following procedure to enable information barrier policies to work as expected in Microsoft Teams.

    1. Run the following PowerShell cmdlets:

      Login-AzureRmAccount 
      $appId="bcf62038-e005-436d-b970-2a472f8c1982" 
      $sp=Get-AzureRmADServicePrincipal -ServicePrincipalName $appId
      if ($sp -eq $null) { New-AzureRmADServicePrincipal -ApplicationId $appId }
      Start-Process  "https://login.microsoftonline.com/common/adminconsent?client_id=$appId"
      
    2. When prompted, sign in using your work or school account for Office 365.

    3. In the Permissions requested dialog box, review the information, and then choose Accept.

When all the prerequisites are met, proceed to the next section.

Tip

To help you prepare your plan, an example scenario is included in this article. See Contoso's departments, segments, and policies.

In addition, a downloadable Excel workbook is available to help you plan and define your segments and policies (and create your PowerShell cmdlets). Get the workbook.

Part 1: Segment users

During this phase, you determine what information barrier policies are needed, make a list of segments to define, and then define your segments.

Determine what policies are needed

Considering legal and industry regulations, who are the groups within your organization who will need information barrier policies? Make a list. Are there any groups who should be prevented from communicating with another group? Are there any groups that should be allowed to communicate only with one or two other groups? Think about the policies you need as belonging to one of two groups:

  • "Block" policies prevent one group from communicating with another group.
  • "Allow" policies allow a group to communicate with only certain other, specific groups.

When you have your initial list of groups and policies, proceed to identify the segments you'll need.

Identify segments

In addition to your initial list of policies, make a list of segments for your organization. Users who will be included in information barrier policies should belong to a segment, and no user should belong to two or more segments. Each segment can have only one information barrier policy applied.

Determine which attributes in your organization's directory data you'll use to define segments. You can use Department, MemberOf, or any of the supported attributes. Make sure that you have values in the attribute you select for users. See the list of supported attributes for information barriers.

Important

Before you proceed to the next section, make sure your directory data has values for attributes that you can use to define segments. If your directory data does not have values for the attributes you want to use, then the user accounts must be updated to include that information before you proceed with information barriers. To get help with this, see the following resources:
- Configure user account properties with Office 365 PowerShell
- Add or update a user's profile information using Azure Active Directory

Define segments using PowerShell

Defining segments does not effect users; it just sets the stage for information barrier policies to be defined and then applied.

  1. Use the New-OrganizationSegment cmdlet with the UserGroupFilter parameter that corresponds to the attribute you want to use.

    Syntax Example
    New-OrganizationSegment -Name "segmentname" -UserGroupFilter "attribute -eq 'attributevalue'" New-OrganizationSegment -Name "HR" -UserGroupFilter "Department -eq 'HR'"

    In this example, a segment called HR is defined using HR, a value in the Department attribute. The -eq portion of the cmdlet refers to "equals." (Alternately, you can use -ne to mean "not equals". See Using "equals" and "not equals" in segment definitions.)

    After you run each cmdlet, you should see a list of details about the new segment. Details include the segment's type, who created or last modified it, and so on.

  2. Repeat this process for each segment you want to define.

    Important

    Make sure that your segments do not overlap. Each user who will be affected by information barriers should belong to one (and only one) segment. No user should belong to two or more segments. (See Example: Contoso's defined segments in this article.)

After you have defined your segments, proceed to define information barrier policies.

Using "equals" and "not equals" in segment definitions

In the following example, we are defining a segment such that "Department equals HR."

Example
New-OrganizationSegment -Name "HR" -UserGroupFilter "Department -eq 'HR'"

Notice that in this example, the segment definition includes an "equals" parameter denoted as -eq.

You can also define segments using a "not equals" parameter, denoted as -ne, as shown in the following table:

Syntax Example
New-OrganizationSegment -Name "segmentname" -UserGroupFilter "attribute -ne 'attributevalue'" New-OrganizationSegment -Name "NotSales" -UserGroupFilter "Department -ne 'Sales'"

In this example, we defined a segment called NotSales that includes everyone who is not in Sales. The -ne portion of the cmdlet refers to "not equals."

In addition to defining segments using "equals" or "not equals", you can define a segment using both "equals" and "not equals" parameters.

Example
New-OrganizationSegment -Name "LocalFTE" -UserGroupFilter "Location -eq 'Local'" and "Position -ne 'Temporary'"

In this example, we defined a segment called LocalFTE that includes people who are locally located and whose positions are not listed as Temporary.

Tip

If possible, use segment definitions that include "-eq" or "-ne". Try not to define complex segment definitions.

Part 2: Define information barrier policies

Determine whether you need to prevent communications between certain segments, or limit communications to certain segments. Ideally, you'll use the minimum number of policies to ensure your organization is compliant with legal and industry requirements.

With your list of user segments and the information barrier policies you want to define, select a scenario, and then follow the steps.

Important

Make sure that as you define policies, you do not assign more than one policy to a segment. For example, if you define one policy for a segment called Sales, do not define an additional policy for Sales.

In addition, as you define information barrier policies, make sure to set those policies to inactive status until you are ready to apply them. Defining (or editing) policies does not affect users until those policies are set to active status and then applied.

(See Example: Contoso's information barrier policies in this article.)

Scenario 1: Block communications between segments

When you want to block segments from communicating with each other, you define two policies: one for each direction. Each policy blocks communication one way only.

For example, suppose you want to block communications between Segment A and Segment B. In this case, you define one policy preventing Segment A from communicating with Segment B, and then define a second policy to prevent Segment B from communicating with Segment A.

  1. To define your first blocking policy, use the New-InformationBarrierPolicy cmdlet with the SegmentsBlocked parameter.

    Syntax Example
    New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segment1name" -SegmentsBlocked "segment2name" New-InformationBarrierPolicy -Name "Sales-Research" -AssignedSegment "Sales" -SegmentsBlocked "Research" -State Inactive

    In this example, we defined a policy called Sales-Research for a segment called Sales. When active and applied, this policy prevents people in Sales from communicating with people in a segment called Research.

  2. To define your second blocking segment, use the New-InformationBarrierPolicy cmdlet with the SegmentsBlocked parameter again, this time with the segments reversed.

    Example
    New-InformationBarrierPolicy -Name "Research-Sales" -AssignedSegment "Research" -SegmentsBlocked "Sales" -State Inactive

    In this example, we defined a policy called Research-Sales to prevent Research from communicating with Sales.

  3. Proceed to one of the following:

Scenario 2: Allow a segment to communicate only with one other segment

  1. To allow one segment to communicate with only one other segment, use the New-InformationBarrierPolicy cmdlet with the SegmentsAllowed parameter.

    Syntax Example
    New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segment1name" -SegmentsAllowed "segment2name" New-InformationBarrierPolicy -Name "Manufacturing-HR" -AssignedSegment "Manufacturing" -SegmentsAllowed "HR" -State Inactive

    In this example, we defined a policy called Manufacturing-HR for a segment called Manufacturing. When active and applied, this policy allows people in Manufacturing to communicate only with people in a segment called HR. (In this case, Manufacturing cannot communicate with users who are not part of HR.)

    If needed, you can specify multiple segments with this cmdlet, as shown in the following example.

    Syntax Example
    New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segment1name" -SegmentsAllowed "segment2name", "segment3name" New-InformationBarrierPolicy -Name "Research-HRManufacturing" -AssignedSegment "Research" -SegmentsAllowed "HR","Manufacturing" -State Inactive

    In this example, we defined a policy that allows the Research segment to communicate with only HR and Manufacturing.

    Repeat this step for each policy you want to define to allow specific segments to communicate with only certain other specific segments.

  2. Proceed to one of the following:

Part 3: Apply information barrier policies

Information barrier policies are not in effect until you set them to active status, and then apply the policies.

  1. Use the Get-InformationBarrierPolicy cmdlet to see a list of policies that have been defined. Note the status and identity (GUID) of each policy.

    Syntax: Get-InformationBarrierPolicy

  2. To set a policy to active status, use the Set-InformationBarrierPolicy cmdlet with an Identity parameter, and the State parameter set to Active.

    Syntax Example
    Set-InformationBarrierPolicy -Identity GUID -State Active Set-InformationBarrierPolicy -Identity 43c37853-ea10-4b90-a23d-ab8c93772471 -State Active

    In this example, we set an information barrier policy that has the GUID 43c37853-ea10-4b90-a23d-ab8c93772471 to active status.

    Repeat this step as appropriate for each policy.

  3. When you have finished setting your information barrier policies to active status, use the Start-InformationBarrierPoliciesApplication cmdlet in the Office 365 Security & Compliance Center.

    Syntax: Start-InformationBarrierPoliciesApplication

    After approximately a half hour, policies are applied, user by user, for your organization. If your organization is large, it can take 24 hours (or more) for this process to complete. (As a general guideline, it takes about an hour to process 5,000 user accounts.)

View status of user accounts, segments, policies, or policy application

With PowerShell, you can view status of user accounts, segments, policies, and policy application, as listed in the following table.

To view this Do this
User accounts Use the Get-InformationBarrierRecipientStatus cmdlet with Identity parameters.

Syntax: Get-InformationBarrierRecipientStatus -Identity <value> -Identity2 <value>

You can use any value that uniquely identifies each user, such as name, alias, distinguished name, canonical domain name, email address, or GUID.

Example: Get-InformationBarrierRecipientStatus -Identity meganb -Identity2 alexw

In this example, we refer to two user accounts in Office 365: meganb for Megan, and alexw for Alex.

(You can also use this cmdlet for a single user: Get-InformationBarrierRecipientStatus -Identity <value>)

This cmdlet returns information about users, such as attribute values and any information barrier policies that are applied.

Segments Use the Get-OrganizationSegment cmdlet.

Syntax: Get-OrganizationSegment

This will display a list of all segments defined for your organization.

Information barrier policies Use the Get-InformationBarrierPolicy cmdlet.

Syntax: Get-InformationBarrierPolicy

This will display a list of information barrier policies that were defined, and their status.

The most recent information barrier policy application Use the Get-InformationBarrierPoliciesApplicationStatus cmdlet.

Syntax: Get-InformationBarrierPoliciesApplicationStatus

This will display information about whether policy application completed, failed, or is in progress.

All information barrier policy applications Use Get-InformationBarrierPoliciesApplicationStatus -All $true

This will display information about whether policy application completed, failed, or is in progress.

What if I need to remove or change policies?

Resources are available to help you manage your information barrier policies.

Example: Contoso's departments, segments, and policies

To see how an organization might approach defining segments and policies, consider the following example.

Contoso's departments and plan

Contoso has five departments: HR, Sales, Marketing, Research, and Manufacturing. In order to remain compliant with industry regulations, people in some departments are not supposed to communicate with other departments, as listed in the following table:

Segment Can talk to Cannot talk to
HR Everyone (no restrictions)
Sales HR, Marketing, Manufacturing Research
Marketing Everyone (no restrictions)
Research HR, Marketing, Manufacturing Sales
Manufacturing HR, Marketing Anyone other than HR or Marketing

With this in mind, Contoso's plan includes three information barrier policies:

  1. A policy designed to prevent Sales from communicating with Research (and another policy to prevent Research from communicating with Sales)
  2. A policy designed to allow Manufacturing to communicate with HR and Marketing only

It's not necessary to define policies for HR or Marketing.

Contoso's defined segments

Contoso will use the Department attribute in Azure Active Directory to define segments, as follows:

Department Segment Definition
HR New-OrganizationSegment -Name "HR" -UserGroupFilter "Department -eq 'HR'"
Sales New-OrganizationSegment -Name "Sales" -UserGroupFilter "Department -eq 'Sales'"
Marketing New-OrganizationSegment -Name "Marketing" -UserGroupFilter "Department -eq 'Marketing'"
Research New-OrganizationSegment -Name "Research" -UserGroupFilter "Department -eq 'Research'"
Manufacturing New-OrganizationSegment -Name "Manufacturing" -UserGroupFilter "Department -eq 'Manufacturing'"

With the segments defined, Contoso proceeds to define policies.

Contoso's information barrier policies

Contoso defines three polices, as described in the following table:

Policy Policy Definition
Policy 1: Prevent Sales from communicating with Research New-InformationBarrierPolicy -Name "Sales-Research" -AssignedSegment "Sales" -SegmentsBlocked "Research" -State Inactive

In this example, the information barrier policy is called Sales-Research. When this policy is active and applied, it will help prevent users who are in the Sales segment from communicating with users in the Research segment. This is a one-way policy; it won't prevent Research from communicating with Sales. For that, Policy 2 is needed.

Policy 2: Prevent Research from communicating with Sales New-InformationBarrierPolicy -Name "Research-Sales" -AssignedSegment "Research" -SegmentsBlocked "Sales" -State Inactive

In this example, the information barrier policy is called Research-Sales. When this policy is active and applied, it will help prevent users who are in the Research segment from communicating with users in the Sales segment.

Policy 3: Allow Manufacturing to communicate with HR and Marketing only New-InformationBarrierPolicy -Name "Manufacturing-HRMarketing" -AssignedSegment "Manufacturing" -SegmentsAllowed "HR","Marketing" -State Inactive

In this case, the information barrier policy is called Manufacturing-HRMarketing. When this policy is active and applied, Manufacturing can communicate only with HR and Marketing. Note that HR and Marketing are not restricted from communicating with other segments.

With segments and policies defined, Contoso applies the policies by running the Start-InformationBarrierPoliciesApplication cmdlet.

When that finishes, Contoso is compliant with legal and industry requirements.