Author: Andy Harris, Chief Technology Officer at Osirium

Privileged Access Management (PAM) and Identity & Access Management (IAM), they occupy the same space but have very different outcomes.

From a cursory glance, it might seem that Identity & Access Management and Privileged Access Management are the same thing – they both deal with users, access and roles.

Perhaps the easiest way to see the distinction is that Identity & Access Management delivers for general users through to customers, whereas Privileged Access Management delivers for administrative and privileged users. For customers and general users, Identity & Access Management controls the access and experience that these users have of an application. Privileged Access Management controls the administrative role of an admin user.

Identity & Access Management and Privileged Access Management users enter applications through different interfaces, Identity & Access Management through the ‘shop door’ and ’till’ whereas Privileged Access Management users are ‘back office’ based. Consequently, there is a difference in the attack surface of each:

The shop door has a low attack surface, the ’till’ can reveal a lot about individual customers – but critically can’t download the entire database. The ‘back office’ interface allows for bulk backup of databases, which represent the most significant data breach attack. The ‘back office’ also allows for subtle changes in stock levels, takings, or log files, which – of course – are the attack vectors for insider fraud.

It’s not a chicken and egg situation; Privileged Access Management comes first. This is because Privileged Access Management delivers a connection between privileged users and the role-based accounts that they need. These accounts exist on the raw systems before deployment and continue throughout the lifetime of system, device or application. These are the very accounts that are needed to set up a connection to an Identity & Access Management system in the first place.

Another key difference is scope. An Identity & Access Management user will have access to a low number of business-specific applications. Privileged Access Management users will have access to a larger number of privileged accounts that have full access to both business and technical functions. Equally, there is generally a high number of Identity & Access Management users and a much lower number of Privileged Access Management users.

In short, it’s PAM before IAM to protect the ‘I’ in IAM.

In the steady state, Identity & Access Management integrates well with PAM since Privileged Access Management works best when there is a secure service for verified identity. As your servers pass through Development, then Test and into Production, the administrative accounts need robust security. Osirium’s Privileged Access Management solution works on the basis of Identity In – Role out, or simply put; the organisation must know the identity of the person that is using an administrative account.

Many organisations use the principle of one administrative account per SysAdmin. On the positive side: using this approach, your system logs will tell you who did what on the system. However, regarding security, the organisation’s attack surface increases with the number of SysAdmins (We often encounter 500+ SysAdmins in large organisations). The risk factor is increased significantly when SysAdmins chose their own passwords. The cognitive load for SysAdmins is very high, and it follows that their password hygiene is often poorer than we assume. Of course, a SysAdmin can easily bypass password rules to reuse their favourites.

The combination of Privileged Access Management and Identity & Access Management reduces the load on SysAdmins so that they only need to remember the password (or factors) for their identity. Given that it’s their identity they are protecting, they’ll be choosing strong passwords.

As part of the onboarding of a device, system, or application, into Osirium’s Privileged Access Management platform, the admin passwords are changed to very strong – typically 128 characters. This avoids the issue of shared passwords and the general and the consequent migration of shared password knowledge.

A more sophisticated integration between the two will have multiple benefits, for example:

Privileged Access Management delivers data to Identity & Access Management regarding who can have access to which role-based accounts.

IAM delivers data to Privileged Access Management defining who should have access to privileged tasks (for example IT and customer help desks).

A third parties’ Identity & Access Management reveals the identity of the sysadmin within their organisation that made changes to your organisation’s systems.