10 things you should know about developing an identity management system

Everyone knows they should securely manage their user-account information, but what about administrative accounts? They're important, so why aren't they under the same microscope? Michael Kassner shares some things he learned while implementing an ID management system.

Everyone knows they should securely manage their user-account information, but what about administrative accounts? They're important, so why aren't they under the same microscope? Michael Kassner shares some things he learned while implementing an ID management system.

A client recently asked me to come up with a quote for an identity management system. The client's organization is relatively small, so I was surprised at the request. Still, I assured the client that I'd check into it right away. Can't be that difficult, it's just managing passwords, right? Well, not exactly. Here's what I discovered.

Note: This article is also available as a download that includes a PDF version and a PowerPoint presentation.

What is an identity management system?

In the process of researching identity management, I came across this definition by the Burton Group:

"Identity management is the set of business processes, and a supporting infrastructure, that provides identity-based access control to systems and resources in accordance with established policies."

What I began to realize

After several days of research, I began to understand the importance of identity management, especially for administrative accounts since they're the "keys to the kingdom." Remember Terry Childs? I also realized there's a lot more to it than just passwords. Fortunately, I knew a consultant who'd been through the process before.

What I was able to learn

With the consultant's help, the project proceeded smoothly. At signoff, she could tell I was pretty excited about identity management and said, "Why not write about it?" At first I didn't think so, not feeling qualified. But then I realized I could at least share what I had learned. So here goes.

1: Determine how many administrative passwords there are

Initially, this seemed trivial. But it can get murky real fast. Besides administrators, every application needing admin rights could have a distinct username and password.

For example, the backup application needs admin rights to access all the data files. It's almost guaranteed that auditors will ask for this information, so you might as well have it ready for them.

2: Establish who has what access

Think number one was difficult? Try asking people what access rights they have. Even people I thought would know didn't.

This can be simple if some type of network management system like Active Directory is in place. If not, it becomes a long drawn-out (but essential) process.

3: Consolidate and automate password management

Creating individual passwords isn't that difficult. What can be difficult is trying to manually manage all of the existing user, application, and device passwords, even in a small organization. Actually, it may be more difficult for an SMB, especially if IT is outsourced.

4: Create a policy defining password properties

An all-encompassing policy outlining the creation and use of passwords gets everyone on the same page. Without it, inconsistencies usually abound, especially in larger organizations with remote sites and multiple administrators.

For example, one admin thinks an eight-character password changed every six months is okay, but someone else requires a 13-character password changed every week.

5: Limit unconditional rights

The concept of all or nothing is alive and well when it comes to access control. You're either an admin with unfettered access or a user so locked down that Windows update doesn't even work right.

That approach may have worked before. But in today's world, free rein may not be in the company's best interest. Adding more levels of access or on-demand access can be beneficial by increasing security and creating a more efficient working environment.

6: Create a policy for disabling user accounts when employees leave

This may seem obvious, but there are countless examples on the Web of let-go employees still having access. Setting up a policy isn't that difficult and it will go a long way toward preventing regrettable situations.

Also, a clear and concise policy will prevent administrators from freelancing when it comes to disabling user accounts. They know exactly what to do and when to do it.

7: Implement a secure method for protecting identity files

Ensuring that identity files including passwords are securely stored and travel over the network in an encrypted format is vital. Most regulating bodies demand it.

This may be difficult for smaller organizations to pull together, as it requires a network-management system at minimum. For example, Active Directory accomplishes this by using Kerberos and a Key Distribution Center.

8: Audit administrative activities

The holy grail of an attacker is administrator (super user) access. It makes no difference whether the attack is from inside or outside the network perimeter; administrative rights are required to alter existing system conditions.

Capturing information about events that require elevated access is the best way to determine if and when an attack occurred. Besides, activity auditing is a healthy deterrent to illegal employee activity, a conclusive record for auditors, and evidence if criminal or civil legal action is warranted.

9: Convey the importance of password security

Ninety percent of all successful insider attacks start out by social engineering a password from a well-intentioned employee. So any identity management system, no matter how well thought out, will fail miserably if users and administrators are not educated and vigilant about keeping their passwords secure.

10: Management needs to buy in

Management buy-in is crucial for identity management to work. It's required to garner top-to-bottom employee acceptance of security measures, as well as to get financial support for the project.

