Moving Admin Passwords from the Envelope to the Digital Safe
Who knows the local administrator password on the servers at your credit union? When was the last time the password was changed? When was the last time it was used?
These questions can lead to an uncomfortable silence at many credit unions.
There are some underlying facts that underscore this problem:
1. Every system has administrative accounts, like “administrator” on Windows or “root” on Linux/Unix.
2. These accounts cannot be disabled or removed. They will always have passwords associated with them. Even if your credit union has two-factor authentication for users and system administrators, these administrative accounts will typically still use passwords.
3. These accounts are not typically “owned” by any one individual, but must be available to multiple people who may need this account to patch or restore a system to service.
4. Many of these accounts may have a default or common password, and few are changed regularly.
There are also some regulatory aspects to this issue. FFIEC examination procedures under Tier II, Authentication and Access Control, Access Rights Administration states that financial institutions must “determine that administrator or root privilege access is appropriately monitored, where appropriate.”
And in real world examples of bad things that can happen if administrative passwords are mismanaged, many remember the San Francisco issue in 2008 where a city network administrator refused to divulge the administrative passwords for the network and was arrested.
The problem is basic, but the solution is not always simple or easy. Most organizations have taken one of the following approaches in trying to solve the issue:
1. Do nothing.
2. Manual solutions.
3. In-house technology solutions.
4. Commercial solutions.
The issue with doing nothing has already been raised, so we won’t add anything here. Manual solutions are the typical envelope in the safe method. The privileged account password is set and then stored in an envelope and accessed when it is needed.
There are a couple of issues with this method. First, it doesn’t scale well (which may not be a problem for some credit unions) beyond a handful of accounts.
The second issue is human beings. They are required to set a strong, unique password and write it legibly and correctly before storing it. You also don’t know if it will work until it is needed. In addition, you have no way to prove the person setting the password didn’t write it somewhere else or tell the password to someone.
Finally, from a disaster recovery perspective, unless you provide at least two copies in separate locations, you could have an issue for DR.
In-house technology can make some of these issues better, but in some cases worse. I know an example of a company that tried to streamline the process using a spreadsheet but left the spreadsheet on a shared drive accessible to most of the company. There is also the issue of the person who created the technology leaving, thus leaving the technology at risk for maintenance and support.
Starting in 2003, commercial products were introduced to solve this problem. Unfortunately for credit unions, most of these solutions were designed for Fortune 2000 companies which required complex products that could support tens of thousands of systems, and had a price tag to match. Very few vendors were designing products for small companies.
This is starting to change, as companies are starting to address this market segment. There are now service solutions and products that are providing some additional options that credit unions can use to address the problem.
In conclusion, when looking at the four choices for solving privileged password management, doing nothing should not be an option. Even a manual solution will at least give you some control over these highly critical passwords.
So if your answer to the question “who knows your administrative passwords?” is silence, take the steps to have a better answer before you are asked again.