Requesting a FINRA/SEC 17a-4 Attestation Letter for Office 365

Published on January 7, 2019February 5, 2019 by Dave Branscome1 Comment

One of the strengths of Microsoft’s cloud services is the deep and broad list of technical certifications that the services have achieved. These include various common standards, such as SOC I and II, and SSAE. Additionally, Microsoft meets various country-specific government standards, such as FedRAMP.

But before we go any further, it’s important to make a distinction between a “certification” and an “attestation”, because they sometimes get used interchangeably when referring to Office 365 compliance.

Certifications are industry standards, such as ISO and SOC that are audited by a 3^rd party. Microsoft is required to operate their datacenters and services according to those audited standards.
Attestations, on the other hand, are more like 3^rd party guidance, or opinions, related to specific regulations. They are reference documents created by a 3^rd party that say, “Yes, the necessary controls exist in Office 365 so that you can configure your tenant to meet a given regulation.” For example, it could be HIPAA for medical and health customers, FERPA for education or FINRA for the financial industry. These attestations often provide implementation guidance, but the important point here is that the responsibility is on the customer to configure the controls in the tenant to meet the regulation. What the attestation does is confirm that the necessary controls exist in Office 365 that will allow the customer to meet that regulation.

The point of these certifications and attestations is not simply to be able to tick a checkbox on an RFP. Rather, these certifications and attestations form a foundation of trust that helps assure customers that their data, identities and privacy is being handled in a responsible way, according to a set of standards defined outside of Microsoft.

There are numerous resources a customer or partner can go to and get information about specific compliance requirements, but sometimes it can be hard to track down exactly what you’re looking for – simply because there is SO MUCH information and it’s categorized and stored in different locations.

Take for example, the SEC 17a-4 letters of attestation, which are often referred to as the FINRA attestation letters. To be clear, SEC 17a-4 is the regulation, whereas FINRA is actually the agency that enforces the regulation. (Yes, the SEC is also an enforcement agency, but let’s not muddy the waters.) These letters may be required by a customer to confirm that Office 365 meets certain regulations of the Financial Industry Regulatory Agency (FINRA) in the United States.

Since neither the customer nor the SEC have direct access to the Office 365 cloud environment, Microsoft bridges the gap through these letters of attestation to the SEC on behalf of the requesting customer.

These letters affirm, among other things, that the Office 365 service – and specifically the Immutable Storage for Azure Blobs that are the underpinnings of the Office 365 storage services – can be leveraged by the customer to preserve their data on storage that is non-rewriteable and non-erasable.

The next question is – where can a customer get that letter? Let’s talk for a moment about the various resource locations available for a customer to review to find the information they might require. (You can also skip straight to the end to get the answer about FINRA, but you’ll miss some interesting stuff.)

Trust Center
The Trust Center Resources are located at https://www.microsoft.com/en-us/trustcenter/resources

Here, you can use the drop-down selections to find articles, blogs, whitepapers, e-books, videos, case studies and other resources related to Microsoft’s compliance to different types of regulatory standards.

For example, in the screenshot below, I’ve narrowed my search down to any type of resource related to the financial industry in North America related to compliance in Office 365. The result is a single document, named IRS 1075 backgrounder.

That’s probably interesting in a different scenario, but it’s not a FINRA attestation letter, so it won’t help me in this instance.

Let’s dig some more…

Office 365 Security and Compliance Center

The next place I might look is the Office 365 Security and Compliance Center. I can get to this location in my Office 365 tenant (whether it’s a paid or a demo tenant) by going to my Admin portal, then to Admin centers, and then Security & Compliance.

Under the Service assurance section, I click on Compliance Reports.

From here, I have the ability to sort my reports according to the type of reporting I’m interested in, such as FedRAMP (for US federal government customers) and GRC (which simply means Governance, Risk and Compliance) and others.

For your reference, the same documents are available in the Trust Center here: https://servicetrust.microsoft.com/ViewPage/MSComplianceGuide

In looking through these documents, there is plenty to see, but nothing that specifically references FINRA.

Let’s look at the next blade – Trust Documents.

The default section that opens is a list of FAQs and Whitepapers, but the second section on the page is Risk Management Reports. This includes results of penetration testing and other security assessments against the cloud services, but again, no attestation letters.

The last section to click on is Compliance Manager.

