Principles for secure privileged access workstations (PAWs)
Pages
Page 6 of 10
Principle 4: Scale the solution
You should make sure that any modifications or changes to your PAW system 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.
4.1 Enforce administration from high trust
A PAW solution relies on a set of policies to determine the technical controls implemented on each PAW device. These controls are critical to the overall security of the solution, as they determine what the device can do, the features it has and the systems it can talk to.
To trust these controls, you must be able to ensure their integrity and maintain an effective audit trail of any changes made. It’s also important to limit who can alter them. Your organisation should have a defined list of PAW administrators and within that, the number of individuals who can alter the PAW solution should be highly constrained and regularly audited. No user outside of this group should be able to make changes.
While 'browse up’ refers to an architectural anti-pattern in which a system is administered from low to high trust, it is essential that a PAW follows the concept of ‘browse down’, where a high-trust system administers a system of equal or lower trust. This means the PAW controls must only be managed from another PAW device. But consider carefully how you will avoid locking administrators out of the solution.
To avoid locking administrators out of the solution, it’s possible to use a technique such as deployment pools. Here you apply policies to a set group of devices, and have a defined delay between each group receiving the updated policies. The controls and policies being applied should be tested before you deploy them at scale, to prevent major outages.
4.2 Implement auditable and validated controls
A set of auditable and validated controls allows you to gain assurance that each device in your solution is compliant, so you can establish confidence throughout its lifecycle, and not just at initial deployment. The controls for a PAW solution should be centralised to ensure that:
- it is possible to enforce consistent control of policies across a deployment
- there is a ‘single source of truth’, namely a definitive overview of the policies applied to each device
When scaling a PAW solution beyond a single device, consider using a mobile device management (MDM) service. The more devices you have, the easier it is to use an MDM to manage them, as it provides the tools to remotely control, monitor and enforce policies on your PAW devices.
Some organisations require multiple segregated identities, such as an identity for operational technology (OT) and another for information technology (IT). A PAW solution should be designed so that it avoids introducing connectivity between these identities, as this could allow a threat actor move laterally between them. To minimise the risk of this happening, use a separate MDM to manage the PAWs in both the OT and IT environments. |
By its nature, the MDM solution has considerable privilege. It can alter the configuration, install applications and execute scripts on your PAW devices, so it’s important to choose and implement a secure one. See the NCSC guidance on MDM for more information.
If the threat model of the system you are administering requires the system to be fully isolated from public and external networks, a cloud-based MDM may not be suitable, and an on-premises solution is the preferred option. An on-premises solution should still support audited and validated controls on the device and not drive standalone or individually built devices. |
When choosing an MDM for a PAW solution, consider whether it supports device attestation. This provides stronger assertions of device compliance and device health, by reporting a set of trusted signals and measurements for the device and the software running on it.
Stronger forms of attestation typically combine hardware-backed key stores and roots of trust with public-key-based cryptographic operations. The use of hardware-backed root of trust allows the measurements to be trusted, even if the device is compromised. The higher level of confidence that device attestation provides is critical for high-trust solutions, such as a PAW device.
4.3 Change management
Where possible, use automation to replace manual administrative processes. This could include using Infrastructure as Code (IaC) and a secure continuous integration and continuous delivery or deployment (CI/CD) mechanism. Where automation is used for configuration management and infrastructure deployments, it becomes easier to detect malicious activity using manual processes.
Use of IaC alongside a secure CI/CD mechanism can enhance your ability to scale and make changes to deployments rapidly. This also allows for effective audit trails over the PAW infrastructure, giving you greater confidence in the system and any changes made. The ability to repeatably deploy infrastructure also makes your PAW solution more resilient.
Effective permissions should limit which users, systems and solutions can alter PAW controls. Monitor for changes so that any controls in your core PAW solution are authorised, and reflected in your updated design and requirements. All changes to the PAW solution should go through the appropriate change management processes in your organisation, and require approval before being actioned.
