Taking The Fluff Out of Zero Trust

IT security office with lone man working at a desk and empty PC desk
Uri Arjitecter

Uri Arjitecter

Solutions Architect, Threatcape's Microsoft Security Practice

Zero Trust, what does it mean?

You’ve probably heard the term Zero Trust a lot recently, and the likelihood is that you will hear it more and more in the coming months. Big players such as Forrester, Microsoft, Palo Alto Networks and Cisco all have a defined framework and model that revolves around a Zero Trust strategy, which conveniently maps to their respective product sets.

But what does it actually mean? Is this just another transient marketing term? Aren’t we already employing Zero Trust anyway? Most organisations are already limiting access to resources through authentication mechanisms, firewalls and intrusion detection tools today, so how is Zero Trust different?

Let’s try and take away some of the fluff

Today, when a user logs on to their device or to a corporate resource (on-premise or in the cloud), they perform some sort of authentication and are issued an access token.

The issued access token will also contain the permissions and rights the user has been granted. Typically, the permissions will either be granted directly to the user’s account or will be based on the user’s group membership. For example, an HR user will have access to HR apps and documents while a member of the sales team will have access to sales-related documents and resources. So far, so good.

Now, once an access token is issued the lifetime of that token will normally be for 10 hours and in some cases even days. In a Non-Zero Trust environment, that access token isn’t validated again until the token expires, which means the user can gain access to resources even if their circumstances have changed.

What do I mean by circumstances? Here are a few examples:

Change of Location
Let’s say Bob accesses a Teams or SharePoint Online site from his laptop while inside the corporate network. After Bob has been authenticated, he will be issued with an access token granting access based on his permissions. Next, Bob takes his laptop to his local coffee shop and continues working from there through the public Wi-Fi.

An event like that should elevate the risk of Bob’s session as he may be accessing sensitive data from an insecure or untrusted connection. A Non-Zero Trust environment would not be able to identify that Bob is now connecting from a different location, meaning his access token would still be valid, presenting a risk of data and infrastructure exposure.

Compromised Identity
Let’s say Bob’s credentials have been compromised through a phishing attempt, Keylogger or brute force attack.

An event like this should elevate Bob’s user risk to high but his current access tokens would still be trusted and valid. A Non-Zero-Trust environment would allow Bob, as well as the bad actor using the stolen credentials, to continue accessing resources without restriction, increasing the risk of data exfiltration or damage to infrastructure.

Compromised Device
Let’s say Bob’s device (computer, laptop or mobile phone) has been compromised through malware or a ransomware attack.

An event like this should elevate Bob’s device risk to high as it can potentially spread the malware across other devices. This can happen when devices are either inside the corporate network or outside the network through a VPN connection.

A Non-Zero-Trust environment would allow Bob’s compromised device to remain trusted and have network access to corporate resources, increasing exposure and risk to data and infrastructure.

Never trust, always verify — putting it into practice

Today’s cybersecurity risks shift and change with our ways of working, particularly now during the Covid-19 pandemic, users are connecting from any location and any device, be it corporate or personally owned. As our ways of work shift and change so are the techniques used by attackers.

This means that:

We need to implement solutions that provide continuous evaluation of users’ circumstances and identify changes in their risk factors. Once identified, automatic remediation controls should be triggered to alert, block access or challenge the user for stronger authentication.

So, what can we do? How do we ensure ongoing evaluations are in place?

Below are some examples and suggested solutions that can help, many of these points are also inline with the controls suggested by the Center of Internet Security (CIS).

Here it goes:

Adopt an identity and device centric risk approach and implement strong adaptive authentication

  • Focus on implementing controls based on users’ identities and device risks rather than their location. Connecting from inside the network does not mean the users should automatically be deemed trusted.
 
 
 
  • Limit access to cloud resources based on continuous risk assessments and gain visibility of risky cloud application usage. Once identified, limit access to unauthorised applications. Microsoft Cloud App Security (MCAS) provides visibility and controls of cloud application usage through APIs, log correlation and built in detection policies. To enhance these features, consider implementing “in session” restrictions by enabling the Conditional Access App Control which will block unauthorised activities such as downloading data to non-corporate devices or blocking administrative actions from untrusted locations.

Remove permanent administrative access and use Just-in-time/Just Enough Access controls

  • Removing permanent administrative access and leveraging Role based Access Controls (RBAC) will reduce the risk of impact to your environment should an administrative account be compromised.

 

  • Leveraging Azure AD Privileged Access Management to implement “Just In Time” and “Just Enough Access”, ensures administrative access as well as virtual machine access is granted through a monitored and controlled workflow, reducing the impact of compromised admin credentials.

Implement adaptive network segmentation controls

 

Automate and remediate risks through event correlation across multiple solutions

  • Solutions like Azure Sentinel and Microsoft Threat Protection correlate signals and events identified across multiple attack vectors such as, identities, devices, applications and infrastructure. The aggregation and correlation of events spanning these attack vectors allow these solutions to generate incidents which are “fused” together to provide visibility of malicious activities that would have not raised suspicion in individual solutions. The incidents are then prioritised based on the risk level and can trigger playbooks which will run alerting and remediation tasks.

Zeroing In

To conclude, our current infrastructure designs are preventing us from keeping up with the latest risks and a new approach focusing on ongoing validation is needed.

Zero Trust may just appear to be the latest buzzword but if we take a closer look the logic is sound and fits in with adapting to today’s ways of working. Ongoing validation of user and device risk factors, correlation of events from all security platforms combined with automatic remediation and response are key to keeping up with the modern threats.

READ MORE about how your enterprise can stay more secure in the times during and after the pandemic.

 

This article was first published on Medium.

You may also be interested in these articles:

welcome!

Contact Us