Chances are good that many of your servers share administrator passwords that haven't been changed in a long time. Chances also are good that these passwords are well-known to many staff members--including some former ones.
If that doesn't scare you, it should: Anyone who knows the passwords could log in and have complete control over servers and applications, and you'd have no ability to track who made changes or accessed data.
The problems with poor administrative password management extend beyond insiders to external threats as well. Penetration testers have proven that there's a way into nearly every network, and once attackers find it--often in a typical user's desktop--they can reverse-engineer the passwords on the system and discover the local administrator password. If this password is common to other systems, as it often is, attackers can then use it to access other systems and move through the network.
Just as bad, at many companies there's only one system administrator who knows a critical password. This situation is dangerous, as the case of Terry Childs shows. Childs, you may remember, was a network administrator in San Francisco who last year was accused of locking top administrators out of the city's network. At the time, he was the only person with passwords to many of the city's routers.
The dangers of administrator accounts are well known, but few organizations have a comprehensive way to manage these all-powerful accounts. It's not that organizations want to leave themselves open to vulnerability and accountability issues. The problem is that privileged accounts are difficult to manage because there are so many of them. Every server and workstation has a local administrator account, as do most applications. Even services running on servers, such as a backup agent or a Web server, use privileged accounts to function. All the routers, switches, and firewalls on your network do, too.
Some organizations use a low-tech approach to secure administrator accounts, constructing elaborate systems where privileged account passwords are stored in sealed envelopes in a fireproof safe, with a paper record of when they were accessed. These measures are probably better than nothing, but they don't fully address password access control and user accountability, and can quickly become unworkable for larger installations.
At first glance, management of privileged accounts and passwords seems like a problem that an identity management system could solve. Sometimes it can, but identity management is aimed at a different problem: managing the life cycle of accounts tied to actual humans. User accounts need to be created and destroyed as users are hired and terminated, with their access to resources granted or denied based on job roles.
Identity management tools are typically tied to ERP or human resources systems, so changes in employment status trigger matching changes to computer access. They typically implement single sign-on via connectors to applications and directories but can't interface with the more limited systems that form the infrastructure of a network. These tools are built to handle large numbers of users with similar access needs and thus aren't suited to the more specialized needs of accounts that aren't tied to individual employees.
Where identity management systems provide a one-size-fits-all approach to user passwords, privileged account managers provide a custom-fit match to the needs of nonidentity accounts. The standard privileged account management feature set includes generation of a unique, complex, random password for each account and the ability to automatically log in to the client system and change the password.
Nearly all privileged account management systems employ an agentless design, where they use the server's native protocols, such as SMB, Telnet, or SSH, to interactively log in and make password changes, with no preinstallation or configuration of the managed systems required.
When authorized users need access to a privileged account, they can log in to a Web portal and request the password for a particular system. After verifying the user's right to view that password, the system provides it and logs the fact that the user has accessed the password. After the user has finished with the password, the system generates a new password, logs in to the client system, and resets the password (see diagram, "A Stronger Front Line", below). In this way, the user no longer has access without again requesting it through the privileged account manager.
The most secure setup comes from using identity-managed single sign-on to authenticate the individual's access to the privileged account management system, combining the identity-based access control of identity management with the tight control and auditing of privileged account management.
Besides controlling access to servers and accounts, privileged password managers provide enhanced accountability. Since high-privilege accounts aren't tied to individual users--often just to "root" or "Administrator"--there normally isn't a way to tell who actually accessed a system and made a particular change. By logging every time an administrator requests a password, privileged account managers provide an independent log of all access to servers using the administrative accounts.
To further enhance accountability, the systems can be configured so that no other user can access a specific password while it's checked out to another admin. The password is only made available for use after the first user has checked it back in or a specific time has elapsed, and the password automatically changed.
This can be especially useful to meet audit requirements, and most applications can produce extensive reports suitable for presentation to auditors. The logs also can be useful for demonstrating that corporate password policies are being followed in areas of complexity and change intervals.
The second mistake Bosnian mentions almost could be considered a feature: When all privileged passwords are changed as part of a company-wide system rollout, some people lose access they've always had. Even in companies with the best security practices in place, there are employees who need privileged access or have undocumented exceptions to normal job roles. While this can cause an immediate failure of some business processes, it also provides an opportunity to clean up such special cases and ensure that they're handled through proper channels in the future.
Beyond Access Control
Many vendors offer unique features that do more to control access to privileged accounts. For example, Cyber-Ark's just-announced Privileged Identity Management Suite version 5.0 will include the option of creating passwords that aren't presented to users.
Because employees often write down and share passwords, Cyber-Ark's Privileged Session Manager component and similar tools from other vendors can be configured to act as a sort of single-sign-on portal for servers. When an administrator requests access to a system, PSM proxies the actual connection and passes the credentials to the host system transparently, logging in the administrator directly.
PSM also can be configured to record the session between the administrator and the server. This recording can be saved for later review in case there are concerns about the actions taken by the administrator.
Sometimes, it's not a very good idea to store a service's password in a clear text configuration file--in fact, the Payment Card Industry Data Security Standard requires that such embedded passwords be eliminated before the applications are placed into production. Most vendors offer an API that can be used to replace such clear text passwords with a library call that accesses the password vault dynamically at runtime. They even include defenses to validate that an approved application is requesting a password, and not an intruder running the API code.
Another barrier to controlling privileged passwords is finding them.
Phil Lieberman, president of Lieberman Software, says this makes changing passwords almost impossible for many companies. If they change a password without understanding everywhere it may be used, things will break. Most servers have several service accounts, used by processes running on the server to access server or network resources. While most privileged account managers can be configured to change these passwords, doing so without informing the service of the change will result in downtime and lots of scratching of heads.
Most privileged password managers enable organizations to build a workflow around access to passwords. This allows a company to specify which users need approval before accessing passwords, and can automatically route these requests to managers for approval. Hitachi ID Systems' Privileged Password Manager can automatically escalate unapproved requests, searching out additional approvers in cases where the originals fail to respond in a timely manner.
The workflow can be configured to require multiple approvers, implementing a true separation of duties. Workflow can be especially useful for providing access to employees who might not normally need access, such as during a disaster or when regular admins are unavailable.
Once you start relying on a system to provide critical access to all your other systems, your password manager must be rock solid. Besides internal redundancies, look for systems that provide for multiple layers of fault tolerance. Clustering also is a feature to look for, as is the ability to distribute agents throughout your network. These agents spread out the work of setting and checking passwords on the systems throughout your network, preventing bottlenecks and providing extra redundancy.
Passwords are still our first line of security, keeping outsiders out and insiders away from functions they shouldn't touch. The ever-increasing complexity of both networks and organizations makes managing these passwords ever more difficult, and accountability legislation such as Sarbanes-Oxley places high stakes on getting this right.
Avi Baumstein is an information security analyst at the University of Florida's Health Science Center.