Privileged identity management (PIM) vs. privileged access management (PAM): In a nutshell

The adoption of cloud technology has forever changed modern identity and access management, with increased data access points, numbers, types and locations of users and privileged accounts.

As a result, data breaches are on the increase in terms of volume and severity. Whilst some attacks are the result of carelessness and a lack of training, the accuracy and volume of phishing attacks mean that we should assume our environment has been, or will be, compromised.

So how do we stop a breach escalating into a major incident? The answer lies in applying proper privileged access management (PAM).

There’s a lot of confusion surrounding PAM and its relation to PIM (privileged identity management). Particularly over what they do and where they live within the Microsoft identity space.

This blog will explore the basics of PAM and familiarise you with its variations, giving you a better idea of what they do, where they do it, and why they’re a good idea.

What is privileged access management (PAM)?

We (hopefully) all learned years ago that performing non-administrative duties via an account with admin privileges is NOT a good idea.

For years, we provisioned users with multiple accounts – one for normal use and another (or more) for administrative tasks.

There are multiple reasons why organisations need to monitor and protect the use of these privileged (admin) accounts:

• A user may log into an insecure computer using a privileged account.
• A user may, intentionally or unintentionally, browse to a hostile site whilst logged in with a privileged account.
• A user may set the same password for their privileged and non-privileged accounts making compromise twice as dangerous.
• In a large organisation, privileged group memberships may become bloated.
• With no-one monitoring the use of privileged accounts or membership of privileged groups, accounts can be compromised and privileges can be escalated unnoticed.

Privileged accounts come in multiple forms, such as global administrator, domain administrator, local administrator (on servers and workstations), SSH keys (for remote access), break glass (emergency access or firefighter) accounts, and non-IT accounts – these may have privileged access due to the nature of the applications and the type of data being consumed (such as a CFO).

Other privileged accounts which are often overlooked, but are just as vulnerable as the ones mentioned above, include service accounts, system accounts, application accounts, and SSH keys used by automated processes.

The modern approach to protecting these accounts is known as privileged access management or privileged access security (PAS). But you may also hear it called privileged identity management (PIM) or Cloud PAM, depending on where and how it’s applied.

The basic principles of privileged access

Broadly speaking, all PAM approaches follow the same basic principles:

• Isolation/scoping of privileges: User accounts used for day-to-day work are not assigned privileges. Privileges must be requested and approved or denied based upon policy.
• Just-in-time administration: Administrators should possess their privileged permissions for the minimum time possible.
• Just-enough administration: Administrators should only have the permissions that they need to achieve the task at hand.
• Elimination of permanent membership of administrative groups.
• Implementation of secure administrative hosts.
• Provide time-bound access to resources.
• Require approval and justification to activate privileged access.
• Enforce multi-factor authentication.
• Configure notifications for when privileged access is activated.
• Configure access reviews.
• Configure audit logging.

So what’s the difference between PIM and PAM? Let’s clear up the confusion around what each provides and what they can (and should) be used for.

PIM and PAM: Sisters or cousins?

In order to protect all of those different accounts mentioned earlier, what we really need is some sort of control, with an audit log, for the IT systems.

If this was a secure physical location that people needed access to, we would put the keys in a box and make people sign them out only when they needed them.

In effect, this is what PIM and PAM do. When a user needs to elevate their privileges, they go to the PIM or PAM site and ask for permission to take the keys. Once this is approved, they are granted the relevant privileges and can do the work. After a set period, the keys are taken back from them and they become a normal user again.

Because the request is audited it is easy to see who had the keys and when. Mistakes become less likely as the user does not always have higher-level access.

So, why do we have both PIM and PAM? Simply put, we have two different directory environments – Active Directory (AD) and Azure Active Directory (AAD). One being on-premises (AD) and one in the Cloud (AAD). PAM deals with elevated privileges on-premises with any system that uses Active Directory to control the access. PIM does the same sort of thing for access to roles in Azure AD.

Easy to remember if you think that ‘pAm’ is Active Directory and ‘pIm’ is Internet.

PIM and PAM can be used to help address the following problems:

• Pass the hash attacks.
• Pass the ticket attacks.
• Spear phishing.
• Lateral movement attacks.
• Privilege escalation.

So, PIM and PAM are related but live in two different realms. One provides access to AD resources and one to the Internet. Cousins separated by an internet pipe. Providing access to elevated privileges for the right users, when they need them. Both have their place, but they work independently to control privileged access to services.

PIM or PAM, which is right for your environment?

Let’s consider two scenarios:

1. A pure-play Microsoft environment, but with a hybrid (on-premises and Azure) deployment

For on-premises control, deploy PAM which uses components including Microsoft Identity Manager (MIM) and provides the following capabilities:

• Just-in-time privileged access to Active Directory and other resources governed by AD group memberships.
• Assign time-bound access to resources using start and end times.
• Request and approval (including auto-approval) of administrative privileges using MIM workflows.
• Logging of workflows, requests, approvals/authorisations and post-approval events.
• Customisable workflows based upon the parameters of the requesting user or the requested role.

For the Microsoft Cloud, leverage Azure Privileged Identity Management (PIM) to manage, control and monitor access to important resources in your organisation.

These resources include those in Azure AD, Azure and other Microsoft online services – for example, Office 365 or Microsoft Intune. This is designed to minimise the number of people with access to secure information or resources. It provides the following capabilities:

• Just-in-time privileged access to Azure AD and Azure resources.
• Assign time-bound access to resources using start and end times.
• Require approval to activate privileged roles.
• Enforce multi-factor authentication to activate any role.
• Use justification to understand privilege requests.
• Get notifications when privileged roles are activated.
• Conduct access reviews to ensure users still need privileges.
• Download audit history for internal or external audit.

Whilst these are two separate capabilities, which share no common framework, it should be possible, and economically sensible, to run them both in parallel.

2. A more complex scenario where multiple cloud vendors are involved

Consider an organisation that runs their business using Microsoft technologies (365, Teams etc.), but for technical reasons need to run payloads using a different cloud solution.

If they also have a hybrid on-premises and cloud-based solution, then we have crossed a complexity boundary from the first scenario – we need a more capable and unified solution.

Currently, only one vendor provides a workable and cost-effective cross-vendor and hybrid capable privileged access solution; the governance and administration controls; and all the automation provided by any capable IDM solution. That’s Saviynt.

In addition to their long-standing privileged access management capability and their remarkable governance platform, Saviynt has now embarked on a cloud PAM journey where time-limited privileges are requested, approved and administrative access occurs and is logged in intimate detail, all without having to leave the Saviynt environment.

The first target is Linux workloads running under AWS, but other workloads and cloud services are on the roadmap for the future.

So, in short, if you are a pure-play single vendor client, then make use of that vendor’s solutions (such as PIM in Azure and Azure AD Identity Governance for Microsoft), but if you require cross-platform capability, or need greater flexibility, then you should absolutely consider making use of the Saviynt platform.

Conclusion

Privileged access management is a must for today’s cloud-driven IT landscape.

As you can see, how you can apply it varies depending on your needs, but, by making use of PIM and PAM correctly, you can ensure that admin privileges are only extended to those accounts and users who need it – and when they need it.