Archive for the ‘ID Management’ Category

IAM versus PAM: understanding the differences

Tuesday, September 25th, 2018

I frequently talk to people tasked with “securing privileged accounts” who struggle to understand the roles of different product categories — separating identity and access management (IAM) from privileged access management (PAM).

In the interests of clarity, I thought I’d try to clear the air about what these distinct product categories have in common and where they diverge.

First, lets consider what problems we are trying to solve:

  • There is at least one login ID with elevated security privileges (entitlements) on every system and application that one can sign into. This includes hardware — servers, iLO or DRAC cards, desktops, laptops, network devices, etc.; operating systems and hypervisors; applications and databases; on-premises and cloud services and more. If it’s a physical or logical computing system, there is at least one administrative account on it and in almost all cases, this account only supports password-based logins.
  • These accounts are normally shared by multiple people and sometimes also accessed by software processes (scripts and applications). This makes them shared accounts, which leads to accountability problems — who used this account? What did they do? Was their activity appropriate?
  • The passwords to these accounts are static by default and because the accounts are shared, coordinating password changes is difficult. Static passwords represent an elevated security risk, because the window of opportunity for a bad actor to guess or steal the passwords is large.
  • The passwords to these accounts are often stored in plaintext — in scripts, applications, registry entries, configuration files, spreadsheets or printed on paper. Plaintext passwords are a clear security problem.
  • As these accounts represent an elevated security risk, they should be subject to closer scrutiny: are they still required? Do they really need all the entitlements they are assigned? Who owns them?

    High risk accounts that aren’t really needed should be disabled or deleted, to reduce unnecessary risk. Likewise, entitlements that are not actually used should be revoked. Accounts without clear owners are especially vulnerable to abuse, because (a) nobody can make a determination about their continued need or appropriate entitlements and (b) it’s likely that nobody would notice successful compromise of the account in question.

Alright – so what do we do about it? This is where two product categories come into play:

  • Identity and access management (IAM) systems are used to manage the lifecycle of accounts and their entitlements. Specifically, we can use an IAM system to:
    • Create privileged accounts when needed (often this is not necessary as most systems and applications come with these accounts already present).
    • Disable or delete no-longer-needed accounts.
    • Periodically review these accounts and update information such as who owns them or what access rights they have.
  • Privileged access management (PAM) systems are used to control access to the accounts that already exist:
    • Periodically randomize and vault passwords.
    • Identify, authenticate and authorize people before brokering their access to shared accounts. In other words: directory integration to authenticate users, MFA to authenticate users and single sign-on to launch logins.
    • Record and enable search/playback of login sessions, to create strong, forensic-level accountability.
    • Enable scripts and applications to fetch the passwords they use to connect to services in a secure manner, rather than from plaintext local storage.
    • Periodically change the passwords for service accounts, used to launch scheduled jobs, services and other unattended processes.

In other words, IAM systems manage the lifecycle of accounts while PAM systems act as a gate to gain access to the accounts at runtime.

Incidentally, this is why the industry seems to have finally settled on the terminology “privileged access management” and deprecated older terms such as “privileged identity management,” “privileged user management,” or “privileged account management.” These older terms might lead you to think that a PAM system creates and manages accounts, rather than brokers access to existing accounts, which is wrong in most cases.

In some organizations, there are additional differences, because IAM systems have not (yet?) been integrated with privileged accounts. When IAM systems are not used to manage privileged accounts:

  • The IAM system will typically have a few (or even a few hundred) integrations, as compared to thousands of integrations for the PAM system.
  • It is reasonable to onboard managed systems and applications into the IAM application manually, one at a time. This does not scale for PAM systems, where automation is required to onboard thousands of endpoints at once.

IAM systems also have more normal “uptime” requirements than PAM systems. If an IAM system is shut down for a few hours for maintenance, the few people who needed to request access, approve requests, perform reviews or change their own password during that time window can wait a bit or call the help desk. The impact is not catastrophic. On the other hand, if a PAM system goes down for a few hours, the entire IT operation grinds to a halt as nobody can access the accounts they need to do their jobs.

To summarize:

  • IAM systems:
    • Are used to create, update and delete accounts.
    • Grant and revoke entitlements and track account ownership.
    • May only have a modest number of integrations.
    • Can tolerate modest outages without severe business impact.
    • Are always integrated with major systems and applications that thousands of users sign into.
    • May not be integrated with the thousands of bits of hardware and software that only IT staff sign into.
  • PAM systems:
    • Broker access between strongly authenticated and authorized users and already-present high-privilege accounts.
    • Address the problems of static, plaintext passwords.
    • Are used to introduce strong accountability.
    • Require extreme scale, including in how endpoints are onboarded and removed.
    • Cannot tolerate outages.
    • Typically have thousands of integrations.

