What is Privileged Access Management (PAM)?

What is Privileged Access Management?

The key is to understand the significance of the word “Privileged.”

A privileged user is someone who has administrative access to critical systems. For instance, the individual who can set up and delete email accounts on a Microsoft Exchange Server is a privileged user. The word is not accidental. Like any privilege, it should only be extended to trusted people. Only those seen as responsible can be trusted with “root” privileges like the ability to change system configurations, install software, change user accounts or access secure data. Of course, from a security perspective, it never makes sense to unconditionally trust anyone. That’s why even trusted access needs to be controlled and monitored. And, of course, privileges can be revoked at any time.

How else do people refer to Privileged Access Management?

The nomenclature for this category of software is still in flux. Privileged Access Management is also often referred to as “Privileged Account Management” or “Privileged Session Management”.

For this reason, the acronym PAM is sometimes also known as PSM or PxM.

Why would I need PAM?

PAM keeps your organization safe from accidental or deliberate misuse of privileged access. This is particularly relevant if your organization is growing. The bigger and more complex your organization’s IT systems get, the more privileged users you have. These include employees, contractors, remote or even automated users. Many organizations have 2-3 times as many privileged users as employees!

Some of these admin users can override existing security protocols. That’s a big vulnerability. If administrators can make unauthorized system changes, access forbidden data, and then hide their actions, you’re in trouble. Insider threats aside, this is a huge opportunity if an outside attacker can gain access using these admin credentials. PAM solves this problem.

A PAM solution offers a secure, streamlined way to authorize and monitor all privileged users for all relevant systems. PAM lets you:

  • Grant privileges to users only for systems on which they are authorized.
  • Grant access only when it’s needed and revoke access when the need expires.
  • Avoid the need for privileged users to have or need local/direct system passwords.
  • Centrally and quickly manage access over a disparate set of heterogeneous systems.
  • Create an unalterable audit trail for any privileged operation.

Components of a PAM Solution

Privileged Access Management solutions vary in their architectures, but most offer the following components working in concert:

  • Access Manager – This PAM module governs access to privileged accounts. It is a single point of policy definition and policy enforcement for privileged access management. A privileged user requests access to a system through the Access Manager. The Access Manager knows which systems the user can access and at what level of privilege. A super admin can add/modify/delete privileged user accounts on the Access Manager. This approach reduces the risk that a former employee will retain access to a critical system. (This situation is far more common that most IT managers would like to admit!)
  • Password Vault – The best PAM systems prevent privileged users from knowing the actual passwords to critical systems. This prevents a manual override on a physical device, for example. Instead, the PAM system keeps these password in a secure vault and opens access to a system for the privileged user once he has cleared the Access Manager.
  • Session Manager – Access control is not enough. You need to know what a privileged user actually did during an administrative session. A Session Manager tracks actions taken during a privileged account session.

How is PAM Different from Identity Management?

PAM is sometimes confused with the broader category of Identity Management. There is some overlap, but the two subjects are separate and quite different. PAM is focused on privileged user access. Identity management concerns authenticating and authorizing any user who needs access to a system. A bank teller who logs into a banking application is authenticated by an IdM solution such as Microsoft Active Directory. Active Directory, which is based on the Lightweight Directory Access Protocol (LDAP) standard, is not well suited to PAM. It’s a great product. It’s just not meant to control privileged users. Not all devices with privileged user accounts integrate easily with Active Directory, for example.

IdM solutions are also often designed with openness in mind. PAM tends to be closed, on purpose. For instance, the OAuth standard enables an enterprise application to authorize access to a mobile app belonging to a third party. (E.g. a bank system uses OAuth to permit a mobile user to see the balance on a stock trading account managed by a different entity.) Or, IdM solutions leverage “security assertions” like SAML to “vouch” for a system user as he or she requests access to data belonging to third parties. PAM does not use security assertions or third party authorization standards. They are neither needed nor wanted in PAM.

Want to learn more about PAM? Contact us!