Are We Managing Identity Based on Incomplete Data?

I was thinking about a conversation I had last night with a friend here in Manhattan about Identity and what it means vs. what we perceive, and the deltas of the two.

Identity management means a lot of things to a lot of people depending upon your definition of it. That got me thinking about what is the definition of identity. Back in the day it was about a directory with a username and password, and in essence was a records management application - I managed attributes of your 'identity'. Well, what is that identity? Is it your role, is it what you say it is, is it your behavior, is it your device you use to interact with applications, is it what someone else higher up the corporate food chain says it should be to satisfy a particular momentary need (emaergency password resets, or TPS Reports)?

In practical application it is a mix of all of these components. As an IdM leader I am tring to manage all of these components and map them to a single piece of data (username for example, or SSN) and based on this component mix, come up with a way to make sure that what I believe is in fact happening as it should and is accurate.

Version 1.0 of IdM seemed to be movement from directories (user centric data files) to provisioning (building on that user centric data file to establish and implement an automated process). Now what? How do I add more value to the management part of Identity Management? What does the Management part of identity management mean, since we seem to have the Identity part of Identity Management mature enough to be useful.

Is Management validation? Is Management audiability, is Management all about enforcement? What layer should Identity Management take place - the app or the network layer. Having spent time in both worlds now for several years I have made the move from thinking about Identity Management as moving from the application layer to the network layer. If someone is on my network I want to know who it is, even if they are unknown, and I want to be able to control & enforce what they can see, what they can do, and what they can access.

There are typically fewer network admins than applications and corresponding application owners which means that there are fewer people who have access to the control and enforcement ability, which makes it more manageable than say an organization with 1000 applications and 1000 application owners. Which means you've added a ton of value to your application owners by protecting them and their feifdoms, to risk management looking at risk based security, and to the security organization from the badging folks' applications, to the sensitive databases with millions of user records.

Managing Indentity at the newtork layer gives you the ability to quickly extend YOUR control and enforcement to partner organizations and control and enforce what they can see, do, and access more quickly than to request an audit of their 1000 applications by talking with their 1000 application owners and trusting what they find, or inheriting their potentially higher tolerance for risk. It is being able to control and enforce YOUR policies whether your partners want to follow them or not.

I think this has a profound impact on managing offshore vendor access with a high degree of granularity, by being able to segment a network's access and only give access to certain network segments by offshore vendor or offshore project team by user and by their specific device. In so doing you're controlling access to the servers and applications they need to interact with, while staying within the risk tolerenaces that your company has in place, and insuring that your policies are being followed.

Another use case to follow soon...

Mark

identitystuff @ gmail.com