The evolution of access control

Do you remember what it was like when everyone had desktop computers and data security focused on the best way to physically lock computers to heavy desks?

Many customers are asking us the question how they would be able to take control again of their “environment” where the environment now has become scattered amongst on-premise or outsourced resources, Cloud resources and Mobile devices.

In this blog post, we’ll review the ways security and access control have changed over the years, highlighting how Enterprise Mobility Management solutions (we’ll be showing you the  Microsoft Enterprise Mobility suite here) are poised to provide integrated solutions for the current world with mobile devices and online (Cloud) services.

We’re using the Microsoft Enterprise Mobility (EMS) solution as the explicit example here, because Microsoft has a different vision on how to solve these issues compared to other solution providers like MobileIron or Airwatch. The main and most important difference in vision between those providers, is the way they are handling the delivery of (mobile) applications and data. Where MobileIron and Airwatch (as an example, there are many other providers out there) are desperately trying to create “controlled bubbles”, the Microsoft vision is to use the native device and application experience, while protecting the access towards the application and the data. That’s a fundamental other way of taking care of the challenge here. It’s not that the “bubble” approach is wrong to begin with (even more, there are specific use cases to use the approach) but the end-user will lose the “native device experience” but even more the end-user will end up using the EMM solution provided mobile apps to replace the native apps…

bubble approach

Picture: showing the MobileIron “apps” with the “bubble” approach 

We’ve seen cases at customers where the “bubble” approach failed or at least was not that successful as end-users did not fully accepted the fact that they where losing the native device apps like Outlook mail of ActiveSync. Let’s not get going about the quality of those non-native EMM apps here but you’re able to imagine the challenges there for the EMM providers 😉

So what’s the vision of Microsoft here ? Well, Microsoft has of course the best interest in using their  applications but on the other hand they have a great bundle of solutions to their availability. But first, let us have a look in the way things have been changed the past years for now:

Mobile Access version 1: Mobile Laptops

In the past, corporate data was hosted on-premises. It was accessed by desktops that were physically connected to the corporate network. Then, laptops emerged as the dominant corporate device, and the Virtual Private Network (VPN) was born.
VPNs provided 3 primary functions:

1. They made it possible for laptops to reach corporate services on the Intranet
2. They restricted corporate access to Internet-connected laptops
3. They helped prevent data loss by encrypting communications and running agents on the laptops that helped contain data

Over time, VPN technology evolved. The criteria that could be used for access control (e.g. require the laptop to be domain-joined) expanded and the technology to prevent data loss matured.
Eventually, new types of VPNs such as SSL VPNs emerged. SSL VPNs enabled app-specific, as opposed to device-wide, access to corporate services from the Internet. This reduced the attack surface and also enabled new scenarios such as accessing corporate services from web browsers running on unmanaged devices.

Mobile Access version 2: Smart Mobile Devices

Later, when smart mobile devices arrived in the corporate computing landscape, they needed access to corporate resources, and VPN technology was the tool available to provide that. Mobile devices, primarily connected to the Internet, needed network reachability to corporate services. However, theses always-on devices brought many security concerns from their early general lack of IT controls. This drove demand for complementary technology to the VPNs which would help protect data.
All of this created an opportunity for integrated solutions based on Mobile VPN, Mobile Device Management (MDM), and Mobile Application Management (MAM). The management system would provision a VPN profile to a mobile device and thereby give it controlled access to corporate services on the Intranet. MDM and MAM features would help provide data protection on mobile devices analogously to the agents deployed by VPN clients on laptops.
Over time, Mobile VPNs emerged into per-app Mobile VPNs. The per-app variety provided similar benefits to mobile devices that SSL VPNs had provided to mobile laptops in the past. They reduced the attack surface and enabled new scenarios.

Mobile Access version 3: Identity-based Access Control and Data Protection

Now, we are in an era of mobile access where increasing amounts of corporate data lives outside of the network perimeter. Data still lives on corporate networks, but it’s also in cloud services, on mobile devices, and in mobile apps. Perhaps one day you won’t have any corporate data left on-premises, but the moment you start adopting cloud services you need to rethink the way access is controlled and data is protected.