The Compliance Manager tool can be accessed at any time by going to https://servicetrust.microsoft.com/ComplianceManager and logging in with your Office 365 credentials.

In Compliance Manager, you can track your organization’s level of compliance against a given regulation, such as GDPR, FedRAMP or HIPAA. I won’t go into a lot of detail about Compliance Manager here, but the basic idea is that you define the service you are interested in evaluating and the certification you’re interested in, as seen in the screenshot below.

As an example, let’s select HIPAA.

What I see now is a gauge that shows how far along my organization is in implementing all the controls related to HIPAA. Some of these controls are managed by Microsoft (such as those related to datacenter security) and others are managed by the customer (such as the decision to encrypt data).

First, I see the actual control ID, title and a description of the control, as it is defined in the HIPAA documentation. This allows me to get a quick overview of the regulation itself.

You can also see information about how you could meet the requirements for this control using Microsoft products. The screenshot below shows how Azure Information Protection and Customer Managed Keys in Office 365 could help you meet the requirement for this HIPAA control.

Next, I see a list of related controls, so that, if there are areas of overlap, I don’t necessarily need to spend a lot of time and effort planning how to implement this control. For example, in the screenshot below, if my organization has already configured the controls for ISO 27018:2014: C.10.1.1, then I can simply verify that this would also meet the HIPAA control listed in the screenshot above.

I can then use the last section to provide my supporting documentation and the date of my validation testing, along with the test results.

Compliance Manager is a powerful tool for tracking your adherence to certain regulations, but it’s still not a FINRA attestation letter.

FINRA Attestation Letter Process

The actual process for requesting a FINRA attestation letter is not very complicated at all. Go back to your main Office 365 Admin portal page and open a New service request under the Support section.

You can choose to submit a “New service request by email”, ensuring that “FINRA attestation letter” is noted at the beginning of your documentation.

The support engineer who gets the ticket will be directed to pass this along to an escalation team.

Based upon the information exchanged with the customer, the escalation team will engage CELA (Microsoft’s legal group) and they will get the attestation letter generated and executed. The final letter will look somewhat similar to this, but the highlighted areas will have the actual customer name and address.

Note that this process carries a 10-day SLA.

When the support ticket has been opened the support engineer will provide the information shown below, and then they will work with the customer to collect specific tenant-level information that ensures the accuracy of the prepared document.

Microsoft’s position, confirmed by is that Office 365 provides administrators with configuration capabilities within Exchange Online Archiving to help customers achieve compliance with the data immutability and data storage requirements of SEC Rule 17a-4.

The Azure external review confirms the ability for customers to achieve compliance with the data immutability and data storage requirements of SEC Rule 17a-4.

Microsoft actively seeks to help our customers achieve compliance with the many and varied regulatory requirements found in domestic and international jurisdictions. That said, it is important to note that while Microsoft will do all we can to assist, Microsoft itself is a not a regulated entity and does not directly comply with the SEC 17a-4 regulation.

Financial services firms are the regulated entities and as such remain responsible for direct compliance with the applicable rules when using Microsoft technologies. Due to the many variances within customer environments, financial services firms themselves need to ensure all appropriate steps have been taken to meet the regulatory requirements, including using Microsoft’s online services appropriately and training employees to do the same.

Microsoft has published the blog, Office 365 SEC 17a-4 , which offers customer-ready information along with the capability to download our whitepaper.

The SEC 17a-4 requires the regulated entity to secure a secondary resource to provide the archived data to the SEC upon request, should the regulated entity not be able or willing to provide the data to the SEC directly. Microsoft will provide data to the SEC under the terms of the regulation for Office 365 customers who remain actively licensed for the service. Data for customers who exit the service will only be retained per the current data retention policies. Microsoft will attest to meeting SEC requests for data by providing customers with the required Letter of Undertaking, addressed to the SEC and referencing the regulated entity. This letter is described within the regulation, under section 17a-4(f)(3)(vii).

The SEC 17a-4 also requires the regulated entity to attest to the immutability, quality, formatting and indexing of the archived data. This requirement is referred to as Electronic Storage Medium (ESM) Representation under section 17a-4(f)(2)(i). Microsoft will attest to the ESM capability by providing customers with the required Letter of Attestation, Electronic Storage Media Services, addressed to the SEC and referencing the regulated entity.

