User provisioning best practices: Access recertification

The organization has its enterprise provisioning system up and running. It's adding, modifying and deleting user accounts on several, if not dozens, of the organization's major business applications. The workflows needed to create access parameters are functioning well and everything looks like it's proceeding as planned. But is it? How does a company know it chose the right access rules? How do managers know they authorized the right access for their personnel without giving employees too many rights for their jobs?

A provisioning system does what it's been configured to do, and if the rules are wrong, the tool will provision accounts incorrectly. The only true way to verify that the system is operating to policy is to audit its functions: "Recertification" is the best process to do this.

So what is access recertification? Recertification is the process of gathering user access rights and doing comparative analysis to determine if the access rights are valid and/or necessary. This audit function is used with an enterprise provisioning system to provide a feedback loop necessary to ensure the provisioning system is correctly granting access. While this process is easy to define, it's difficult to execute. Because of this, an organization must follow a series of predefined steps to properly implement a recertification process.

The first step in the recertification process is to gain access to all the account and access information on the systems being provisioned. In the beginning phases of a provisioning deployment, this is normally done by auditors and/or security personnel who either physically extract account information into a format for comparison, like a spreadsheet, or are granted administrative privileges on the business systems to view provisioned account information. In later, more mature phases of a provisioning deployment, most organizations use a recertification system to perform automated, periodic file extractions from the business systems for this analysis. The point when an organization is ready to move to automated extractions will generally be determined by several factors:

• How many systems are being provisioned: Greater numbers of systems make individual access to account information more difficult.
• The number of security personnel available to audit the systems.
• How siloed the organization is: Geographically dispersed systems, different line-of-business management structures or different authorization processes for different lines of management will all affect how quickly this process can be performed. The less siloed, the faster things will go.
• The number of accounts regularly being managed by the provisioning system.

The next step in the process is to normalize and compare the access information. For example, cryptic names for mainframe ACF2 privileges, such as ASYSRDPRGC1USER11, don't really give an outside auditor or security person the ability to understand what privileges were granted to the user by the provisioning system. Access rights from each system need to be translated into a common set of access rules as used by the provisioning system -- such as roles-based or business function access -- so a one-to-one comparison can be done. This can be completed manually using a set of spreadsheets with translation formulas and a highlighter, but, the more systems and accounts that are included in this step, the more difficult and time consuming a manual process will be.

As this step becomes more complex, a commercial enterprise access governance tool -- such as Aveksa Inc.'s Access Certification, Oracle Corp.'s Oracle Identity Analytics, Novell Inc.'s Access Governance Suite, etc. -- is needed to perform this activity. These systems have application connectors to automatically extract account information, as well as knowledge engines that can translate application privileges into the same rules used by the provisioning system. Once the information is normalized, their knowledge engines can then be used to do comparative analysis. The end result of this step is the determination and reporting of any "fatal" combinations of access rights, or inappropriate rights that have been inadvertently granted by the provisioning system.

Alternatively, a functional manager may have authorized the system accounts and privileges for an end user. If this is the case, once the account access rights have been collated and normalized, some type of interface must be developed to notify managers that they have application accounts they need to verify for their employees -- typically email or a task notification system like that deployed in Microsoft's Exchange Messaging service is used. The managers must then use an application to review and update, if necessary, the employees' accesses before they are approved. While these interfaces can be developed in-house, the enterprise access governance tools used in the step above also provide communications interfaces for manager notification and Web-based applications for manager reviews.

Finally, if any invalid accesses have been discovered from the recertification steps listed above, this information must be fed into the provisioning system to correct and/or remove bad accounts, while the rules that created these invalid accounts in the first place should be identified and modified to keep inappropriate provisioning from reoccurring. Again, in initial provisioning implementations this can be done manually, but, eventually, organizations will want to create a workflow where this information is fed into the provisioning system through an automated feed from the verification tools used to ensure the feedback loop is optimized.

Provisioning systems are great tools for administering the life cycle of end-user account management, but if the rules they follow are incomplete or flawed, they can create access rights that violate company policies and cause regulatory compliance issues. Implementing a recertification process as part of the initial provisioning system rollout is one of a few key user provisioning best practices, allowing auditors, security personnel and managers responsible for end-user access to verify that the workflows and rules configured within the provisioning system are correct. In addition, by defining this process up front, as new systems are connected to the provisioning system and new workflows are defined, the recertification process can be modified to ensure the provisioning system configurations are correct the first time, and not after a security incident has occurred because someone had access to information they shouldn't have.

About the author:
Randall Gamby is an enterprise security architect for a Fortune 500 insurance and finance company who has worked in the security industry for more than 20 years. He specializes in security/identity management strategies, methodologies and architectures.