Lessons Learned

Lesson 2 - Least Privilege

No one should have administrative access. All elevated access should be checked out when you need it and checked back in (automatically if possible). Just like UAC. MFA should be required, proximity or push based. And every use of a break glass account should be highly monitored

I think “Least Privilege” has been harped on at least … you know what, let me wager that you can’t find a single infosec or hacking conference from 2000 until now (2022) that doesn’t have 4 talks with the words “least privilege” in the talk. But maybe a handful out of all of those talks tell you how to accomplish such a feat.

The Goal

Lets talk about the goal first though, just-in-time administration. Identity and Access Management (IAM) has tried very hard to steal the “Just-In-Time” (JIT) terminology from the software development and reverse engineering world but I don’t think it has ever stuck. I do however completely agree with it’s concepts. JIT Privilege Access Management (JIT PAM, try to say that acronym in a meeting, probably won’t end well), is the concept where you get rid of all of the administrative accounts across your entire organization, replacing them with temporary (you only have access to the account for a short amount of time) and even sometimes transitory (the admin account gets deleted after use) administrative accounts. That’s the goal, where if you business closes down at 8 PM on a Friday, by 9 PM (for example), there isn’t a single administrative account left on your company network.

Why is this needed?

Right now, in the organization that you work in, can an IT admin use their own administrative account to make a change to your systems or network? Of course, that’s their job. We definitely don’t want to hinder them from doing their job right?

Here are the problems that this scenario faces:

  1. The password for administrative accounts should be much more secure but many times it’s not, since it’s up to a human to select. They also have to type it in a large number of times a day so we don’t want to make it difficult to do so.
  2. The time an administrative user’s password is valid for can be weeks, months, years.
  3. An administrative user can forget or simply not know the correct way to log out of sessions with administrative access (this is super common both on web applications and RDP)
  4. Very rarely have I seen a network completely devoid of “old” or “forgotten” administrative users. This could be a lack of off-boarding process or just laziness but it’s pretty universal.
  5. Where does the administrator write down which systems they are going to access or which actions they are going to perform?
  6. Admins leave all kinds of scripts and saved passwords lying around on systems they only access for short periods of time. We all do this, if we didn’t then kiosks in hotels wouldn’t need to be wiped between use… oh yea, they aren’t… you get the point.

I can use a vaulting product to take care of #1, #2, and possibly help with #4. I can use Active Directory GPOs to work on #2 and #3 possibly. But there is still no accountability around what actions are being performed or on what systems.

How do we get there?

  1. Start with pairing down and auditing the list of administrators. Starting with Domain Admins is easy. Narrow it down to just the people who actually truly need that much access.
  2. Now make a generic Domain Admin accounts instead of the personalized ones and vault them. It’s ok if the admins each still use just one of those accounts. This is getting them used to the idea that these aren’t “their” accounts and they can’t just leave stuff on the desktop or saved passwords.
  3. Make MFA required to check out these generic accounts.
  4. Enable “reason” fields in your vaulting software (like Hashicorp Vault, CyberArk or Thycotic) and push those logs to your SEIM / logging platform (or better yet, into and admins chat channel that the IR team has access to as well)
  5. Make all profile customization (files on desktops, custom terminal sessions, etc) get deleted once the account is checked back in. (this will require roaming profiles or a way to manage it remotely)
  6. Now start doing that for each and every administrative group / accounts, cloud, network infrastructure, virtualization platforms, databases, etc.

Eventually you’ll get to a place where it’s normal for people to check out accounts and have it log why they are doing so, then everything access privilege that account has is revoked and the password is automatically rotated and randomized. You can even get to the point where they have to specify the servers they need to access and it only gives them access to just those servers.