In the first installment of our series on Privileged Access Management (PAM), Tola walked through the key planning issues that need to be considered. Here I will address the critical success factors that should be taken into account when PAM is actually being implemented. We pick up this section with Step #5. Implementation
5. Account Provisioning
It is important that all of the preparation during the planning phase is properly implemented on an organization’s systems to ensure access controls operate as intended. In less controlled environments, users are often given privileges on an ad hoc basis. The user may start out in an overly general user role and then have additional rights and privileges added to their account over time. Unfortunately, when privileges are granted in this fashion they are rarely removed; individual users can accumulate nearly administrator-level access over time without anyone being aware.
To combat this issue, account provisioning must be conducted in a regimented process:
- Roles must be clearly defined at the platform and application level to help determine appropriate privileges for users within those roles. The roles should clearly align with major functions within the system, with an understanding that some duties may also need to be spread across multiple roles for security reasons.
- A management authority should be notified of all new user requests and provide an approval for those requests. These approvals are necessary to ensure all requests are properly vetted and are a key artifact for auditors governing the PAM process.
- Users should be assigned only to appropriate roles. If a user’s privileges need to change, they should be moved to the role that grants those privileges only with the proper approvals (management, system owner, etc.).
- Users and system managers should be required to review access privileges and attest to the need for access so that unnecessary access does not linger and accumulate.
The preceding steps can all be conducted through manual processes, but as the complexity of an organization increases it can also be increasingly hard to keep track of access requests and necessary privileges across the enterprise. Privileged identity management (PIM) tools can aid in the provisioning and management of accounts in complex environments by providing automated mechanisms for correctly provisioning access. The tools can be integrated with the organization’s platforms and applications so that new accounts are created consistently and uniformly. Workflows can be generated to automatically compile access requests and collect necessary approvals. Finally, these tools can provide metrics for analysis. A manual audit of accounts provisioned is still necessary, though it can be done on a sample of systems just to verify the PIM tool is properly configured and working consistently.
6. Implement Password Vaulting
Password management can be a chore for complicated environments and can motivate some users to circumvent rules by writing down their passwords or sharing them with others. This is of particular concern for privileged users as they may have privileged access to numerous system. In this situation a password manager/vault may be necessary.The password manager tool can simplify user interaction by holding the password for target systems and issuing some type of token/ticket for the target system when administrative duties need to be performed. The user may or may not even see the password, as some tools can login on behalf of the user. Either way, this places a gate between users and their use of elevated permissions on a system, which can reduce unintended actions and provide another hurdle to a malicious user.
To further control the use of privileged access the password vault may integrate with a work ticketing system, and require a cross reference or pre-authorization from that ticketing system before granting a user access. The vault could also be the method of implementing an emergency access procedure; if no work ticket exists, users could be presented an option to gain emergency access that would trigger alerts that emergency privileged access has been used.
A password vault can also have the added benefit of reducing user complexity by eliminating the disparate passwords required for various platforms. The vault is a single point of sign on that handles authentication to the various backend systems without requiring the user to memorize multiple passwords. Less passwords to remember means less chance of passwords being written down, enhancing overall password security.
7. Utilize an Emergency Access Process
Always-on privileged access poses two threats. First, a user could accidentally perform an action without realizing they’ve logged in using their privileged credentials. Second, and more dangerous, a privileged user could be taking malicious action on a system such as downloading copies of important documents for exfiltration, and this action likely wouldn’t raise any type of alarm.
An emergency access process can be helpful in addressing this threat. A break-the-glass style procedure where users must formally request access to privileged credentials provides a useful gate for controlling privileged access. The formal request can be used as an alert trigger: when a user initiates the procedure (breaks the glass, so to speak) an email is automatically generated to the user’s manager, relevant IT support department, etc. If the access is part of planned maintenance or known issue troubleshooting/support, the worst that’s happened is an unneeded email. If the access is not legitimate, the alert is a useful tool to kickstart an incident response and hopefully limit the impact of a malicious inside user.
8. Managing Production Code Promotion
Production promotion is the process of moving changes to an application or software into the operational environment, and is often the source of unrealized privileged access to applications. A developer does their coding in an offline version of the application or software that resides in a test or quality assurance environment. In these environments, developers require the highest level of privilege, and rightfully so. Considering that developers can build into the application almost any function or process imaginable, it is extremely important to manage the process of promoting their code to production. A disgruntled employee could build logic bombs or backdoors, or build processes that quietly steal information or even fraudulently change data.
A properly implemented Secure Development Life-Cycle is the first line of defense against this type of threat, and properly implemented procedures for promoting code into the production environment are an important component.
The first step in Production Promotion Management is to ensure that developers do not retain their level of privileged access in the production environment. Any and all privileged access for developers in the production environment should be heavily scrutinized and eliminated where possible. Code reviews should also be conducted to specifically target the “service hooks” which developers often use to legitimately test their own code, but can act as backdoors if not removed when testing is complete.
Promoting code, like all other IT system duties, should be properly separated among multiple users/roles. This might involve requiring system administrators to implement new code or run promotion scripts, rather than granting developers privileges in the production environment. It could also be implemented via temporary privileged access for members of a dedicated Application Support/Development team to promote the code or implement the changes, provided the access is removed immediately after use.
The important principle is that the person who developed the change should not be the same person who promotes this code to production.