In a recently released article on their website titled Unmanaged corporate login accounts are a significant source of risk, Andreas Faruki, Partner and Identity Management Lead for Deloitte Canada states:

“Most companies report that scrubbing old accounts requires a massive, long-term, manual effort, while still leaving 10% to 20% of the problem”

I urge you to read the details here.

Deloitte has done some significant fundamental research and analysis of real world enterprise identity data to verify the scope and nature of this problem. They are way ahead of the game in understanding the real issues and how to deal with them.

The main conclusions are:

• The risks of unmanaged login accounts are real
• These identity management risks affect all industry sectors
• Removing old login accounts is essential to robust identity management

Most importantly, Deloitte has build a service offering to solve this problem for large enterprises. I urge you to get in touch with them to explore it more.

(disclosure: The Deloitte solution uses components that I have had a hand in developing)

Phil Becker, Editor of Digital ID World, and deep thinker on network identity offers some keen insights in his series The Coming Third Wave of Identity ( Parts: 1, 2, 3, 4). In the conclusion Phil points out the distinction between the management and use of identity data:

One of the more difficult things for people to gain clarity about in their understanding of identity management, is the separation of the management of identity data itself, and the actual leveraging and use of that data to accomplish various network application and data focused missions such as access control, provisioning, data protection, policy enforcement, etc.

He highlights the importance of the identity data foundation and the difficulty of getting a set of well managed data (emphasis mine):

..today the emerging identity third wave is producing more and more products that seek to leverage identity for a wide variety of purposes. But to be successful, they must rely on a well-managed network of identity data, and obtaining that is a major task in itself.

It turns out that this first step is the hardest one, as it brings to light all of a company’s processes around on-boarding and off-boarding both employees and contract personnel, along with processes around promotion, internal job changes, transfers within the organization, management changes, acquisition integration, outsourcing, etc.

He then points out that we have deluded ourselves in the past about how the problem will be solved by this or that technology:

It is this part of identity management that was long been thought to be “solved by a good directory”, but which has been seen to be a far more networked problem than that. (Although the rise of Active Directory in many companies promises a reprise of this difficult learning curve for many companies.)

So far, so good but, I have a problem with the following statement:

… resulting product evolution has been finding ways to create a well managed identity data set without radically disrupting and altering existing company processes. It is here that technologies such as identity virtualization, synchronization, delegation of management via workflow, etc. come into play.

Initially, the well managed identity data was used to feed such things (as) web access control..

I have two major challenges to this statement. Let me explain.

Since we were mistaken in thinking a few years back that “a good directory” would solve this problem, how can we say with certainty that the current set of tools will solve this problem. I submit that we are quite likely building a giant Rube Goldberg Machine that has still not solved our problem and may need to be dismantled and replaced by true solutions, yet to be determined. I will delve into this aspect in a future post but, let me just point out that the industry regularly adds new components to “the solution” as we realize that the identity machine we are building still does not solve the problem. I have not seen these additions stop. Ergo, it really isn’t solving the problem yet.

The second problem that I have is that Phil Becker is suggesting that in a significant number of cases organizations have been able “to create a well managed identity data set.” I submit that the identity data foundation at almost all organizations, no matter how much time and money they have spent on identity solutions is still riddled with problems.

Becker is not being deliberately misleading but, he is ignoring the facts on the ground. These facts are that for the vast majority of organizations, >20% of their legacy login credentials remain active even though they cannot determine who they belong to. His own conference sessions continue to underline this problem.

In the name of getting early successes on identity projects, a subset of data for the easy systems with the easiest politics, are being managed by the latest and greatest identity software. However, while all this time and money is being spent, these lost legacy login accounts remain live and are creating a growing risk as the old firewall based security is broken down by compelling needs to deal with Internet. Most importantly, the state of the art ‘identity machine’ does not even attempt to address this underlying data clean up problem.

As identity becomes a central part of the way the internet operates, enterprise identity systems become a vital component in doing business while reducing risk. The data is the foundation of any system. If one in five identity credentials cannot be trusted in your organization, then you can’t trust your identity system, which supports your compliance reports, security, and more.

Like a termite infested foundation, it needs to be fixed before you put on yet another addition. Cleaning up the underlying legacy data is far more important at this time than tweaking centralizing vs. synchronizing vs. virtualizing and the like.

Ironically, doing this would be easier and cheaper and reduce more risk than what organizations are doing now.

IT security focused publication SC Magazine reports $400 million corporate espionage incident at DuPont. This is a further example of the risk of only one person’s improper access to an enterprise. In this case, data leakage was the issue. It even went beyond the business dollar value and started to take on national security overtones. These are not trivial matters.