Hopefully, this information helps you as you work to meet FINRA compliance requirements in your Office 365 tenant.

UPDATE: On January 28, 2019, Microsoft published an article describing how Exchange Online and the Security and Compliance Center can be used to comply with SEC Rule 17a-4.

The article includes a link to the Cohasset assessment, which, it is important to note, also contains information related to Skype for Business Online. The reason for this is that Skype for Business and Microsoft Teams store data in Exchange for the purposes of eDiscovery and data retention/archival.

I encourage you to read this article as well!

Use Exchange Online and the Security & Compliance Center to comply with SEC Rule 17a-4

Leverage the Microsoft Graph with Azure Active Directory Identity Protection to Identify Network Threats

Published on April 11, 2018 by Dave Branscome1 Comment

What is Azure Active Directory Identity Protection?

Azure Active Directory Identity Protection is a feature built into the Azure AD Premium P2 license. The P2 SKU is important if you want to configure SharePoint Limited Access, CAS Proxy, or perform actions related to identity protection or control of privileged identities. The Azure AD Premium P2 (AADP P2) licensing is included with the Enterprise Mobility & Security E5 license, but can be added on to other licensing, such as the EM&S E3 license.

What’s great about it is that it also allows you to use the Microsoft Graph to query your Azure AD tenant and identify potential threats to your organization and even configure an automated response to them. This post will show you how to find these sorts of events in your organization, with a very simple script.

It only takes about 5 minutes to set up, so let’s get started!

What Do I Need to Do This?

For the steps below, I’m using a trial tenant with Office 365 E5 and EM&S E5 licensing (which as mentioned above, includes the Azure AD Premium P2 licensing). This means I don’t have a fully-functioning Azure tenant, where I can set up virtual machines, web apps, containers and so on – but I have enough to do the steps below.

First, I log in to my Office 365 tenant and go to the Admin Centers and click on my Azure Active Directory admin center. I can, of course, just go to http://portal.azure.com and log in there, but this just helps illustrate the connection between the Office 365 tenant and Azure AD.

Click on the Azure Active Directory icon and see all the properties of the Azure Active Directory instance that underpins my Office 365 and EM&S tenant.

I click on App registrations, as shown below:

Click on New application registration

Now I fill in the properties for the new application registration.

The values below will work as shown.

Click Create when finished.

Click on the Settings gear as shown below:

One of the settings is Required permissions .

Click on the arrow to expand this property.

Next, click on Add to set up permissions for connecting to the Graph API.

You have the option of selecting which API you want to grant access to.

Click on the Select an API arrow.

You’ll now see a bunch of API’s that you can connect to.

For our purposes, we’ll choose the Microsoft Graph, which contains security event information.

Click Select at the bottom of that pane.

Now click on Select permissions.

In the Enable access page, scroll down till you see the Read all identity risk event information line.

Click the checkbox next to that line and then click Done.

You should see the Windows Graph in your Required permissions page.

Click on Grant permissions to apply the permissions you just selected.

When you click on Grant permissions, you’ll be asked for confirmation, so click Yes if you agree.

Back in the Settings page of your Application, click on Keys.

Configure an access key as shown below and click Save.

You should see the access key value in the field below.

Copy this key and save it somewhere. You’ll use it in the script as the $ClientSecret variable.

Back on the Properties of the application itself, you will also see the Application ID value.

Copy this value somewhere as well. This will be used in the script as the $ClientID variable.

Use a PowerShell script to connect to Microsoft Graph and Look for Identity Risk Events

The script below can be used to query the Microsoft Graph for identity risk events. You’ll need to fill in the following values:

$ClientID
$ClientSecret
$tenantdomain

For my script, it looked like the screen capture below.

I deleted the application after running the script so these credentials aren’t valid anymore.

Shown below is the sample script for querying the Microsoft Graph to capture identity risk events.

$ClientID       = "Application ID value from the Registered App properties page "       # Should be a ~36 hex character string; insert your info here
$ClientSecret   = "Password value from the Keys page" # Should be a ~44 character string; insert your info here
$tenantdomain   = "Tenant name"   # For example, contoso.onmicrosoft.com

