How Passwordless Authentication supports the principles of Zero Trust

1 Dec 2020 04:27 PM

Guest blog: Tor Clark from Coltech Consulting looks at Passwordless Authentication and Zero Trust

On November 19 techUK held a session with NCSC, “Defining Zero Trust Network Architectures” which outlined the 8 principles defined by the NCSC which are being maintained in Github. 

Fundamental to the NCSC’s principles is the idea that networks cannot be trusted and must be treated as hostile! Perhaps this should be the first principle! The response is to “build trust into users, devices and services”. These principles are useful guidance when looking at where to focus your strategic approach to ZTA, and what you need to consider in your programmes to update and manage your networks. 

There are common themes that run through each of these principles and the approach you should take in applying the ZTA principles. Throughout all of these principles you should consider the role of passwordless authentication and how it can provide your frontline defence; certainly for users accessing your network but the technology behind certain passwordless technology can also be applied to providing greater levels of security in authenticating devices and services. Below I build a picture of the role of each principle and the role passwordless technology can play.

Principle 1 – Know your Architecture 

It sounds obvious, but many organisations I have seen do not know, let alone understand their architecture. Often it has evolved and grown organically over time with many demands and influences, mergers and acquisitions. With different strategies, priorities, and a string of architects throughout its lineage, you often need an archaeologist rather than an architect. Get help. Like home DIY you can do it yourself, but it’s better to get the professionals in to understand and map out what exists and ensure that you don’t make the architecture worse and introduce additional vulnerabilities. 

Professional authentication services will not just hand you the technology but ensure that the current environment is understood. This includes ensuring a disciplined approach to planning, design, integration & implementation, testing and operations management. 

Principle 2 – Identify the endpoints using the network 

Identifying users, devices and services is “one of the most important factors in deciding whether someone or something should be given access”, and they should be “configured to [have] the ‘least privilege’. However, identifying users, devices and services is not

enough. How can you be confident that the identity correctly associates the intended user, device, or service? And this is fundamentally where most current implementations of passwordless authentication fail. Most rely on devices that can be stolen, identity that can be spoofed and impersonated. However, there are those that are unique to the individual and if basic measures are followed reduce the risks dramatically and can give confidence in the identity.

Principle 3 - Check the currency of the endpoints

The principle here is that the endpoints, ie the devices used in connecting to the network are “healthy”, in NCSC terms this relates to having confidence that the devices accessing across your network are “compliant with the device configuration, policies and state”. (NCSC has guidance on assisting with mobile device management, NCSC's mobile device guidance). Passwordless authentication increases the confidence in the user’s identity is as intended and therefore contributes to the efficacy of your services by reducing the risks of granting access to the users and systems with nefarious intent. 

Principle 4 – Only process authorised requests based on policies

You should use policies to authorise requests (and rerequests). A policy engine is essential in enforcing an organisations policy. The policy engine will decide to accept or reject a request for a service or data based on a set of simple

logic rules. More sophisticated policy engines should now also make use of “AI” and apply machine learning in the assessment or risks, based on a wider set of “signals” including combinations of response data from various sources, and over time. For example, the policy engine should assess against patterns of usage, locations and intervals between access (not just count the number of times attempts are made). Passwordless authentication should provide greater confidence in the user access through strong authentication and aligned to the policies implemented in the policy engine. 

Principle 5 – Authenticate everywhere, everything and everyone

“Assume the network is hostile and authenticate all connections”, UK-NCSC goes on to say “….authentication of user requests require a stronger mechanism than a simple username [usually one of the users many email addresses as the ubiquitous username] and password combination”. This principle is central to passwordless authentication and should provide a stronger approach to authenticating identity. New mechanisms that introduce improvements in the usual username/password combination are emerging, but each have their foibles: 

Few have a unique approach that address these issues. The principle also describes the role of Multifactor Authentication (MFA) in this principle, “MFA is a requirement for Zero Trust Network Architectures”. There are additional principles (therefore sub-principles of ZTA) of MFA, that the mechanism should have, and include: 

Most passwordless solutions will address one of these and rely on additional capabilities of devices or additional services to achieve a minimum of 2 factor authentication (2FA). Few (one) could be said to be all three, although there would always be comfort in the addition of any of the other principles. NCSC also includes “usability” in consideration of this principle as a legitimate user for example should not be too impeded by the technology used to authenticate the person, so passwordless authentication is again ideal.

Principle 6 – Monitor the architecture, endpoints and resources

Monitoring must show that the devices, users, and services are performing as intended and accessing data in accordance with their scope and the defined policies. Any operations outside their scope and policy should be initiate a controlled response and appropriately defined alert. 

It is as important, if not more important, to monitor the authentication services and ensure that any unusual behaviours initiate controlled actions. IT is precisely the “unusual behaviours that can identify nefarious attempts to gain access which could also hinder other users experience (ref principle 5, and especially usability), drain resources and if the security measures, policies and controls are insufficient then the consequences can be catastrophic as well as financially and reputationally binding. 

The passwordless service should help enforce comprehensive polices, controls and monitoring. Warnings should include notification of increasing risks, and alerts if issues have been identified. This could include (but not limited to): 

Principle 7 – All networks are hostile, no network can be trusted 

Since the network can be compromised and seen as hostile, NCSC’s response is that you should, “build trust into users, devices and services”. This means we need mechanisms to ensure trust and minimise risks of impersonation, duplication, and malicious misuse. This seems as if all we are doing is shifting theproblem. We are. We are moving the issue to the endpoints, or our central view of the endpoints, where the right mechanisms have been implemented in order there is confidence that: 

As passwordless authentication provides a strong mechanism for the users are who they say they are (or at least associated with the username), currently they don’t ensure the health of the devices, or authenticate services. There are other tools for the latter two mechanisms. Although there are those that could be used if further developed. 

Principle 8 – Use services designed for Zero Trust

As legacy systems are migrated and transformed, there is an opportunity to assess those services and whether they can be updated for Zero Trust Networks or replaced. In this principle UK-NCSC also say, “services need to be designed to protect themselves”. Legacy services may need to have

additional services that wrap the legacy service to add the required protection. It may be more cost effective though to replace the service with another available service designed for Zero Trust. The potential costs of a service introducing a threat vector or presenting an attack surface may out way the cost of avoiding the cost and making compromises. Don’t be financially short-sighted and apply a false economy.

Further advice from NCSC includes, “Look at standards” – use and apply standards in your architecture such as OpenID Connect, SAML etc. Most Passwordless services apply standards. And this may depend on your current implementation architecture, but using the appropriate standards reduces your security risks.

Click here for the full blog post