Privileged Access Workstation
Disclaimer: This blog post is not a complete guide on deploying Privileged Access Workstations (PAWs) that work in any environment. The information contained here defines the concept behind Privileged Access Workstations and presents a working generic implementation. Complete implementation requires deep knowledge of the specific infrastructure and definition of all the tasks to ensure that any other activity is denied execution on the machine, which reduces the likelihood of a potential compromise of it, significantly.
It is assumed that network segregation and access control lists are already implemented in your environment, as they are a fundamental part of ensuring the effectiveness of Privileged Access Workstations and the Active Directory Tier model.
The blog post is split in the following sections:
Section 1 - Introduction to Privileged Access Workstation
Section 2 - Deployment of (generic) Privileged Access Workstation
Introduction to Privileged Access Workstation
Privileged Access Workstations (PAWs), is a dedicated workstation for administrative purpose. It is a security hardened, feature and functionality locked-down and is forbidden direct internet access (unless certain cloud-based providers are used by the organization and access is given only to them). PAW should only be used to access or administrate critical infrastructure and perform sensitive tasks.
PAW can be a physical workstation or a virtual machine (VM). Using a VM may weaken the overall security of the PAW and the enterprise architecture behind it, since the virtualization hypervisor is the security boundary, not the PAW itself.
Additional security features are also required - the PAW must be a Shielded VM or similar, due to the fact that hypervisor administrators have the ability to access the PAW (and/or its storage files) through the hypervisor console or by access the datastore.
My recommendation is using a physical workstation, therefore this post includes details about physical PAWs. If you nonetheless decide to go for the VM approach, remember to secure the hypervisor, use full disk encryption and shield the VM.
The most common usage is for Active Directory Tier 0 management and administration, however PAW can be used in a plethora of ways, e.g. in Industrial Control System environments or for Cloud Solutions such as Microsoft 365.
Since PAW implementation is not a one-click implementation, I will be outlining it’s deployment in Active Directory and as such the main purpose of the implementation of the machine is to lock it down to allow only Tier 0 access. The overall actions can be reproduced for creating a PAW for another environment (Azure, AWS, ICS etc.).
An alternative of PAW is the classic “Jump Server”. Jump servers is typically a virtual RDS/Terminal Windows server installed with RSAT and other needed applications required to support and maintain the domain infrastructure.
The jump server should only be accessible for administrators, but the jump server design features a critical caveat. This caveat is called “Clean Source principal” which renders the jump server solution insecure. The clean source principal requires the source to be as secure as the object being accessed.
Administrators would be able to access this jump server from the same workstation, they use to browse the internet and access productions-level applications such as Microsoft Office. Using the same workstation for production use and Active Directory management is the exact problem PAW aims to eliminate by providing a single, secure and one-task designed workstation to the administrators.
If an administrator’s workstation is compromised, his “source” will not be “clean” and thus will his connection to the jump server, shared with other administrators, potentially be compromised. An attacker can keylog (capture physical keyboard keystrokes) the administrator’s credentials, initialize a connection to the jump server, provide the administrators credentials and effectively be domain admin.
A (brief) note on Tiers in Active Directory
The Tier model is 3 layered architectural concept for designing and configuring Active Directory. The tiers are defined as follows:
Tier 0 – Includes identities and systems in control of the Active Directory forest or domain.
Tier 1 – Includes identities and systems associated with the application level, e.g. IIS servers and DBA’s.
Tier 2 – includes identities and workstations associated with the production users and help desk.
The Tier model is meant to be a guideline and used based on system criticality. For example, a domain critical server such as ADCS/PKI would be treated as a Tier 0 system, although it is a member server of the domain.
Read the rest of the blog post here.