Picture: showing that within the current world the apps, devices and resources are scattered

In the mobile-first, cloud-first world, a fundamentally different approach was needed, so we built access control and data protection directly into mobile devices, mobile apps, and the cloud infrastructure itself.  In this world your network perimeter is replaced by an “identity perimeter.”


Picture: showing that within the perimeter protection layers do not apply anymore

That’s what Microsoft has built with Office 365 and the Enterprise Mobility Suite, as a supplement to the classic VPN provisioning mechanisms that other  EMM providers like MobileIron or Airwatch have for on-premises apps. Microsoft EMS delivers integrated identity, access control, management, and data protection – built to protect your corporate data wherever it lives, using technologies like Device and Application Management, Information Right Management, Risk based contextual based authentication, Analytic Security Services and more.

With Microsoft EMS, whenever a mobile device or app attempts to authenticate to an online service (Microsoft or 3rd party) or on-premises web app, subjects the request to criteria you define, consulting with the management system as needed. Is the mobile device managed and compliant with your IT policies? Is the mobile app managed? Has the user presented multiple forms of authentication? Is the PC domain-joined and managed or controlled ? Is the request coming from the corporate network or the internet? All of these criteria and more are provided without the need for VPN. It’s just built-in the solution.
The diagram below shows how Microsoft EMS ensures that you have the access controls in the cloud needed to replace the access controls in your VPNs.


Picture: illustration of conditional access using Microsoft EMS

In addition to providing cloud access control, Microsoft EMS also provides native data protection. Again, this is based on identity and integrated with management.
Was a corporate identity used to access the data? If yes, then the mobile apps will prevent the data from being shared with consumer apps or services via Save-As, Open-In, clipboard, etc (Intune MAM with or without device enrollment into MDM). Is the document itself explicitly protected by an access policy (using IRM like Azure RMS)? If so, enforce access control on that file, even when it roams outside of apps and devices under management.

This integrated approach to data loss prevention enables the same application to isolate the corporate and personal data that it handles. This means your employees will not have to use separate apps for work. They can just use native or Office mobile apps for work and personal use and the right protections will apply at the right times. The diagram below shows this concept.


Picture: showing the Microsoft EMS approach to handle Data Loss Prevention

As mobile access evolves from VPN-based to identity-based, we foresee several benefits:

  • Cost savings compared to VPNs. VPN technology is typically expensive and complex. Deploying VPN agents, profiles, and certificates is also complex and expensive. As more and more of your data moves to the cloud, you’ll enable larger and larger populations of cloud-only users that don’t require a VPN and everything it carries.
  • Simpler access infrastructure to operate. Instead of operating a global scale network perimeter with various proxies, gateways, and VPNs, you just need to connect your existing on premise AD with the Azure Active Directory. From there, Office 365 and other SaaS apps will route their authentication through Azure AD and your modern access controls will be enforced.
  • Better end-user experiences. With EMS’s identity-based access control, your end users will not have to install and launch separate VPN apps. The access control experience is natively a part of the sign-in experience in the mobile apps. Since your traffic isn’t bounced from the Internet to the Intranet and back, your employees get better latency and performance in their mobile apps.
  • Positioned for the future. Once your basic cloud access infrastructure is in place, you have a solid foundation for future innovation. Because the capabilities are provided from the cloud, improvements come often and automatically. You don’t need to plan upgrades or migrations to start to take advantage of the latest and greatest. Compare this to your VPN infrastructure today and the tremendous amount of effort it takes to upgrade to the latest and greatest.

As Route443, we’re often working by the identity-based model for mobile access control and data protection, as it has our special interest we’re following any developments very closely. We see this development as one of the best things offered in the industry to help you provide great mobile experiences to your employees and in the most future-proofed way.

In the meantime, if you’d like to know more on how you are able to use this functionality within your corporate environment, please contact us and let us know how we can assist you.



Azure Active Directory Identity Protection

Hi folks,

