The Importance Of Password Vaulting In IAM & PAM
In the previous article, Part 1 – Access Control was discussed as the first step in setting up a successful Privileged Access Management (PAM) program. Many people see Password Vaulting as the first step in a PAM program, but controlling the access can help reduce the most organizational risk the fastest. Password Vaulting is added as the next step in the maturity curve because it too can significantly reduce organizational risk. As with phase 1, the Password Vaulting phase of a PAM program’s maturity can often overlap with functionality provided by Identity Access Management (IAM) aka Identity Governance Administration (IDG) tools.
Most systems have accounts that are not owned by individuals. This includes service accounts, built-in accounts and other accounts that are not technically owned by a single individual. These accounts have their passwords set to strong values that are not known by any person and stored in a digital vault. Policy can be set to ensure they have very complex requirements and that they are changed at a higher frequency.
Accounts stored in the vault are the most sensitive accounts in an organization. Regulatory compliance, good security posture, and best practices all require that these accounts are unknown to anyone. The functionality of PAM programs will allow for these accounts to have their passwords set to very complex values, encrypted and stored. When they are needed, workflows can be used to enable proper controls to be enforced; all usage can be audited and logged, then the password can be changed again.
By combining the access control portions of stage 1 with these vaulting capabilities, we can allow for the use of privileged access on systems, while using our bastion approach to ensure that all access is key logged and video recorded for audit purposes. Those same role and request examples from earlier are applied to check out the credential for usage as well as gain access to the management applications for the servers.
This portion of PAM has the most significant overlap with IGA. One important piece of IGA is certification of account access within systems. These certifications are audits to ensure the provisioning and de-provisioning controls are being executed properly. Essentially, a certification ensures that every account in a system or with specific types of rights (such as rights that PCI, SOX, and HIPAA auditors are concerned about) have their access reviewed.
When performing a certification, the accounts that are not owned by individual people are certified as well. We typically give this task to the owner of the system or application to ensure that they are still necessary. This step in IGA is an excellent way of determining the accounts that should be added to the password vaulting functionality of a PAM solution. If an account is not owned by an individual and only used by that individual, it should be checked into the password vault, what better way to determine this than to use the certification process to find them, since it will review every single account in the system.
As you check them in, you want the PAM system to manage the lifecycle of that credential automatically. Mature, full-featured PAM software has many different shims to do credential life-cycling, but they will not have connectivity to everything. In mature IGA programs, there are connectors to the most critical business systems. IGA systems can provide mechanisms to maintain credential lifecycles without the need to build a custom PAM connection to the system. If the IGA system is already integrated, that integration can be leveraged.
A common mistake we have seen is for IGA programs to try to handle all of these connections. There are some that just do not make sense.
Connections That Do Not Belong With IGA Programs
1. Admin AD Accounts – We have set this up a few ways in the past. In organizations that incorporate IGA, but no PAM, we add logic to provision a second account for a privileged user to authenticate themselves with elevated rights. This is a best practice in many organizations, but it changes when a PAM program is introduced. With PAM, the need for this is eliminated. When you have password vaulting, generic super-user accounts can be provisioned, then checked out when needed. This helps reduce complexity in the environment and removes a common finding during audits related to missing the removal of the AD admin account owned by an individual.
2. Service Accounts – Similar to AD Admin accounts, with PAM, there is no need for IGA to be involved in the lifecycle of these accounts. PAM software can automatically maintain the password lifecycle. PAM introduces capabilities that can control the processes, allow the change of the credential and programmatically update it in the systems that need to use it. The requirements to handle the provisioning and lifecycle maintenance of service accounts should not reside in an IGA system if a PAM system is in place.
3. Local OS Accounts – IGA systems need to configure connectivity to each system that they provide access specifically. In large organizations, this can be thousands or tens of thousands of systems. This is not what IGA tools were designed to do. PAM systems quickly onboard thousands of systems of various types, scan them for accounts and automatically onboard them into the password vault. While it is possible to do this in IGA tools, PAM tools were designed to do it.
There are additional steps in this stage of a PAM program, such as securing app-to-app, updating scripts and other more advanced features of password vaulting. For the most part, IGA isn’t overlapping this functionality other than the already mentioned features. The primary area where they overlap in these regards is the IGA tool accounts need to be secured by the same lifecycle features as other service accounts. The interesting part is that in over a decade of working with IGA and PAM tools, there still is not any meaningful integration between the two systems and it is always a hefty lift to get IGA service accounts managed and updated by PAM tools.
At this point, the first two phases of maturity have focused on removing as much organizational risk with regards to privileged access as possible. All access is audited, and all credentials that do not have their lifecycle controlled through an Identity Governance Administration program are being maintained through the Privileged Access Management program. Each organization can then evaluate if the final phase of a PAM program’s maturity need be implemented.
Stay tuned for part 3 of this article where we explore PAM Program Stage 3 – Privilege Escalation and Delegation.
Want to learn more? Contact us today for a complimentary consultation on how we can help enhance the effectiveness of your organization’s IAM and Governance tools.