Author: Goce Argirov, Microsoft Certified Trainer | Consultant | Solution Architect | Azure Infrastructure and Security at Semos Education

 

Azure AD at the heart of your Zero Trust strategy

Long gone are the days when the security was focused on a strong perimeter defence to keep malicious hackers out. Anything outside the perimeter was treated as hostile, whereas inside the wall, an organization’s systems were trusted.

Today’s security posture is to assume breach, a mindset that guides security investments, design decisions, and operational security practices. In its essence, assumed breach guides you to think differently, to change your mindset: you are already breached, or you will be- there is no other outcome.

In 2012 during an interview former director of the CIA and National Security Agency Retired Gen stated: “Fundamentally, if somebody wants to get in, they’re getting in. Alright, good. Accept that.”

During that time, many people didn’t quite understand what he really meant, but this sentence is the core of the assume breach approach.

Data breaches can cause devastating financial losses and affect an organization’s reputation for years. From lost business to regulatory fines and remediation costs, data breaches have far-reaching consequences. The 2019 Data Breach Study, conducted by Ponemon Institute sponsored by IBM, found that the global average cost of a data breach for the 2019 study is $3.92 million, a 1.5 percent increase from the 2018 study.

Having all this in mind, you probably say: ok, what now? From my point of view, implementing Zero Trust Architecture is the next thing to aim for!

No matter which security expert you ask regarding the “zero-trust model” they will all agree that this is the best way to stop data breaches and streamline the path to compliance in your organization. “Never trust, always verify” Zero Trust helps secure corporate resources by eliminating unknown and unmanaged devices and limiting lateral movement.

In 2010 John Kindervag, principal analyst at Forrester Research, created the Zero Trust model. This model states that you should never assume trust but instead continually validate trust. When users, devices, and data all resided inside the organization’s firewall, they were assumed to be trusted. This assumed trust allowed for easy lateral movement after a malicious hacker compromised an endpoint device.

Implementing a true Zero Trust model or Zero Trust Architecture requires that all components—user identity, device, network, and applications—be validated and proven trustworthy. Zero Trust verifies identity and device health before granting access to corporate resources. When access is granted, applying the least-privilege principle limits user access to only those resources that are explicitly authorized for each user, thus reducing the risk of lateral movement within the environment. In an ideal Zero Trust environment, the following four elements are necessary:

• Strong identity authentication everywhere (user verification via authentication)
• Devices are enrolled in device management and their health is validated
• Least-privilege user rights (access is limited to only what is needed)
• The health of services is verified (future goal)

Implementing a Zero Trust Security model

Migrating to a Zero Trust security model provides simultaneous improvement of security over conventional network-based approaches, and better enable users where they need access. A Zero Trust model requires signals to inform decisions, policies to make access decisions, and enforcement capabilities to implement those decisions effectively.

Conditional access in Azure AD at the heart of the strategy

In today’s work environment, we have seen that users can work on any device, whether using a laptop provided by the organization or using a personal smartphone and from any location, working from home, at the office or on the move. Employees expect to have seamless access to what they need to do their job. While the need for productivity does not change with circumstances of access, the level of risk of each connection does evolve. Not all devices, applications, or networks are secure, and attackers are likely to exploit any vulnerabilities that will give them access to your users and/or resources. It is therefore essential to protect identities, but it is not enough. Managing and verifying identities is the first step in protecting your environment. Provisioning user identities through Azure AD and connecting your on-premises Active Directory service if necessary, allows you to centralize identities for each user to  be able to establish policies based on devices, groups and applications.

As previously discussed, the “Zero Trust” approach requires flexible security policies that meet the requirements for user access to data and resources. Moreover, one of the essential aspects of a “good” security is that it should be almost invisible to legitimate users. Excessive friction inhibits productivity, and legitimate users will find ways to circumvent provisions that block their productivity, thereby creating (additional) risks. Although you can enforce multi-factor authentication (MFA) for each user, maximizing productivity is ideally expected to allow legitimate users to do their jobs with minimal disruptions while blocking malicious people. Azure AD enables you to set conditional access policies for users in your organization to help secure your hybrid or cloud environment. Conditional Access is the tool used by Azure Active Directory to bring signals together, to make decisions, and enforce organizational policies.

Configuring conditional access policies in Azure AD

It is recommended that you apply appropriate policies to your organization for the following conditions:

• Users and user groups: to reduce the risk of sensitive data leakage, define which users or groups of users can access applications or resources, paying particular attention to the highly sensitive information sources such as human resources or financial data.

• Connection risk: Machine Learning algorithms in Azure AD evaluate each connection and give it a low, medium, or high-risk score based on the probability that someone other than the legitimate owner of the account is attempting to connect. Anyone with a medium risk must be challenged with multi-factor authentication (MFA) when connecting. If the connection is high-risk, access must be blocked. This condition requires Azure AD Identity Protection.

• Device platform: for this condition, you can define a policy for each device platform that blocks access, requires for example compliance with Microsoft Intune, or requires the device to be joined to the domain.

• Location: a location can be risky if it is a country with limited security policies or if the wireless network is unsecured. Also, it can be risky simply because it is not a place where the organization usually has its activities. You can change the access requirements for connections from locations that are not on a list of safe IP addresses or that are risky for other reasons. Users accessing a service when they are outside the corporate network must be forced to use multi-factor authentication.

• Device status: you can use this condition to set policies for devices that are not managed by your organization.

• Client applications: users can access many applications using different client application types, such as Web applications, mobile applications, or office productivity applications. You can enforce security policies if an access attempt is made by using a client application type that causes known issues, or you can require that only managed devices access certain types of applications.

• Cloud applications: this condition specifies unique policies for sensitive applications. For example, you can require that HR applications such as Workday will be blocked if Azure AD detects a risky connection or if a user tries to access it with an unmanaged device.

When a condition is met, you can choose the policy that Azure AD will enforce in terms of control:

• Require multi-factor authentication to prove identity;
• Modify the actions that the user can take in the cloud applications;
• Restrict access to sensitive data, such as limiting downloads or sharing features;
• Require password reset;
• Block access.

Conditional access in Azure AD allows you to enforce your “rules of engagement” by defining a set of policies that specify conditions and controls. You can set access levels by the employee, by device, or by the group. Conditional access in Azure AD is a hub of identity-based security policies. Previously, you should have specified: “no access outside the corporate network” or “no access from a personal device”; today, the ability to block or authorize access is offered under conditions.

Implementing a Zero Trust approach with Azure Active Directory Conditional access in Azure AD allows enforcing security policies that are triggered automatically when certain conditions are met. You can block access if the context data suggests that the user has been compromised, or if it is very unlikely that the user should log in under these conditions. You can apply additional authentication requirements when the system detects a medium risk based on connection conditions.

Note that Conditional access in Azure AD is an Azure AD Premium feature (P1 or P2). All users accessing an application or resource-limited by conditional access policies must have an Azure AD Premium license.

CONDITIONAL ACCESS IN AZURE ACTIVE DIRECTORY: https://docs.microsoft.com/en-us/Azure/active-directory/active-directoryconditional-access

“Never trust, always verify”