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.