Bay31 announces Role Designer for role mining and role analysis

Bay31 announces Role Designer - a completely new solution for role mining and role analysis.

From now on, I'll blog on Access Governance at blog.bay31.com. I hope to see you there.

GRC shifting the center of gravity in IAM

Here is a prediction that has consequences for the IAM industry: The growing importance of access governance is changing the ROI calculation for investment in IAM. Traditionally, investment in IAM has been justified mainly by lower costs for IT processes. But the ongoing convergence of IAM and GRC is shifting the ROI calculation from IT processes to core business processes.

Access management is the "last mile" of many enterprise governance processes. For example, remediating SoD policy conflicts means revoking or compensating certain user entitlements, and tracking the compensating controls. A centralized entitlement repository is a valuable source of operational risk information for ORM tools. And access events are the low-level triggers for many enterprise governance processes prescribed by governance frameworks, such as COBIT, or data privacy regulations, such as HIPAA. Ultimately, this will unite GRC, access governance (SoD, access certification, role management, etc), entitlement management and provisioning. IAM will take a supporting role to business technologies higher up the value chain.

A consequence is that companies that serve businesses with technology for risk management, compliance, and business process governance now have an opportunity to unseat the incumbents in IAM, whose customers are primarily IT departments. Some examples are:

• Management consulting firms, particularly those with general risk management expertise
• Providers of ERP and general business process automation
• MSSPs and providers of cloud services

I think this shift will drive the IAM segment over the next couple years. I welcome your comments.

Bottom-up vs. top-down access risk analysis

Bottom-up access risk analysis refers to risk metrics that can be calculated automatically from low-level user permissions. A trivial example is the number of access permissions a user has (more is riskier). This bottom-up approach is attractive because it is automatic and gives the impression that a very clever algorithm may do the hard work for us to identify operational access risks.

The holy grail of bottom-up risk analysis is a single quantitative "risk score" for a user – any user with a risk score greater than some magic number would be subjected to a review. While I don't discount that there are some useful quantitative risk metrics, I think there is a dose of hype behind the scoring approach.

Top-down risk assessment, on the other hand, is not automatic. The top-down approach requires that people make subjective assessments of the risk associated with certain kinds of access. I visualize it as labeling applications, processes and other access entities with red, orange and yellow "risk labels". The challenge is to create a model of enterprise access that facilitates this risk assessment.

Engiweb Security IDEAS' access management model has a number of entities that are particularly suitable for top-down risk assessment:

• Roles – groups of permissions that correspond to a business function.
• Activities – the building blocks of business processes. For example, the complete purchase process may consist of 3 activities: 1) creating a purchase order, 2) approving a purchase order and 3) executing a purchase order. Activities are associated with the permissions required by a user to perform the activity.
• Applications – such as an accounting or CMS application. Applications are hierarchical, so they can model functional or logical parts of an application. An application is associated with the permissions that grant access to the application (or part of the application).
• Policy conflicts – conflicts with access policies, such as segregation of duties, role visibility, or activity visibility.

The key is that all these entities are defined by combinations of access permissions and are thus interconnected. For example, if a certain activity is assessed as high risk, and a certain role confers the permissions necessary to perform that activity, then this indirectly implies that the role is also high-risk, although it was not explicitly defined as such. This works the same way with users: by analyzing a user's permissions, the system can automatically discover the users roles, activities, applications and policy conflicts, creating the user's access risk profile.

A user's risk profile can be displayed during access management processes, such as access request workflow, to support decision making. For example:

The interconnectedness of the entities in the model means that access risk assessments can be made by independently by different experts, in different parts of the enterprise. As more risk assessment information is added, the network grows and gets richer. The trick becomes to implement a workflow that that coordinates the assessment tasks of the various people, and keeps the assessments up to date.

Trip Report - The Garnter IAM Summit in London

I went to this conference looking for some confirmation of a couple pet theories of mine (but by no means only mine):

• That the driver for IAM investment is shifting from IT cost-savings to regulatory compliance and governance.
• And that IAM and GRC are converging.
  

Certainly this view was reflected in the vendor displays, many of whom touted their products' support for "policy" and "compliance".

But in the customer case studies, discussion of "compliance things" like access certification, SoD and identity risk remediation was almost completely absent. When I described some of my IAM/GRC convergence ideas to one of the Gartner analysts, he gave me the feeling I was talking pie-in-the-sky. Earl Perkins scolded "us" in his presentation that in 2010 implementing even basic IAM functionality like user provisioning is still a risky venture for a company. Perhaps we should not be aspiring to "fancy" things while customers are still struggling with the basics.

But I'm not convinced of this - I don't think it is too soon to offer the benefits of IAM technology to GRC customers. My hunch is that if you try to automate many reporting, audit and governance processes, the "last mile" will often be in IAM, particularly entitlement management. But we need to begin with GRC business processes and work down to the technical plumbing, instead of the other way around. We need to start thinking of IAM as business infrastructure, instead of IT infrastructure.

I'd like to speak with non-IT people responsible for GRC business processes, but I did not find people like that at the Gartner IAM Summit. Maybe I need to start hanging out at different conferences.

In London this week: At the Gartner Identity & Access Management Summit

I'll be in London on Wednesday and Thursday this week to attend the Gartner Identity & Access Management Summit. If you're attending, feel free to introduce yourself.