27
October 2020
IAM v PAM - best option for user security?
Andy Harris
All privilege attributes are equal, some are more equal than others
In some ways, IAM (Identity and Access Management) solutions reflect George Orwell's dystopian view of the future. They are promoting the view that if you know everything about a person's identity, then you can deliver a 'single pane of glass' to control everything they can do within an organisation. Therefore IAM is the central view of truth.
This illusion quickly breaks down as soon as you realise that you need to take into account what a Privilege (or Attribute that maps to a Privilege) means. Because these Privileges are so contextual, the further you are from a device, the further you are from the truth of privilege based risk.
As a shorthand, being 'admin' on a local network switch is not the same as being 'admin' on the firewall between your organisation and the Internet.
Let's consider how PAM (Privileged Access Management) and IAM get users signed on to Systems Devices Applications:
.png)
In the above diagram it is the devices that are the infrastructure that support both the users and their applications.
In simple terms we can see that Bob as a user arrives as 'Bob' an identity at an application. But Alice, a SysAdmin, will need to use Privileged Role Based Accounts for systems devices and applications. For Alice, not all applications and infrastructure are in production use.
This is one of the many reasons PAM needs to deliver a clear separation of the User and their Role.
Here's another difference between IAM and PAM users:
- Business users generally interact with 5-6 application suites. Their access that is unlikely to be able to breach an entire database.
- SysAdmins, DevOps and SecOps will interact with hundreds of parts of the infrastructure, and these are often changing, for example development, test and production systems. The Privileged Accounts they use will often be able to breach entire databases.
- Users traverse Infrastructure, NetOps manage Infrastructure.
This is because users and admins enter applications using different interfaces:
.png)
It is this scale between number of interfaces that makes the application of IAM and PAM different. An attribute for use with standard, production business applications is a logical choice of IAM using SAML.
Let's consider an attribute 'ADMIN' for a moment. If an 'identity' arrives at an application with the attribute 'Admin', what does this actually mean. Of course multiple applications will have their own Role for admin, which may well be 'administrator', 'Administrator', 'root' or 'config' etc.
.png)
Now, it is useful to look at how Privileged Access Management approaches the problem by separating the user from the Privileged Accounts. Essentially a Policy maps the Identity of the User to the Role Based Accounts they need to use to get their work done:
.png)
We can summarise the functions of IAM and PAM thus:
- IAM has a purely Identity View of the organisation
- PAM is the confluence of Identity and Application Role for Privileged Users
- Devices have only a Role view of their function
- IAM is operated by HR and extends into managers
- PAM is operated by Senior IT
- Devices are administered by subject matter experts (Automation effectively distills this knowledge for others to use in business specific ways)
The goal of our Privileged Process Automation product is to be able to delegate specific Privileged Processes to the Business users that need them most. There are many examples where repetitive operations need privilege and are better initiated by business users - for example flushing print queues or fixing specific database entries. These are good examples where an IAM attribute can be useful to a Privileged Security Management product. In this case it would indicate that the user has the right to have a Privileged Process run on their behalf rather than the rights to the needed Privileges.
.png)
Therefore we can take a risk view of the policies held in IAM and PAM. We can say that IAM gives us a good view of what general users can do within Applications. Whereas PAM holds the confluence of User Identities and the Roles they can assume on Infrastructure and Applications. This makes PAM the best place to reason about the security posture of your Privileged Users.
Our conclusion is that there is not a single pane of glass, but that it can be reduced to two panes:
.png)
Of course, if you'd like to know more, please get in touch.