12 Security and Compliance Center
_______________________________
In This Chapter
- Security and Compliance Center
- Connecting with PowerShell
- Permissions
- Classifications - Labels and DLP
- Search and Investigation
_______________________________
Due to the nature of Office 365, there are overlaps between features as well as unique apps that do not appear on-premises. The Security and Compliance Center from Microsoft is the new central point of administration for compliance and other features for Office 365. Overlap between SCC and Exchange Online rests on items like eDiscovery and holds on mailboxes.
In this chapter we'll cover the basics of the Security and Compliance Center (SCC) interface which is Microsoft attempt at consolidating numerous security features and functions into one interface. This console touches up many workloads in Office 365, but we will concentrate on those that directly affect Exchange Online. this means that some functions and good features will not be covered.
Later we'll take a deep dive into PowerShell for the SCC. That way the interfaces for interacting with the SCC will make more sense. The cases we create, the holds that are put in place and more will then be visible in the SCC and allow for downloading or further manipulation. Because of the consolidation, PowerShell management also has to be consolidated and therefor there is a specific PowerShell URL for SCC.
In SCC we have Classifications and Labels in order to tag or designate items for policies. Classifications are ways of identifying objects or items to apply policies to. These classifications are like Exchange Retention Policies and Tags. There are three parts to the concept of labels - Label, Label Policy and Retention Rule. These three work together to create automatically applied labels or ones that are available to end users.
Data Loss Prevention - just like Exchange Online, there is a DLP module in the SCC that covers a broader set of workloads. However, the general idea is still there in the sense that we are now trying to protect data in SharePoint and OneDrive in addition to Exchange Online.
Search and Investigation - eDiscovery, content searches and mailbox holds can be done from here. Companies with Exchange Online tenants will want to learn these features as they are the future for these Exchange Online functions.
Security and Compliance Center
The Security and Compliance Center (SCC) is an effort by Microsoft to create a centralized place for processes like eDiscovery, Compliance Management, DLP and more. The central console will tap into many of the workloads that exist separately now in Office 365. These workloads include Exchange Online, SharePoint, OneDrive and more. Features that currently exist in these workloads are being pulled into the SCC.
For Exchange Online, workloads that are handled or can be handled in the SCC include items like eDiscovery of mailbox content, mailbox holds, DLP and more. Some of these features were to be transitioned earlier in 2017 but are taking longer to actual move to the SCC. In the end, it is better to prepare for this change rather than creating your processes in Office 365 only.
Reviewing the SCC console we see that there are a few options available to us right off the bat. These options are:
- Permissions - Where to grant access to individual users in your tenant. The roles included here include specialized roles like Compliance Admin, Security Reader and Reviewer. Assign permissions carefully.
- Classifications - This tab deals with retention labels and sensitive information types.
- Data Loss Prevention - Puts controls in place that control access to sensitive data and how it is accessed or disbursed.
- Data Governance - Provides a way to control data for importing, archiving, retention and journaling.
- Threat Management - Cover ATP Safe Links and Safe Attachments, Anti-Malware, Anti-Spam and DKIM.
- Search and Investigation - Construct Content Searches, review Audit Logs, perform eDiscovery searches and access Office 365 Cloud App Security (E5 licenses).
- Reports - Review reports, schedule reports and download reports.
Earlier in the book we explained how a connection could be made to remote PowerShell for Exchange Online. The Security and Compliance Center also has its own connection point. As such, we can use a PowerShell window to make a connection to our tenant's Security and Compliance Center and make changes, modifications or simply do some reporting via this console.
What we know is that the SCC has it's own remote PowerShell connection point and we can connect to it like so:
$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.SCC -ConnectionUri https://ps.compliance.protection.outlook.com/powershell-liveid/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session
The only difference between connecting to the SCC and Exchange Online is the 'ConnectionUri':
ps.compliance.protection.outlook.com vs. ps.outlook.com
The connection should look something like this in PowerShell:
Once connected we can now run cmdlets specific to the Security and Compliance Center. Notice the Module Name listed above - 'tmp_eg2khs5g.iho'. This is the temporary module name that will be associated with all SCC specific cmdlets. On the next connection, this name should be different.
If the Module Name is always changing, how would we be able to query just those cmdlets and know what is available in that session? First, let's see what modules are loaded when we've connected to the SCC:
Get-Module
Notice that the Module type for the SCC module is a 'Script'. No other loaded module is of this type. Another common attribute we can work off of is the name. Even thought the name will change, it has at least one consistency and that is the name will always begin with 'tmp_'. So if we were to run a filter like so, we would find all cmdlets for the loaded SCC module:
Get-Command | Where {$_.ModuleName -Like 'tmp_*'}
To see how effective this is, let's see how many cmdlets are available for the entire SCC connection and only those that are specific to the SCC module:
(Get-Command).Count
(Get-Command | Where {$_.ModuleName -like 'tmp_*'}).Count
Like other services in your Office 365 tenant, controlling who has access and who has access to what in the SCC is an important aspect of managing the SCC. These assignments will be important as the data that can be pulled from the SCC can be highly sensitive and confidential. We cover a similar set of Management Roles, Role Groups and Role Assignment. First, let's review what roles are available and what they mean in the context of the SCC.
Get-ManagementRole
As we can see from the above list, there are quite a few Management Roles which are the individual rights that can be assigned to end users or preferably to Role Groups which are then assigned to end-users. Roles Groups are preferable because they allow for more than one Management Role to be assigned to a user or group of users at a time. Built-In Role Groups have a list of Management Roles that are preassigned for convenience. Let's review what Role Groups we have available in the SCC:
Get-RoleGroup
These same groups are the ones that are exposed in the GUI for the SCC Permissions page. What is a little hard to work with is the column of values titled 'AssignedRoles'. Trying to parse this takes a bit and if you were to examine all the properties for one Role Group, it makes it easier to decide how to extract a particular Role Groups Management Roles that are assigned to it.
Take for example the eDiscoveryManager Role Group. Let see what properties are available:
Notice in the results, the field 'AssignedRoles' does not appear, but we have two to content with 'RoleAssignments' and 'Roles'. The properties are different.
Digging further into this Role Group, we'll specifically look at the 'Roles' property as the roles are ones we can then pick apart to see what is assigned to the Role Group in total.
(Get-RoleGroup 'ediscoveryManager').Roles
This provides us a list of roles (with VERY long names):
Taking the first one, we know the right is 'Export' for short. This is a Management Role and we can pick it apart like this:
Get-ManagementRole 'Export'
Not very descriptive, so we'll add a 'Fl' at the end and get this:
Now we have a description of that particular role. Now, if want to automatically pull this information and get the Management Role descriptions for each under one Role Group, we can do so with this script:
$Roles = (Get-RoleGroup 'eDiscoveryManager').Roles
Foreach ($Role in $Roles) {
$RoleName = $Role.Split([char]0x002F)
$Name = $RoleName[3]
$Description = (Get-ManagementRole $Name).Description
Write-Host $Name -NoNewline -ForegroundColor Green
Write-Host ': '$Description -ForegroundColor White
}
A successful run reveals the descriptions from each Management Role in the 'eDiscovery Manager' Role Group:
To apply this to any role, we simply need to replace the Role Group listed on the first line with the one we are needing information on. Expanding upon that, we can even use a loop for each Role Group and pull out the Management Roles if we so desired.
Being able to figure out who has what role assigned to them can be accomplished with the Get-RoleGroupMember -Identity cmdlet that is available. By default the only group that should contain a member is the TenantAdmins group that is listed here. This group is also known as the Global Admins for your tenant. With the default setup we have a blank slate with which to assign rights to the SCC.
Add-RoleGroupMember eDiscoveryManager -Member 'Damian Scoles'
We can then verify that the user is added correctly:
Removing a role member is just as easy as adding one:
Remove-RoleGroupMember eDiscoveryManager -Member 'Damian Scoles'
Classifications - Labels and DLP
When it comes to working with data on an automatic basis, we need to provide some sort of system or information that these processes can work with. In the case of Office 365 and Exchange Online, these processes are DLP and Transport Rules. The bits of information that can be fed to these processes are Labels and Sensitive Information Types. We can originate this information from two places - Exchange Online Admin console and the other is the Security and Compliance Center. While we have covered the Exchange Online Admin Center version of this, we also need to cover the SCC because that is where Microsoft is investing for the future of data protection that will include Exchange Online as well.
When reviewing the console for the SCC, we see that we can use two methods for data classification. We can use Labels or we can use Sensitive Information Types. If you are familiar with Retention Policies and Tags, then you will understand the concept of Labels and Label Policies. These follow a similar set of rules, with a twist. While Sensitive Information Types can be used in Exchange Transport Rules, Labels are applied in a more automatic fashion to the content in Office 365.
Labels are used to define what we want to tag. These Labels can be used to control content that gets tagged. This could include emails, SharePoint data and OneDrive data in your Office 365 tenant. We will cover this topic from the perspective of Exchange Online only. When we dig a bit deeper into Labels, we find that there are three components to successfully apply them to content in your tenant - Compliance Tags, Compliance Rules and Compliance Policies.
Make sure to read this article on how Labels are applied, in terms of timing, for each workload in Office 365:
https://support.office.com/en-us/article/overview-of-labels-af398293-c69d-465e-a249-d74561552d30
PowerShell
First, let's see what we can find for PowerShell cmdlets when it comes to creating Labels for the SCC.
Get-Command *label*
Hmmm.... no results found. ? How are we going to create Labels? Well, let's go to our favorite search engine to see what we can find:
Search Terms: PowerShell Security Compliance Center Labels
Notice the reference to one PowerShell cmdlet here, New-ComplianceTag. Sounds promising. Let's take a look in PowerShell help to see what it can do:
Some cmdlet examples:
Common parameters used with Compliance Tags:
- IsRecordLabel - Can tag content permanently or not. Once tagged a Record Label cannot be removed.
- RetentionAction - Decided if the content is kept, deleted or keepanddelete.
- Retention Duration - How long will the item be retained.
- RetentionType - CreationAgeInDays, EventAgeInDays, ModificationAgeInDays, TaggedAgeInDays.
Labels can be used by the end user once they are published in Outlook, SharePoint and OneDrive. The workloads the tag can be created for are not customizable. It will apply to all of these workloads. However, we can use Label Policies to restrict the end workload that the Label applies to.
Example
We can create a retention tag for confidential emails that would allow us to keep the emails for up to seven years. A sample Label would be created like this:
New-ComplianceTag -Name Confidential -RetentionAction Keep -RetentionDuration 2555 -RetentionType ModificationAgeInDays
Now we need to restrict this just to Exchange Online. In order to do so, we need to use a cmdlet called 'New-RetentionCompliancePolicy'.
New-RetentionCompliancePolicy -Name 'Exchange 7 Years' -ExchangeLocation All
Then we can publish the Labels with the Compliance Rule cmdlet:
New-RetentionComplianceRule -Policy 'Exchange 7 Years' -PublishComplianceTag 'Confidential'
More information on publishing these Labels and Policies can be found here:
Now we have a Label and Label Policy that is this together with a Compliance Rule that will allow users to assign a seven year Label on their emails. We used the 'All' designation for ExchangeLocations which means all mailboxes will see this Label.
Built In
As with Exchange Online, the Security and Compliance Center has built-in Sensitive Information Types that we can use right away. We can take a quick peak at the names of some of the policies like so:
Get-DlpSensitiveInformationType
The above is a partial list of the available types. The number of types appears to be greater than that of Exchange Online. How many are there? Let's do a '.Count' for all of these types
(Get-DlpSensitiveInformationType).count
What we find is that there are 82 Sensitive Information Types in the SCC, compared to only 40 DLP Policy Templates in Exchange Online. We can pull from the above list when constructing Transport Rules or using them in the SCC for applying them to other workloads like SharePoint and OneDrive.
Custom
In addition to the built-in Sensitive Information Types, we can add our own custom ones. Custom data types could be used to track bank routing information, social security numbers, credit cards, confidential phases and more. Let's review the PowerShell cmdlets that we can use to make these new types:
Get-Command *DlpSensitiveInformation*
First we will start with the creation of some new Sensitive Information Types. Here is the sole example from this cmdlet:
Get-Help New-DlpSensitiveInformationTypeRulePackage -Examples
Notice the highlighted section that refers to the use of an XML file for the new data type. Microsoft does not provide a link here on how to create such an XML file, but if you search the Internet, you will be able to find this handy link:
This link takes us to a page explaining how to create an XML file that can be used against custom scenarios. Creating an XML file takes a bit of time and is somewhat complicated. These XML files can be created with a PowerShell script that has a series of questions. This script was written by one of the authors of the book and can be found here:
https://justaucguy.wordpress.com/2015/01/27/dlp-custom-xml-generation-script/
In practical terms, creating a one-off XML file is easier if you can use the Microsoft help and TechNet pages that are provided. Skipping forward, assuming an XML file has been created (ConfidentialInformation.Xml) we can import the template using the example above for guidance.
$FullDirectory = "C:xmlscriptConfidentialInformation.xml"
New-DlpSensitiveInformationTypeRulePackage -FileData ([Byte[]]$(get-content -Path $FullDirectory -Encoding Byte -ReadCount 0))
When run successfully, we should see a good result like so:
Which we can then verify as well, post-creation:
In order to use these we need to create Transport Rules in Exchange Online. Connect to Exchange Online via PowerShell first, as we explained in Chapter 5. Once connected we can create a Transport Rule, like we did in Chapter 10. In this case however, we need to reference the DLP information. In this case we need the 'MessageContainsDataClassifications' parameter:
A sample rule, using one of the Sensitive Information Types we just defined, would look like this:
New-TransportRule -SentToScope 'NotInOrganization' -MessageContainsDataClassifications @(Name="KeywordSearch-CI";mincount = '1') -ModerateMessageByUser @([Microsoft.Exchange.Management.ControlPanel.PeopleIdentity]) -Name 'Sent to scope Outside the organization' -StopRuleProcessing:$False -Mode 'Enforce' -Comments '' -RuleErrorAction 'Ignore' -SenderAddressLocation 'Header'
This Transport Rule will look for our criteria and if there is a match once or more in the email, then it will trigger the rule above.
Searching for content, exporting content and holding content are all part of the Search and Investigation piece. If you need to perform these types of functions for Exchange Online, the optimal place to do that now is in the SCC. These types of actions will eventually be removed or at the very least deprecated from Exchange Online. The reason for that again is consolidation. From the SCC, an eDiscovery Manager can now search multiple workloads in Office 365 with ease. For the scenarios and cmdlets provided in this book, we will concentrate on Exchange Online only.
Reviewing the cmdlets for the SCC, we don't see any specific to Content Searches. However, there are cmdlets that deal with Compliance Searches. If we review the help for the New-ComplianceSearch cmdlet, we'll see that there is a parameter for content searches:
Content queries can be constructed with the Keyword Query Language (KQL) which can be referenced here:
Now, if your legal needs are a bit more complex, or if you have searches and holds that need to be held together as groups, we can use Compliance Cases to assist us with this task. A Case is a holder for the searches that you've created. These can be convenient in a legal sense because we can group together multiple Compliance Searches into one Compliance Case. Organizing them in this way will make it easier for a legal team to pull information from one source instead of having to comb through a lot of informational sources.
PowerShell
Get-Help New-ComplianceCase -Examples
Not much to go on here. Let's review the parameters that are available to us in the full Get-Help for this cmdlet. We have these parameters - Name, Confirm, Description, Domain Controller, Sources and WhatIf. Most of these parameters are 'reserved for internal Microsoft use'. This means that the Compliance Case is purely just a holder and the only way to associate searches with a case, is to first create the case and then specify this case in the creation of a new Compliance Search. In fact we see this in the help for the New-ComplianceSearch:
Let's walk though an example so that we can build a case and then associates some searches with it.
Example
Your company, Bib Box, Inc. is currently involved in a legal case where a client is suing because some of the boxes you provided were too small compare to the specs that were provided by their engineers and confirmed by your company's R&D department. The manager of the company's compliance department is asking for all of the content from the mailboxes of R&D members as well as a couple of salespeople that were involved in the deal. In order to keep track of this better, the searches need to be stored in their own case. The reasoning for the last decision is that there are currently two other legal cases in-progress now and they need to be kept secret.
First create the case:
New-ComplianceCase -Name 'BigBox-vs-FastBox'
Now that we have case, we can create our compliance searches we can define all mailboxes and store them in a variable to be called later:
$Mailboxes = 'John Bean','Tyrone Smith','Han Francis'
For each mailbox we'll create the same search and associate it with the same case we created earlier:
Foreach ($Mailbox in $Mailboxes) {
New-ComplianceSearch
}
A successful run will show all three of the content searches created, but not started:
If we try to run Get-ComplianceSearch after these are created it would appear that none were, because we get a blank response from PowerShell:
In order to find the cases, we need to specifically reference them:
Get-ComplianceSearch 'John Bean'
Get-ComplianceSearch 'Tyrone Smith'
Get-ComplianceSearch 'Han Francis'
We see again that these are not started. To start them, we need to use the' Start-ComplianceSearch' cmdlet:
Get-ComplianceSearch 'John Bean' | Start-ComplianceSearch
Get-ComplianceSearch 'Tyrone Smith' | Start-ComplianceSearch
Get-ComplianceSearch 'Han Francis' | Start-ComplianceSearch
Now we have searches running in the background and available to our legal team for our example legal case.