If you missed the previous article in this series please read Identity Lifecycle Process and You (Part 1).

What to do About Identity?

In the last article, Identity Lifecycle Process, Part I we talked about identity and how it gets used on a network. Now that you know the problem, obvious question is, “What do I do about it? “

Your first line of defense and the basis of your security policies should be a good identity management process.  Notice that I’m not saying a good identity management product.  If you choose to get something to automate your process later, that’s great.  If not, that’s great too as long as you have a process, defined or implied by the way you do business that meets your needs AND YOU FOLLOW IT CONSISTENTLY. In addition to meeting you operational needs, a good identity management process must also result in only valid identities being available for use at any given time. 

Over time, I’ve gathered several implementation ideas and concepts that help with creating and using a good identity management process.

One of the biggest claims I hear is that you cannot ever delete a network identity due to regulatory requirements. That’s a little scary because as long as that security principal exists, it may be possible to utilize it to at least logon to the network. What’s the risk? By default, a user’s network identity or security principal...

...is able to logon to a workstation, which would allow the ability to mount an attack unnoticed. There are also implications of users using that identification to untraceably execute actions. What’s worse is that unused security principals rarely receive the same care and attention that active principals get.

Overly complex process schemes also raise a lot of concern. This can lead to mistakes and access being possible when it should not be, or just as bad, access not being available when it should be! I’ve also seen many an instance of overly complex schemes being so unusable that it gets circumvented over time.  In one shop, I’ve seen network administrator credentials used by just about everyone because it was easier to give out the credentials than it was to properly allow access.  Yikes!

Obviously these results are detrimental to the goal of allowing authenticated and authorized access to users that need it, while protecting the assets from those that don’t. My advice? KISS it: Keep It Simple Silly.

What can you do? Create a process that takes into account the entire lifecycle of an identity across all systems in your network or that may access your network.  Then create a plan.

Create a lifecycle table. Do you have a beginning, a middle and an end? If not, consider your table to be at least provisioning and de-provisioning of security principals. If you do nothing else, at least focus on the beginning and the end of the lifecycle. This is your roadmap and criteria of success that you’ll measure your solution on. Be sure to spend plenty of time here!

1. Create a table of the user types.  For example: Vendor, Contractor, Employee, Administrator and Manager might be your types.  You might have more, but it’s good to know about all the pieces to the puzzle before you get too far down the road
2. For each of the types of user in your map, define the sub types and relationships.  For example, do you have more than one system that defines an administrator? If so, do you need multiple sub-types of administrators?
3. Define overlap between your types. Do you have vendors that are administrators? Do you have contractors that are also users? Contractors that are administrators? Can you see a common access pattern? If not, keep playing with the format until you can see the common access requirements.
4. Next you’ll have to prioritize the different stages of an identity’s lifecycle. Often, the cycles will be something like: creation, modification, and deletion.  Within each of those stages, there will be sub-stages that include provisioning and de-provisioning of resources, access rights, and so on. This is important because access to resources can be fluid and change often. Your process needs to take this into account and be flexible without compromising your security goals.
5. Consider how you’ll prevent your process from being circumvented. Is it easy? Is it natural for your environment? Is it too complex and rigid so that I have to make exceptions all the time? Does it rely on a person to carry it out, or is it semi-autonomous? Some of my accounts should have a person that verifies that, such as an account with elevated privileges, but what about other classes? Maybe normal Employee class of user is created and deleted without additional approvals?
6. Create an initial rights matrix for user types. That allows you to create the security principals and give a base level of usage without a lot of customization per department or job function.  That’s much fancier than we’ll discuss in this document.
7. Create a plan for ensuring the removal of identities. That’s critical to your security policy enforcement – if there are no identities to be taken without being noticed, then they won’t be!
8. Create an implementation plan.  

That’s pretty much it. Seems simple, but it can take a while to get everything investigated and lined up. Give yourself time and remember that this is important and that it’s a marathon and not a sprint.   

Sample Lifecycle Process Information

A sample might look like this:

LifeCycle Table
	Task	Time in Process
	Creation	Beginning
	Removal/Archive	End
	Modification	Middle
	Move	Middle

User Types, Sub-types, and Overlap
	Type	Access Sub-Types	Overlap
	Vendor	Guest, Internet Usage Only	Guest
	Contractor	User, Administrator, Internet Usage Only	Employee, Administrator, Manager
	Employee	User, Identity Manager	Manager, Administrator, Other Systems Administrators, Contractor
	Manager	User, Identity Manager	Administrator, Other Systems Administrators, Employee
	Administrator	Other Systems Administrators	Administrator, Other Systems Administrators, Employee
	Guest	Internet Usage Only, Temporary, Kiosk User	Vendor

Process flow:

1. New access request
   1. Determine type of access: Vendor, Contractor, Employee, Manager, Administrator, Guest
2. Create new network identity
3. Change request
   1. Determine type of change – move, additional access, less access, etc
4. Implement change request
5. Identity End of Life
   1. Archive necessary information
   2. Remove the identity and it’s access anywhere it occurs on the network (note, centralized directories make this easy)

If you missed the previous article in this series please read Identity Lifecycle Process and You (Part 1).