It’s really not the first time that you see this feature, EMS Conditional Access, in this blog. Just try to make a search, just like this: http://systemplus.gr/?s=conditional+access and you’ll get a lot of related information.
So as you can see, we need to find a way to protect our corporate data, while allowing our users to be productive, just using any device, giving them the best possible experience.
We should now start exploring what we can do using conditional parameters at the application, user or location layer. Take a moment to take a look at the following diagram:
How to protect data using the Application layer in EMS
Some of your cloud applications might contain sensitive information, and you should consider control access. As you can see on the right side of the picture above, you could create policies that can ask for Multi-Factor Authentication, depending on the location it’s being accessed from. These policies can be applied to any cloud (SaaS) or on-premises app protected by Azure Active Directory, including their rich, mobile or browser-based clients.
User layer conditional access
That’s probably the easy part, because if you use Azure AD Premium as your identity management mechanism, you already know that you can specify to which users or groups these conditional access policies should apply. You can assign multiple conditions at the location, application or device information levels to users or multiple groups, You can also create exclusions.
Location layer conditional access
Just define a set of trusted IPs, but also define what will happen when the user tries to access an application from an unknown location, for example you could ask for MFA.
Let’s see a common scenario that implements all the previous topics:
But what about devices?
You need device compliance, just to make sure that you allow only managed and compatible devices to access your data-sensitive applications. This can be done by using Device compliance policies to enforce device compliance requirements. Some of these could be device enrollment, domain join, passwords and encryption, but also the OS that runs on devices.
You can use compliance policy settings in Microsoft Intune to create a set of rules for and to evaluate the compliance of employee devices. When devices don’t meet the conditions set in the policies, the end user is guided though the process of enrolling the device and fixing the issue that prevents the device from being compliant.
In this scenario, when you use a conditional access policy in combination with a device compliance policy, only users with compliant devices—in addition to any other rules you’ve set—will be allowed to access the service.
This is how it works:
Microsoft recently partnered with Lookout, and this integration can give you all the information that you need, related to mobile device risks, including advanced mobile threats and app data leakage. If a device is found to be not compliant due to a mobile risk identified by Lookout, access is blocked and the user is prompted to resolve the issue with one-step guidance from Lookout before they can regain access. Note that Lookout licenses must be purchased separately from EMS:
But the same policies can be applied to on-premises apps also. Microsoft has now partnerships with popular network access providers such as Cisco ISE, Aruba ClearPass, and Citrix NetScaler. Now you can extend your Intune conditional access capabilities to work with these networks. Every time that a user tries to access an on-premises application, additional checks can be made for Intune-managed and compliant devices before allowing user access through these devices.
It’s also important to take into consideration some additional threats and risks, so we can use….
Risk-based conditional access
Today’s threats are really sophisticated, but the good thing is that after every attack we know that there is a pattern that fortunately can be analyzed. Every month Microsoft updates more than 1 billion PCs, services more than 450 billion authentications, and analyzes more than 200 billion emails for malware and malicious websites. They gather information about every kind of attack there is, and they push the data directly into the Microsoft Intelligent Security Graph.
So now that we have the data, we can use it as part of a conditional access policy we create. It’s important to know that in many cases these risks are automatically recognized by Microsoft, and when they are detected they could block user access.
The same happens when they detect the possibility of leaked credentials. Microsoft security researchers search for credentials that have been posted on the dark web, which usually appear in plain text. Machine learning algorithms compare these credentials with Azure Active Directory credentials and report any match as “leaked credentials.”
Can you travel from Europe to the US in just an hour? Probably not. So when two sign-ins originate from different geographic locations within a window of time too short to accommodate travel from one to the other, it’s probably an indication of someone else that used your credentials to sign-in.
Infected devices
The Microsoft Intelligent Security Graph maintains a list of IP addresses known to have been in contact with a bot server. Devices that attempt to contact resources from these IP addresses are possibly infected with malware and are therefore flagged.
Anonymous IP addresses
Why should you hide your IP address? Probably because you want to perform some malicious activities. In this scenario, a risk-based conditional access policy can require MFA as additional proof of identity.
IP addresses with suspicious activity
Multiple failed sign-in attempts that occur over a short period of time, across multiple user accounts, and that originate from a single IP address, also trigger a risk event. This scenario can be analyzed and enforce the correct conditional access policy if required.
To get a full picture of conditional access from EMS, you can download this white paper with a lot of additional information, so please cheek it out.
Thanks for your time!
