The last few weeks, I have been immersed in the topic of privileged identity management (PIM). One aspect of a typical PIM solution got me thinking.
In the old days generic administrative accounts that could not be tied to users were anathema. They required identity and password sharing between multiple administrators and audit trails were useless when it came to identifying who actually performed a specific action.
To address the generic/shared ID problem, best practice was to assign administrators a “standard” account for normal activities and “admin” variations with elevated privileges for everything else. While everyone recognized there was a proliferation of identities resulting from this approach there were few options. To work around the inconvenience of juggling multiple accounts, administrators rarely (read never) used their “standard” accounts. They just always stayed logged in with whichever account had maximum privileges. I distinctly remember a story from our days of penetration testing. My team and I were conducting a security evaluation at a large financial organization. Soon after the project kickoff, an Active Directory administrator took a member of our team to his office to set up accounts that would allow hands on review of the security controls in place. Soon after he unlocked his desktop, he received a phone call. Completely distracted by the content of the call he walked out of his office, leaving my colleague staring at a computer with an active session. Given it was a penetration test, my colleague took this opportunity to check things out and it took just a few keystrokes to discover that this administrator was logged in with an account with very elevated privileges. The keys of the kingdom were left unguarded for many minutes. We recorded the violation and presented it during the final presentation of findings. Interestingly, even though everyone agreed it was not ideal, the security folks were OK with calling this a medium lapse because in their opinion at least the audit trails could be used to make him accountable!
Today there are many security products that are designed to address the issues of privileged identity management and the wheel has turned again. Most products offer the ability for administrators to check out accounts with elevated privileges, perform the activities they need to and then check them back in, at which point the passwords are automatically changed. Additionally solutions can be configured such that administrators can single sign on with these elevated accounts to required target platforms or applications, thereby ensuring that they do not even need to see the passwords associated with the privileged accounts. The identity of the administrator checking out the account, the length of time for which the account was checked out and check in time are all audited as part of normal functionality. Given this the assignment of an “admin” account per administrator adds little or no value and on the flip side contributes to the proliferation of identities that have to be managed.
So what’s best practice now? My recommendation, if you are implementing a PIM solution, is to configure a shared pool of administrative accounts per target within your solution. You can then set a consistent access policy that applies to all accounts within this pool. Administrators can login with a standard organizational account, only needing to check out a privileged account from the shared pool when they need it. If required the number of identities in the shared pool can be adjusted based on usage. Audit trails will ensure you know who checked out an account and the whole problem of accountability is addressed while still controlling the number of identities users have to juggle. You might get some push back from the diehards who always want to leave things as they are, but it’s good to see that somethings are definitely getting better!