Principles for secure privileged access workstations (PAWs)
Pages
Page 7 of 10
Principle 5: Reduce the attack surface
On this page
- 5.1 Block access to corporate apps
- 5.2 Minimise connectivity to external networks and internet services
- 5.3 Securely connect to your administration targets
- 5.4 Remove unnecessary device features, applications and functionality
- 5.5 Protect the physical device
- 5.6 Apply equivalent controls to third parties
The goal is to mitigate risk as much as possible on your PAW, whilst balancing security and usability.
A PAW device should be configured to meet your administrative access needs, while also minimising its attack surface. The goal is to mitigate risk as much as possible on your PAW, while ensuring that administrative tasks can still be carried out effectively.
You should carefully consider every feature, application and connection to a PAW, and make sure they are adequately protected. Disabling unnecessary functionalities or connections prevents a threat actor exploiting them. Any component of a system that connects externally can present a threat. For this reason, you should only allow external connections when access is essential, and manage it very carefully.
It shouldn’t be possible to directly access any services on the PAW that pose a risk to it. This includes corporate applications, email and communication tools. If you require access to these services, manage it carefully, so that it doesn’t affect the integrity of the PAW. Examples here may include use of isolation and cross domain solution (CDS) technologies.
It’s important that these controls apply to any device that is used to access high privileged or critical service, including when that use is by a third party, and you should make sure that suitable controls are also in place for these users.
5.1 Block access to corporate apps
It's essential to block direct access to corporate applications on a PAW device, including email and messaging systems.
Direct access in this context refers to when an application runs on the PAW, within the PAW operating system. When allowing indirect access to corporate applications, you should implement technical controls such as:
- cross domain solutions (CDS)
- remote desktop solutions
- a local hypervisor
The control you put in place should provide a layer of separation between the PAW device and the service being accessed. When choosing your control, consider the risk to the service and the wider threat context of your organisation.
While technical solutions that add a layer of isolation are there to improve security, misconfiguring these services can lead to a threat actor finding an exploit path between the PAW and untrusted applications. The level of protection required to ensure adequate isolation between a PAW and untrusted services depends on your organisation’s risk tolerance and the wider threat landscape.
Effective isolation is crucial for mitigating the most common ways an attacker gains access to systems, such as phishing or other social engineering attacks. Creating a strong boundary prevents malicious content reaching the PAW, both directly from outside the organisation, and indirectly via other corporate systems and repositories.
5.2 Minimise connectivity to external networks and internet services
In most use cases, a PAW requires connectivity to external networks or internet services. But its access to external services must be restricted to the services that are essential for it to operate. This may include receiving updates or configurations from an MDM, or carrying out administrative tasks on a cloud portal.
| By removing access to unnecessary internet services and enforcing strict network traffic rules, you limit a threat actor’s initial access and make data exfiltration more difficult. |
A PAW should have technical controls in place to prevent unnecessary network connectivity. The controls implemented should depend on the accesses to which it is connecting, as well as your organisation’s threat context and resiliency requirements. It's common for controls to be implemented in one of two ways:
-
Locally on the device, such as through a software firewall with policy controls. These controls are typically static, providing a set of permanently enabled connection routes to the required services. When using local controls, users must not be able to change the rules and policies to enable broad internet access. You should use automated auditing to make sure that internet access remains disabled.
-
Off-device or remote controls, such as through secure access services edge (SASE). These controls typically use local software to securely connect to the SASE service, where a policy function can then be applied to the traffic. These types of services can be useful when connecting multiple sites together, and can provide a single internet edge for all devices, making lockdown policy and audit functionally easier. They also enable a more dynamic approach to controls, as connectivity routes are only enabled when required, rather than permanently enabled. As with any third-party service, you should also consider the supply chain risks associated with any SASE products you use.
The control you choose should be well designed so that it works as intended. Think about how a threat actor could bypass these controls – for example, by using the device proxy settings to restrict internet access. Although this would restrict a device’s ability to connect to the wider internet, it could easily be defeated by a DNS poisoning attack.
If your organisation is in a regulated sector, you must also consider any legal and regulatory requirements where failure or loss of connectivity to the SASE service would disrupt your ability to manage your network(s). You should consider if the SASE product offers appropriate resilience for your regulatory requirements. Where appropriate, you should still put in place contingency plans. This includes having a defined backup route to your services, so that privileged management can still be carried out from trusted PAW devices. This backup route should be treated as a break-glass solution, and controlled and monitored appropriately. |
Connectivity technology
To reduce your attack surface, make sure the connectivity methods the PAW uses, such as Wi-Fi or cellular, are adequately secured.
Public Wi-Fi networks can present a major risk to a PAW device, as they often require use of a captive portal, where the local device connects directly to the local service to authenticate. The requirement for an unsecured connection to the captive portal conflicts with the on-device controls and would require an exception to a critical PAW control. For this reason, you shouldn’t allow connectivity to a captive portal from a PAW. Unless additional controls are put in place to mitigate this risk, consider alternative routes to connect to public Wi-Fi.
For organisations that use cellular networks with a private Access Point Name (APN), be aware that although an APN provides separation, it doesn’t provide encryption within the telecoms network.
5.3 Securely connect to your administration targets
A PAW needs to communicate with the systems and devices it manages and for many use cases, this could mean multiple systems or devices. Some may be less trusted or more vulnerable than others, which presents a threat to your PAW and any other system it is used to access.
Depending on how you connect your PAW device to its target system or asset, it may be exposed to different risks. The important thing is to design it in such a way to reduce its risk of compromise, if connected to a compromised asset.
Types of connectivity:
Many use cases for PAWs involve connecting to a system over a network, either locally or remotely. It's important that communications from the PAW are protected from any threats on that network.
- You should use secure protocols, such as TLS or IPSec, to authenticate the systems or networks to which you are connecting. This also protects the confidentiality, integrity and authenticity of the data in transit. It’s important that your product uses an encryption protocol that offers an appropriate strength. The NCSC has guidance on recommended profiles in its guidance on how to use TLS to protect data.
- The PAW device itself should not run any network services that accept incoming connections, and all communication should be established outbound from the PAW.
- Where you need to use insecure protocols, tunnel them over a secure protocol, or only use them on a suitably isolated network.
- For services that are considered high risk, add technical controls which ensure they can only be accessed if authenticating from the PAW device.
Some use cases may require direct physical connectivity to the administrated device, such as over serial or ethernet links.
When using direct physical connectivity to a system or asset, the controls on your PAW device are the only layer of security between the PAW device and the asset being managed. You should understand the risks this could introduce to your system, and mitigate them using the controls on your PAW device. For more information about controls where obsolete software is required, see principle 6: Isolate high-risk activity from your PAW.
In many cases, a PAW which is used to manage standalone or isolated equipment is also used to manage or connect to other systems and networks. Where this is the case, the PAW device acts as a bridge between the systems and networks, even if the connections aren’t active at the same time. Even if a network is temporarily disconnected, malicious data could be stored and transferred via the PAW once it reconnects.
Where possible, avoid intentionally disabling connectivity from the PAW to its supporting systems, such as its MDM and logging solution. Removing this connectivity could limit the user's ability to carry out their role, for example, by blocking access to your file transfer solution. It also disrupts monitoring and threat detection, especially where antivirus solutions are configured to use cloud-based analytics.
A system or device managed by a PAW could be considered less trusted for several reasons, which include, for example:
- it processes high-risk data
- it is one of many systems which need segregating from one another
- a third party has privileged access to it
If one of these systems is compromised, you should consider the risks it would present to the PAW device and your wider estate. If you are not willing to accept this risk, you can add additional security controls between the PAW and the less trusted system. This protects the PAW device by creating stronger separation. The NCSC cross domain principles provide an appropriate level of separation. For example, you could implement a jump host (bastion host), a privileged session manager (PSM) or a hardware-based CDS solution.
A PSM can offer additional functionality for screen recording or session management, and it also keeps an audit trail of established sessions. PSMs are often provided as a part of a broader PAM product. Although they offer many benefits, the impact of compromised privileged access is very high, so it’s important to use a PAW to access the PSM solution.
5.4 Remove unnecessary device features, applications and functionality
A PAW aims to reduce the attack surface of the device an organisation uses for high-risk accesses. Following basic cyber hygiene measures, such as installing security updates when they are available, is an important part of this, but to reduce the PAW device attack surface further, you should remove or disable any unnecessary application or functionality.
The aim here is to design a PAW solution in such a way that it meets the requirements for your use case but ensures that each user only has access to the tools, services and features required for their role.
You should enable OS (operating system) features to restrict the execution of code only to known binaries, linked libraries or shared objects.
Limit applications with an allow-list
Minimising access to unnecessary applications makes it more difficult to execute malicious code. Use an allow-list to limit access of approved apps to user groups or individual users. It's also important to make sure that all apps originate from a trusted source. Block any attempts to execute applications that aren’t on the allow-list, and then log and investigate them.
The NCSC has guidance on using third-party applications on devices that you should apply to your PAW solution.
Prevent remote control of a PAW device
The PAW device should represent both the physical and logical end of the management chain, meaning the point where the administrator has ‘hands on keyboard’. The physical PAW device should be hardened to prevent remote connectivity into it, by disabling associated protocols, network ports and services. Where jump hosts, privileged session managers (PSM) and virtual desktop infrastructure (VDI) are used for follow-on access, it should only be permitted from a PAW.
Sometimes it might be necessary to screen-share between a PAW and another non-PAW or external device: for example, when providing technical support. Here you should use a stronger technical solution which provides visibility of the screen but doesn’t allow control of the PAW.
Minimise permissions for local device users
To reduce the attack surface, the controls and features used to configure a PAW must be technically enforced. Note that having a written policy in place isn’t itself a technical control. To maintain confidence in the PAW, a user shouldn’t be allowed to disable the controls, as configuration changes to a PAW is considered a high-risk action. If you need to allow an engineer to amend the configuration, you need to accept the heightened risk this introduces, and ensure their actions are verified by additional monitoring and auditing.
Principle 6: Isolate high-risk activity from your PAW outlines how this could be implemented in a way that doesn’t undermine the security of the PAW. Privileged accounts should not be directly accessed on the PAW.
Only enable essential peripheral interfaces
Limiting peripheral access from a PAW is critical to preserve trust. Most modern devices support a wide range of peripheral connectivity, including short-range wireless connections, such as Bluetooth, and physical interfaces such as USB and Thunderbolt. These interfaces are another way that a threat actor could gain access to a device and its data, and many of these interfaces are enabled by default.
Where you choose to enable peripheral interfaces, you should implement technical controls that limit which devices can connect. A PAW should only allow connections from authorised peripherals, and they should be securely sourced, and use signed drivers. For peripherals such as USB devices, policy-enforced allow-listing based on the peripherals, hardware ID and serial numbers can all be used achieve this control.
You can put in place controls that limit connectivity to these interfaces that are vendor specific. The NCSC has guidance on using peripherals securely to support the design of any technical controls implemented.
5.5 Protect the physical device
As well as protecting a PAW from traditional network-based attacks, it’s also crucial to protect it from an attacker who has gained physical access if a device is lost, retired or stolen. Physical access makes it possible for an adversary to:
- extract cached credentials or stored sensitive data
- implant malware or modify the device configuration to undermine or bypass protections
- infect the UEFI or firmware to maintain persistence
You should add protections to the device, and put in place physical handling and storage procedures to mitigate the risk of loss, theft or physical tampering. They should be proportionate to the threat level of the systems which the PAW is used to access.
On a PAW device, it’s critical to use trusted platform modules (TPMs) or similar hardware security processors to underpin device-level protections. If none are in place, many modern security features can’t be used. Device-level protections must include:
- enabling secure boot so that only trusted software which is verified by a trusted authority can run during the boot process
- implementing full disk encryption to protect the confidentiality and integrity of the software and data when the device is switched off – the NCSC’s device security guidance platform guides provides recommendations for your chosen platform
As well as making sure the platform is suitable to hold your organisation's privileged data, assess if data is suitable to reside on a physical end user device. You should aim to minimise data at rest on such devices because if such data persists, it heightens the risk that it may be compromised.
To minimise this risk, use a dedicated off-device storage repository for your PAW. This allows you to audit file access, user-level access controls and centralised backups of critical information more effectively.
It’s essential to adequately secure the device UEFI because if a threat actor gained physical access, they could override critical device functionality and security controls. Your device UEFI should be consistently configured, locked down, monitored and securely maintained. The NCSC has additional guidance on managing device firmware which helps you choose the appropriate controls.
Finally, you should put in place a suitable mechanism to authenticate users to the PAW device to protect it from unauthorised use. Make use of security co-processors, such as TPMs, that provide hardware-backed protection of the credential on the device including brute-force credential guessing ('anti-hammer') protection. These options often also support strong MFA to administration targets using FIDO2.
Repeated failed authentication attempts should be alerted and investigated. In environments where it’s necessary to enforce a strong separation of duties and have strict accountability for privileged actions, single-user devices are recommended, as it allows for stricter user-device binding.
5.6 Apply equivalent controls to third parties
If a third party is compromised, it offers an access route to all the organisations to which they provide services. This is why a third party access is viewed as a significant risk and should be managed appropriately.
To ensure that your PAW solution is an effective defence, any third party that requires access to your organisation's administration interfaces must also adhere to the same controls.
Where possible, supply third parties with both a PAW device and user account from your organisation. This is the most effective way to ensure you have trust in the device they are using.
But it may not be feasible in cases where a third party is providing management services to multiple organisations. Where this is the case, make sure that the PAW device which they use is built to the same security standards that your organisation has in place. Validate this either through technical or contractual controls. To build trust in the devices a third party uses, you may wish to mandate that a penetration test or risk-based review is carried out.
If you allow a third party to use their own devices, it's essential that they still authenticate through your organisation's identity provider. By retaining control in your environment over the identities a third party uses, you can more effectively control the policies used to validate a user's identity. This could include, for example, the locations from which a user is allowed to authenticate, or the type of MFA used.
When allowing a third party into your environment, you should carry out a risk assessment of their access, and regularly review it. Regular auditing and continuous monitoring of third party access is critical to manage the surrounding risks.
Only allow a third party to access equipment where there is a requirement for them to do so, and use technical controls to limit any further access.
The NCSC defines a PAW as a physical device. Any third party PAW device which connects to your administration interfaces should also be a physical device. Allowing a third party that is working on your behalf to use virtualisation instead of a PAW is not a secure alternative. They must put in place a physical PAW device which complies with your organisation’s polices on PAWs. |
