Risk ROI for –Some– Provisioning Solutions…

Today I ran into an interesting post on Matt Flynn’s Identity Management Blog entitled Extending the ROI on Provisioning in which he discusses the fact that, in addition to the “traditional” value propositions centered around increased efficiency and cost reduction, there are also significant risk management and oversight capabilities that can be had.

All provisioning solutions provide some facilities for:

  • Reduction of paper-based processes in favor of electronic requests and work flows
  • Reduction of manual updates in favor of automated entitlement updates

All provisioning solution providers strive to have a compelling story for these items. Additionally, these were the focus of the first generation of solutions which emerged in the ’90s.

For the Identity Management programs with which I have been involved, automation and risk management have been equally important. This is somewhat reflected in the definition I use for provisioning:

Provisioning is the processes and systems which:

  • Manage the entire Lifecycle of an Entitlement from request, through approval processes, onto issuance, and eventual revocation
  • Provide transparent views of the status and history of each step in the Entitlement Lifecycle through the creation of durable and detailed records, which include all the information required to provide non-repudiation and event reconstruction for each step in an Entitlement Lifecycle

Note: Fulfilling these objectives always involves a mix of manual and automated activities, technical and procedural controls.

Based on my experiences, having prepared several product selection scorecards in this space, there are two major approaches (philosophies), that provisioning products take in this space:

The provisioning system “sees itself as”…

  • Coordinating identity and entitlement activities among systems with the objective of providing automation

– – – OR – – –

  • Maintaining a single centralized record of reference for identity and entitlement, as well as providing tools to automate approval, issuance, revocation, and reconciliation

The “Centralized Record of Reference” concept is the watershed between these two. The systems that are designed purely for automation tend to focus on “Coordination” of external events. These systems often do not contain an internal store of entitlements. The systems that maintain a “Centralized Record of Reference” approach have the ability, through reconciliation, to validate that the entitlements in the “wild” (e.g., in AD, LDAP, within local applications, etc.) match the “official” state (which they maintain). This enables these systems to detect changes and take action (e.g., drop the privilege, report the discrepancy, trigger a follow-up work flow, etc.)

Which system is right for you?

This really depends on what percentage of your systems require tight oversight. If you are in an industry with low-IT regulation, and the data of your core business is low risk, then it may make more sense to invest in routine manual audits of a few systems, rather than monitoring your entire IT world. On the other hand, if you are in an industry that is highly regulated, with high-risk data, then the automated oversight and reconciliation capabilities are likely a good fit for you.

FYI, last week I co-taught a one-day class on Identity and Access Management Architecture at RSA 2008. For the last 3rd of the class, Dan Houser and I had a list of advanced topics for the class to vote on. I prepared a module on Provisioning, but alas it was number 4 out of 7 options, and we only had time to cover 3… As a result, a Provisioning slidecast is “coming soon” to the Art of Information Security podcast.

Cheers, Erik

5 thoughts on “Risk ROI for –Some– Provisioning Solutions…

  1. Matt Flynn

    Thanks for weighing in Erik!

    Are you saying that the provisioning systems themselves provide sufficient non-repudiable evidence that the access rights stored in the connected systems is totally within policy 100% of the time? What about when they’re changed?

    What if an account was found to have been given elevated rights through a back channel (direct admin access). Does the provisioning system tell you who granted those new permissions? Is a third party auditor satisfied with the provisioning system logs?

    These aren’t meant to be sarcastic or trick questions. My experience is that provisioning systems alone aren’t enough because they don’t see past their own arms. The DBA still has control over the database. There are often practical limitations to the systems abillity to even capture the most basic information. …maybe the connector is tied to a specific portion of AD rather than the entire domain or maybe it checks for updates every hour or even every fifteen minutes. There just seem to be holes.

    But, I sincerely appreciate hearing alternate viewpoints – I just wanted to clarify that I’m hearing you right.

  2. Erik Post author

    Matt –

    Reconciliation is a detective control, not a preventative one.

    The goal is to detect when the other controls have failed and to detect that quickly. How quickly? This generally depends on the kind of connectivity between the Provisioning system and the entitlements store. Generally, you can achieve very tight oversight over directories (such as AD, LDAP, etc.), knowing within minutes that an change has occurred. Systems that require data extracts of the privileges will obvious be reviewed on a schedule.

    As to what action to take…

    Reporting and alerting are generally the best options. There are systems that support immediate revocation of a suspect privilege – but I personally see the operational risks of that outweighing the security risks of taking a day or two to run down the discrepancy.

    As to your other questions, no control is prefect. Compare this kind of Reconciliation to the Reconciliation of business checking accounts. Do you reconcile all accounts on the same cycles? Is there additional oversight on accounts with higher risk transactions? You see, it’s not a question of appeasing an auditor, it should be a question of identifying and managing risk.

    Did I come close to addressing your questions?

    Cheers, Erik

  3. Dan Houser


    Whoa — if you find a system that can guarantee 100% accuracy with all provisioning activities, buy it (and buy the company!!).

    I have designed systems that ensure that no one can mess with the logs of what was reported to have happened, sufficient for evidentiary controls. However, it’s a completely different problem to ensure that everything that actually happens gets logged. There are too many opportunities for collusion, malicious admin, failure in update, and other issues that will cause events to go unlogged.

    Fortunately, for those of us in the private sector that don’t deal with nuclear materials or secrets, that level of rigor usually is not needed. 99.999% logging is good enough for most business applications, and probably for nearly any court case you’d need to prosecute, since that log isn’t the only point for forensic evidence. I’ve only seen a few systems that were capable of 100% logging, and those spent millions on aircraft engines and diesel tanks for tertiary power alone. Most of us don’t need perfection.

    What we do need to do is to show reasonable due diligence at implementing and manage preventive and detective controls commensurate with risk. For nearly all of us, that risk doesn’t require 100% accuracy.


  4. Matt Flynn

    I’m not claiming that one system can do 100% of anything. But, we can get closer to 100% by adding on to what provisioning already does for us. All I’m saying is that I believe there are holes in what provisioning systems can do alone. They weren’t designed for today’s expanded requirements for audit and risk management. And no, audit is not the ultimate goal, but it is a reality for many companies.

    AD, for example, generally takes 15 minutes to replicate. So, even if the provisioning system sync’s every 2 minutes to a DC, there may be a 15 minute window where an account could be created, used and deleted — and then the logs cleared. That’s just an example. Another is that provisioning system logs can’t tell you WHO created a rogue account in one of the connected systems or that a DBA opened a table to review identity data in Oracle.

    My point is that we should look at extending the reach of the overall systems to protect against additional attack vectors – encrypt the database, monitor the database for local changes, record who makes those changes, etc.. It provides additional security, audit ability and deterence.

    Dan – logging isn’t bad by itself, but we need logs of what’s happening at the connected stores in addition to logs of what the provisioning systems are doing.

    Am I way off base here? Are you saying that there are no holes or that there’s no need to fill them? I thought I heard a little of both of those arguments. I know you both by reputation and appreciate your input.

  5. Erik Post author

    Matt –

    I think we are closing in on violent agreement 😉

    Reconciliation can add tremendous value to the provision solution, if tight management of “privilege drift” is risk appropriate. And of course, the trust one can have in any control system is limited by the trust inspired by the integrity controls for the platform those controls run on.

    – Erik

Comments are closed.