Streamlining user access with zero trust (part 2)

In part one of this two-part series, we took a look at the trade-offs between security and ease of use in a solution based on zero trust network access (ZTNA). I outlined the application access design process for a frictionless yet secure user experience. 

Now, we’ll dive deep into each security control needed for zero trust network access and how to make them work together to create a balanced passwordless user experience.

First, let’s lay the foundation with a look at the role of out-of-band authentication and managed versus unmanaged devices. 

Out-of-band (OOB) authentication methods

Though the out-of-band concept with passwordless is similar to traditional MFA, there is much more to consider due to removing the “something you know” factor (i.e., the password).

Suppose you only allow managed devices with tightly controlled enrollment to access corporate applications. You’d simply register the device with a short-lived, one-time password (OTP) issued by a central authority.

However, if you allow unmanaged devices to access applications or expect users to self-enroll devices, it is necessary to implement tight controls on what users can use for the OOB method and how the devices are protected and unlocked for access.

For example, the NIST 800-63B Digital Identity Guidelines describe multifactor OTP authenticators or cryptographic devices as “...something you have, and it SHALL be activated by either something you know or something you are.” In my view, you should avoid single-factor methods for OOBA/OTP devices like copying a code from an SMS message or answering a phone call.

When a new OOB device is registered, informing users is a must to detect malicious enrollments and report suspicious behavior.

Choose managed devices whenever possible 

When designing the passwordless user experience, you consider two classes of devices: managed and unmanaged.

Unmanaged devices

As mentioned above, corporate application use on unmanaged devices (PCs or mobile devices) is much like traditional MFA authentication today. It requires an OOB authentication on each use: The user typically identifies themselves by their email address and uses the chosen OOB authentication method to complete the identification loop.

Periodically, the user must manually re-authenticate due to the lack of trust in the unmanaged device and reduce the risk of stolen authentication tokens from being used.

Managed devices

A managed device is a PC or mobile device that the user has previously registered for corporate use and the process is carried out by the user's OOB authentication method or OTP.

After registration, the user unlocks the device with biometrics or a device-local PIN. Thereafter, when the user accesses corporate applications, the ZTNA service and the identity provider (IdP) use the context of the user, device, and application seamlessly to determine whether to authorize access to the application.

The user may be prompted to authenticate manually or re-register the device if the ZTNA environment detects any abnormalities.

Managed devices provide the most seamless application access, so we’ll focus on that category. The following assumptions apply for the rest of this article:

• Your organization has a modern identity and access management (IAM) platform (example: Azure Active Directory). You can also implement this model with legacy authentication integrations, such as NTLM or Kerberos, provided you also have an IdP and the right ZTNA service to support it.
• The user already has registered an out-of-band authentication method.

The authentication process

In a conventional modern application environment, the authentication process entails a negotiation between the IdP, the application, and the user.

In a ZTNA-based passwordless environment, the “negotiation” is between the IdP, the ZTNA service, and the device (on behalf of the host application). The device's host application can be a web browser or a dedicated app.

In the past, security teams have placed a lot of focus on protecting user credentials and detecting misuse. In this model, much of the effort is focused instead on protecting the device, since it contains the credentials.

Figure 2 shows the control layers that protect user credentials, which are stored in a device’s secure hardware module (TPM, Secure Enclave, or Keystore). The multiple layers of security in this implementation make the user credentials hard to steal.

Let’s take a deeper look at these security controls, starting from the core and moving outwards.

Personnel Controls

Perhaps the most important part of the ZTNA strategy is personnel controls. Your organization needs strong security policies and end-user agreements for employees and contractors. Technical controls at each level should help enforce policies.

For example, users must promptly report missing or stolen devices so their access can be disabled on the IdP side, and their contents remotely wiped if and when a thief attempts to authenticate. Users should also be warned proactively, in real time, about potentially risky behavior while using their systems. Many information security groups have historically tried to stay in the background while keeping the enterprise secure, but experience has shown proactive warnings of risky behavior to be more effective.

The next step in designing the passwordless user experience is to add technical controls.

Unlocking credentials from the secure hardware module

To unlock the device, the credentials must be retrieved from the secure hardware module: Trusted Platform Module (TPM) on Windows, Secure Enclave on Apple, or Keystore on Android. Credentials should be unlocked using secure passwordless methods, such as biometrics or device-local PINs, which are common across modern Windows, Apple, and mobile devices.

A device will need to be protected with a PIN where biometrics capability is not available. However, PIN entry introduces the risk of credential theft through “shoulder surfing”. A complex PIN can reduce this risk, but system requirements must achieve a balance between complexity and usability.

Device login controls

Device boot

All devices are at risk if an attacker has physical access to it, even if it is turned off. If a device is stolen, the attacker should not be able to gain access to the OS or at the very least, access is delayed through technical controls to give the user time to report the theft.

All devices need to have storage encryption enforced by policy. Carefully consider what OS standby modes to allow for PCs and Macs. If a machine is on standby with unlocked storage, this can undermine boot protections.

All devices should have a device local PIN or passcode set, with policy configured to erase the device, or exponentially delay the time between attempts after a low number of incorrect entries.

