Sunday, August 29, 2010

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.

Friday, August 27, 2010

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.