This is part of a series of articles about email security in Microsoft 365. Please check out previous articles here:
End to End email protection with Microsoft 365 – Part 1
End to End email protection with Microsoft 365 – Part 2
End to End email protection with Microsoft 365 – Part 3
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 previous parts, we covered how an external email was delivered into the Microsoft 365 service and all the protections that it passed through until it finally came to rest in the Data container (user’s inbox) ready to be viewed. The next step in the process will therefore for the user to fire up their device to read the email. This article will therefore focus on the protections available for that device.
For the sake of simplicity we’ll focus on that being a modern device running at least a Windows 10 Professional. Of course, email from Microsoft 365 can be viewed on just about any devices these days, Windows or not, and all of these have unique and overlapping protections. However for the sake of brevity let’s just focus on the more common Windows 10 device for now.
A range of hardware device protection is available and recommended including:
- Trusted Platform Module (TPM) 2.0
- BitLocker Drive Encryption
- UEFI Secure Boot
- Drivers and Firmware Distributed through Windows Update
- Virtualization and HVCI Enabled
- Drivers and Apps HVCI-Ready
- Windows Hello
- DMA I/O Protection
- System Guard
- Modern Standby
and should already be in place to protect the device.
We will also assume that the Windows device is fully up to date
How to keep your Windows computer up to date
The device in question should also already live inside the Device container as shown in the above model. This is largely achieved thanks to being joined to Azure Active Directory (AD):
Join your work device to your organization’s network
Tutorial: Join a new Windows 10 device with Azure AD during a first run
When that device is turned on we want it to complete the:
Once the machine has booted and before the user has logged into the machine, thanks to being Azure AD joined, Microsoft Endpoint device policies have already been pushed and implemented on that machine per:
Manage device security with endpoint security policies in Microsoft Intune
Such policies could be enforcing disk encryption, implementing Attack Surface Reduction (ASR) and so on.
Importantly, you can also enforce device compliance policies to ensure devices meet a security standard before they are allowed to access any data:
Use compliance policies to set rules for devices you manage
All of this is achieved via:
which I have also written a whole series of articles to help provide a better understanding of the role that it plays with device security. You can read these articles here:
Modern Device Management with Microsoft 365 Business Premium–Part 1 of 10
Assuming that the device has booted and successfully completed all the protection processes associated with that have been correctly applied, it is now time for the user to login to that devices. This means that we now follow the User connector in our model shown above, into the Service container from outside, then onto the Device Container and so on.
The user’s identity is protected inside the Microsoft 365 service via a variety of mechanisms. When logging into a Windows 10 device they will typically need to provide their account and password details that were set up with the service. However, best practice would now be to use Windows Hello for Business.
Windows Hello for Business Overview
Windows Hello addresses the following problems with passwords:
- Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites.
- Server breaches can expose symmetric network credentials (passwords).
- Passwords are subject to replay attacks.
- Users can inadvertently expose their passwords due to phishing attacks.
Many mistakenly believe that the Windows Hello PIN is all that protects a users access to device and the service when at login. That is in fact not the case as Windows Hello leverages the TPM hardware to provide a highly secure login to the service.
Why a PIN is better than a password
How Windows Hello for Business works
These days just a login and password are not enough to secure any identity, you MUST implement Multi Factor Authentication (MFA). Why? As Microsoft will tell you:
Your password doesn’t matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.
All your creds are belong to us!
So MFA, along with a number of other recommended steps, are what can be done with Microsoft 365 to protect user identity.
Five steps to securing your identity infrastructure
Windows Hello for Business requires all users perform multi-factor authentication prior to creating and registering a Windows Hello for Business credential. Importantly, Windows Hello for Business replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN. Many don’t appreciate that correctly configured Windows Hello for Business DOES provides MFA when users access their devices, while making the device login process seamless. If you are however still concerned about this ‘single credential’ being compromised then you can also implement:
It is also important to remember that MFA is provided FREE on all Microsoft 365 accounts and support a variety of methods including authenticator apps, hardware token and more.
Enable multi-factor authentication for free
Once the user has correctly provides a login and password, then completed their MFA challenged (or equivalent thanks to Windows Hello for Business) they would then be subject to Azure AD Conditional Access.
It is important to remember that Azure AD Conditional Access is evaluated AFTER a successful login from a user, not before! This means that it can’t be used to block things like Password Spray Attacks.
Conditional Access policies at their simplest are if-then statements, if a user wants to access a resource, then they must complete an action.
For example, user account access can be blocked if it comes from outside a specific country or region.
Conditional Access: Block access by location
and enforcing MFA
Conditional Access: Require MFA for all users
Conditional Access: Require MFA for administrators
Once any Conditional Access policies have been met the user will be able to login to their device. At this point additional Microsoft Endpoint Manager policies will be applied to that specific account now logged in. Such policies could restrict applications the user has access to, limit Windows functionality and so on.
Remember, all of these protections have taken only during the user has logging onto their device. They have not as yet run an application like Outlook to read the inbound emails. That is what is going to happen next and I’ll cover that process in the next part of the series, so stay tuned.
CIAOPS 