Moving on to Conditional Access. This is the ability to set policies at a tenant level to review every authentication attempt that comes into your tenant and to see if it meets the criteria of that policy. It will make more sense for me to go through. I’ve split them out into policies we think can be done a lot quicker and increase your security massively without impacting users too much and then at the bottom we’ve got a few that might require a bit more planning to roll out.
Starting off, we’re going to start with something we’ve touched on before. Rather than relying on your administrators to manually enable MFA you can configure an additional aces policy that will make sure that anytime an admin authenticates or logs in to an account with any administrative role it would basically ask them to provide a second form of authentication. The beauty of conditional access is that it’s not manually enabled at a user level, it’s a tenant level so it will always apply. We would then recommend configuring that policy as outlined in the document we will send you as this will show you how to make these policies actually work in the portal. Every setting a policy needs to be set up is in the document we will send you so if you want to do any work yourself by all means use that document to do that. You can actually configure exceptions to make sure you don’t get logged out of your tenant. The policy will also allow you to configure exceptions, for this particular one to make sure you don’t get locked out your own tenant, we recommend creating some policies in your break glass accounts. We need to make sure break glass accounts have extremely complex passwords in place.
Second one, very similar so will touch on that quickly, it would force any connections to the Azure Management Console either through the web portal, powershell or through the command line or graph interface to also use MFA.
Third is to block legacy authentication so legacy authentication is allowed in the tenants and blocking that will hugely improve your security posture straight away. The Microsoft research on this shows that around 97% of breaches that happen are through the legacy authentication protocols. Also, tenants that have a block legacy authentication are 67% less likely to be breached. That’s huge numbers with a fairly small change.
If you do have a requirement for legacy authentication, again use exceptions so block legacy authentication for everything and then go through and allow the accounts you’d still need it to work for or even IP addresses if it’s a server. Again, in the document it will tell you how to do this in more detail.
Requiring MFA for guests and external users is really important. You have less control over guest users in terms of training them and you don’t know who’s passing credentials around outside of your organisation so ensuring MFA's for all guests and external users is a really handy policy to implement. Also, putting some terms of service in place so the first time a guest accesses your tenant they have to agree to your terms of use which is always useful in the event of a data breach.
So, that’s the sort of ones that we feel there is reasonable impact for. In terms of things that would need a little more planning, we’ve got a few more policies but they are still mandatory policies that we have in place for all of our customers.
What those are, the first one is approved apps on mobile devices. So, that’s basically apps that we have control over, so apps that are protected by application control policy which we’ll come to later on a mobile device which basically means that we can set some restrictions on those apps so we can say people can’t copy data from OneDrive on their phone to their Gmail or Google Drive, that sort of stuff. We can wipe those apps on those mobile devices as well so if people are using an app that we have the control over it won’t let them use the application basically.
The other policy we think you should put in place is MFA, so you can request MFA or block any non-compliant devices. We’ll touch on compliance a little bit later but what it basically means is you can set up compliance policies as an Endpoint Manager to assess your devices against your security baseline criteria which might mean the device has to be used in a certain patch level of windows, it might have to be bitlocker that sort of thing. If it meets those criteria and it's deemed compliant it will be allowed into your tenant without any MFA. If the device is not compliant because it doesn’t meet the criteria you set out we have two options. We can tell the policy to force the user to be MFA’d to make sure it really is them and not some brute force attack but some organisations opt for if it’s not one of our devices or a compliant device then we don’t want it in our tenant at all. It just depends on some of the information security policies of the particular organisation but one of those is definitely a good idea to put in place.
Require an exchange active sync police for mobile devices, it’s a secure protocol that makes sure that the exchange is using active sync and not some sort of third party apps to interface with the exchange.
The last one might be something that people aren’t fully aware of. There’s this security registration process which is effective if you;re using self-service password reset or multi-factor authentication, when a user first sets up those services they need to register other methods of authentication such as email or mobile number. They need to enrol into those services initially to provide that information. If you think about if you've set up a new user and they haven't logged in yet, somebody else or a brute force could technically enrol that user if they are in that account first so what you can do is secure that process and say that any sort of enrolment for MFA or self service password reset can only happen from a particular location in terms of IP address or you can provide the user a temporary password or code to do the enrolment first and only they would have that code. So that conditional access policy enforces that basically.
We’re just going to quickly show you the document now. You can see it's got a section on Conditional Access policies and it's got all of the recommended details to implement these policies so you can use the document to implement them if you wish to. So, this is a section of the document we’re going to send over to you, it's quite a big document but if you go here it's got the Conditional Access section and you can see here this document details exactly the policies we’ve been discussing there. All of the details here such as the assignments and access control are the exact options you'll see in the portal and you can use the document as a reference to get these policies up and running.
