Much has been written about the benefits of Privileged Password Management (including by me) and the risks that it addresses, but there may be a lack of a definitive definition of what that is. I will try to solve that right now.
Privileged Password Management is the lifecycle management of the passwords for privileged accounts. This includes accounts such as “root” on Linux and “Administrator” on Windows.
These accounts are not typically owned by any one individual, but must be shared by various people who require the access to perform system functions. This leads to issues of individual accountability, as the account password may be known by more than one individual.
Frequently, these powerful accounts also have the ability to bypass other security controls on the target system. Tracking the usage of these accounts is critical to maintaining control of the system.
The first thing the credit union must do is identify who will lead the process to implement Privileged Password Management. If the credit union has an IT security officer, this would be the normal person to take this role. Otherwise, this may need to be the IT manager, risk officer, or even the CIO.
The person who implements Privileged Password Management may not be the same person involved once the process is defined.
Privileged Password Management involves the following five steps:
1. Identify the Privileged Accounts.
2. Identify the users who should have access to these accounts.
3. Define the process to control the Privileged Account Passwords.
4. Define the review procedures for the process defined.
5. Communicate and train the individuals who will be involved in the process defined.
Step 1. Identify the Privileged Accounts
A good starting point is Item 41 (Inventory list of IT equipment (include servers and a list of services offered on each)) on the “IT Items Needed” section of the NCUA IT Questionnaires Workbook. This will show you the list of all of your servers, and each server will have at least one Privileged Account (“Local Administrator” if Windows, “root” if Unix).
The deciding points of whether or not an account should be on this list are the following:
1. Does the account have the ability to bypass controls on the system? This would apply for Local Administrator on Windows, root on Unix/Linux, enable on Cisco routers, admin/root on firewalls, sa on databases.
2. Is the account shared and capable of making changes that should be done with individual accountability?
3. Does the account have application level change capabilities that should require additional approval or dual control prior to use?
The basic rule is that any server will have at least one Privileged Account. Additional Privileged Accounts will be based on the services running on the device.
Step 2. Identify the Proper Users
Again, a good starting point is Item 36 (Listing of personnel and vendors with special access privileges to administer operating systems, networks, and applications) on the “IT Items Needed” section of the NCUA IT Questionnaires Workbook. This will list all of the people who have the requirement for access to Privileged Accounts.
The challenge is mapping which individuals identified in Step 2 should have access to the Privileged Accounts identified in Step 1. If the security officer is tasked with making these decisions, he or she should look at who has used these accounts in the past and under what circumstances as a baseline for moving forward. This list will become an important control for the release of these Privileged Account Passwords.
Step 3. Define the Process
Controlling Privileged Account Passwords consists of four basic tasks:
a) Storing the Privileged Account Password.
b) Changing the Privileged Account Password.
c) Checking the Privileged Account Password.
d) Releasing the Privileged Account Password.
a) Storing the Privileged Account Password
The Privileged Account Password should be stored in a manner that it cannot be known prior to it being released to the authorized user. A process that has been used for years is to write the password on a piece of paper and store the paper in a sealed envelope. The seal on the envelope will indicate that the password has not been released.
The envelope should then be stored in a container that provides protection – the classic example is a safe. Using a secure container prevents loss, damage (hopefully), and provides an additional measure of control for the release of the password. Depending on your disaster recovery requirements, you may also need to have off-site storage in a similar fashion.
b) Changing the Privileged Account Password.
The process to change the password will depend on the target system. The key controls are the following:
1. The Privileged Account Password should be changed by someone who will not be an authorized requestor of the password. If the Security Officer has the ability to change the passwords, and is distinct from the IT users defined in Step 2, then they are a good choice.
2. The Privileged Account Passwords should be changed to strong, random passwords in accordance with the credit union’s password policy. Since random passwords are not easily created by humans, I recommend a random password generator such as this free tool.
3. The Privileged Account Passwords should be typed to avoid confusion over handwriting issues (i.e., “l” versus “1” and “0” versus “O”). Obviously, it is important that the document is securely deleted after it is printed to avoid disclosure of the passwords.
4. Each Privileged Account Password should be on a separate piece of paper in a separate envelope to ensure that only the password requested is released when needed.
5. The decision on when the Privileged Account Passwords will be changed must be made. Best practices have shown that these passwords should be changed periodically (i.e., every 30, 90, or 180 days) as well as after each use. Changing the password after each use ensures that the credit union can provide individual accountability over a shared account since only the requestor will know the password until reset.
c) Checking the Privileged Account Passwords
The Privileged Account Passwords are most often needed in critical situations (e.g., fire call since regular access is not working) and therefore it is critical that these passwords will work. The process to change the passwords should also ensure that the new password is checked before being stored.
Depending on the target system, this can be difficult to accomplish, but experience has shown that confidence in the integrity of the stored passwords justifies the extra time needed for password changes.
d) Releasing the Privileged Account Passwords.
This is typically the most process intensive part of Privileged Account Management. This will define how the authorized users defined in Step 2 get the Privileged Account Passwords defined in Step 1. This will vary widely depending on your IT environment. A typical process is as follows:
1. A trouble ticket or other notification is created that dictates that a Privileged Account Password is needed. This may be created by IT operations, IT staff, support, etc. The main control is that a record of the requirement is created.
2. The authorized user (defined in Step 2) requests the Privileged Account Password from the organization that has control of the storage of the passwords. This could be IT operations, the security officer, a manager, etc. This person will then check the list (the mapping done at the end of Step 2) to see that the authorized user is allowed to have the Privileged Account Password requested. They would also note if any additional approval or notification is needed. They then would provide the envelope to the authorized user.
3. The trouble ticket would serve as the notification to the person responsible for changing the password if the process dictates the password should be changed after each use.
4. Once the authorized user has finished using the Privileged Account Password, he or she should return the opened envelope back to the person who released the password to ensure that no other individual has access to the password before it is changed.
4. Define the Review Procedures and Timeframes
The review procedures should include at least the following:
1. Review the Privileged Account Password list against the list mentioned in Step 1, to ensure that newly added systems have their Privileged Accounts identified. This should also eliminate Privileged Account Passwords that are no longer needed due to system decommissioning.
2. An entitlement review of the list created in Step 2 to ensure that all authorized users are still valid for the Privileged Account Passwords defined. This should take into account changes of roles or responsibilities.
3. A review to ensure that periodic and usage based password changes are happening as defined in the process.
5. Communication and Training
Once the process has been defined, it must be explained to all affected individuals so they know the procedure moving forward. As explained before, these Privileged Account Passwords are often needed in critical situations, so it is important to run through the procedure prior to putting the process in place. The procedure must also be coordinated with the DR team to ensure that DR is not adversely affected by the changes.
Privileged Account Password Management has been a key control point for IT since the introduction of distributed systems in the 1980s. While this was initially addressed in large scale environments, the issues are the same whether you have 20 systems or 20,000.
It is also important to know that technology solutions, whether commercial product solutions or service solutions, only serve to automate Step 3. Product and service solutions may also provide better solutions for reporting, notification and disaster recovery.