This is the second part of a three-part blog post series that looks at different design decisions, considerations and options an organization should bear in mind when planning, implementing and maintaining a tiering model in order to administrate the IT infrastructure securely. It describes the various options for implementation, explains trade-offs that must be made and their residual risks, and outlines the technical measures that need to be taken.
Due to the amount of material necessary to cover the topic, the blog post was split into three different parts:
Part 1
- Introduction
- Design phase
- Different ways of implementing the tiering model
- Classification of systems in (three) tiers
Part 2 (this blog post)
- PAW basics
- Possible PAW implementations
- Securing the PAW
- Administrative access and tools
Part 3
- Privileged account/access management (PAM)
- Changes to AD structure and delegation
- Network segmentation and restriction of administrative access
- Practical benefits of the tiering model
PAW basics
The Microsoft documentation describes PAWs and their tasks very aptly:
Privileged Access Workstations (PAWs) provide a dedicated operating system for sensitive tasks that is protected from Internet attacks and threat vectors.
Source: https://learn.microsoft.com/en-us/azure/active-directory/roles/security-planning
The very specific purpose of a PAW and the strict restrictions significantly reduce the attack surface of these devices. For instance, PAWs should not be able to access the Internet or receive emails, and they should not be able to open PDF or Office files from untrusted sources.
In addition, the clean-source principle should be observed for the software used. For example, the operating system image should be downloaded directly from the manufacturer and then the hash checksum of the downloaded file should be compared with the value specified by the manufacturer. The same also applies to third-party tools such as Notepad++ or 7Zip.
Furthermore, when procuring new PAW hardware, care must be taken to ensure that it meets all the important safety-related requirements wherever possible:
- 64-bit CPU
(possibly already based on Pluton architecture when available[1]) - CPU with Intel VT-x or AMD-V
- CPU instruction set for DMA protection (IOMMU)
- SLAT/EPT
- TPM 2.0
(preferably integrated into the CPU and not as a separate component on the mainboard) - UEFI Secure Boot
- Memory soldered to the mainboard
When it comes to the physical security of the PAW, the companies must again find the compromise that suits them best. For companies with particularly high security requirements, a PAW can, for example, be a workstation housed in a metal cage in a specially secured “PAW room” with an access control system based on more than one factor (such as a key and a biometric authentication mechanism). Other companies use a mobile notebook as a PAW and specify via organizational rules that administrators may use the PAW when working from home, but not in a hotel Wi-Fi or on the train.
Possible PAW implementations
Depending on which implementation type of the tiering model has been chosen in the section “Different ways of implementing the tiering model” in part one of the blog post series (i.e. which tiers may be administered exclusively from PAWs), and depending on the number of administrators of the affected tiers, the number of PAWs to be procured and operated in the future can quickly become quite large. Therefore, once again, a compromise must be found.
PAW implementation with two separate devices
The safest solution is to purchase a second physical device that is used exclusively for administration. The first device, which may already exist, is then used for regular work (including Internet and email use). This allows a strict separation between administrative and regular work, and there is no attack surface of the PAW through Office software, for example, or through websites. In addition, the clean-keyboard principle is adhered to for administration, which dictates that the first computer in the possibly longer access chain for administration (i.e. the computer to which the physical keyboard is connected that the administrator operates) is a particularly secure system. Why this principle is especially important will be discussed in more detail in the following scenarios.
Due to the very specific purpose of the PAW, particularly strict hardening measures can be implemented without causing major technical problems.
The disadvantages of this solution are that the additional computers incur costs for hardware, software and the administrative effort. It is also more cumbersome for administrators to work with, as they now have to use and possibly transport two devices. Depending on how strictly PAW security is implemented, administrators’ collaboration options may be limited because there is no Teams on the PAW and no Internet access.
Host PAW with office VM
A possible alternative, which does not require procurement of new PAW computers, is to format the regular computer already used by the administrators and install it as a PAW after reinstallation. Then a hypervisor is installed on the PAW (e.g. VirtualBox, VMware Workstation or Hyper-V), and the regular computer is virtualized in the form of a VM. Logging in with the tier admin account and all administrative activities are then done directly from the host PAW, and email processing and web browsing are done in the office VM.
This saves the purchase of a second computer, and the administrator always has the PAW and his regular workstation system with him, which makes work more comfortable and flexible.
However, the last point also represents a disadvantage. The administrator then no longer has the option of not taking the PAW into possibly insecure environments. In larger meetings, for example, the PAW might even remain in the meeting room at lunchtime while being switched on, or it requires the discipline of the administrator not to let his computer out of his sight in dangerous situations and to always lock the screen.
Another major drawback of this solution is that there is no strict separation of the two devices, which means that the PAW and the office VM may share a network interface, making isolation of the PAW in a PAW network more difficult or impossible to implement.
Furthermore, the PAW can potentially be attacked via the hypervisor. Using a VM guest-to-host exploit, it may be possible for an advanced attacker to break out of the office VM and compromise the underlying hypervisor and thus the PAW. Other potential problems exist for the regular work on the office VM. For example, there can be performance issues when playing videos or graphically demanding applications because often the GPU cannot be used within VMs or problems occur in general due to the additional virtualization layer. There can also be problems with Bluetooth headsets or other peripherals, e.g., in Teams or Zoom.
Host PAW with an office VDI (Virtual Desktop Infrastructure)
A further development of the latter implementation is to run the office VM not on the PAW itself, but in the company network, e.g., as a Citrix VM. This has further advantages: Due to the stronger separation of the two systems than in the previous scenario, there is no attack surface through guest-to-host exploits, and isolating the PAW in a PAW network becomes much easier to implement. However, the potential performance and peripheral issues still exist. One disadvantage is that “offline work”, i.e., working in the office VM without a connection to the company network, is no longer an option.
Access to PAW from regular office client (not recommended)
An often-discussed approach is to virtualize the PAW on the regular work notebook and perform administration from the PAW VM. This, however, contradicts the clean-keyboard principle, since an attacker who was able to compromise the regular notebook has many opportunities to compromise the PAW as well. For example, he could install keylogger or screen monitoring software or simply copy the PAW VM away.
Summary of possible implementations of the PAW:
