This is part of a series of articles about email security in Microsoft 365. Please check out previous articles here:
These articles are based on a model I have previously created, which you can read about here:
designed to help better explain expansive security included with Microsoft 365.
In the previous part we had arrived at the stage where the user had successfully logged into a Windows 10 device.
At this point, the user is most likely to launch Outlook to read their emails. Visually the process is going to look like:
The email has been delivered from outside the Microsoft 365 Service to the Data container. The User has authenticated themselves via various methods to the Device container. An App on the device will now apply the User authentication to allow the App access to Data container to retrieve the email so it can be displayed to the User.
The focus for this articles will be the access of the App (Outlook) to the email Data as mentioned.
When it comes to the security of this interaction the place to start is to ensure that the App (Outlook) is supported and up to date. The first thing to check is:
and make sure that it is supported by the Service:
Given that most Microsoft 365 plans come with a subscription to Office on the desktop, the assumption here is that it is fact supported. There are various ways to:
but for simplicity the assumption will be that it is installed and maintained using:
It is obviously very important to ensure that all applications that access secure data are updated regularly.
The assumption will be that, via whatever method, the Microsoft Office desktop application are indeed up to date.
When the Outlook app runs, it will do so on the device, which will be typically connected to the public Internet. this means it is going to need top copy data from the secure Data container in the above model to the secure Device container which lives in another location.
Transferring secure data across an insecure medium like the Internet involves a lot of technology. A lot of them you can read here:
however the most relevant is probably:
Once the email data has traversed from the Data container in Microsoft 365 to Outlook on the user Device is typically stored in an OST file on the local machine.
This OST data file is not itself encrypted but the location in which it resides on the device is encrypted using BitLocker.
Outlook incorporates a number of in-built security features including:
Emails in Outlook will also be protected by Defender for Office 365:
Yet another layer of protection will be:
including technologies like Attack Surface Reduction (ASR) which I have detailed previously:
Further data protection can then be provided by Windows Information Protection (WIP) per:
“Windows Information Protection (WIP), previously known as enterprise data protection (EDP), helps to protect against this potential data leakage without otherwise interfering with the employee experience. WIP also helps to protect enterprise apps and data against accidental data leak on enterprise-owned devices and personal devices that employees bring to work without requiring changes to your environment or other apps.”
For example, if WIP was implemented, it would prevent user saving corporate attachment to non-compliant devices. Perhaps like a USB key.
Further still there is:
which protects information no matter where it travels.
So even when a copy of the email is sitting in Outlook on the desktop it is and can be protected by a wide variety of technologies in Microsoft 365.
If we now take a step back and have a look at a summary of many of the protections we have been talking about so far we would see something like shown above. Remember here that all we have focused so far on is email! Many of these protections will in fact protect information as well as the protection it provides for email. The take away is, in a nutshell, there is a lot of stuff protecting user data provided by Microsoft 365.
Although there is a lot of protection capabilities in Microsoft 365, many of the protection services are either not enabled by default, require unique policies or have generic policies. It is important for each organisation to evaluate what their security requirements are (i.e. what they want to protect) and then implement the services available to them in Microsoft 365 to meet these requirements. The take away is, if you want all the protection features available in you need to configure them, they don’t all magically work to your requirements out of the box!
Also, simply enabling or configuring all these services is something that will need to be continually reviewed and adjusted over time. We’ll also cover that topic in some details in upcoming articles.
Now you can enable all these services and make everything super secure but doesn’t provide absolute security, because that simply doesn’t exist. It will certainly mitigate the majority of threats out there but it still means that the whole environment needs to be monitored constantly to ensure nothing is getting through. Remember, every time we cross a container boundary above, logs are generated. Where and how to use these logs will be the subject of the next part in this series, so stay tuned.