Privileged Account Management Primer
Privileged IDs are sometimes referred to as the “keys to the kingdom.” It’s a very accurate description since privileged accounts often have the highest level of access to make changes to applications, infrastructure and data. Compounding the risk is that many organizations have not deployed tools to monitor and mitigate the risk posed by privileged IDs.
Only a few individuals typically know the passwords for privileged IDs. This sometimes creates a false sense of assurance for organizations. These trusted IT administrators oftentimes have long track records with their employer. However, sometimes when separations occur between trusted administrators and their employer, the organizations struggle to cut-off access for those administrators. Need some recent examples? Check out this article about a San Francisco based admin who got busted for abusing his privileged access after separation. Identropy’s own Nishant Kaushik blogged on this topic last summer.
Adding to the risk of privileged IDs are similarly powerful service accounts or “application IDs”. These IDs are created and configured for applications to access resources, processes or data. These applications usually require elevated privileges. Oftentimes we see service accounts being granted more access than they need.
Service accounts, like any other account, should adhere to the principle of least privilege. This principle requires that access be limited to the minimum amount of applications, infrastructure and data necessary to complete the intended purpose. When service accounts are given excess privileges, the amount of damage the account can cause increases.
Unfortunately, many (most) organizations do not do a good job of managing service accounts. Typically, there is not a well-orchestrated, centralized process for managing the lifecycle of service accounts. Service accounts are generally the muse of the infrastructure team. They usually require passwords that do not expire and before long, organizations have an unmanageable number of accounts with privileged access and non-expiring passwords. In most cases, a few trusted administrators know those passwords.
This is a problem that can be solved; however it will take a concerted effort by the organization. Privileged Account management is its own IAM program, and like most IAM disciplines requires mature people, processes and technology.
Just as any new process or technology that is deployed, treating the affected people (in this case system administrators) as end-users is important. For the most part, enterprise privileged ID management will add inefficiencies to the day-to-day activities of system administrators. Gaining their buy-in before deploying a new technology or process is imperative. As Nishant pointed out, cultural change can be tough because of our common history of treating IT administrators with kid gloves.
Big change needs executive and grass roots support. The CSO, CISO or even CIO must set the vision and direction. From a grass-roots perspective, I recommend identifying a respected member of the system administrator team, ideally someone with a strong security background, to champion the initiative. This person should buy-in to the idea that it is vitally important to mitigate the risk that privileged IDs pose to the enterprise.
Most likely, you will start your effort to manage privileged IDs by getting an inventory of what access currently exists. You should start by identifying sources – applications, databases, LDAPs, middleware, and network hardware where IDs are stored. The next step will be to audit those devices to determine what access currently exists. This audit can be performed in a variety of ways but I recommend that it include an impartial party rather than tasking the administrators. At the very least, have them provide screenshots of the user administrative interface as proof. The inventory should include privileged IDs that were created for administrative use as well as service accounts.
After developing the inventory, you’ll need a process for managing the IDs. The process should include checkpoints for the entire ID lifecycle. I recommend that approval come from a senior manager or approval body whenever a privileged ID is issued. Look to leverage existing identity workflows for privileged account management where possible – it should be possible to build a connector between your identity administration tool and your Privileged Account Management tool.
I also reccomend a periodic review process such as a quarterly recertification campaign. For service accounts, since they typically have passwords that do not expire, something that is a violation of most organization’s password policy, an exception should be required for those IDs and the exception should expire requiring a renewal.
There are also technologies available to address this issue. Password vaults are becoming very popular on consumer devices and there are apps for iPhones and Android devices. However, enterprise password vaults, while mature, have not seen broad adoption. Password vaults enable organizations to manage privileged IDs by taking them over and issuing passwords on a temporary basis (for example 6 hours – just enough time for the system administrator to perform her work) before automatically changing. The check-in check-out process is also logged for later audit. The idea here is to have a single point of control for privileged access.
In addition to password vault, other enterprise security tools are being used in tandem with identity management to orchestrate what privileged accounts can do. Data Loss Prevention (DLP) tools can provide additional monitoring and prevention to prohibit access to sensitive data or applications. Tools also exist to restrict superuser privileges by changing the OS kernel to allow policy based monitoring and restrictions.
Privileged account management is not only about password vaulting. As I mentioned earlier, privileged account management should be addressed as part of any holistic account lifecycle management strategy. For smaller enterprises though, there are “quick and dirty” point solutions available that can remediate the security risks quickly.
One of the newest technologies to hit the landscape is privileged session management or monitoring. With this technology, companies can record privileged management sessions. This is a great option when systems are managed by multiple administrators or a third party. If forensic work is ever required, there are screen recordings of everything that was done.
Microsoft has developed a new functionality geared towards managing service accounts in its operating systems called “Service Account Management” (see this technet article). The main shortcoming is that this solution is focused on homogeneous Windows environments running Windows 2008 Sp2 or later. Furthermore, there is no GUI. It merits mentioning it here since Microsoft has clearly recognized this issue and this is a first attempt at fixing it. They could mature the functionality at a later date