How Passwordless Authentication supports the principles of Zero Trust
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:
- most are either convoluted or complex,
- rely on device capabilities or require additional devices,
- visible by shoulder surfing or require additional application infrastructure.
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:
- Knoweldge – something only the user knows
- Posession – something only the user has
- Inherence – something only the user is uniquely associated with
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):
- (Distributed) Denial of Service Attacks (DDoS)
- Brute Force Attacks
- Man-in-the-middle Attacks
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:
- the user is who they say they are, and they are authorised to do and access what they have been allowed to do
- the devices are “healthy” and running at the appropriate and intended level of security patches etc, and they are “approved” devices, and
- the services are enabled to access and deliver the data and events they are intended to do
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.
Latest News from
£3m to fund new wave of Artificial Intelligence for the Military15/01/2021 16:25:00
techUK members have won funding as part of the DASA Intelligent Ship Phase 2 competition.
Defence Digital and techUK publish joint list of signatories to collaboration Code of Practice15/01/2021 13:33:00
Following the recent launch of a new Code of Practice for collaboration, techUK and Defence Digital are delighted to share a joint list of MOD and industry signatories to the code.
Avon and Somerset Police Proof of Concept (PoC)15/01/2021 11:25:00
Guest Blog: Phillip Ridley, Senior Business Development Consultant at 1Spatial and 'Interoperability in Policing' Working Group member shares his recent work with Avon & Somerset Police in the world of spatial data.
Ofcom report: Technology Futures14/01/2021 16:05:00
The UK's communications regulator Ofcom has published a new report, Technology Futures, that shines a spotlight on the innovative, emerging technologies that could shape the communications industry in the future.
5G Create trials to utilise Open RAN14/01/2021 11:25:00
The UK Government’s 5G Testbeds and Trials Programme has announced the latest projects to receive funding for innovative new uses of 5G, following the 5G Create competition.
Digital Ethics Summit 2020 Day One- Lessons to be learnt from 202011/01/2021 14:25:00
Summary of day one at techUK's Digital Ethics Summit 2020.
Digital Ethics Summit 2020 Day Two- Moving Forward in 202111/01/2021 13:33:00
Summary of day two at techUK's Digital Ethics Summit 2020.
Contribute a case study to techUK’s landmark digital twins report!11/01/2021 09:15:00
techUK is aiming to kick-off 2021 in style with the release of a landmark report ‘Unlocking value across the UK’s digital twin ecosystem’.