A Strategy for Protecting Privileged Access
So, there was a major attack recently. Apropos of that, I wanted to re-up how we (Microsoft) recommend folks lay out their environments for security-mindedness. In short we call it Privileged Administration. It's the foundation of our (ugh) zero trust model.
— Steve Syfuhs (@SteveSyfuhs) December 22, 2020
Twitter warning: Like all good things this is mostly correct, with a few details fuzzier than others for reasons: a) details are hard on twitter; b) details are fudged for greater clarity; c) maybe I'm just dumb.
Fundamentally the system is simple* because it's just** about isolation -- isolation of business impact. The more damage you can do to the org the fewer things you're allowed to touch. https://docs.microsoft.com/en-us/security/compass/privileged-access-strategy
*I'm lying.
**It's never "just"
This is somewhat contradictory because by definition highly privileged users have more power. Our model doesn't really reduce these privileges, it just prevents them from being used in certain places.
This is the isolation piece. Domain admins shouldn't be able to do squat in most parts of your network, for instance. They should have an isolated little hole they can live in where *only* domain admins can go.
It's structured into security levels or more often described as tiers. Think of them as high, medium, and low impact.
High impact is all your critical infrastructure and accounts required to manage that infrastructure. These are your DCs and domain admins. They can destroy your business with a single command. Maaaaaybe don't let them log in to user workstations to install random programs?
Medium impact is for specialized roles. They can cause significant damage, but the risk is lower. These are folks like executives, developers touching production, or helpdesk techs.
And then low impact is for everyone else. They can access some stuff, but usually nothing critical.
The delineation of all of these is business impact: how badly can I break the company just by doing my job (poorly)?
That's all well and good, but these are just words and I'm just some person on the internet. Implementation and follow through are critical here.
How does one implement such privileged administration? We have docs: https://docs.microsoft.com/en-us/security/compass/security-rapid-modernization-plan
But start simple. On the Venn diagram of regular user and privileged user accounts, there should be two circles that don't overlap.
That means your domain admin account isn't your daily driver. You don't check your email with DA. You as the admin have two accounts: a named DA account, and your regular low (or medium) tier account.
Also follow the concept of clean source. That is -- the thing you're accessing a resource from should have the same level of security. In other words the laptop you check your email from shouldn't be the machine you RDP into a domain controller with. More on this later.
While you're at it prevent yourself from shooting yourself in the foot: lock down where privileged users can log in. A compromised workstation shouldn't get you keys to the kingdom because a DA logged in three days ago because the user was complaining about something.
Enforce strong authentication starting from high privilege on down. Domain Admins must always log on with smart cards. Period.
Why TF is your DA logging on with a weak password of i@mgR00t!?
This of course gets more complicated the further down the stack you go. Smart cards can be expensive and error prone. Introduce other technologies like Windows Hello or FIDO. Your users will love you and it reduces the number of password resets.
Audit audit audit audit audit audit audit audit audit audit audit. And for the love of god, review the audit logs. There are tools for this. Some cheap, some not. Some good, some...not. Tune it for critical systems and users first, then work your way out.
Build up isolated interfaces for those things that require transitioning between privilege levels. HR apps, group management, etc. Make it easy for users to modify non-impacting data so they don't need super privileges just to change their middle name or add themselves to a DL.
And (or at least) enforce conditional authz policies for such things to require MFA.
Better yet, build out a just-in-time elevation process for these privileges. Even if you *are* logged on as a domain admin you should still have to indicate what permission you want so you can fiddle with stuff.
JIT plus auditing and you have a complete record of what happens in your network.
Once you've done all these things we can revisit this clean source principle. If I'm the IT person managing my domain, how do I access the necessary tools? I'm absolutely not doing it from the machine I check my email from.
Highly privileged access requires high security. Yes, that sounds dumb, but the point is sound: an attacker that compromises your low privilege account should not be able to leverage that into a high privilege account.
So again, that machine you check your email on shouldn't have domain admin creds on it, ever. Use a dedicated machine for highly privileged operations, period. To make your life easier you can create a VM on that machine to check your email.
The difference is you can go from the host into the VM, but not from the VM to the host. These are called Privileged (or Secure) Access Workstations or PAWs/SAWs.
I use one all the time. My daily driver is my corporate desktop. I can access my email and write code on it. However, if I need access to production systems for troubleshooting or fixing stuff I use my SAW.
But I don't use my regular account. I use my privileged account, which requires a smart card to log on. And then I JIT to get the permissions I need to access resources. If I need to access the internet I have a scratch VM running my low privilege account too.
You'll notice I never once mentioned jump servers. That's because they aren't secure as people think. They are by design doing something that breaches isolation. You're transitioning from a low privilege to a high privilege in a low privilege environment.
And also note that this doesn't give you a pass to ignore endpoint security. Security is a group effort. Lock down your machines, keep them patched, deploy ATP, Cred Guard, HVCI, etc.