Just recently,  Microsoft released their long awaited implementation of risk based authentication/authorization control. Personally, we’re very excited about this announcement. Hold your horses, as it’s still in public preview …. for now…

Let’s have a little background on the subject. What’s so interesting about this component and why should you be interested in it?

For starters, in the contemporary cloud, we’re relying on Identity & Access Management frameworks to provide our subscribers with secure and manageable paths to authentication and authorization of their resources. By secure we mean we are able to provide our subscribers with a corporate identity in the current framework, but there are limitations. For example, how are we to know if it’s really that subscriber using the resource at a given moment ? Sure, we know that the credentials are valid, but what if the account has been compromised? How does one tell? Cue Azure AD Identity Protection: a big step in the right direction for helping establish a risk posture and applying it during the authentication process, particular when combined with other mechanisms, such as Multi-Factor Authentication (MFA).. (something we’ll cover in a later blog post).

Azure Active Directory Identity Protection is a security service within Microsoft Azure that provides a consolidated view into risk events and potential vulnerabilities affecting the organization’s identities. Identity Protection leverages existing Azure AD’s anomaly detection capabilities (available through Azure AD’s Anomalous Activity Reports), and introduces new risk event types that can detect anomalies in real-time.

The vast majority of security breaches take place when attackers gain access to an environment by stealing a user’s identity. Attackers have become increasingly effective at leveraging third party breaches, and using sophisticated phishing attacks. Once an attacker gains access to even a low privileged user account, it is relatively straightforward for them to gain access to important company resources through lateral movements/traversal attacks. It is essential, therefore, to protect all identities and, when an identity is compromised, proactively prevent the compromised identity from being abused.

Discovering compromised identities is no easy task. Identity Protection uses adaptive machine learning algorithms and heuristics to detect anomalies and risk events that may indicate that an identity has been compromised.

Using this data, Identity Protection generates reports and alerts that enables the administrator to investigate these risk events and take appropriate remediation or mitigation action.

Azure Active Directory Identity Protection is more than simply a monitoring and reporting tool. Based on risk events, Identity Protection calculates a user risk level for each user, enabling the security professional to configure risk-based policies to automatically protect the identities of the organization. These risk-based policies, in addition to other conditional access controls provided by Azure Active Directory and EMS, can automatically block or offer adaptive remediation actions, including password resets and enforcement of multi-factor authentication.

Now, let’s have a look at the delivered functionality here.

In the reporting module of the Azure Active Directory Identity Protection service, we’re now able to view some important security related events within our environment (tenant):

Detecting risk events and risky accounts:

  • Detecting 6 risk event types using machine learning and heuristic rules
  • Calculating user risk levels
  • Providing custom recommendations to improve overall security posture by highlighting vulnerabilities

Investigating risk events:

  • Sending notifications for risk events
  • Investigating risk events using relevant and contextual information
  • Providing basic workflows to track investigations
  • Providing easy access to remediation actions such as password reset

Very useful additions for incident and event management. The real-time evaluation and mitigation are also very interesting.

Risk-based conditional access policies:

  • Policy to mitigate perceived “risky” sign-ins by blocking sign-ins or requiring multi-factor authentication challenges.
  • Policy to block or secure “risky” user accounts
  • Policy to require users to register for multi-factor authentication

Risk level, determining the authentication context

The Risk level for a risk event is an indication (High, Medium, or Low) of the severity of the risk event. The risk level helps Identity Protection users prioritize the actions they must take to reduce the risk to their organization. The severity of the risk event represents the strength of the signal as a predictor of identity compromise, combined with the amount of noise that it typically introduces.

  • High: High confidence and high severity risk event. These events are strong indicators that the user’s identity has been compromised, and any user accounts impacted should be remediated immediately.
  • Medium: High severity, but lower confidence risk event, or vice versa. These events are potentially risky, and any user accounts impacted should be remediated.
  • Low: Low confidence and low severity risk event. This event may not require an immediate action, but when combined with other risk events, may provide a strong indication that the identity is compromised