There are a number of strategies that a company needs to employ to mitigate this type of event. One of them certainly should be to gain control of the huge number of legacy login accounts floating around in your organization that are currently unmanaged.

There is no excuse for not attending to this as straight forward solutions are available.

When we talk about matching login accounts to people, groups and systems across multiple silos, we need a reliable mechanism to maintain the connection – a unique identifier. When you are dealing with Enterprise Identity Matching, it is important that you have a unique identifier that will have the appropriate scope to do the job. Using employee number will not do the trick. Let’s look at the details.

GUIDs are too big

A GUID is an acronym for ‘Globally Unique IDentifier’. I have always pronounced it ‘goo-id’ other say ‘gwid’. If you look it up in Wikipedia you find reference to specific programming implementations of GUID’s and variations on that theme. I am using the term more generally here. There are three components to the concept.

1. The scope of the application of the identifier (The term Global rarely is referring to the real globe but, some other domain of concern)
2. Uniqueness which applies to the target of the identifier (eg only one person can be assigned a given identifier)
3. The identifier itself which has a specific, consistent form.

For example: the US Social Security Number (SSN) is a 9 digit number issued to citizens, permanent residents, and temporary working residents. The scope of this is the US Federal Government which uniquely assigns this 9 digit number. There is actually information in the code of the number itself. There is even an urban legend regarding hidden information. There has been a practice in the past for businesses to use a person’s SSN as an identifier within company records. For many privacy and emerging legal reasons this is now considered bad form if not illegal.

CUPIDs are too small

Back in 2002, I had the pleasure of working with Don Bowen, currently the Director of Identity Integration at Sun Microsystems. Prior to Sun, as an early IdM pioneer, Don had done a lot of real world work of installing Identity Management at Caterpillar, Inc. I always pay attention to people who speak from experience with real implementations – even simple observations may be hard earned nuggets of wisdom.

Don had coined the acronym CUPID for Corporate Unique Personal IDentifier. In addition to creating a cute acronym, Don gets nice and clear on the scope of the identifier – the whole corporation – and no more. ie. bigger than the IT silos, departments, and divisions but, not something that spills outside the organization (like SSN).

Don had some well thought through opinions on the form of the CUPID. From my old notes, I recall:

• Only one per person, never changes
• Unique to one person
• Not required to be know – can be looked up
• Used only for the linking process
• Completely numeric with no programmatic meaning. No chance undesirable words or human meaning could enter in. No chance of people reading in meaning or relying on meaning in it.
• Only for person objects.

To my mind these qualities are just right, except the last one. Since over 8% of accounts may belong to systems or groups, we really need an Identifier which can be used to more than people.

An employee number is a type of CUPID but, does not usually include all people that are given access to the system (consultants and other non-employees) and certainly does not contain group or system identifiers. Employee ID’s also can have meaning embedded in them and may have security implications attached to them which makes them unsuitable to be the ultimate matching identifier.

While they may not provide the ultimate solution, if a system has employee numbers, or some other CUPID, populated across systems, then you have a great head-start in the matching process.

TRUIDs are just right.

I have coined a term for our use called TRUID for ‘True Identity”. It is a play on our brand name and refers to the purpose of determining the ‘true identity’ of the person or system controlling a credential. I am not suggesting anyone else use this term but, it is what we use to delineate from the more generic and alternate terms.

A TRUID is very much like a CUPID as defined by Don Bowen but, also can be assigned to other targets that can hold login accounts such as systems and group accounts.

The TRUID is the unique identifier that can be used to build the link table of all resource credentials to their account holders. This is the main deliverable in the Enterprise Identity Matching process.

If you have ever lost your keys, it is a real pain. Most people think it is prudent to change the locks, rather than take the risk that someone might have found them and take advantage of you. Most likely the keys are in the cushions of a couch or found by some harmless, trusting soul. However, why take a chance. Change the locks and sleep better.

Organizations have been losing track of keys (login credentials or login accounts) to their most important computer systems for decades and as I showed in my last post, for larger organizations, this is amounting to about 100K keys where they cannot answer the simple question: who controls this key? Mostly these misplaced keys are in safe hands but, in many cases, they are controlled by an ex-employee, consultant, partner, or current employee who has moved into another area and should no longer have that access. Some may use them against you.

Of course each one of these un-accounted-for keys is a potential negative compliance finding but, also, they represent a ticking time bomb for a business reputation disaster – or worse. For example:

