Segregation of Duties - Panacea or Pandemic
by Deborah Volk on May 6th, 2009

Recently I have been exploring the new APIs that came out in Oracle Identity Manager 9.1.x and what they can do for our customers. Most exciting are the new reconciliation APIs. For any company that views compliance as a raison d'etre of their identity management system, reconciliation must occur. Audit and reporting are aspects of compliance that require reconciliation. From a business perspective, it doesn't matter whether reconciliation is done under the auspices of the software product or by an IT group that gets together nightly for cappuccinos and crackers while comparing source systems or by monkeys hitting random keys.

Even though reconciliation ranks as #1 or #2 in terms of priority in most identity management implementations, the out-of-the-box tools for managing reconciliation events are sorely lacking. Customers with extensive reconciliation needs fill in the gaps on their own; witness Yale University's custom application for dealing with various types of mismatches. (The challenges of implementing identity management in higher ed are somewhat unique but I digress). Perhaps these new APIs are clues to a new and wonderful set of 21st (!) century user interfaces to be released in Oracle Identity Manager 9.2 (11g) or perhaps not. If you don't want to wait for 11g, you can take advantage of these APIs yourself and we've done some interesting work with them for customers on OIM 9.1 (contact us for a demo).
While engineering a better solution after a few rounds with reconciliation APIs, I ran into a logical challenge. One of the main selling points of reconciliation is the ability to detect rogue accounts on target systems. With these APIs, we can finally start delegating management of reconciliation events to the "appropriate" people. If a reconciliation event for a rogue account comes in, it's an orphan event. That is, it cannot be linked to a known identity since, well, it wouldn't be rogue if it had a known owner! I decided to make orphan reconciliation events be attestable by the application owners (delegation to the "appropriate" people). After all, usually it's the application owners who truly know if an account should or should not exist.

My assumptions (based loosely on many real-life requirements and processes) started to break down in some of my use cases. Along with knowing if an account is valid or rogue, application owners usually have the ability to either approve the creation of a new account or force the change of an existing account on the target system. This creates a logical puzzle having to do with Segregation of Duties (SOD). Can the attestors actually be the approvers of requests for (or creators of) rogue accounts? How about any accounts? I would like to know if there exist organizations out there with a policy or procedure that differentiates the approvers from the attesters, requiring these two roles be played by different people. I believe that for the most part companies in fact have an opposite policy, the approver and attester is usually one and the same person.
In this era of compliance or jail and Segregation of Duties as the holy grail of compliance, it becomes apparent that companies are going to need people with an in-depth knowledge of systems... yet without the power to do anything on those systems. A read-only system administrator is a good description. In this economy the cost of this type of organizational segregation where you have administrators who know the system but can't touch the system might be prohibitive, thus leaving the risk to be unmanaged.

Ask yourselves this: is attestation a check that mitigates insider threats or is it merely an acknowledgment of trust between an organization and the attester?

Posted in Oracle Identity Manager, Identity Management    Tagged with rogue accounts, reconciliation, oim, sod, attestation


Rob Otto - May 7th, 2009 at 1:42 PM
More like pandemonium, I'd say! :)
Leave a Comment

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)