Exchange Online Security and Compliance 101 (Part 2)

by [Published on 15 Nov. 2016 / Last Updated on 15 Nov. 2016]

In this article I will dive further into the Exchange Online security and compliance aspects on the physical, logical and data layers.

If you would like to be notified when Henrik Walther releases the next part in this article series please sign up to our MSExchange.org Real-Time Article Newsletter.

If you would like to read the first part in this article series please go to Exchange Online Security and Compliance 101 (Part 1).

Introduction

In part 1 of this article series revolving around “out of the box” Exchange Online security, compliance and privacy, and what you can do to improve things from your side, I explained why EXO is a good choice for companies that must adhere to very strict security and compliance policies. I also talked about what Microsoft does in order to provide word class security and compliance at the service-level.

In this part 2, we will continue where we left off in part 1. Let’s get going.

The Three Layers of Security

So what would security be if it wasn’t implemented at all the necessary layers (and the different layers within each layer) in the stack? True. Not very good and an extremely poor match for a cloud service such as Exchange Online.

Facility Security Layer

Let’s start with the physical datacenters themselves. Microsoft has +100 globally distributed datacenters of which many have the EXO service deployed that has been built from the ground up to not only protect customers against cyber threats, but also natural disasters and any unauthorized access. The facilities are guarded 24/7-365 by on-premise security officers that have been through rigorous background checks prior to taking on the role of guarding the facilities. Very few people are allowed into the facilities themselves.

The datacenters are of course not only protected by security officers, but also state of the art security equipment such as video surveillance, motion sensors, and security breach alarms. Personnel that are allowed into the datacenters need to use smart cards with multi-factor authentication as well as go through biometric scanner checks just like you have seen in the movies.

To protect against natural disasters such as earthquakes or heavy vibrations caused by bombs, all servers are mounted in seismically braced racks. In case of fire, there is an automated fire prevention and extinguishing system in place. If the impact destroys a datacenter, the respective service is not only highly available but also site resilient meaning that a fail or switch over to another datacenter can be performed to keep the service running and accessible by customers. For EXO, this is achieved using database availability groups and multiple database copies (of which one is a lagged copy).

Network Security Layer

You can protect the datacenters in which the EXO service is running as much as you like at the physical facility layer, but if the network isn’t secure, it doesn’t matter.

Network security in the Microsoft datacenters follows a basic principle which is to only allow connections as well as communications between systems that require it to operate properly. All other connections, ports and protocols are blocked.The respective networks within the Microsoft datacenters are segmented to separate back-end servers and storage devices from public facing interfaces. Also, all network devices, IPSec policies and firewalls are protected using Access Control Lists (ACLs).

The routers on the edge network can detect intrusion and signs of vulnerability at the network layer. If suspicious activity occurs, this is alerted immediately so the operations teams can act accordingly.

Logical & Data Security Layer

As I mentioned back in part 1 of this article series, there are many controls and processes in place to avoid inconsistent configurations and malicious activity occurring on the hosts themselves and within applications. In addition, any operations that can be automated will be or are in the process of being automated to prevent against human errors.

The operations personnel have been through stringent background checks and as also mentioned previously have no standing access as they are added and removed from the role based access control groups based on the task or case they are working on. To get the requested access, they need to go through a lockbox process where relevant persons must accept the requests. If customers have the required subscription and enable the customer lockbox feature, this can also involve the customer tenant and/or data the engineer needs to work with.

All access that is given to an engineer and all actions taken by the engineer are audited.

The Exchange Online (and all other Office 365 workloads) are protected using anti-malware software that detects and prevents the introduction of viruses and worms into the hosts and applications. Should a system be infected it will be quarantined immediately to protect other systems from being damaged by the malware or virus.

All standard baseline configuration for servers, network devices and applications are documented as required. Updates, hotfixes and patches applied in production follows the same change management process. Any changes are taken through a strict review and evaluation process by the review teams and the change advisory board.

At the data layer, customer’s share the same hardware and software as other customers. When it comes to EXO, this means different customers have mailboxes on the same Exchange servers and even in the same mailbox databases. This is the whole idea behind a multi-tenant service. Customer data is instead secured via data isolation based security boundaries provided by Azure Active Directory segregation.

No matter the workload, all data at rest and in transit is encrypted. For EXO, the mailbox databases are stored on bitlocker encrypted disks (volume level encryption), and any data in transit is protected using SSL and/or TLS depending on the protocol and involved partners.

This concludes part 2 of this multi-part article series. In the next part, we will talk more about the compliance and privacy aspects of the EXO service.

If you would like to be notified when Henrik Walther releases the next part in this article series please sign up to our MSExchange.org Real-Time Article Newsletter.

If you would like to read the first part in this article series please go to Exchange Online Security and Compliance 101 (Part 1).

See Also


The Author — Henrik Walther

Henrik Walther avatar

Henrik Walther is a respected writer with special focus on Microsoft Exchange and Office 365 solutions. He works as a Principal Architect/Consultant on engagements of all sizes and complexity and have close to two decades of experience in the IT business.