Organizations don’t get to choose one or the other — IAM or PAM. All organizations need solutions from both categories.

Groups versus roles

Monday, February 12th, 2018

Periodically, I’m asked what the difference is between groups and roles. This is coming up even more frequently now that we’ve released version 11.0 of the Hitachi ID Identity and Access Management Suite, which includes full lifecycle management of groups (i.e., create, delete, update group objects on systems like AD).

This is actually a harder question to answer than one might think, because different systems and applications use the terms interchangeably. The object that I think of as a group might be called a group on one system (e.g., AD) and a role on another (e.g., SAP).

Ambiguous and overloaded terminology is very common in the IAM business, unfortunately.

Still, there’s a difference, once you define the two terms. To understand it, we should start with definitions. I’ll use Hitachi ID’s standard nomenclature here:

  • A group is an object that exists on a target system (LDAP, AD, SAP, RAC/F, etc.). Accounts are attached to the group as members. The group is assigned security privileges. This way, it’s not necessary to assign individual access rights to each user — which would be painful for a variety of reasons.Note that this is an approximate definition. For example, on some systems, groups can contain other groups as members (AD, RAC/F come to mind). On other systems, groups are also used as mail distribution lists (AD, LDAP). In some cases, a group on one system can contain among its members accounts or groups from another system (AD with cross-domain groups, for example).
  • A role is an object that exists on the IAM system. It’s used to collect entitlements (mainly groups, but also accounts) on target systems for more convenient assignment. Roles are typically nested — i.e., roles can contain other roles.Roles may be “technical” which just means that they represent collections of entitlements that are normally assigned together, but might not make much sense to business users, or they might be “organizational” which means that they represent business functions that requesters, authorizers or reviewers are more likely to understand. The difference here is a bit fuzzy, and that’s OK.

Beyond groups being on the target system and roles being in the IAM system, how are roles and groups different?

It turns out that how these objects are used in practice is quite different!

While IAM software vendors and implementation consultants strive to make role management a business-friendly task that managers will participate in, I’ve found that this rarely comes to pass. Managers rarely have the motivation, skills or time to participate meaningfully in defining or updating role definitions.

This has practical consequences: an IT team is ultimately responsible for defining and maintaining roles. They have limited visibility into business requirements and limited time to spend on any given role. These constraints make role definitions fairly static and formal.

Static, formal IAM roles usually wind up representing business functions (think job code). With static, formal roles it is natural to automatically assign roles: For example, birthright access for employees and contractors, departmental level roles for common access rights, job-code driven roles for jobs that are shared by large numbers of workers, etc. As HR systems or requests update identity attributes, the IAM system recalculates eligibility criteria and automatically assigns or revokes roles.

The consequence of all this is that roles are used to assign highly predictable, very regular access rights to users. If your location, department code, job code or cost centre can be used to predict your access rights and if your access rights are the same as many other people, then roles are the right tool to assign those rights to you, without extra manual intervention.

In practice, some access rights are simply hard to predict based on available data. For example, projects start up and wind down all the time. There is usually nothing in the HR database to indicate that a given user is involved in a project, so automation driven by HR data cannot grant or revoke project-related access rights.

This is part of a general pattern: automatic assignment of rights, via roles or not, only works well if we have both a sufficiently detailed, timely and reliable data source and a matching model that maps from identity attributes to entitlements.

Where this pattern ends is where directly assigned privileges begin. For directly assigned privileges, users could create new roles and request role assignment, but in practice users will skip the role definition step and just request the rights they want. i.e., users will request membership in the security groups that grant access to the share, folder or other item they wish to access, or ask to join a given mail distribution list.

There are two patterns for group membership management: groups may be included in roles, in which case they tend to be automatically assigned to appropriate users, or groups are not part of a role, in which case they tend to be requested on an as-needed basis.

Put another way: roles are formal and static, while groups may also be ad-hoc and dynamic.

What does ad-hoc mean?

  • Ad-hoc groups won’t be automatically assigned, so users must be able to sign into a portal and find and request them.
  • Users often don’t know what group to ask for (or even where to find the request portal), so significant usability support is required.
  • Ad-hoc may also mean creating and deleting the groups themselves, rather than just just requesting membership.
  • Anyone could request anything, so an approval workflow is required to prevent inappropriate requests from being completed.
  • Nobody ever asks for access rights to be reduced, so a periodic access review and revocation process is essential.

And that’s it:

  • Roles are IAM constructs used to build a formal model of predictable, static access rights that are usually automatically assigned,
  • Groups are objects on existing systems and applications. They may either be parts of roles, or may be requested, approved, reviewed and revoked in an ad-hoc manner.