1. The much publicized WestJet-Air Canada fiasco was enabled by an ex-employee login credential being misused.
2. If you read between the lines on this Honeywell situation, I think we hear them saying that an ex-employee got in there by using a credential they gave him but, did not control properly. So much for the honor system. We are supposed to feel better because the system was not “hacked” – small comfort for those affected. Don’t worry Honey, they didn’t break into the house, they just used the key I lost last week.
3. More recently we got an example of a huge public relations business reputation disaster with the TJX security breach. While we have no details of how the data was compromised, this is certainly the scope of event that might happen if one of the 100K lost credentials at any number of large corporations gets used for such nefarious purposes.

These risks can readily be mitigated by matching and dealing with all those old lost keys (login credentials) that have been ignored for decades. We can take care of it in a few months time with a very modest project. Think of it as changing the locks.

Until then, this should be keeping you up at night.

Up to now I have thrown out the round number that 20%+ of your login records are likely ‘unmatchable’ using normal techniques. Here is some more detailed data behind that number.

This particular table is a composite and simplification of detailed real-world findings. It is representative of an organization with about 30,000 active employees and considers data for 7 common applications/directories.

This is not a guess or speculation but, resembles what we have found when we do detailed analysis within organizations. Obviously specifics are confidential.

It is my hypothesis that this represents the situation in almost all large organizations. Every organization that we have investigated so far has a problem of this magnitude. You may be the exception but, I would not count on it.

Over the next few days I will dig into some of the details but, for now, here is the chart. Do you find this as shocking as I do?

click here to enlarge

I am a regular reader of the informative Network World Identity Management Newsletter by Dave Kearns.

A long time ago, Dave was onto the problem of identity data quality. Back in June 2003 he wrote an excellent post E-provisioning’s dirty little secret subtitled: First rule of e-provisioning is to ‘cleanse’ your data. In it he makes a number of excellent observations and clearly was ahead of the curve on the necessity for data cleansing and matching prior to implementing identity management system. Rather than summarize it here I urge you to take a couple of minutes to read it.

Last fall, Kearns followed up with The messiest part of identity management. Subtitled: Cleaning up before depolying identity managment. He brings this important issue back to the fore which I applaud. He also talks about some very interesting findings of some in-depth analysis by Deloitte Canada – that large enterprises are unable to match 20%+ of their active credentials to a person.

However, I do take issue with a couple of Dave’s points. One minor and one major.

First the minor issue. Actually a clarification. Dave assumed that Eurekify’s Sage is a tool to address the matching problem. I know that Ron Rymon of Eurekify did not make this claim but, was only passing on what he thought were very interesting findings from Deloitte. Sage is a solid role management tool and like most identity tools, needs to be fed corrected and matched identity data to do it’s work properly. Otherwise you get garbage-in, garbage-out. We in fact provide the tools behind Deloitte’s enterprise identity matching services referred to in this article. Eurekify looks to Deloitte to do this cleansing and matching.

The second is a more significant disagreement. Again, I think Dave Kearns is getting caught by assuming again. Not only did he assume that Eurekify had a solution, he goes on to claim that the other provisioning vendors have tools or can recommend tools to solve the cleanup and matching problem. This I think is misleading.

While provisioning vendors generally have tools which help in automatic matching based on reliable rules, they cannot effectively deal with the real world mess that legacy credentials are in. In fact Deloitte has found that 20% plus of the credentials in a large organization are still unmatched, even after cleansing and automatic matching. What is left is a huge manual effort of many man years to clean this up.

Our True_Identity Enterprise Identity Matching solution is designed to deal with these difficult to match credentials. We use special tools and techniques (Forensic Matching and Adjudication systems) in addition to the normal data quality and automatic rule based matching. This significantly cuts down on the normally huge manual effort at this stage.

As one example, Sun (who are among the leaders in the provisioning area) was not able to help Frank Ma at Petro Canada with this problem despite the fact that he had their full tool set and resources available to him.

Bottom line. Dave, three cheers for getting awareness on the identity cleansing and matching issue. However, you should know that effective solutions are not as widely available as you think.

In my day to day efforts to solve enterprise identity matching problems, one of the biggest obstacles is getting people to realize they have a problem. One of the reasons that this issue is little known is that until you actually have to install a large identity management project, you can ignore the issue. Very few organizations have got to that stage. IE. very few organizations have actually implemented large, multi-system identity management solution where legacy credentials are involved.

Once you get to the stage of having to load in legacy credentials, the problem comes front and center. Recently I have been trying to find public examples to prove this point. In this post, I discussed how Frank Ma of Petro Canada urges all to plan on the difficult matching issue before you are too far into the project.

