Principles for secure privileged access workstations (PAWs)

To design your PAW to be an effective security control, you first need to understand how it will fit into your organisation's existing privileged access management (PAM) strategy. Each organisation is unique, with a different set of threats, risk tolerances and access requirements.

You should consider which use cases and accesses your PAW requires, and how to design it in a way that is appropriate for your wider threat context. A good understanding of the threats to your business, as well as your risk appetite, helps you establish which types of accesses are high risk and should be secured with a PAW.

This principle helps you understand how a PAW complements other privileged access management approaches, and where it provides unique benefits.

An effective PAW solution is designed to meet both your organisation’s user needs and its risk tolerances. Although a PAW can be highly restrictive by nature, it still needs to be an enabling technology. It should provide users with the tools they need to carry out their work effectively, or they will seek less secure alternatives. To ensure you have a secure solution that is also useable in practice, you should take the time to understand these needs. Designing your PAW to balance user needs and risk makes it less likely that people look for less secure workarounds.

As the needs of your organisation and users change over time, the design and implementation of your PAW should evolve too. You will need to revisit and update both for the PAW to stay effective and to help prevent use of insecure workarounds.

A PAW has some of the highest levels of access and permissions in your organisation, so it’s important to build a strong foundation of trust in it, both at the start and throughout its lifecycle. Not doing this could later undermine its security controls.

As part of this, it’s also crucial to consider the supply chain for all of the components, software and services used in your PAW solution. You should think about how you gain effective control and oversight when you design the PAW solution, and how to maintain it throughout its lifecycle.

You should use a ‘clean’ environment to build trust in your PAW solution. A building-block approach is best here, starting with a clean standalone initial device, before then rolling out and operating the PAWs across your organisation at scale. 

Starting small helps you establish a foundation of trust on which to build.

Where a PAW solution is made up of multiple devices, it's important to be able to scale your security controls effectively. This requires a well-secured management platform that is administered from a system you trust.

You should make sure that any modifications or changes to your PAW are consistent and reliable, for example, by using Infrastructure as Code (IaC). This allows you to automate the provisioning and configuration of your infrastructure, which reduces human error. This approach also makes it easier to duplicate environments, streamline updates and maintain compliance across your estate.

You should maintain a single view of device compliance across your estate, and closely monitor any configuration changes to make sure they are authorised.

A PAW device should be configured to meet your organisation's 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 helps prevent a threat actor exploiting them.

Any component of a system that connects externally can pose 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, you should make sure you 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 used to access high privileged or critical services, including when that use is by a third party, and you should make sure that suitable controls are in place for these users too.

Maintaining trust in your PAW is essential but sometimes it may be necessary to enable software or features on it that could undermine its security posture and create additional attack surface. Examples here may include running legacy software that is potentially vulnerable, or allowing local system administration to configure the device.

You should avoid this as far as possible, but if it’s really necessary, you must fully understand the risks of doing so. An alternative is to implement these actions in a way that isolates it from the PAW. You can use virtualisation to achieve this.

If your PAW is attacked, compromised or abused, it’s important to be able to detect and respond accordingly. Implementing protective monitoring and auditing is a crucial part of maintaining trust in your PAW and the wider systems accessed from it. 

If you have in place a good PAW strategy and effective system administration, you should have a good understanding of what actions are allowed, or not allowed, on a PAW device. This understanding will make it easier for you to put in place misuse case detections.

In some situations, you may need to import files to your PAW from an untrusted third-party location. If this data is malicious, it affects the integrity of your PAW. 

Similarly, you may need to export data from your PAW which risks sensitive data leaving your device and getting into the hands of an adversary. 

This presents a data import and export challenge to your organisation. Failure to put in place effective data transfer measures can drive the adoption of shadow IT or other poor practice.