Your Weekly Tech Tidbit…Walking the road toward NIST compliance…Controlled Use of Administrative Privileges

December 19th, 2020
Your Weekly Tech Tidbit…Walking the road toward NIST compliance…Controlled Use of Administrative Privileges

 

Controlled Use of Administrative Privileges / DETECT / PROTECT..Change Default Passwords..Ensure the Use of Dedicated Administrative Accounts

There is a lot here to unpack.

If you haven't done so already, you should try very hard to break your reliance on the default "Administrator" account. You should try to have discrete administrator accounts for each user authorized as an "admin" user. If I have an account Scott-Admin, it shouldn't be the account that I use sitting at my desk surfing the internet or doing email. All administrator accounts should be treated like a master key. When I need to have that level of control, I use that account, just like I would get a master key to unlock a specific door.

I would also seriously question who needs that true Administrator account to begin with. If Ford Motor Company can run the company worldwide with 3-4 true admin accounts, you probably don't need 7-13 (what we generally see when we look). The secret to limiting administrative privileges is delegation. Here are a few examples of what you don't need a true administrator account for:

  • Active Directory User and Group Management including lock outs and password resets.
  • DNS Management
  • DHCP Management
  • Domain Joining Computers
  • Remoting into servers or computers

Many sites will set a garbage password and disable the true Domain Admin and Local Admin accounts and setup an innocuous named account instead - say Mary Domingo (mdomingo). It is just another name on the list. Some rename the default accounts and then create fake Administrator accounts with no rights, disabled, and a garbage password. We do this because we can to see if anyone or anything is attempting to go after our default Administrator accounts. Failed logins for the fake, default (now guest) accounts means someone is trying to do something bad to you.

Microsoft makes the free Local Administrator Password Service (LAPS) to allow you to centrally manage and change your local Administrator passwords for whatever local account you designate.

For cloud implementations I have repeatedly heard the recommendation that you create a "break glass" admin account to use if you've lost control of the cloud system. This is specifically an admin ID with a 255 character super complex password. This ID will not have multi-factor authentication. You take this ID and literally put it and the password locked away in a drawer (air gapped). This ID is for emergency access only. It should never be used for normal administrative functions.

Then we move to the question of tracking use of these privileges. Paladin Sentinel Monitoring provides some basic tracking of IDs, changes, lockouts, and RDP connections. For a more robust tracking of what is going on with IDs and shares and rights I strongly suggest you add a true Auditing server to your network. It isn't that hard to do. Our friends at UserLock also have an awesome ID tracking, reporting and security tool.

For those that have done all the basics and already have auditing in place the next steps would be:

  • Multi-factor authentication (MFA) for logon and RDP and cloud app access.
  • Implementing Microsoft Just In Time (JIT) functionality (found in Windows Server 2016 and higher)
  • Implementing a true Microsoft Red Forest design (Privileged Access Model - PAM)
  • Implementing a "least privilege" tool with single use admin credentials managed by the tool. Also PAM.

CSI can help with any of these tasks. If you need assistance, give us a call.

Have a wonderful holiday break. See you in 2021!

-Scott Quimby