$loginURL       = "https://login.microsoft.com"
$resource       = "https://graph.microsoft.com"
$body      = @{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}
$oauth     = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body $body
Write-Output $oauth
if ($oauth.access_token -ne $null) {
   $headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}
   $url = "https://graph.microsoft.com/beta/identityRiskEvents"
   Write-Output $url
   $myReport = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $url)
   foreach ($event in ($myReport.Content | ConvertFrom-Json).value) {
       Write-Output $event
   }
} else {
   Write-Host "ERROR: No Access Token"
}

Once you fill in the appropriate values for your environment, you can run the script in PowerShell and it will find any identity risk events associated with your tenant.

What Information Does It Provide?

In my tenant, it found one identity risk event, as shown below:

What this tells me is that on February 26, 2018 there was an AnonymousIPRiskEvent that took place using Allan DeYoung’s user account.

It looks like someone logged in with his credentials using a TOR browser, and it was classified as a medium risk event.

Additionally, I am able to see the location where this event took place and the IP address associated with it.

From there, I am able to start tracking down what happened and see if it poses any risk to my network or Allan’s account.

What other types of events would we be able to identify? Microsoft Graph contains identify events such as:

Impossible travel to atypical locations (Did you log in from New York and then 5 minutes later try to log in from an IP address in Indonesia?)
Sign-in events from unfamiliar locations (Is the location you are signing in from outside of your typical login patterns?)
Sign-ins from an infected device (Is the device where the login was attempted communicating with a botnet server?)
Sign-ins from IP addresses with suspicious activity (Maybe an IP address where a number of login attempts are taking place for lots of different accounts, which could indicate a brute force password attack)

We can categorize the risk events because the Microsoft Graph maintains information related to billions of login events each month. That means we can detect anomalies and determine whether they are just a user who forgot their password three times, or some sort of automated attack against that user’s account.

This is a very simple example, but you could configure something like this to run periodically and dump the events to a SIEM, allowing you to collect all your security related events in a single place and have them reviewed by your security team.

There are LOTS of other event types you can query on using the Microsoft Graph API (and the other application-specific API’s). I encourage anyone who manages the security for a network to take advantage of these API’s and create automated scripts that can capture risk events on your network.

Have fun with Microsoft Graph!

Killing Sessions to a Compromised Office 365 Account

Published on October 5, 2017December 31, 2018 by Dave Branscome1 Comment

David Branscome

Partner Technical Architect

We live in a world full of nasty threats to our online environments. One of your end users might click on a link that they shouldn’t and they get sent to a location where a piece of malware is installed on their machine and it captures their user credentials. In many cases, the goal of the attacker is to compromise a user account – ANY user account – and then move forward from there. Maybe their goal is to use that email account to send spam email or access organizational data for exfiltration. Or maybe the bad guy wants to have access to the environment so that he can gather confidential information and misuse it.

If an account in your Office 365 environment is compromised in this way, what can you do?

We have to recognize that there are two basic approaches to the problem:

Watch what the bad guy does so that you can take legal action against them

In this case, the actions we take will be done on the advice of the customer’s legal team and will be designed to establish a legal framework for prosecution. For example, there may be a scenario where an employee has been fired, but he knows the CEO’s password – maybe because the CEO left it on a sticky note on his monitor? Nah. That NEVER happens. The fired employee then decides to access the CEO’s mailbox for some nefarious purpose.

What can we do in this situation? Again, on the advice of the customer’s legal team, you may want to take steps such as the following:

Put the CEO’s mailbox on Litigation Hold so that the data in the mailbox is preserved in its entirety. https://technet.microsoft.com/en-us/library/dn743673(v=exchg.150).aspx
Configure Exchange Transport Rules so that all incoming as well as outgoing email is also forwarded to a second mailbox for preservation. https://technet.microsoft.com/en-us/library/jj919238(v=exchg.150).aspx
If the compromise is severe enough, it may be advisable to set up a new, temporary Office 365 tenant so that communications related to the legal case are handled out-of-band and cannot be seen by the bad actor. This tenant would be where the legal team, IT and the users whose accounts have been compromised can communicate without the risk of their email being read by the bad guy.

Kill the session to block access to all Office 365 resources

The thing to remember about this effort is that we have to do more than simply block access to the mailbox. The user’s identity can be leveraged across multiple Office 365 services, so we have to block access to all those additional services as well. The challenge is that, in order to improve performance, the services often will cache the credentials of the user for a period of time, which means that EVEN IF you change the user’s password, there will be a period of time when the bad actor can remain authenticated and do damage.

