Privileged Account Management (PAM) is a key part of any security strategy. For those of you who may not be familiar with it, PAM focuses on improving the security of privileged accounts and providing more controlled access to those accounts — from an account with Enterprise Admin rights all the way down to an account with local admin rights, and everything in between.
PAM seeks to centralize privileged accounts by hosting all passwords in a vault-like database, for which access can be limited and in which advanced real-time workflows can be put in place to authorize the use of privileged accounts. Further, PAM offers a number of additional capabilities well beyond these basic functions — providing secure remote sessions, using analytics, and even session recording — all in the name of ensuring the highest levels of security regarding the access to and usage of privileged accounts.
Even with all of these capabilities, let’s stop for a moment and consider the purpose of PAM. Whether you already have PAM in place, are in the process of implementing it, or are just learning about it for the first time, it’s important to think about why PAM is necessary and about what else needs to be done to underpin and ensure the success of PAM.
PAM’s purpose is simple — to limit access. The goal is to provide access to only specific privileged credentials to only certain individuals. (In practice, it’s a bit more than that. PAM also involves which client machine is used to utilize the credentials, what days of the week and times the accounts are used, etc. But for the purpose of this blog, this simple definition will suffice.)
PAM’s underlying principle is least privilege. That’s what makes it work. Limit access to accounts so that users have the ability to exercise privilege only when appropriate.
But how do you know your privileged accounts have the least privileges possible?
As noted in previous blogs, 54% of end users cite that they frequently or very frequently have access to information that they shouldn’t. That is, they have too much access. And that doesn’t just include non-privileged users. Administrative accounts can be over-privileged as well.
Because privileged accounts usually get their access via membership within Active Directory groups, it’s easy to see how accounts can become over-privileged. Most IT organizations don’t have a grasp on the current state of their Active Directory groups. It’s more likely that your groups haven’t received enough attention and are actually increasing your risk.
So, if the intent is to limit who has access to and can use privileged accounts, shouldn’t you know whether the access is correct in the first place?
To make PAM as secure as possible, it’s important to establish a foundation of proper Active Directory group management. Whether this is done proactively or reactively, it’s critical to the success of PAM to ensure the following:
- Proper Group Memberships: Members of any group should be attested to periodically in order to ensure that only the necessary users are included.
- Proper Group Permissions: Because permissions are assigned outside of Active Directory, permissions need to be documented and attested to periodically in order to ensure least privilege.
- Proper Groups Presence: Just because a group exists doesn’t mean that it should exist. A groups’ very existence needs to be periodically attested to, in order to ensure that extra permissions aren’t being granted simply because no one wants to delete a group for fear of the unknown.
To make all of this work, you need to make sure that true ownership of groups is in place: One or more individuals should be responsible for the three aspects of group management discussed above, and they should meet periodically to ensure that group security (and, therefore, the least privilege that PAM requires) is correct and up-to-date.
If you’re interested in learning more about how to better manage your Active Directory groups, read the whitepaper 7 Best Practices for Better Management of Active Directory Groups.
Jonathan Blackwell
View ProfileSince 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.