The term ‘PAM’ is interpreted differently by different people, and by different companies. Everyone agrees on the ‘P’ and ‘M’: ‘Privileged’ and ‘Management’. But the value and meaning of the ‘A’ wants to differ quite a bit: ‘Account’, ‘Access’, ‘Authorization’, … These are all correct and logical, but it is useful - before buying an expensive tool - to first think about what is needed for the organization.
The idea of PAM
The idea behind PAM is to reduce risk to the organization by ensuring a number of things:
- Granting risky permissions at the time they are needed for a particular task and revoking them when the task is done.
- Recording the reason for the issuance of risky permissions so that it is possible to find out afterwards why the permissions were issued.
- Recording transactions carried out with risky rights, so that afterwards it can be traced who did what and when.
This increases security because the user is always fully aware that a risky right is being used and knows that afterwards it is possible to find out what was done with it. By strictly monitoring the use of authorizations in this way it is possible to gain direct insight into misuse.
PUM, PIM and PRM
Broadly speaking, there are three points of view from which you can look at PAM:
- Privileged User Management (PUM)
- Privileged Identity Management (PIM)
- Privileged Rights Management (PRM)
PUM
Privileged User Management focuses on those individuals whose privileges pose an increased risk to the organization. This may be because these individuals (privileged users, PUs) have many rights or combinations of rights that are risky, while the rights themselves are not risky. A good example of this is Nick Leeson - who was able to bring down a bank through a combination of what were in themselves innocent rights.
PIM
Privileged Identity Management focuses on digital identities, often accounts, with high privileges (Privileged Identities, PIs). The most common example of this is management accounts. These have many risky authorizations combined within them. Other PIs that should not be forgotten are:
- Functional system accounts - accounts that are used between systems.
- Vendor accounts - accounts used by external management parties to access their management objects.
PRM
Privileged Rights Management would be better called Privileged Authorization Management, but then that confusing ‘A’ comes back. PRM focuses on the authorizations in high risk applications.
Why PRM?
PRM is the most stringent form of PAM. Issuing and revoking risky permissions at the authorization level ensures that only those permissions are available that are necessary for the task. Once this reason is no longer current, the right is revoked. The main advantage is that only the rights that are actually needed are issued, so the risk of mistakes and abuse is significantly reduced. A disadvantage is that PRM requires an administrative organization that can quickly and accurately issue and revoke these rights. Particularly in the event of disruptions and calamities, such a working method can negatively affect the speed of action.
When PIM?
PIM provides a lower level of security but higher speed. By bundling risky rights into Privileged Identities, instead of determining which rights are needed for each task, common combinations can be bundled into a Privileged Identity. This makes determining which access a person needs for a task easier because the choice is smaller. An example would be a PI with the permissions needed for a particular regular maintenance task. PIs should always be functional, personal PIs should be avoided. There is no added value in permanently associating identities with high privileges to one person. The result will be that each administrator will have their own personal PI, to which a very diverse set of rights has been assigned, some ‘because they needed it once’. Monitoring and managing these personal PIs is an unnecessarily heavy burden on the administrative organization, and risky combinations are not out of the question.
What about PUM?
In order to prevent the stacking of per se innocent permissions into a risky combination, insight must be gained into what the risky combinations are and what countermeasures apply. Such controls and analysis can come from the regular IAM process. Rules for segregation of duties and the risk assessment of certain ‘ordinary’ rights are laid down therein so that the information in the IAM system can be analyzed and these PUs come into view. What, and if, something should be done with that is a human decision and will vary from situation to situation.
In conclusion
As with any project within IAM (and beyond), it is important to properly define in advance what the organization wants to achieve and where its risks lie. With that clearly in view, one can look at what needs to be done about PAM, and whether that is achieved with PUM, PIM or PRM.
©Steven van der Linden, March 2020
