Principles for secure privileged access workstations (PAWs)
Pages
Page 4 of 10
Principle 2: Design your PAW solution to be usable and secure
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 look for 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 when designing your PAW.
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.
2.1 Design for usability and accessibility
A PAW solution changes ways of working for your users. You should design it with this in mind, taking into account the views of those who use PAWs in their work and not just the views of your risk owners. When you set up a new process, collaborate with your users, and don’t make assumptions about how roles are carried out.
To minimise issues at adoption, carry out user testing and research throughout the process, especially during the early design phases. You should also routinely review the design as the requirements change, as detailed in principle 2.3 ‘implement lifecycle management’.
Factors to consider during commissioning and procuring
Working to the wrong requirements at this stage risks buying or building the wrong thing. Things to consider here include:
- what works well now, and what doesn’t
- who will be doing what, and under what conditions
- understanding work as it is done or prescribed, rather than work as imagined
- using diverse sources of information to gain a better understanding
- scoping usability work, so you have a better chance of getting the usability resources you need
- having suitably qualified and experienced people to carry out usability work, where possible
- not relying only on what people say they want, to avoid designing a ‘faster horse’
- not relying only on technical excellence as this may lead to a ‘perfect’ control that is never used
- identifying the key people and stakeholders, including system owners, administrators, installers and end users
A solution which doesn’t meet user needs will result in workarounds or shadow IT that expose your organisation to more risk. Establish a learning and feedback cycle so that you learn where processes haven’t worked effectively and to help improve the system.
2.2 Understand your resilience requirements
Once in place, a PAW should be the only way of using high-risk accesses to manage systems in your organisation. You should design your PAW solution to be resilient enough to support your systems, in both normal operations and failure scenarios. In the design phase of a PAW solution, consider how resilient it needs to be and the impact if all, or part of it, fails.
Make sure that your PAW is accessible and available to the people who need it, when they need it. As you think about how to make your PAW resilient, also consider its role in the response and recovery of the systems it manages. A PAW solution is an important part of your business continuity and recovery plans. This includes acting as a trusted device when you need to establish emergency access using ‘break-glass’ accounts. By making sure the solution is highly available, you reduce the need for users to resort to non-PAW devices to access emergency break-glass accounts.
There are typically no technical restrictions on the use of break- glass or emergency-access accounts, to ensure they always work when you need them. But, where possible, break-glass accounts should be used from a trusted PAW device, because of the high-risk nature of these accesses. In exceptional circumstances where a PAW is not available and it is business-critical that access or a service is restored, your business policies should allow any device to be used to access the break-glass account. |
You should also think about how you would recover the PAW solution if there is a cyber incident or system failure. This should include emergency-access accounts and procedures, availability of devices for incident investigations, as well as backup solutions.
Some key considerations for break-glass accesses are:
- A break-glass access should be exempt from the technical enforcements outlined in this guidance. It shouldn’t rely on other services to be available when required.
- Within a PAW solution, the break-glass access should only be able to access the systems required to recover functionality. It shouldn’t be possible to connect to the systems which the PAW administers.
- As soon as a break-glass access is activated, it should automatically trigger an alert for immediate investigation and be handled as a maximum criticality incident. Break-glass access should only be used as a last resort and never for any other purpose other than recovery.
- Activating the break-glass access should always result in post-access investigation. After the incident, make a risk-based decision to determine if trust in the solution is broken, and if any of the systems must be rebuilt, to reestablish trust and restore to a known good state. As part of the post-access investigation, you should consider how to reduce your reliance on break-glass accounts: for example, whether you should change any other systems so that the same incident in future wouldn’t require use of a break-glass account. You might also need to review the security of your break-glass access, including changing any passwords that were used during recovery.
Break-glass access should only be used in an emergency. Organisations or third parties should not use a break-glass access as an alternative way to gain remote access to a solution. Using a break-glass access when there is no emergency exposes excess privileges unnecessarily and makes it harder to spot a major compromise. The credentials for the break-glass access route should be stored securely, including as a physical copy. You should make sure that only authorised individuals have access to the credentials and that access is monitored and audited. A break-glass access should be routinely tested to make sure it still works as intended. Testing should also validate the alerting and incident escalation process. |
2.3 Implement lifecycle management
As the technologies and user requirements in your organisation evolve, the PAW solution must evolve too. To support this, put in place an effective lifecycle management process to provide assurance that the PAW solution is effective, from its initial deployment through to end of life.
A key element to achieving this is to make sure you have an established process for change that allows a PAW user to request new functionality. There should be a decision process which establishes if the change is required, and what risks it could introduce to the system. This process should be low-overhead for the user and implemented as a continual process.
A PAW device should be an enabling technology for users which is secure, but which lets them carry out their roles effectively. Managing change effectively helps mitigate the risk that users find alternative ways to carry out their role.
As well as allowing change for new functionality, you should also provide a way to feed back on usability. The feedback process should establish if the solution still meets the needs of your organisation and users. Regularly review the PAW solution to make sure the designed functionality is still required and that it's still relevant to the systems it supports. This helps minimise the attack surface and ensures that any unused functionality doesn’t remain on the device.
