Talking Identity

Attestation (aka Re-certification aka Periodic Review) is one of the latest must-have's in the world of compliance-driven IdM (if you know of another name it goes by, please share). It essentially refers to the management practice of periodically checking and certifying that only the individuals who need certain access privileges have those access privileges. Here at Oracle, we have spent a considerable amount of time building the necessary tools into our provisioning product to ensure that our customers are able to meet their regulatory needs around attestation. Being an authoritative source for Who has What (and When, and Why) puts provisioning solutions in the unique place of being able to serve as the central vehicle for corporate attestation processes around user entitlements.

In developing our entitlement attestation offering, we found ourselves having to create two classes of attestation processes to address the different requirements that our customers presented to us.

The first one is User-centric attestation. Not to be confused as having anything to do with user-centric identity (which will be the subject of a separate post), user-centric attestation tackles the problem from a identity-centric perspective, where the focus is on looking at the user's entitlement profile as a whole. In other words, looking at the entire set of entitlements that a user has. The most common attestation processes deal with managers (organizational, team, etc) needing to look at the entire set of entitlements for users they are responsible for, and certifying that user entitlement profile. This allows managers to identify privileges that may have been granted at some point for a valid reason, but are no longer needed, catching potential toxic combinations, etc. Reviewers can be asked to certify the entitlements of users who are members of a particular team, have a particular role, exist in a particular department, etc.

Resource-centric attestation tackles the same issue from an application perspective, where the focus is on looking at the accounts and privileges that users have on a particular system or application. This allows application owners to get visibility into who has what access to the systems that they own, and certify or reject that access. This has proven to be extremely helpful for owners of especially sensitive systems, where the number of users to be certified may not be large, but the significance of the system means that certification needs to happen much more frequently, and therefore needs to be optimized for operational efficiency.

I recently had the opportunity to validate the approach we have taken. I spent a full day with some folks from one of our financial services customers. They have been tackling their attestation problem for a few years now and have not been able to come up with a satisfactory solution. They came to us for help because they have only a few months left to their delivery deadline. We spent a whole day going over their requirements, digging through reams of analysis data. When we worked out that they could deliver the solution they needed almost entirely with the capabilities we have, they literally jumped up and down with joy. And, like almost everyone we have talked to, they had a need for both classes of attestation. The distinction between the two classes resonated with them in a big way, and the fact that we offered both was huge for them. While their most common use cases were centered around their organizational structure and manager attestation, they had some pretty sophisticated use cases for specific applications that looked at the users global location, system ownership and financial impact.

However, as it turns out, the biggest deal for them was the attention to operational efficiency that we had put into the design of our attestation screens. As they pointed out, a lot of reviewers only have the attention span of a few minutes, and cannot afford to be pulled away from their day jobs for too long. So useability and efficiency is extremely important when they are being asked to sit at a screen and re-certify 30-40 users with 10-15 accounts each (thats the potential equivalent of a 1000 line report, folks). The biggest obstacle that they see to the success of their project is making sure that the reviewers are not confounded with a complex and time-consuming UI to the point where they start certifying users without the proper due diligence, just to get the task over with. After all the internal debates and hours long sessions we had trying to get it right, getting props on that aspect of our work was hugely gratifying.

By no way am I saying that we have cracked the case on this one. We have a long slew of enhancements planned around this as we start exploring some of the finer nuances of attestation, and as we start moving beyond entitlement attestation to add controls attestation (certifying the policies and processes themselves instead of the results of their execution). It is an extremely interesting problem, because it is so simple to understand, yet so complex in its variations. So stayed tuned for more on this. There is more information about our attestation work on the Oracle IdM site at http://www.oracle.com/products/middleware/identity-management/attestation.html. A new white paper is going to be published there in a couple of weeks that goes into a lot more detail than I have covered. Feel free to ask me more about this, or share any interesting stories and insights you may have. Especially if you have seen the need for a new class of attestation process.

One of the philosophies at Thor (that we have proudly carried over to Oracle) is our commitment to building products that deal with the dirty realities of our customer's deployment needs, instead of living on some idealized plane. Getting there requires a lot of input from our customers. This week, our Product Management team is doing a customer roadshow regarding our audit and compliance features, in an effort to validate and get input on the next phase of our offerings. As they embark on this trip, I wanted to share the most significant takeaway we had from our last such effort.

The Problem Statement
After the initial design of our attestation feature offering, we did a similar roadshow with the IdM teams at some of our customers who have been supporting significant audit efforts within their organizations. While they liked the effort we had put into weaving attestation into the fabric of IdM, and the attention to manageability we had put into the UIs and flows, they pointed out one aspect we had not anticipated - the lack of predictable reviewer patterns. What they pointed out was that the automated processes around attestation would only be as good as the data that would drive the decision-making; and that, for better or for worse, that data is almost impossible to find/capture in any kind of authoritative source. While the concept of managers attesting to the access rights of their reports is good in theory, the reality is that the knowledge needed to actually make an informed decision is often distributed among different people, who may have dotted relationships to the subject at best, and no visible relationship at worse. The scale of a lot of these organizations also means that a single manager could end with an impossibly large number of entitlements to attest to, a lot of which he/she really has no context into. Roll ups in the attestation world are extremely common, and having the head of a division attest to the entitlements of everybody in their organization just cannot happen (especially when it is their head on the line).

The Solution Statement
The advice that we got was to build into our attestation offering a key feature - Selective Delegation. In the old world of paper-based attestation, this would be the equivalent of the reviewer putting in the notes column of a particular entitlement in the spreadsheet the phrase "Not sure, ask Jim to review this". Imagine the headache this causes for the team generating and receiving these spreadsheets, having to sit and compile all these ad-hoc requests into new spreadsheets. There are only two ways this can end - both of them badly. Either the compliance teams spends man-years handling these ad-hoc requests, compiling new spreadsheets, sneding them out and tracking the results. Or they push back on the reviewer against such requests, resulting in the reviewer being forced to take a decision without any context (or having to do a lot of legwork to gain that context, which as was explained to us, never happens in real life). The result - bad attestation certifications.

Now imagine if all of this is automated to happen online, and instead of having to write a note back to the compliance team asking for Jim to review a particular entitlement out of a hundred or so, the reviewer can just tag that entitlement with Jim's name. The system automatically picks this up and generates an attestation request for Jim, complete with the same entitlement data, and the reason why they are being asked to do the certification. The delegation is tracked and audited, and a chain of responsibility is created. Best of all, this simple act has eliminated potentially man-years of effort, and closed an extremely serious audit loophole.

The Answer
This critical aspect of Human Integration (stealing a phrase from Kim Cameron's elegant 7th law) was repeated at each customer we talked to. So we went back to the drawing board, and spent quite a while designing an elegant solution to this problem. The feature - selective delegation - is proving to be quite the hit with everyone we have shown it to since it came out. In fact, one prospect said that just this one feature is enough for them to green light a project, because it gives them the confidence that automated attestation can become a reality in their complex world. The key element that all of them pointed out was that, unlike everything they had tried up until this point, it gave them a way to handle completely ad-hoc occurrences in a systematic, audited manner that did not break the process. And to them, that was pure gold.