- Azure PowerShell vs. Azure CLI - Wed, Mar 15 2023
- Use Azure Storage for backup - Thu, Feb 23 2023
- Azure Data Studio vs. SQL Server Management (SSMS) - Wed, Feb 8 2023
When I entered the IT industry full-time in 1997 (yes, the days in which I had to walk uphill both to and from work in a blizzard, etc.), we normally operated under the following access management "norms":
- Sysadmins used administrative accounts all day long
- Sysadmins often shared use of built-in administrator accounts
- Privileged account passwords were synchronized across all systems
As I sit down to write this piece in spring 2016, I know darned well that there are many shops still operating like this today. I'm not here to moralize or lecture; instead, I want to teach you a bit about the Privileged Access Workstation (PAW) model developed by the Microsoft Cybersecurity Services group.
Windows security trends
Let's start by entering a time capsule and reviewing the progress Microsoft has made over the past dozen years or so with regard to identity/access management. First, we had User Account Control (UAC), introduced in Windows Server 2008.
The idea behind UAC was that administrators could log onto their administrative workstations by using low-privilege Active Directory accounts and then use Run as to temporarily elevate their privilege only when needed.
UAC borrowed heavily from the Unix/Linux su command. Apple's OS X has had temporary privilege elevation for a long time as well.
That said, a problem with Run as is that Windows still caches administrative credentials in the LSASS memory space. This opens systems up to "pass the hash" attacks, privilege escalation, and lateral movement across your network.
It has been a long-standing suggestion to rename the built-in local and domain Administrator accounts and assign strong passwords to them. Of course, the built-in accounts all have well-known security identifiers (SIDs), so an intelligent hacker would ignore the fact that the account is named "Joe" and instead focus on the underlying, unchanging SID.
In Windows Server 2012 we received fine-grained password policies. Now AD administrators can assign a super-strict password policy to high-privilege accounts and more relaxed password policy to end-users. That said, there is still the problem of administrators logging on with high-privilege accounts as a matter of habit.
Smart card authentication is all well and good. After all, multi-factor authentication has shown itself to be a formidable method of protecting user identity. Sadly, Windows caches smart card credentials in LSASS memory as well. If a hacker can hit your workstation with a penetration testing tool like Mimikatz, then you're owned, especially if you're logged on the workstation with domain administrator credentials.
The Microsoft security researchers like to say that identity is today's network perimeter. Also, the current guidance is for Windows systems administrators to adopt an "assume breach" security posture. In other words, we approach system security from the perspective that we're already compromised and we haven't yet discovered that compromise.
How PAW works
At the most general level, the privileged access workstation (PAW) model involves both a logical and a physical separation between standard privilege and high privilege network access. Schematically, it looks like this:
The PAW model--high-level overview
Notice our domain administrator has two completely separate pipelines to corporate resources. Using his hardened, locked-down PAW laptop, he logs on with a privileged account and establishes a secure connection to the privileged management servers. In Microsoft terminology, a privileged access server is a Windows Server machine that holds sensitive data. Examples of privileged access servers include domain controllers, certificate servers, and database servers.
The PAW should not be connected directly to the Internet, and its incoming access is strictly locked down. In other words, the PAW always originates outgoing administrative connections; it does not accept inbound connections itself except when explicitly authorized and configured.
A key principle of the PAW is what Microsoft calls the clean source paradigm. This means that all security dependencies need to be as trustworthy as the object being secured. Consider the following schematic diagram:
The clean source security principle
In the previous figure, notice that the target server (C) trusts incoming connections from the management workstation (B). However, unless we lock down B, then incoming control connections from A to B indirectly grant A control of server C. This is not good!
Making PAW more workable
In information security, we administrators are perpetually balancing high security and user convenience. Password policy is always a good example. By forcing our users to adopt a stricter password policy, we elevate the overall security posture of our environment. On the other hand, user morale (and their opinion of IT) correspondingly decreases due to frustration.
Microsoft advises Active Directory administrators to maintain separate hardware for their admin and user environments. However, this is often easier said than done. First of all, there's more money involved. Then there's the issue of mobility--does the administrator need to pack up her admin desktop PC every time she goes home?
One alternative to the "dedicated hardware" profile is to use notebook computers as PAWs. This way, an administrator can indeed take the admin PC wherever he or she goes and make us of a strong IPSec VPN tunnel when remote administrative access is required.
Another idea is to adopt the "simultaneous use" model of PAW implementation. Take a look at the following graphic:
Running the user PC from within the PAW
Here we ensure that the hardware host runs a qualified operating system. Windows 10 Enterprise Edition is the best choice for many reasons, not least of which is because it supports Device Guard and Credential Guard.
We then make use of Windows 10 client Hyper-V to deploy our user PC as a virtual machine running inside the admin PC. Note that we never want to do the opposite, that is, use the host hardware as our user PC and deploy the PAW as a VM. The reason for this is that the admin PC would consequently be dependent on the user PC, and this violates the clean source rule.
Okay ... how do you implement PAW?
In this article, I've spoken in generalities. This was intentional because (a) this is such a complex subject; and (b) Microsoft has many solutions available for implementing PAW, and we could publish a separate blog post for each and every one of them.
Let me close by giving you some good resources to help you take the next step in your PAW journey.
Start by reading Microsoft's Privileged Access Workstations white paper. This is essential. Next, download the PAW PowerShell scripts and test them out. These scripts create the OUs and Group Policy Objects (GPOs) that support the PAW network model.
The Securing Privileged Access whitepaper is also really good.
Finally, make sure you learn the enabling technologies behind deploying privileged access control. It should come as no surprise that many of these solutions assume Windows 10 Enterprise on the desktop and Windows Server 2012 R2 or Windows Server 2016 on your servers:
Subscribe to 4sysops newsletter!
- Local Administrator Password Solution (LAPS)
- Device Guard
- Credential Guard
- Advanced Threat Analytics (ATA)
- Trusted Platform Module (TPM)
- JEA (Just Enough Administration)
- Enhanced Security Administrative Environment (ESAE)
- Enhanced Mitigation Experience Toolkit (EMET)