The login method should revert to PIN entry upon a low number of incorrect biometric authentication attempts.

Operating system login

Device login settings and policies are set by the enterprise administrator and controlled by a mobile device management (MDM) agent installed on the device. Biometric login is the preferred method because it avoids shoulder surfing, which is the main risk of PINs.

Operating system controls

The goal of the OS-level controls is to detect and prevent tampering and unauthorized use. The following OS-level controls are widely available, although some are less common on mobile devices:

• Screensaver and lock screen timeouts
• Pre-boot policies (pushed to the OS for implementation)
• PIN unlocking policies
• Storage encryption
• Restriction and control of privileged/administrator access
• Tamper prevention
• Local firewall policies to restrict network access
• Controls on software installation that prevent use of unauthorized software
• Installation and enforcement of centralized tools for logging, endpoint detection and response (EDR), and forensics
• Aggressive OS security update strategies, with access blocked for outdated systems

Endpoint detection and response controls

EDR tools are used to help prevent, detect, and respond to malware. Advanced tools can integrate with other controls listed in this framework to help achieve contextual-based access. Digital Forensics and Incident Response (DFIR) tools are also included in these controls. Tools must be tamper-proof, or have a tamper-detection design. The health of EDR agents on the client must be checked as part of other controls listed here.

Network controls

Network controls should include the “assume breach” paradigm, a security mindset that always presumes the local network to be compromised. By putting a secure web gateway (SWG) in between the network and the device, traffic can be inspected for malware and other threats. At the same time, data loss prevention (DLP) can be carried out to prevent data exfiltration.

Device agents that provide the network controls must either be tamper-proof, or the system must be able to detect whether they have been tampered with through other means. Consider denying or restricting application access if traffic arrives from non-SWG networks. SSL inspection on all traffic is essential.

Application controls

The application controls take two forms – host-based and remote.

Host application (local to device)

The host application is typically a web browser or a local “thick client” provided by the vendor.

Default configurations from major vendors are generally sound but you should review their individual needs and review Center for Internet Security best practice guides for recommendations. Technical controls should enforce a standard browser only to be used for corporate application access. 

Thick client applications may have their own controls and the vendor should be approached for recommendations.

The host application must be aggressively kept up to date to ensure that any vulnerabilities are quickly patched.

Application (remote to device)

The ZTNA service hides the application and prevents connection until the IdP has successfully authenticated and authorized the access. After authentication through a proxied connection, the gateway provides connectivity only to needed applications, ports, and protocols. It does not offer direct network-level access. The ZTNA service integrates with other controls (IdP, network, EDR, and OS controls) to determine the device’s security posture and provide appropriate access. The application’s sensitivity may dictate that interactive OOB authentication, alongside the device-based authentication, occurs each time the application is accessed.

Identity provider controls

Contextual access

To determine access authorization, the IdP receives telemetry from other controls in the ecosystem, both during login events and periodically during the application session.

Following are some examples of questions the IdP might answer to determine proper contextual access. The range of these capabilities is expanding as IdP capabilities and machine learning mature:

• Who: What type of user are they, and do they need further verification?
• What: Is it a corporate or a non-corporate device? Should the app be accessed from this type of device? Is the type of device, or the type of sign-in event, considered risky?
• When: Is the app being accessed outside of allowed or typical timeframes?
• Where: From what network, country, or geographical coordinates is the app being accessed from? Is access permissible from that location?
• Why: Has this user or device accessed this data before? Is the size of the download typical? Is anything about the data access out of character?
• How: How did the user authenticate? Are any extra authentication steps required based on other controls and the security posture needed?

The ZTNA service will evaluate the access request based on contextual controls, which, depending on the result, might lead to re-authentication, restricted access, outright blocking of access, or account disablement.

Device enrollment

Because the device is the main protection focus, enrollment processes must be highly secure. There are many possible levels of both security and convenience. To select the appropriate balance, carefully consider the sensitivity of the data and the associated risks.

For example, you may need to look at:

• What type of strong authentication (such as OOB/OTP) should protect the enrollment process when a device is enrolled?
• Who should enroll a new device: the user or IT?
• Can a device be enrolled from outside the corporate network or building?
• Can any device be enrolled or only devices in a controlled inventory?

Unauthorized enrollments must be quickly identified and disabled. A tremendous help with this detection is proactive user polling, where the system contacts the user, for example, by email, to confirm when a new device is registered in their name.

Benefits of adopting passwordless with ZTNA

Organizations receive many benefits from a passwordless ZTNA environment

• Frictionless user experience
• Increased enterprise security posture 
• Reduction in credential-based attacks
• Decreased service and customer support costs
• Ability to attain higher assurance levels (NIST AAL3)

Your next steps 

In this two-part article, we explored the essentials of an application access design encompassing zero trust network access principles and passwordless technologies. This design generally follows NIST guidelines and results in a frictionless yet secure user experience.

To develop a detailed implementation, consult the following publications:

·  Digital Identity Guidelines (NIST Special Publication 800-63-3)

·  Zero Trust Architecture (NIST Special Publication 800-207)

What to read next 

Streamlining user access in a zero trust environment (part 1)