Much has been written about the benefits of Privileged PasswordManagement (includingby me) and the risks that it addresses, but there may be a lackof a definitive definition of what that is. I will try to solvethat right now.

Privileged Password Management is the lifecycle management ofthe passwords for privileged accounts. This includes accountssuch 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 toperform system functions. This leads to issues of individualaccountability, as the account password may be known by more thanone individual.

Frequently, these powerful accounts also have the ability tobypass other security controls on the target system. Tracking theusage of these accounts is critical to maintaining control of thesystem.

The first thing the credit union must do is identify who willlead the process to implement Privileged Password Management. Ifthe credit union has an IT security officer, this would be thenormal person to take this role. Otherwise, this may need to be theIT manager, risk officer, or even the CIO.

The person who implements Privileged Password Management may notbe the same person involved once the process is defined.

Privileged Password Management involves the following fivesteps:

1. Identify the Privileged Accounts.

2. Identify the users who should have access to theseaccounts.

3. Define the process to control the Privileged AccountPasswords.

4. Define the review procedures for the process defined.

5. Communicate and train the individuals who will be involved inthe 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 serverwill have at least one Privileged Account (“Local Administrator” ifWindows, “root” if Unix).

The deciding points of whether or not an account should be onthis list are the following:

1. Does the account have the ability to bypass controls on thesystem? This would apply for Local Administrator on Windows, rooton Unix/Linux, enable on Cisco routers, admin/root on firewalls, saon databases.

2. Is the account shared and capable of making changes that shouldbe done with individual accountability?

3. Does the account have application level change capabilities thatshould require additional approval or dual control prior touse?

The basic rule is that any server will have at least onePrivileged Account. Additional Privileged Accounts will be based onthe services running on the device.

Step 2. Identify the Proper Users

Again, a good starting point is Item 36 (Listing of personneland vendors with special access privileges to administer operatingsystems, networks, and applications) on the “IT Items Needed”section of the NCUA IT Questionnaires Workbook. This will list allof the people who have the requirement for access to PrivilegedAccounts.

The challenge is mapping which individuals identified in Step 2should have access to the Privileged Accounts identified in Step 1.If the security officer is tasked with making these decisions, heor she should look at who has used these accounts in the past andunder what circumstances as a baseline for moving forward. Thislist will become an important control for the release of thesePrivileged Account Passwords.

Step 3. Define the Process

Controlling Privileged Account Passwords consists of four basictasks:

a) Storing the Privileged Account Password.

b) Changing the Privileged Account Password.

c) Checking the Privileged Account Password.

d) Releasing the Privileged Account Password.

Details:

a) Storing the Privileged Account Password

The Privileged Account Password should be stored in a mannerthat it cannot be known prior to it being released to theauthorized user. A process that has been used for years is to writethe password on a piece of paper and store the paper in a sealedenvelope. The seal on the envelope will indicate that the passwordhas not been released.

The envelope should then be stored in a container that providesprotection – the classic example is a safe. Using a securecontainer prevents loss, damage (hopefully), and provides anadditional measure of control for the release of the password.Depending on your disaster recovery requirements, you may also needto have off-site storage in a similar fashion.

b) Changing the Privileged Account Password.

The process to change the password will depend on the targetsystem. The key controls are the following:

1. The Privileged Account Password should be changed by someone whowill not be an authorized requestor of the password. If theSecurity Officer has the ability to change the passwords, and isdistinct from the IT users defined in Step 2, then they are a goodchoice.

2. The Privileged Account Passwords should be changed to strong,random passwords in accordance with the credit union's passwordpolicy. Since random passwords are not easily created by humans, Irecommend a random password generator such as this free tool.

3. The Privileged Account Passwords should be typed to avoidconfusion over handwriting issues (i.e., “l” versus “1” and “0”versus “O”). Obviously, it is important that the document issecurely deleted after it is printed to avoid disclosure of thepasswords.

4. Each Privileged Account Password should be on a separate pieceof paper in a separate envelope to ensure that only the passwordrequested is released when needed.

5. The decision on when the Privileged Account Passwords will bechanged must be made. Best practices have shown that thesepasswords should be changed periodically (i.e., every 30, 90, or180 days) as well as after each use. Changing the password aftereach use ensures that the credit union can provide individualaccountability over a shared account since only the requestor willknow the password until reset.

c) Checking the Privileged Account Passwords

The Privileged Account Passwords are most often needed incritical situations (e.g., fire call since regular access is notworking) and therefore it is critical that these passwords willwork. The process to change the passwords should also ensurethat the new password is checked before being stored.

Depending on the target system, this can be difficult toaccomplish, but experience has shown that confidence in theintegrity of the stored passwords justifies the extra time neededfor password changes.

d) Releasing the Privileged Account Passwords.

This is typically the most process intensive part of PrivilegedAccount Management. This will define how the authorized usersdefined in Step 2 get the Privileged Account Passwords defined inStep 1. This will vary widely depending on your IT environment. Atypical process is as follows:

1. A trouble ticket or other notification is created thatdictates that a Privileged Account Password is needed. This may becreated by IT operations, IT staff, support, etc. The main controlis that a record of the requirement is created.

2. The authorized user (defined in Step 2) requests thePrivileged Account Password from the organization that has controlof the storage of the passwords. This could be IT operations, thesecurity officer, a manager, etc. This person will then checkthe list (the mapping done at the end of Step 2) to see that theauthorized user is allowed to have the Privileged Account Passwordrequested. They would also note if any additional approval ornotification is needed. They then would provide the envelope to theauthorized user.

3. The trouble ticket would serve as the notification to theperson responsible for changing the password if the processdictates the password should be changed after each use.

4. Once the authorized user has finished using the PrivilegedAccount Password, he or she should return the opened envelope backto the person who released the password to ensure that no otherindividual has access to the password before it is changed.

4. Define the Review Procedures andTimeframes

The review procedures should include at least the following:

1. Review the Privileged Account Password list against the listmentioned in Step 1, to ensure that newly added systems have theirPrivileged Accounts identified. This should also eliminatePrivileged Account Passwords that are no longer needed due tosystem decommissioning.

2. An entitlement review of the list created in Step 2 to ensurethat all authorized users are still valid for the PrivilegedAccount Passwords defined. This should take into account changes ofroles or responsibilities.

3. A review to ensure that periodic and usage based passwordchanges are happening as defined in the process.

5. Communication and Training

Once the process has been defined, it must be explained to allaffected individuals so they know the procedure moving forward. As explained before, these Privileged Account Passwords areoften needed in critical situations, so it is important to runthrough the procedure prior to putting the process in place. Theprocedure must also be coordinated with the DR team to ensure thatDR is not adversely affected by the changes.

Summary

Privileged Account Password Management has been a key controlpoint for IT since the introduction of distributed systems in the1980s. While this was initially addressed in large scaleenvironments, the issues are the same whether you have 20 systemsor 20,000.

It is also important to know that technology solutions, whethercommercial product solutions or service solutions, only serve toautomate Step 3. Product and service solutions may also providebetter solutions for reporting, notification and disasterrecovery.

Kris Zupan, CISSP, is CTO atRallypoint Solutions LLC in Wilmington,Del.