That means that we have to break the sessions that allow them to connect to any of the services. There are three ways we can accomplish this:

For the first method, we need to sign in to the Office 365 Admin portal. Then go to Users –> Active Users, and then select the account of the compromised user. Expand OneDrive Settings, go to the Sign-out area, and click on the Initiate link. Notice that this will sign out users from all Office 365 sessions across all devices, but it will still allow the user to sign in. That means the bad actor can immediately sign back in and go about his day. We’ll address password change in a moment.

When you click Initiate, the service begins killing the sessions for the user on all their devices.

At this point, it’s a good idea to also block further sign-ins for the user. Granted, it’s impactful, but so is having a compromised account.

To block sign in, from the properties of the compromised user account, go up to Sign-in status and edit the status.

Change the status of the account to “Sign In Blocked”

With the sign-in blocked, nobody (good or bad) can re-authenticate using that account until an administrator unblocks the account. When you click Save, notice the recommendation given.

This reminds us that another good idea is to change the user’s password.

The second method is specific to SharePoint and uses the SharePoint Online PowerShell Module, which can be downloaded here: https://www.microsoft.com/en-us/download/details.aspx?id=35588 . Once you have it installed and have connected to your tenant (Steps are here https://technet.microsoft.com/en-us/library/fp161372.aspx) run the Revoke-SPOUserSession cmdlet, as shown below.

