While there are many different ways to authenticate with IT systems, often things still come down to a master password. By creating a password escrow, you can make sure that your systems can be accessed in an emergency.
Proving you are who you say you are has gotten more complicated over the last few years. There are new technologies for user authentication popping up all the time. We’ve seen the rise of security tokens and client certificates, key pairs and biometric devices, and they all have their purposes. In many cases though, the IT systems on your network are still governed by user names and passwords. Good security practice says that no user should have more network rights than necessary to perform their job, but what happens in an emergency? If your IT manager or systems administrator isn’t available, will your help desk have the access they need to keep the organization running?
Security best practices are important to bear in mind, as those techs whose systems have to comply with HIPPA rules can certainly attest. The problem with a limited-access model, though, is that there may be certain things that only one person will know, especially in a smaller organization. Help desk techs may not need the Domain Admin password on a daily basis, but if there’s an emergency and managers aren’t available, it’s important that the enterprise be able to continue. That’s why I’d suggest that one of the most important tasks for admins to consider is planning for password succession. One way to accomplish this is through a password escrow.
An escrow, generally, is when a trusted third party holds an item for someone until a certain condition arises. For our purposes, it means securely storing administrative passwords in the event that other personnel need them. So, how should you go about creating an escrow for your passwords? My solution is pretty informal, but I think it works for my organization.
First, I printed a table of our admin passwords on a sheet of paper. It goes something like this…
Server User Name Password
apple.server.com root alpha
Banana.server.com admin beta
Printers printmgr gamma
Then, I separated the paper into three pieces, cutting between the columns. I sealed each individual piece into an envelope, and labeled the envelopes with the date and a description of the contents—“server address”, “user name”, or “password”. Finally, I signed my name across the edge of the envelope flap. Once I had made my envelopes, I gave one each to three trusted members of upper management.
In my password escrow, three separate trusted individuals have to combine their material to gain admin access. I’ve talked with them about the situations where this might have to be done, and they’re all responsible individuals. I feel certain that no one will breach the escrow unless everyone agrees it’s necessary.
There are ways that the security of my password escrow could be enhanced. It’s probably not suitable for missile launch codes. But I think it will work pretty well for us. Wait. I mean…I hope it won’t ever have to work well for us.
What do you think of my password escrow? Do you have ideas for improving it? Have you handled this issue some other way in your office? Let me know in the comments.