Provisioning is dead, compliance rises from the ashes

In my blog post, “An abridged (and unofficial) history of identity and access management” I talked about provisioning systems.  These systems, the big brothers of meta-directories, are business-driven identity management systems and are today’s prevalent systems used for managing the life-cycle of user credentials and rights.  So why would I declare them dead? This probably takes some back-story first…

The advantages that provisioning systems had over meta-directories was the concept of process flows.  In order to create and maintain a user’s privileges it normally takes several process steps (i.e. HR creating an employee’s initial information, creation of accounts on internal systems for employee resources, hiring managers approving job specific privileges, changes through promotion, etc.).  Provisioning systems provide a user interface for inputting these processes (meta-directories required configuration code or tables) and system interfaces to the “source systems” for enacting the changes.  But they also maintain logs of the activities for validation that the provisioning service’s processes and activities worked.  While nice to have, in reality, validating process activities through the logging files is unwieldy and only contains the information on what the provisioning system’s actions were.  If you need to validate that the action took place on the source systems, or validate that the local source system’s administrator didn’t make manual, unauthorized changes, you have to go out and collect the log information from each of the source systems as well.  While not as cumbersome as defining new flows with each source system connection, like meta-directories, having to, collect, collate and report on activities via the logs is generally not done due to the effort and expense necessary; not to mention that each log file contains different levels of information, if logging is even turned on.

Jump forward to today. In this regulation-frenzy society, most organizations are required to attest to having good processes and guaranteeing the protection and authorized access to sensitive information (i.e. PII, PHI, PCI, etc.).  This “compliance activity” is in the forefront of most C-level security and IT managers.  So while the IT department has their provisioning system collecting the information that these managers need, as stated above, they’re not the reporting tool.  Many of the same vendors that make provisioning tools also make compliance and reporting tools.  These tools have the ability to search out regulated and sensitive information on source systems by collecting their log files and querying their configurations.  Once this information is collected and analyzed, the compliance tool generates reports on configurations, potential policy violations, high risks, potential data loss, etc.  These tools are heavily sought after by many organizations that recognize the cost savings in effort and time needed to manually do this work.  The vendors see this and are attempting to step up and make tools that people want.  So there’s a natural technology-focus evolution occurring again.  Directory Synchronization evolved to Meta-directories, Meta-directories evolved to Provisioning Systems, and now Provisioning Systems are evolving to Compliance Systems.  The death of one type of identity management tool creates the birth of a newer, better type of system.

From an organizational point of view, just as I mentioned in the post on the history of identity management, as business managers started interacting with IT staff for provisioning, IT staff are starting to interact with the security organization for compliance.  In many organizations the identity management systems are now being referred to as “security systems”. The question that has to be answered is, “Will the provisioning system stay a standalone tool or will it be relegated to a module within the compliance tool’s architecture?”  I predict compliance tools will win but I suspect the answer is coming sooner than we know.

r