Once an organization has secured the paths for access control and vaulted non-named accounts, their organizational risk with regards to a Privileged Access Management (PAM) program is greatly reduced. Many organizations consider their PAM program to be successful if they have reached this point. The final stage, in some organizations, is considered optional. As a Privileged Access Management consulting organization, we intend to educate leadership teams on the processes, best practices, and technologies that make up a PAM program. Whether or not an organization needs to move on to the third stage in the maturity curve is a decision to be made by an informed leadership team.
Once an organization has secured the paths for access control and vaulted non-named accounts, their organizational risk with regards to a PAM program is greatly reduced. Many organizations consider their PAM program to be successful if they have reached this point. The final stage, in some organizations, is considered optional. As a Privileged Access Management consulting organization, we intend to educate leadership teams on the processes, best practices, and technologies that make up a PAM program. Whether or not an organization needs to move on to the third stage in the maturity curve is a decision to be made by an informed leadership team.
Privilege escalation is the final step in maturing a PAM program. Up until this point, we have controlled the connectivity to the administrative interfaces, managed the access and lifecycle of privileged accounts and audited all usage. The final gap to try to close is too much access. At this point, much of the access being used are super users that have more privileges than are necessary to do the task at hand. Privilege escalation is aimed to give only enough access to perform the specific paths.
Rolling this functionality out requires some specific features to make the process manageable in medium to large enterprises.
Features Needed For Successful Privilege Escalation Implementation
1. “Discovery” mode – this is a mode where the privilege escalation software does not execute, but simply monitors all usage. All functions and commands are then recorded so the software can profile usage of escalated rights for different populations of users across the organization.
2. Blacklists – some privileges should just be removed from the majority of the user population. Blacklist functionality can be enabled first to remove these rights from the user population and lower the risk to the organization very quickly.
3. Whitelists – by using the profiling aspects from the discovery mode functionality, a whitelist of functionality for each population can be built to ensure only those rights are allowed and no more. This is where the maximum amount of risk is removed from the organization.
Identity Governance Administration (IGA) overlaps in the definition of these different populations. Once it is determined who gets what rights, they can be easily provisioned to the different user populations using IGA functionality. Upon invocation, the PAM software will check back against the central directory, AD in most circumstances, where a group was assigned by the IGA tool granting them the profiled set of rights necessary to do their work.
A common misconception in the PAM space is that this functionality is limited to servers and IT administrators. This functionality can be enforced all the way at the desktop level for individual users and the local admin token. Most organizations are either provisioning the local admin token to their user population for a specific purpose, such as the need to add printers or install programs. Other organizations have a significant operational impact by not granting this because a ticket must be used each time one of these tasks need to be performed. Privilege escalation can be leveraged to allow specific whitelisted applications and other tasks to be performed without granting the users that local admin token. While this seems like a small thing to organizations that have granted their users local admin rights on their machines, those who have had to deal with a malware or ransomware outbreak will attest to the dangers of increasing the use of the local admin token.
In summary, PAM and IGA programs are very closely related. There will be overlap, and in some cases, organizations will have implemented functionality using one that should have been implemented using the other. Knowing the intended usage, strengths, and weaknesses of each tool will help make better decisions on where the functionality should be maintained. Security is always asked to do more with less, by implementing the tools in the intended ways and using their strengths, you can increase your security and risk posture with less cost and effort.
As a Privileged Access Management consulting organization, many leadership teams ask when these projects will be completed. Please remember that PAM is a program, not a single project. The stages of PAM maturity can be implemented for your existing resources, but all companies change, and as new applications, tools, and infrastructure are added and removed, our PAM best practices will constantly be applied during these lifecycles within an organization. Most organizations will never be completely finished with PAM; they will continuously reduce their organizational risk by ensuring that these best practices are followed with all systems that have any data of value.
This concludes the final article in this 3-part series.
- See Part 1: Access Controls
- See Part 2: Password Vaulting