Privileged Access Management

About the Anatomy of a Cyber Security (NIST – Cybersecurity) Program Series

In this blog series, I will be walking you through many of the specific controls that fall into the domains mentioned above. My goal is to give you some insight into the issues, and potential remedies we encounter daily while performing these assessments. Please utilize the suggestions to improve the posture of your own organization. No solution, remediation or mitigating countermeasure is one-size-fits-all; however, I will do my best to provide information from a generic enough standpoint that you should be able to at least find value in the knowledge even if it is not relevant to your environment.

Updated February 8, 2019

For a complete and comprehensive Cyber Security Program, a ‘Privileged Access Management’ plan is yet another critical component. This involves applying the “The Principle of Least Privilege” (PoLP). PoLP is a direct or implied requirement of many compliance directives (HIPAA, PCI-DSS, FISMA, etc.) and is a critical part of most security and governance frameworks include the NIST Cybersecurity Framework (NIST-CSF) and COBIT 5/COBIT 2019.

The following scenarios are very common and show the areas where failing to apply PoLP can have disastrous consequences. Everything a hacker can do to your network with Domain Administrator (DA) or Enterprise (EA) access to your network.

It is fairly common for us to find ourselves three hours into a compliance audit or risk assessment and have the following conversation with the CISO: “We just created an AD user account with EA (Enterprise Admin) privileges and dumped the SAM database. So far we have identified at least 2 distinct paths to EA”. This may be responded to with colorful 4 letter expletives, a disbelieving “You have got to be kidding me!”, or a simple head hung low, but regardless of the initial reaction all are followed by “HOW??”. Most of the time we ask the following questions because they were the root or key enabling factor:

Why does “HelpdeskUser” (the actual name and shared account) or Bob, who is in the “Helpdesk” department have domain privileges?
Why does Jane in accounting have local admin privileges to her PC?
Why does service account SQLAccess have domain admin privileges and a 7-character password that has not been changes in 4 years? (See SAM Dump)

There are more – but you will get the idea quickly. Starting at the bottom and moving up:

Scenario 1: Service Accounts

“We have had that account since we started using SQL or Windows 2000. No one knows what will break if we change the account password or setting”. A service account does not need Domain Admin privileges! See this 2006 article from Microsoft “Securing Critical and Service Accounts” This article will help understand what access these accounts need and do NOT need. Passwords and the need for password complexity will be addressed in another blog post. Use your ‘Change Management’ (also another blog post) process to create a maintenance window to test the changes (one per window). Don’t let the possibility of a change breaking something dissuade you. The alternative is potentially a nefarious individual with Domain or Enterprise Admin privileges waltzing through your network.

Scenario 2: Local Administrative Rights

Users with administrator access on their assigned PC or Laptop. Typically, this happens so the support team does not need to be called if the user needs to update/change something on the PC, so mobile users can add printers, or to make an installed application function (typically to solve write/modify restrictions prevent by default windows configurations). Since Windows 7, ALL of these situations can be solved without giving the user local administrator access. It is inconvenient for the user and support personnel, but so is EVERY measure that increases security. Security and convenience are inversely proportional. Allowing local users administrator access rights gives hackers the ability to find the fastest and most direct path to Domain Admin with free opensource tools like “BloodHound”. It also allows the hacker to install services and software, modify the registry and turn the PC or Laptop into a proxy server (pivot) to scan and find other vulnerable systems on the network. If a helpdesk user with domain administrator access (next paragraph) has logged into the system, then local administrator access gives the hacker, the ability to dump the helpdesk user’s password in plain/clear text. See “Mimikatz”.

Scenario 3: Help Desk Privileges

Helpdesk accounts do not need full DA or EA access to the network, yet on most networks helpdesk personnel do have DA privileges. Helpdesk accounts are the most frequently used and accessed privileged accounts. Many times, an organization with have a common use helpdesk account, frequently called (surprisingly enough) “Helpdesk”, “HelpdeskUser” or, my favorite, “HelpdeskAdmin”. Free tools like ‘Responder’ that come with Kali Linux toolkit, make identifying accounts being used on the network easy and gives the hacker the ability to capture the password hash. The names above tell the hacker which accounts to focus on. The common use account part is not a PoLP issue, it has more to do with Nonrepudiation (a long word that means you know exactly who did it, and when). Lock these accounts down to only the elevated privilege they need to perform their regular tasks and only get DA access for the duration necessary to perform that one off task like reinstalling an application that is corrupted. These accounts should never have regular access to Domain Controllers (DC). One of my favorite tactics, if I can compromise a local administrator account or services account is to turn the “Spooler” service off so the user can’t print. It is usually not long before a user with helpdesk access privileges logs in to find out why. Make sure the hacker wastes his/her time and does not have a direct path to a DC and DA access privileges. Note: Helpdesk, DA and EA accounts should be audited on at least a quarterly, if not monthly, weekly or automated daily basis.

These scenarios are extreme, but very common examples of what we see happen when ‘The Principle of Least Privilege’ is not implemented. System devices, programs, and data are system resources. Each system resource may need to be accessed by users for work to be performed. Access beyond the minimum required for work to be performed exposes the systems and information to a potential loss of confidentiality, integrity, and availability.

Accordingly, the goal of access rights administration is to identify and restrict access to any particular system resource to the minimum required for work to be performed. The organization’s security policy should address access rights to system resources and how those rights are to be administered. Management and information system administrators should critically evaluate information system access privileges and establish access controls to prevent unwarranted access. Access rights should be based upon the needs of the applicable user to carry out legitimate and approved activities on the information systems. Policies, procedures, and criteria need to be established for both the granting of appropriate access rights and for the purpose of establishing those legitimate activities.

The days of “If” you will be compromised are over, it is an accepted fact that it is just a matter of “when”.

Bottom line: If a user, system or process does NOT need access to a file, directory, share, VLAN, printer, or server to do their job or perform a critical function every day…don’t give it t!! If they need temporary access, grant those access privileges only for the period necessary to accomplish that task and audit the account activity after the work is completed.

We will address “Audit Trails” “Logging” and “Monitoring” in other blog posts in the near future.

Happy Hunting!!