Technical Challenges / Solution Requirements
Describing a basic process for periodically randomizing and archiving administrator credentials is easy, while implementing such a process in a manner that scales well to thousands of devices, that is secure and fail-safe can be challenging.
The following sections describe some of the technical challenges such a system must address.
Every type of IT asset has a local administrator password. This is true even if network credentials are used in the normal course of business to manage the device, since a local administrator password must be used to attach each device to the network in the first place.
To be effective, a system for managing administrator passwords should support a broad array of platforms. This includes workstations, Windows servers, Unix servers, network routers, database servers, ERP applications, midrange servers (iSeries, VMS, etc.), mainframe computers, directories and more. In short, every device that contains sensitive data or whose operation is critical to the business should be supported.
Workstations: Location and Connectivity
A privileged access management system can easily make connections to servers, which have fixed network addresses, are always on and are continuously connected to the network. It is much harder for a central system to connect to mobile laptops, for several reasons:
- Laptops frequently move from site to site.
- Even when they remain in one place, laptop IP addresses may change dynamically, due to use of DHCP.
- Laptops are often turned off and do not respond to network inquiries when deactivated.
- Laptops may be unplugged from the network, either to move them or for periods of disuse.
- Laptops may be protected by a firewall that blocks network connections inbound to the PC.
In short, while it is easy for laptops to contact a central server, it is nearly impossible for the reverse to happen reliably.
To reliably secure local administrator passwords on workstations, a password management system should include technology to overcome location, connectivity, address and firewall challenges.
Scalability to Millions of Credentials
A large organization may have thousands of workstations, servers and applications. If each of these IT assets gets a new administrator password daily, the total number of passwords that must be securely managed, including historical data, quickly grows into the millions of passwords.
Note that historical passwords need to be stored along with current ones, since in the event that a managed device crashes and is restored from backup media, its old password will be needed.
A scalable solution for managing administrator passwords must be able to randomize tens of thousands of passwords daily and to keep permanent records of millions of historical passwords.
Reliable Operation and Race Conditions
A robust system for managing administrator passwords must ensure that the password kept in its database for a given administrator account always matches the password on the system in question. This should be true even if an attempt to change passwords failed in the middle of an update.
For instance, if a password management system sets a new password on an IT asset and experiences a connection failure, it is not clear whether the new or old password is actually in effect -- should the value stored in the database be updated?
A robust system for managing administrator passwords must ensure that the password it stores in its database is always the right one -- even if a fault occurred in the middle of a password update.
Fault Tolerance: Hardware, Network and Facility Problems
A password management system must be fault tolerant. If it becomes unavailable, IT workers would not be able to do their jobs -- making failure of the system catastrophic.
Hardware servers, including "appliances" Appliances are generally just branded x86 servers. sometimes fail, due to disk crashes, power supplies burning up, etc. Network connections, especially over wide area links, also sometimes fail. Whole data centers can fail as well, due to power outages, earthquakes, hurricanes, tornados, fires or floods.
If one component of a privileged access management system fails, the accounts it secures must still be available. This is typically accomplished by running at least two servers, ideally at different sites. This means that if one server or one data center goes offline, IT staff elsewhere will be able to keep retrieving passwords and doing their jobs.
Fault tolerance between servers and sites requires data replication between servers. Such data replication must take place in real-time. The alternative -- scheduled, batch replication -- is inadequate. Consider, for example, a backup system that runs nightly. If a password management server were to fail just before a backup cycle begins, then the day's new passwords would be lost. If passwords are changed daily, the current administrator password for almost every system would be lost: a catastrophic event.
Encryption in Transit and Storage
Compromise of even a single privileged password represents business risk. Compromise of many privileged passwords may represent catastrophic business risk. Consequently, a system for securing access to privileged accounts must protect these passwords cryptographically. It should protect passwords both when they are stored (at rest) and in transit: between users and itself, between replicated servers and between itself and target devices.
Connectivity and Firewalls
Networks are increasingly being segmented, to create a layered defense against intruders. This creates situations where the privileged access management system is attached to one network segment while an IT asset to which it controls access is attached to another segment.
To manage passwords on a system on the far side of a firewall, a password management system must be able to send password updates over the firewall. This may not be simple: many network protocols are insecure by design (e.g., SMB for Windows, SQL*Net for Oracle, plaintext LDAP, plaintext HTTP, etc.) and are blocked by firewall administrators for good reason.
To overcome this problem, an effective password management system must be able to replace network protocols that are native to a given target system with its own protocol. The password management system's network protocol must be appropriate to pass over a firewall.
Services and Applications
Sensitive passwords are not limited to those used by human IT workers. There are also service accounts, used to run attended software such as web servers and application passwords. There are also application passwords, used by one service on one computer to authenticate itself to another service, possibly on another computer.
On many systems, service passwords are static and application passwords are embedded in scripts, programs or text files. These passwords unlock login IDs that are often just as powerful as administrator accounts.
An effective solution for managing sensitive passwords should include mechanisms for managing service and application passwords, in addition to managing the administrator passwords used by IT workers. This calls for two specific capabilities:
- The ability to automatically notify one program of the new password it should use to run a second program, after the password on the account used to run the second program has been randomized.
- An API that allows one application to securely fetch a password that it can subsequently use to authenticate itself to another application.
Not every IT worker should be able to access every privileged account. Likewise, applications invoking an API to retrieve a password should only be able to get passwords for services to which they legitimately need to be able to connect.
To enforce such security policies, a password management system must include a flexible access control infrastructure, capable of determining whether a given user of the system -- human or software agent -- should be granted access to a given privileged account.
Audit Trails and Alerts
Every action in the password management system, including looking up assets and their passwords and changing access control policies should be auditable. This creates a chain of accountability between users and their actions.
It also makes sense to link auditable events to alerts. For example, if a legitimate user retrieves a given server's administrator password, the owner of that server might wish to receive an e-mail about the event.
To create accountability, to meet audit requirements and to enable system owners to promptly respond to anomalous administrator activity, a privileged access management system must include detailed logs of user sessions, must retain its audit data indefinitely and must be able to act on, rather than just record, security events.