Risk levels
Given we’re able to classify the risk level of any authentication attempt, using the classification within the context of the authentication process, we still need to look at how the information is collected.  Let’s have a look under the hood of the Azure Active Directory Identity Protection service a little further…

Leaked credentials

Leaked credentials are found posted publicly in the dark web by Microsoft security researchers. These credentials are usually found in plain text. They are checked against Azure AD credentials, and if there is a match, they are reported as “Leaked credentials” in Identity Protection. Leaked credentials risk events are classified as a “High” severity risk event, because they provide a clear indication that the user name and password are available to an attacker.

Impossible travel to atypical locations

This risk event type identifies two sign-ins originating from geographically distant locations, where at least one of the locations may also be atypical for the user, given past behavior. In addition, the time between the two sign-ins is shorter than the time it would have taken the user to travel from the first location to the second, indicating that a different user is using the same credentials.

This machine learning algorithm ignores obvious “false positives” contributing to the impossible travel condition, such as VPNs and locations regularly used by other users in the organization. The system has an initial learning period of 14 days during which it learns a new user’s sign-in behavior.

Impossible travel is usually a good indicator that a hacker was able to successfully sign-in. However, false-positives may occur when a user is traveling using a new device or using a VPN that is typically not used by other users in the organization. Another source of false-positives is applications that incorrectly pass server IPs as client IPs, which may purport sign-ins taking place from the data center where that application’s back-end is hosted (often these are Microsoft datacenters, which may give the appearance of sign-ins taking place from Microsoft owned IP addresses). As a result of these false-positives, the risk level for this risk event is “Medium”.

s from infected devices

This risk event type identifies sign-ins from devices infected with malware, that are known to actively communicate with a bot server. This is determined by correlating IP addresses of the user’s device against IP addresses that were in contact with a bot server. Be aware; this risk event identifies IP addresses, not user devices ! If several devices are behind a single IP address, and only some are controlled by a bot network, sign-ins from other devices my trigger this event unnecessarily, which is the reason for classifying this risk event as “Low”.

s from anonymous IP addresses

This risk event type identifies users who have successfully signed in from an IP address that has been identified as an anonymous proxy IP address. These proxies are used by people who want to hide their device’s IP address, and may be used for malicious intent. The risk level for this risk event type is “Medium” because in itself an anonymous IP is not a strong indication of an account compromise.

s from IP addresses with suspicious activity

This risk event type identifies IP addresses from which a high number of failed sign-in attempts were seen, across multiple user accounts, over a short period of time. This matches traffic patterns of IP addresses used by attackers, and is a strong indicator that accounts are either already or are about to be compromised. This is a machine learning algorithm that ignores obvious “false-positives“, such as IP addresses that are regularly used by other users in the organization. The system has an initial learning period of 14 days where it learns the sign-in behavior of a new user and new tenant.

The risk level for this event type is “Medium” because several devices may be behind the same IP address, while only some may be responsible for the suspicious activity.

from unfamiliar locations

This risk event type is a real-time sign-in evaluation mechanism that considers past sign-in locations (IP, Latitude / Longitude) to determine new / unfamiliar locations. The system stores information about previous locations used by a user, and considers these “familiar” locations. The risk even is triggered when the sign-in occurs from a location that’s not already in the list of familiar locations. The system has an initial learning period of 14 days, during which it does not flag any new locations as unfamiliar locations. The system also ignores sign-ins from familiar devices, and locations that are geographically close to a familiar location.

Unfamiliar locations can provide a strong indication that an attacker is able attempting to use a stolen identity. False-positives may occur when a user is traveling, trying out a new device or uses a new VPN. As a result of these false positives, the risk level for this event type is “Medium”.

There’s a nice looking management style console as a collation point for gathering all events, but the real ingredients or “special sauce” lie beneath 🙂


We’re still some steps away from the desired end-state, where we’re able to influence or even determine the level of authorization next to the level of authentication, but let’s not be too pessimistic 🙂  This is really a big step forward as a building block within the (Microsoft) Access Management framework!

In the meantime, if you’d like to know more on how you are able to use this functionality within your corporate environment, please contact us and let us know how we can assist you.