Are Privileged Access Management (PAM) and Identity Access Management (IAM) the same?
Andy Harris
From a cursory glance it might seem that IAM and PAM are the same – after all, they both deal with users, access and roles. But although they occupy the same space, they are very different… Identity and Access Management is clearly important but it's not the complete solution needed for modern IT environments. In this article, we'll take a look at how IAM and PAM are different and why that's a good thing.
Different audiences
Both IAM and PAM are critical areas of cyber security delivering protection to different audiences. Let's start with some basics: What is Identity Access Management? IAM focuses on managing general users through to customers, controlling the access and experience that those users are granted within an application. PAM, on the other hand, delivers for administrative and privileged users by defining and controlling the administrative role of admin users. The combination is very powerful when implementing a "least privilege" strategy (sometimes defined as the "Principle of Least Privilege" with the beautiful acronym "PLOP" :-) ) By ensuring the only the right people (who we can prove via IAM), have the right level of access to the right systems (governed and managed by PAM).
Different scope and risk
IAM and PAM users enter applications through different interfaces. Whilst the audience of IAM enter through the ‘shop door’, PAM users are ‘back office’ based. Consequently, there is a difference in attack surface. The ‘shop door’ (IAM) has a low attack surface and can reveal a lot about individual customers, but does not provide the opportunity to download the entire database. In contrast, the ‘back office’ interface PAM allows for the bulk download of databases, subtle changes in stock levels, takings, or log files, etc. This represents the greater data breach surface. An IAM user will have access to a low number of business-specific applications, whilst a PAM user will have access to a larger number of privileged accounts that have full access to both business and technical functions.
Which should come first?
Whilst both areas of protection are crucial, it’s not a chicken and egg situation…PAM should always come first. This is because PAM 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. In fact, they are so important that they are the very accounts that are needed to set up a connection to an IAM system in the first place!
It’s ‘PAM’ before ‘IAM’, to protect the ‘I’ in IAM.
Working together
In the steady state, IAM integrates well with PAM since PAM 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. Our PAM solution, Osirium PAM, 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. Using this approach, your system logs will tell you who did what on the system. However, the organisation’s attack surface increases with the number of SysAdmins accounts created. This risk factor continues to grow when SysAdmins chose their own passwords. The cognitive load for SysAdmins is already very high, and consequently their password hygiene is often poor. Furthermore, a SysAdmin can easily bypass password rules to reuse their favourites. A combination of PAM and IAM 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.
The combination of PAM and IAM reduces the cognitive load on SysAdmins... Given that it’s their identity they are protecting, they’ll be choosing strong passwords.
When a device, system, or application is on-boarded in Osirium PAM the admin passwords are strengthened – typically to 128 characters (or the maximum character count available). This avoids the issue of shared passwords and the consequent migration of shared password knowledge.
A more sophisticated integration between IAM and PAM provides multiple benefits; PAM delivers data to IAM regarding who can have access to which role-based accounts and IAM delivers data to PAM defining who should have access to privileged tasks (for example IT and customer help desks) – a match made in heaven.
The takeaway
In short, PAM and IAM are not the same but they are highly complementary. Whilst PAM protects users with privileged access to sensitive data, IAM deals with a business’s everyday users. Due to this difference in audience, the data breach surface being addressed by PAM and IAM differ. PAM protects access to business and technical functions, whilst IAM protects against a low number of business-specific applications. Given the critical attack surface of privileged users, a PAM solution should always be primarily implemented, followed by a complementary IAM solution.
Watch our fantastic Chief Technology Officer, Andy Harris, discuss the little-understood difference between PAM and IAM at the 2017 IDM event