The third method actually goes beyond just the Office 365 services and kills all active user sessions in any Azure AD application. To use this method, download the Azure AD PowerShell Module here (https://docs.microsoft.com/en-us/powershell/azure/active-directory/install-adv2?view=azureadps-2.0).

Once installed, connect to your Azure AD tenant and kill all sessions by using the Revoke-AzureADUserAllRefreshToken cmdlet, as shown below.

Changing the Password

All of this is great, but as we mentioned earlier, if we don’t change the user password, then all we’ve done is make the bad guy sign in again. This is where it can get kind of tricky, especially in a scenario where we have directory synchronization taking place between an on-premises environment and Azure AD.

Remember, it doesn’t do any good to just configure the user properties to have the user change their password at the next logon. The bad guy can try to login, get the prompt to change the password, and change it to whatever he or she wants to use!

If the password is being synchronized to Azure AD, you’ll need to use the Get-MSOLUser cmdlet to identify the LastDirSyncTime and LastPasswordChangeTimestamp value to ensure that the password change has also been synchronized to Azure AD. Make sure that, if the user changed their password in the on-premises directory, the password synchronization has taken place.

What Else Can I Do?

If none of these seem to have blocked access to the mailbox of the compromised user by the bad actor, one more thing you can do is perform a mailbox move. This would effectively break any current sessions the bad actor had open. If the password was changed and synchronized correctly, then the bad actor should not be able to log in again with the old credentials.

To move a mailbox in Office 365, use PowerShell to connect to Exchange Online using these steps: https://technet.microsoft.com/en-us/library/jj984289(v=exchg.160).aspx

Once you are connected, just run New-MoveRequest compromisedUser@contoso.com -PrimaryOnly.

Depending on the size of the mailbox, this could be fairly quick, but for very large mailboxes, it could take a couple hours to move.

One more thing! Don’t forget about mailbox delegates. If a bad actor granted Full Mailbox delegate access to another user, and the delegate user account was also compromised, then the bad actor would retain access to the original mailbox anyway! Therefore, make sure you check the mailboxes and accounts of any delegates of the compromised user so that you are removing all unwanted access to the original mailbox.

Conclusion

There aren’t many things as unnerving and disheartening to an IT admin as finding compromised accounts in your environment. When you find them, don’t panic!

Following a logical set of steps can help you clean up your environment and get things back to their natural order, where you sit back and collect accolades for a job well done, all day long!

“NOW it makes sense!” – Microsoft’s Collaboration Story in a Single Slide

Published on September 28, 2017 by Dave Branscome10 Comments

By David Branscome

Partner Technical Architect

Who knew PowerPoint would make my day today?

One simple, elegant, PowerPoint slide.

And just like that, the picture of Microsoft’s collaboration strategy became clear and explainable.

This is the slide I’m talking about.

The slide was part of the presentation given by Microsoft’s Office 365 Marketing Chief, Ron Markezich at Ignite this week, and it answered visually what has often been a very challenging question to answer from partners and customers – namely, “What Microsoft collaboration tool should I use for scenario X?”

The reason for the question is obvious. There’s an abundance of tools available for communicating with people inside and outside your organization – Yammer, Teams, Skype for Business, Outlook, Office365 Groups, SharePoint – never mind all the other options like public folders, email distribution lists, OneDrive, and so on. The problem has never been “Is there a tool that will allow me to share this content with somebody?”. Rather, the problem has been “How do I explain to my end users or my customers which tool is best suited for a particular task?”

There is a very well written, detailed whitepaper named ““When To Use What” in Office 365” that you can download here. http://www.2tolead.com/whitepaper-when-to-use-what-in-office-365/ It does a great job of laying out the many options and the specific scenarios where a given tool would be the optimal solution. But here’s the problem: it’s more than 60 pages long.

Anybody in IT knows that you will never be able to get an end user to read a 60-page whitepaper – no matter how well written – and synthesize the information from it. It just won’t happen. To be honest, most of us would be lucky to get the end users to read the email pointing them to the whitepaper.

But Ron Markezich’s slide is digestible. It’s something you could show to an end user and they would “get it”. They would understand when to use a given tool and know how to use it.

Breaking Down the Slide

The principles are simple:

Microsoft Teams is best suited for scenarios where you are working with a group of people on a given project. These are the people in your “Inner Loop” (or “Circle of Trust” as I prefer to call them). Because Microsoft Teams is built on Office 365 Groups, this group of people will have access to the SharePoint site created by default for each Team. That’s where I can share documents and files with the Team. If you’re a member of that Team – you have access. Since an Office 365 Group is also mail-enabled, I can send email to the Team channel so that everyone has access to the information in the email. Teams also incorporates all the features you love from Skype for Business – Instant Messaging, Presence, Conferencing, calling capabilities, etc… Teams keeps the conversations in a persistent, threaded format, so we can always go back and review questions that came up or decisions that were made. And with the recently announced Guest Access capabilities for Teams, you can extend the reach of your Team outside your organization. In effect, Microsoft Teams is a portal into Office 365.

Yammer expands the scope of who has access to a given set of content and the conversations. The people in your Yammer group are the “Outer Loop”. Sure, you still like and trust the people in your Outer Loop, but it’s a different type of interaction. Information and conversations flow much more organically and is likely not going to be project -specific. At Microsoft, our Yammer groups are more likely to be centered around certain technologies (such as Skype for Business Voice) or areas of expertise (“Security” or “Education”) than to be focused on a project (“Contoso Azure Deployment”). This allows for people to jump into Yammer groups at any time and still benefit from the historical knowledge of the Yammer group. And just like with Teams, new Yammer groups are built on Office 365 Groups, so the Yammer group has access to OneNote, a Planner for managing tasks, a SharePoint team site and document library.

And then there’s Outlook. Good old, reliable, “I know how to use this”, Outlook. We all know that Outlook is often the easiest tool for sharing a file….one time. But things start to get sticky when you have to ask multiple people to edit the document or comment on it. Then we run into versioning issues, and you have to find the right copy of the file in your email thread…it’s just not the best tool for really collaborative work on a large team. Rather, Outlook is good for targeted communications – confirming an appointment with a customer, verifying information in a proposal, asking your boss for days off (which is personally my favorite email to write). Now the neat thing is that Outlook also allows you to connect to the mailboxes for Office 365 Groups. This allows you to view and reply to email messages that land in the mailbox of the Office365 Groups you are a member of directly from your Outlook client.

Back to Reality

Now let’s be honest for a moment, shall we?

Even with a single PowerPoint slide, some of your end users are going to get confused about when to use which tool. There will be questions that still come up:

How many users can be in a Team vs a Yammer group?
Can I restrict channels within a Team to only certain members of the Team?
What’s the right way to remove someone from a Team or a Yammer group?
How do I manage compliance concerns with Yammer or Teams?
How do I manage communications over SO MANY individual Teams and Yammer feeds?

…and the list goes on.

Those are all valid questions and they’ll require some end user training and guidance. But the basic framework of how to select the right tool for the job is still the same. My suggestion would be to take that one slide and use it when training your end users. It gives them something that is simple enough to understand in just a few moments and points them in the right direction. They will always have questions – and that’s why a great adoption planning and training program is so important or any rollout of new technology. But with the right planning and the right tools at your disposal, you’ll be successful.

Who would have thought one PowerPoint slide could help you do all that?

Leveraging the Office 365 Service Assurance Portal in Customer Scenarios

Published on August 23, 2017 by Dave BranscomeLeave a comment

August 23, 2017
By David Branscome

In the partner organization at Microsoft, we get lots of requests from partners that are in the process of responding to an RFP for Office 365 or Azure deployments. Maybe the partner has described the Microsoft datacenters to their customers as being ISO 27001 or FedRAMP compliant. But now the customer has stated that they need to know how certain controls are implemented in Microsoft’s datacenters. In many cases, the customer is audited regularly, and they have to be able to provide evidence that their data is stored in a specific manner or that access is controlled in a specific way.

The problem is, getting access into the Microsoft datacenters is REALLY difficult. Most Microsoft employees haven’t even been in one of the cloud datacenters – including myself. (There’s a decent virtual tour here, but I’d sure like to see all the blinky lights someday.)

In any case, partners don’t have to get a datacenter tour to respond to these types of information requests from customers. The information is literally at their fingertips in the Office 365 portal – just go to the Security & Compliance section and on the left side, find the Service Assurance section.

Wait…I Don’t See it!

But wait a second.

This data isn’t available to everyone. So, a compliance officer with no special permissions in Office 365 would see something like this:

They don’t even see the Admin or Security & Compliance application icons – let alone the Service Assurance menu. Now what?

As you’d expect, not everyone with an account in Office 365 needs to see that organization’s security configuration. If there are some users who need to be able to access the Service Assurance Center, here’s how to grant those permissions:

Go to the Security and Compliance app and select Permissions.

In Permissions, check the box for Service Assurance User.

Select Edit role group and in the Members area, click on Edit.

Select Choose members to add the people who should have these permissions.

Click Add and then find the user.

Finish the wizard and you’ll see the user as a member of the Service Assurance User permissions group.

When the user logs in again, they will be able to go to https://protection.office.com and see the Service Assurance center:

Okay…Now What?

Now that you have the necessary permissions, you can start digging into the content in the Service Assurance center. You could start off by looking at all the controls and audited elements, but maybe you want to be more specific in your approach.

Let’s say you want to see how Office 365 meets ISO 27001 standards.

The first thing I’d recommend is to go to the Settings area and define the region whose controls are relevant – in this case, Europe. You’ll also need to select at least one of the industries whose regulations would be relevant to your search, then click Save.

As the green box indicates, you can now go into the Compliance Reports, Trust Documents and Audited Controls and review the content for the relevant region and industry. So, let’s take a look at what’s there.
If you look in the Compliance Reports area, you’ll see the listing of the certificates that Microsoft cloud datacenters have achieved, and you can click on and download the certificate itself.

For example, if I expand the ISO reports section and scroll down, I see a report named “Office 365 Germany ISO 27001 ISO 27017 and ISO 27018 Audit Assessment Report”. If I click on it, I can open the PDF file itself, which provides me with the final report stating that Office 365 meets the expectations for compliance.

But this only tells me if Microsoft complied with the controls or not. It doesn’t tell me what was actually tested as part of the process.

For that, I can go to the Audited Controls section, where I see the ISO 27018-2014 audit report and I can download it for review.

In this case, the report is an Excel spreadsheet which details things like the title of the control, the implementation and testing details, when it was tested and who performed the testing. This kind of information is generally enough for a customer’s audit team to be reassured of Microsoft’s compliance with the standard.
Don’t forget – if you want to change the scope of the controls (the region/country where the controls are relevant, which industry regulations apply, etc..) you can change the parameters in the Settings tab.

The Trusted Cloud

Microsoft is constantly working to achieve, maintain and even exceed compliance standards in order to secure customer data and make our cloud the most trusted one on the planet. The Service Assurance section of Office 365 is one evidence of that effort. Make sure to take advantage of it!
Additionally, check out the resources in the Microsoft Trust Center for information about GDPR, security, protection of user’s personally identifiable information and Microsoft’s commitment to providing customers with the controls necessary to secure their environment and user identities.

https://www.microsoft.com/en-us/trustcenter