Identity thefts have been the hot topic in Microsoft 365 services during the end half of the year 2018. We have seen many customers affected with identity breaching. Here is an overview on how these breaches happen, why you need to protect your indetities and principles on how to do it. If you want to get into the technical details on how to configure strong Conditional Access policies go and check my fellow bloggerz Joni´s blog post.
Lets begin by taking a look at the most common threats we and our customers have been facing regarding the Office 365 services
Without digging too deep in the detail I think you all are familiar to at least some of these categories or threats. Now fortunately for us Microsoft has some good tools and features for protecting against these threats.
Bloggerz.cloud will be introducing you to all of these features and giving best practices on how to implement these. In this blog we will concentrate to the very first bullet up top called Conditional Access including Multi Factor Authentication.
First of all, lets take a look at one common way to steal identities from end users, the Phishing email:
So thats how it works and how it has worked multiple times during the last six months believe it or not. Now some may think that these Phishing messages are easily prevented by tightening email protection policies or configurations. While that may even work for some scenarios it definitely is not a long term solution. Phishing messages develop all the time and eventually they will breach even the toughest email protections. Also keep in mind that there are other ways to steal identites as well.
So the bottom line here is that you really need to pay attention to protecting the identities. And this is where Conditional Access comes in to play. And when we say Conditional Access we mean Conditional Access, not just the MFA (Multi Factor Authentication) that you can easily enable for users in Office 365 / Azure AD.
With Azure AD Conditional Access you can configure policies to meet end user scenarios that you want to protect. Policies consist of Conditions and Actions based on them.
So instead of just enabling MFA you should probably think about conditional access as a whole. One of the most useful benefits of Conditional Access is to recognize if the device is trusted or not and then base the rules according to that. Also with Conditional Access you can totally block some scenarios like for example client use from non-trusted device. With MFA there is no way to achieve this. The reason you want to block client use is because clients tend to create the local copy of the data. So you probably don´t want your users to configure Outlook clients on their personal laptops at home for example. With Conditional Access Policies you can easily prevent that.
If we look at the above Windows workstation scenario as a flowchart from the end users point of view it would look like this
So when user requests access from workstation the first thing that is checked is obviously Authentication. If that passes then the next step is to determine if the device is trusted or not. If it is trusted then access will be granted regardless of the network location or client application that is used. This would be the use scenario for most of your end users with their work laptops. Basically invisible to end users.
The fun begins when non-trusted device such as home laptop, public computer or whatever device the bad guys use, is used. When device is not trusted we want to check if access is requested from client application or web browser. If client is used we will block it totally. We don´t even challenge for the MFA, we just block it. If the browser is used we give the option to access with MFA. So users will be able to access their email using Outlook for Web (or OWA) and also able to access Teams and Onedrive with web client. As long as they pass the MFA challenge.
Nice and effective. If only it was that simple. Unfortunately we have this monster called the legacy authentication that is able to bypass our Conditional Access and MFA policies.
Again fortunately for us it is possible to block legacy authentication altogether with Azure AD Conditional Access policies. Resulting in a final Conditional Access flowchart that would look like this for workstations:
And like this for mobile devices:
Implementing these policies with legacy auhentication block is straightforward, but requires careful consideration and testing of the effects. Here are some of the notifications you should consider when planning conditional access policies with Legacy authentication block
As a summary I have gathered some notes from our customers regarding Conditional Access. For the purpose of educating I chose five common misunderstandings to help you challenge your way of thinking
I hope that by reading this blog you have gotten the idea rather clear, but to summarize and correct these common misunderstandings
- All end user identities should be protected as they all have access to the same system and can be used to cause harm
- Tightening spam filtering is not a viable long term solutions and can probably cause some issues with false events. Also there are other ways to steal identities than email Phishing
- Conditional Access when configured properly is actually very user friendly. In most cases even invisible
- MFA is a good start, but it does not provide enough protection to nowadays threats. You cant block access scenarios with MFA and to be honest MFA can be a bit non-user friendly at times.
- Even if your own users use the modern clients you need to keep in mind that you are not protecting your systems and identities from them. You are protecting it from the bad guys. And you can be sure they use all the possible holes including legacy authentication
For more information about how to actually implement these Conditional Access policies with Azure AD Conditional Access please check Joni´s blog post
0 Comments