Since that post, I have listened to another panel discussion from Digital Identity World’s, Sept. 2006 conference. One Sept. 12th, 2006 panel was called Questions We Now Know We Should Have Asked: A Customer Panel. The participants were: Bob Blakely, Burton Group, Moderator; Heidi Kujawa, Sony Pictures Entertainment; Mike Ruman, Grant Thornton, LLP; and Ken Lobenstein, Continuum Health Partners. The presentation PDF can be found here and the full audio here.

I urge you to listen to the whole talk as it is always very instructive to hear what people who have actually done a project have to say. This is where the reality vs. theory gets heard.

Here are some highlights of the audio. I have indicated approximate minutes in the audio and have tried my best to transcribe the quotes with a semblance of context. Listen to it yourself to get the full impact.

17:44 Heidi Kujawa

We are still after a year and a half later still dealing with data integrity issues and data cleansing is just going have to be part of the program – just be aware of that.

36:40 Ken Lobenstein

…the amount of time they need to spend to make sure the data goes in clean is not something we expected and that is part of the infrastructure cost of the system – we didn’t plan for that

37:40 Mike Rumen

(referring to HR taking the burden to clean up their data source) ..it’s been a year now since we implemented and they have beefed up that staff and they are taking charge of that data…there is still some clean up going on in that area though

40:47 Ken Lobenstein

(referring to the balancing act and trade offs and how data cleanup and matching is taking away from project goals )…do I focus all my attention at the front end on cleaning up my data….(referring to variation in attribute data not matching identity) when is matching, matching and when is matching database building…

42:18 Heidi Kujawa

(again talking to the trade offs of data getting in the way of the ‘real’ project).. data integrity clean up, do we continue to focus on that? We’ve got to figure out a way to improve efficiencies in the process and keep the data clean in parallel because all the work we have done would be for naught…

The pattern I see here, which is consistent with all the other cases I have seen, is that the quality of data in legacy (and even new) access credentials is not good enough. This causes many issues in trying to match identities together. In this panel, all agreed it was a big impediment to the success of the project. They all felt they had not anticipated this problem. All seemed to indicate that they had yet to match all their identities and are still wrestling with this problem (I am reading a bit between the lines here but, I think I am right about this.)

(This is a first pass definition. I will refine this over time and update the definition on this page)

The Problem

Within enterprises, people have multiple access credentials ( mostly user-name and password ). This is particularly true of organizations that have a number of legacy systems, which have been build over the past many years with no concern for the Internet or even working with each other. Each will have a separate credential.

Over time employees will accumulate many different credentials, some which they no longer need, or no longer should have given their current role with the company. Worse yet, when people leave the organizations, often their access remains. This is primarily due to the fact that many are the champion of provisioning new access but, no-one is the champion of de-provisioning.

The result is a large number of active credentials (about 20%) in most organizations are NOT traceable to a person. Simply, they cannot answer the question: “who does this credential belong to”. This fact undermines identity management and compliance activities in most large organizations and is a significant source of risk for organizations and those that they serve … which is about all of us.

The Solution: Enterprise Identity Matching

Enterprise Identity Management is the combination of tools and processes an organization uses to investigate and unambiguously match all their active access credentials to a person, group, or system.

It is my tenet that this problem is pervasive and significant in large organizations. The solution is non-trivial. I also believe that by better understanding the true nature of the problem and using purpose built tools and techniques, this problem can be overcome with a modest investment of time and money. This blog is focused on the exploration of this problem and possible solutions.

Usually anyone who actually has to complete an identity project learns learns two key truths:

1. There legacy identity data is a mess and many of the records are unmatchable.
2. Matching and scrubbing these records is much harder than they originally thought. In the end, it involves a lot of manual, costly, time-consuming effort.

Here is a great example of advice from someone who has lived the problem. From Digital Identity World May 2005 Conference there was a session called the Provisioning Customer Deployment Panel. If you listen to this MP3 and go to about 22 minutes in the podcast when the Q&A starts, you will hear that Frank Ma from Petro Canada says:

“Data Cleansing takes a long time .. implementing the (identity management) product seems to be the easy part .. we thought that would be the hard part. This (data cleansing) has got to be the same problem for everybody else.” – Frank Ma, Petro Canada (starting at about 22 minutes into podcast)

The person who asks the question also agrees that it is harder to clean up and match credentials that implement the provisioning system itself. At the end of the podcast, Frank Ma re-iterates and urges people not to overlook this issue.

Listen to the tone in his voice. It is sound advice from someone who has gone before.

You have been warned. It is much harder than you think.

PS. The folks at DIDW have just released their latest conference proceedings which I will be reviewing shortly for mentions of the data matching problem. Stay tuned.