The best way I know of to accomplish this it to convince management that the project will return a favorable ROI. Luckily, there are many case studies on the Web that can be cited as examples.

Final thoughts

The more security-conscious organizations are taking a hard look at who needs elevated access rights and how to manage those accounts. I see no reason why all of us shouldn't be doing the same.

Special thanks to fellow ISSA member Adam Bosian. His article "Privileged ID Management" in the May 2009 ISSA journal was an excellent resource.


Information is my field...Writing is my passion...Coupling the two is my mission.


We set it up the same way. Of course it didn't take any convincing of the administration, or clients, as it was the law. We were under HIPAA and were on a time line to compliance. The only part I didn't get involved in was the creation of log alerts. But that was easier than planning the "Forest - tree" scope of the security needs in our management hierarchy. I get a head ache just thinking about it even now. At the time regulations were interpreted to use a password turn over every three months, with a minimum 9 character length, upper/lower case, letters and characters encouraged. AD policy popped alerts warning of password change, with a lead time of a week, and character form and the rest enforced by locking out the client for violation. It fell to the lower rung flunky IT techs(like me) to check randomly while traveling between jobs to make sure folks weren't pasting password notes under the keyboard or on the monitor, ect. Intensive training and a regional director with the leadership of an Army colonel, made the difference. We hardly had any problems at all.


Your fine blueprint reverse-engineers nicely into my nefarious own.


With regard to passwords should they be synchronised and all match a single policy. I think not. There is the danger that a password of lowest common denominator is used which reduces complexity and increases the risk of hacking. Instead a model of Highest Common Factor should be used and; where applicable; systems should NOT be included in the "common" password policy. As an example take the iSeries password which is 8 characters and case insensitive. This can be synchonised and does limit the password length to a maximum of 8 but it does not limit the policy to single case as it converts the password internally to single case.

Michael Kassner
Michael Kassner

Small, medium or large, if your organization is using an identity management system, I'd love to hear about it. What entailed? How do the users feel about it? What are it's best and worst features? Finally, what do you think about it.

Michael Kassner
Michael Kassner

Won't the passwords be less than adequate for the very reasons you suggest? I'd much rather have a standard set at a point that exceeds what is considered a quality password.


(And thanks to JC for bumping it up in the comments so I could find it.) It sounds like a temporary PITA, but it seems like it sure makes life easier, and more secure, rather immediately. Great process.

Michael Kassner
Michael Kassner

But, until we get to a different way of authenticating, I see it as a valid method for large entities to ensure security.

Michael Kassner
Michael Kassner

All of those actions are considered variations of just one factor. What you know. I know it's better than just a password, but it's not multi-factor authentication. I get miffed at banks for that. It's bogus advertising for them thinking they are safer, but they aren't. Multi-factor authentication requires: ..Human factors are inherently bound to the individual, for example biometrics ("Something you are"). ..Personal factors are otherwise mentally or physically allocated to the individual as for example learned code numbers. ("Something you know") ..Technical factors are bound to physical means as for example a pass, an ID card or a token. ("Something you have")


on multi-factor authentication made me think Michael, as I thought I had it jelled in my brain. I think I already discussed this in the past, but my bank uses something like that. I only have one entry that is masked, and that is a simple PIN. Setting it up was a royal pain in the behind, but using it is dirt bag easy. I've always wondered how safe that site is. They have a three factor process(I believe), please correct me if I'm wrong. 1. The first page requires the account number and an interpretation of a character set meant to confuse machine entry. Also if a cookie is set to remember that IP, the second factor below is skipped. 2. The second page has a random secret question(five of them on file) 3. The third page has a special image (I suppose to discourage page redirects, as the image could not be reproduced), that is composed of a word created by the person who owns the account. This is where the PIN is entered and masked. Because of the special conditions met at each page, I'm still confused as to whether this is considered three or five factor authentication. The only problem I have with this is video hooks - any hacker could be watching the same video image of the logon as I am, if he has somehow placed a spybot that has survived long enough to make it into my session. Keyboard hooks are irrelevant, as my password vault encrypts and masks passwords. However it DOES NOT mask user IDs and special answers to authentication questions. With finger print scanning, facial recognition, getting cheaper by the minute; why couldn't this be used along with easy to remember pass phrases; perhaps including voice print technology; to implement an even faster, more efficient authentication system?

Editor's Picks