Privileged access rights

Privileged access rights, sometimes called elevated rights or high level access rights, are used to access important or critical components in the infrastructure or application. When you have privileged access rights you might be able to adjust firewall rules, install software on a server or create/modify users in your companies critical application.

As these privileged accounts have access to your critical components, you have an increased risk when these accounts gets compromised. Let me explain with an example. The main job of a database administrator (DBA) is to manage the databases under it’s responsibility. When its account is breached, an unauthorized person is able to access these databases without using the application for which the database is setup for.

These elevated rights are not only used by IT system administrators. Also within applications themselves you might encounter a higher level of access rights, where you are able to manage certain specific functionality, like the setup of user accounts.

This kind of access should be more protected than ‘normal’ user accounts.

How

In order to have control over your privileged accounts, you need to know which onces you have and why their are needed. So start by identifying which functions or systems are critical for you and want to limit access to. Next step is identifying the users, functions or roles which need privileged access.

Have an authorization process setup where people can request privileged access for short term and long term access. Short term access could be used when a small change is required, and a long term access would be needed when a new system administrator is hired.

Make sure that seperation of duties is setup where needed. This means that one person is not able to perform a critical task (like terminating your IaaS account at Microsoft Azure or AWS) and that such actions require at least two persons.

Use seperate accounts for normal usage and privileged usage. What i mean is, don’t setup email for admin accounts and use the ‘Run As’ feature in Windows, or the ‘sudo’ command in Linux when required.

Setup a more comprehensive password policy, using 20 charactor passwords instead of 8 for normal accounts and a shorter expiry date. Also setup Multi Factor Authentication (MFA) where possible.

Only provide privileged access rights when needed. Remove them immediately when not required anymore.

Log all usage of privileged accounts. This is not to check the user who is using the account, but to track any unauthorized actions whenever the account is breached.

Use named accounts. This means that the account is asigned to a single (natural) person who is responsible for the usage of the privileged account. Don’t use default account names, like admin, administrator or root.

Risks

One of the most common risks in setting up privileged access accounts, is the complexity. Start simple and expand from here. But don’t make it more complex than absolutly required.

Example Control Ruleset

When the following controls are used, you should be compliant for this topic:

  • Privileged accounts use at minimum 20 character passwords and MFA
  • Privileged accounts require a password renewal every 1 month
  • Privileged accounts are assigned to a single person
  • Privileged accounts do not use names which reveal the purpose (like admin, root, etc)
  • Privileged accounts are not reused
  • Usage of privileged accounts is logged
  • Brute force prevention is setup for all privileged accounts

Related links

Privileged Identity Management (PIM) at Azure
Managing temporary elevated access at AWS