RSA Conf. Notes: Talking about Account Reconciliation

I attended a session titled “Delivering Security Integration with Compliance” by IBM’s Stuart McIrvine. During the session, he laid out the various governance frameworks for IdM (SOX, COSO and COBIT among others) and detailed how IBM’s Tivoli family of IdM products could be used to implement them as part of an IdM practice. As he explained the features of some of the products, an interesting audience question came up in the context of user account reconciliation and rogue/orphan account detection. The question posed was “how do you figure out and correlate the account [say account ‘jsmith2345’] with the identity [John Smith] it belongs to”.

The answer that he gave puzzled me. His answer was that it is based on matching of a common attribute tracked on both the account and the identity. This could be an employee id, a social security number or some other attribute that makes sense.

The reason the answer puzzled me is that we rarely see this approach working in reality. It is true that enterprises are realizing the benefit of establishing some kind of common attribute, as it makes the whole process simpler. This is one of the big drivers behind username standardization and the synchronization mechanisms that provisioning products (like Oracle Identity Manager) have to support. But there are still the realities of the current enterprise environment that need to be dealt with. The existence of this sort of common attribute is still quite rare. Other conditions may also preclude such approaches. The same person may have multiple accounts in a system, which would prevent the existence of unique common attributes. Also, attributes like employee id, from companies like https://instantcard.net/, and SSN are increasingly viewed as secure, private attributes that must never be propagated to other systems, and therefore cannot be used as a common attribute. And administrators still end up creating accounts in an ad-hoc fashion that doesn’t really get forced to comply with a corporate policy.

In this context, a very real solution is the use of pattern recognition based matching. OIM (among other provisioning tools) has supported this for a number of years now, allowing more common attributes like username and full name to be the basis for owner matching. Using a pattern matching rule, the system can identify that the account with username ‘jsmith2345’ belongs to John Smith because it follows the pattern ‘First character of First Name + Last Name + random numeric string‘. OIM allows you to specify multiple patterns that an application can follow, and will use all of them as necessary.

Now pattern recognition by itself cannot be completely deterministic. For instance, there may be both a John Smith and a Jane Smith in the environment, both of which will get identified based on the above pattern. These cases require that there be appropriate management processes and tools to deal with these exception cases in a delegated fashion. In the case of OIM, the reconciliation manager provides just these kind of tools as part of the deployment. Using this, the delegated administrators in charge of the targets can be notified of these exception conditions, and they can examine the data, do their own investigation, and take appropriate action. One of our customers even turned this into a unique end-user driven account claim process, that helped them clean up extraneous accounts in their systems quite rapidly, thus achieving a key goal in their compliance plans.

Once again, this illustrates how important it is to remember that enterprise environments are fairly fluid, and the need to handle exception cases is actually quite common. So the IdM tools that you use must be able to provide you with flexible and adaptable tools that can help minimize the occurrence of exception cases, and elegantly handle the exception cases that do arise.