Principles for secure privileged access workstations (PAWs)
Pages
Page 8 of 10
Principle 6: Isolate high-risk activity from your PAW
Maintaining trust in your PAW is essential but it might sometimes be necessary to enable software or features that could undermine its security posture, and create additional attack surface. Examples here include if you are running vulnerable legacy software, or allowing local system administration to configure the device.
As far as possible, you should avoid enabling such software or features but if it is 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.
6.1 Secure your virtualisation environment
Virtualisation is not an infallible security control and attackers may target vulnerabilities in the environment to gain access to the host system. Virtualisation platforms on a PAW should minimise connectivity between the guest and host OS. As the hypervisor provides security functionality, choose a product that is robust and trusted.
To limit lateral movement, virtual environments should not have direct access to either the hosts or its networks. There are three key things to limit here:
-
Network connectivity between the virtual and host environment
Design the virtual network in such a way that the virtual environment has no direct access to the host or other local machines. Technologies such as network address translation (NAT) can enable this, as it allows the virtual environment to access external networks by translating the virtual private IP address to the host's IP address.
Using a USB ethernet adaptor on the PAW, and passing it directly through to the guest virtual machine, makes it possible to enable connectivity, without having to reconfigure the underlying PAW network configuration.
-
Limiting virtualisation features
Virtualisation technology often comes with tools and features that provide integration between the PAW host and the guest virtual machine. This could include features such as clipboard sharing, file sharing and direct access to hardware devices.
Although these features make guest virtual machines more usable, they add to the attack surface, which could help an attacker ‘escape out’ of the virtual machine. When you enable or configure these features, be aware of these implications, and make a risk-informed decision about whether they are right for your use case.
-
Securing file transfers between the virtual and host environment
In line with one of the core messages in this guidance, you should be thinking about useability when designing your security controls. In some use cases, there is a requirement to transfer files to the guest OS, for example, when transferring configuration files or error logs.
Where possible, data transfers should use underlying pre-built transfer tools provided by the virtualisation platform. Services to transfer data between the host and guest OS should only be enabled for the duration they are required. This lowers the risk of automated or accidental transfers. See principle 8: control data entering and leaving the PAW solution for more about the risks to consider when designing your file transfer solution.
6.2 Use virtualisation to remove privileged local accounts from the PAW
Review the use of privileged local accounts on your PAW on a case-by-case basis, rather than allowing access to privileged accounts by default. Where possible, design away from patterns that require your local users to hold privileged roles on the local PAW device.
When privileged local roles are assigned, they should follow the principles of least privilege. It’s possible to use virtualisation to limit this access to the virtual environment and prevent the user being able to alter the PAW device controls. Some examples of common use cases are:
- An infrastructure administrator requiring the use of local administrator on the PAW device to execute privileged PowerShell management scripts: In this use case, consider if a script must run on the device itself, or if it could run within a VDI, a virtual machine (following principle 5.6), CI/CD pipeline or remote code environment. This removes the execution risk from the end user device, and with it, the need for local device users to hold elevated permissions.
- An OT engineer may require local network access to a field device for configuration, with the ability to change the ethernet IP address of the PAW device: In this use case, you could use a dedicated virtual machine which is built to the same control set as the physical PAW. This allows administrative permissions to the virtual environment, but not on the physical PAW device. See principle 5.6: apply equivalent controls to third parties, for more information about virtualisation.
- Where legacy or overly permissive applications are driving the requirement for privileged local accounts, you should work with the vendor to identify why the application requires these permissions. Where possible, applications which don’t require privileged local accounts are preferred.
6.3 Virtualise obsolete applications and operating systems
In some organisations, the software required for high-risk administration relies on obsolete applications, or applications that run on an obsolete OS.
The ideal practice is that no obsolete software at all should run on a PAW. But where this is simply not feasible for effective operations to continue, primarily in OT environments, you must isolate and separate these high-risk software packages.
As a first step, engage with the vendor of the obsolete app or OS to identify alternative solutions. This could include upgrading to a newer version of the product, requesting that the application is ported to a modern OS, or seeking advice on containerisation or virtualisation of a product.
If obsolete products are still required and no alternatives routes are identified, use virtualisation to segregate them from your PAW. Also note that obsolete software should only be supplied to the users who require it. Document the obsolete products and users as technical debt, and put in place a roadmap to move to modern solutions.
The NCSC has additional guidance on managing the risks from obsolete products and joint guidance with CISA for owners and operators of OT which also covers this.
Virtualising obsolete systems can help to segregate them from the rest of your infrastructure, but a threat actor could use a compromised virtual instance to launch an attack against other virtual instances, or the underlying virtualisation platform itself. You must treat the obsolete OS as insecure by default, meaning you can’t rely on software or management of the obsolete OS to provide security functionality. An obsolete OS must have additional external controls in place. |
Where the legacy virtual environment requires connectivity to external services, put in place an additional virtualised security boundary, which should be pre-configured centrally. The PAW user should not be able to make changes to the security boundaries configuration.
Within your virtualisation platform each obsolete OS should have:
- no direct network connectivity to the host machine
- no connectivity to any other virtualised hosts – each host should have its own virtual network
It's common to see security tooling, such as third-party antivirus solutions, deployed to these obsolete VMs. You should consider any increased external connectivity risk from the virtual environment from these additional tools before they are implemented. As they probably operate from a vulnerable OS, their results can’t be implicitly trusted, meaning an antivirus product on a virtualised obsolete OS has limited effectiveness. Instead, it’s better to carry out additional external monitoring.
