An Italian clichè

A friend of mine sent me an e-mail with a ppt file attachment. It was in Italian, but the translation in English was easy. It was a joke on an Italian cliché, but it was a great illustration of a common Identity management nightmare: role explosion!

Yes, at least in Italy, most customers we work with are very clever at imagining every level of nuance when “theoretically” defining roles in their organization.

But fortunately, we are used to facing their anarchy and we know how to prevent the awkward problem of “role explosion”.
As the picture says, to survive we have been forced to take adequate countermeasures. For example the waitress can simplify the orders by requiring the customers to add their own sugar, milk, liquor, etc. Therefore, by restricting the number of kinds of coffee, requests are delivered in a timely manner while maintaining flexibility.

So, business managers, don’t be afraid: just select the right tools and adopt the appropriate methodology!

New Technical Paper on Role Mining

A new Technical Paper, “Leveraging Lattices to Improve Role Mining”, has been recently accepted and will be presented at the coming SEC 2008 23rd International Information Security Conference, co-located with IFIP World Computer Congress 2008, Milan, Italy, September 8-10, 2008.
Topics of interest of this conference include, but are not limited to:

• Access control
• Security and Content Policies
• Role Mining
• Security Compliance
• Identity and Trust Management

The paper highlights some crucial aspects on which Engiweb Security “IDEAS Role Constructor” module is based.

Abstract:
“In this paper we provide a new formal framework applicable to Role Mining algorithms.
This framework is based on a rigorous analysis of identifiable patterns in access permission data. In particular, it is possible to derive a lattice of candidate roles from the permission powerset.
We formally prove some interesting properties about such lattices. These properties, a contribution on their own, can be applied practically to optimize role mining algorithms. Data redundancies associated with co-occurrences of permissions among users can be easily identified and eliminated, allowing for increased output quality and reduced processing time.
To prove the effectiveness of our proposal, we have applied our results to two existing role mining algorithms: Apriori and RBAM. Application of these modified algorithms to a realistic data set consistently reduced running time and, in some cases, also greatly improved output quality; all of which confirmed our analytical findings.”
Authors: Alessandro Colantonio, Roberto Di Pietro, Alberto Ocello

Nice, Friends!, But, pardon me if I find much more pleasant another kind of Lattice: A nice piece of the Rhubarb-Strawberry Lattice Tart really hits the spot!

BTW if you are interested in receiving the full text, please send me an e-mail: my surname at eng dot it.

Inconsistency: the revenge

Before going on to introduce the second inconsistency case study, I just want to stress again that we are not speaking of a sort of “event manager” that monitors the activities performed directly on targets and blocks any possible operation. Here we are introducing a solution (part of a Governance and Compliance framework) that intelligently tries to understand if this operation could be accepted, taking into account presently enforced security policies. As a matter of fact, the realistic situation we are facing is the typical end-user’s requirement for additional access to another application (target). The official way (e.g. following a workflow) is not fast, so he calls his friend that works in the IT administration and bypasses the official procedure, quickly achieving access to his coveted application.

Previous episode: IAM System - Targets inconsistency policies: remove
There is not way to prevent someone (a naive “authorized” administrator ) from removing Profile1 from user John on target1.
Meanwhile, the IAM system must assure a single centralized record of reference, even if the IAM administrator is gambling poolside at Vegas with his new intelligent mobile phone…
To be more clear, take a look at the following diagram:


This Latest Episode: IAM System - Targets inconsistency policies: add!
As already anticipated, if the Administrator, again directly on a target, adds a profile to John, this would be even more difficult to manage as there could be a huge impact on Separation of Duty verification.

Actually managing the already described “remove” scenario, means assuring Security Policies, even if the operation ability of the “involved” user could be somehow diminished, but when the unaware user (John) gets a new profile with a direct action on the target, no preventive compliance control is performed and the real danger could be: Security breaches, failed audits, non-compliance, all the way up to fraud.

One again a sound IAM solution should effectively manage the risks associated with such a scenario, with the objective of assuring compliance with the least operational impact.

The following diagram explains how the Engiweb Security solution (the IDEAS suite) deals with this inconsistency (the offset between the IDEAS core repository and a generic target system) and how the Inconsistency Role Engine goes to work to repair the offset.

In this case, an authorized administrator accesses target1 and adds Profile1 to user John.

If the policies are set to try and accept the profile addition if possible, the first check is performed using a Segregation mechanism on the base OU. A profile is available for assignment to a user belonging to a certain OU only if “visible on that OU”. In this situation, particular profiles having some criticality can be “hidden” to OU’s that do not have the so-called “need to know”.

A second mechanism, used in the next checks, performs profile and role incompatibility management. This mechanism is supported by a powerful incompatibility SoD engine able to make run-time checks on a pre-assigned conflict matrix and contextual information. The system also contains a Role_Policy_Definition module which, starting from high-level incompatible activities, helps the administrator define a matrix of conflicting profiles.

Illegal roles and incompatible role-pair lists are also used by the IDEAS Profile Provisioning for other run-time SoD checks during user provisioning compatibility control. The SoD engine is queried for each new role assignment request. If assigning the role makes the user illegal, different authorization workflow steps can be executed.

Yes, in this case our IAM administrator can spend some more time poolside at Vegas undaunted by any notifications he may receive on his new intelligent mobile phone regarding of what’s happening at work!

IAM System - Targets inconsistency policies

I’m joining Matt Flynn discussion on “Extending the ROI on Provisioning”, where he highlights an intriguing problem: how to manage direct modifications on the targets, where a IAM solution is in charge of providing approval workflow, synchronization, compliance, etc..…

Yes. Most organizations we work with are quite concerned about managing direct access to target resources, getting around workflows and central management (e.g. a profile assignment to a user directly on a target).

They confirm that despite all the precautions, it is always possible for inconsistencies to be created in their IT systems, causing authorization misalignments between the target systems and the IAM system.
Moreover, it is not possible to automatically classify and correct in advance all types of inconsistencies that can occur. However, it is certainly possible to provide a tool to detect and manage misalignments.

In our solution (the IDEAS suite), this problem is referred to as "Inconsistency Management". Within IDEAS' internal multilayer model, such actions can lead to the modification of many relations with decisions depending on many factors that must be shaped into appropriate policies.
Thus, whenever an inconsistency occurs (an offset between the IDEAS core repository and a generic target system) the Inconsistency Role Engine goes to work to repair the offset.

But what is the meaning of repairing?

Often there are difficult decisions to be made.

For instance, an authorized administrator accesses target1 and removes Profile1 from user John. Unfortunately Profile1 was assigned to John via a higher level Role: "Role1", which is actually composed of many other profiles on several targets (including of course Target1). Thus how should the IAM solution react?

The simplest policy could be to state that the central system is authoritative and thus everything must be reset back to original settings.
Another alternative policy could state that if the administrator is trusted, the modification must be accepted. But in the central repository of reference, John is assigned Role1, NOT Profile1. So alignment could mean the following:

• remove the entire Role1 from John, or
• verify if there is another available Role composed of all Role1 profiles except Profile1 (e.g. name this Role 2). If so, remove Role1 from John and assign Role2. If Role1 is part of a hierarchy and a lower level Role without Profile1 is available, it could be possible to assign this Role to John instead of Role1. In this case, while there is no impact on compliance, there could be a possible limitation on user access rights
• Notify the relevant people (e.g. IAM administrator, Role1 owner and all actors involved in Role1 authorization workflow, etc..) that there is an offset between the central DB and the target. The policy could state that if there will be no remediation activities within a defined time period, the original settings will be restored.

If the Administrator, again directly on a target, adds a profile to John, this would be even more difficult to manage as there could be a huge impact on Separation of Duty verification. I'll try to write a specific post on this item very soon.

P.S: IDEAS ( IDEntity and Access management Suite) is a solution addressing the full gamut of Enterprise Role Management needs in multiple IdM solutions.

“User lock/unlock” management scenario

In my previous post I was raising doubts about the fact that implementing lock/unlock account procedure might not be so easy. Here I’m trying to explain why.

Preliminary remarks: although this requirement is rarely present in IAM project RfP’s, it is obvious that any large organization already has a procedure disciplining the user lock/unlock processes. Let’s try to imagine it in detail.

A user can be locked for various reasons. For example:

1. Technical lock (a user is locked because he or she has exceeded max wrong passwords or due to extended inactivity).
2. Administrative lock (specific events coming from HR determine a temporary or definitive user lock i.e. maternity leave or grace period before expiration).
3. Security lock (a user is locked by a security manager).

It is also obvious that unlock procedures must follow hierarchy rules, such as:

1. A Technical lock on a user can be removed by any administrator (Head of Unit, Help desk etc..).
2. A Security lock on a user can only be removed by a Security Officer.
3. An Administrative lock on a user CANNOT be removed by any administrator. His or her unlock is determined only by an HR event (return after long leave or expiration interruption etc..).
4. To complete complexity, if a user’s Security or Administrative lock is directly removed by the target (e.g. using AD console), then the IAM system must react in real time by resetting the unlock.

These processes must be managed by the IAM system since access systems (e.g. MS Active Directory) do not have the “intelligence” for this purpose and therefore cannot “assist” such management.
If this type of requirement, even though not particularly complex, is not directly supported by the tool’s data model, a custom development consisting of "data model” definition managing would be required.
The data model shall support data, relations between them and other already available data as well as necessary developments to implement policies.

In conclusion:

• When the product data model itself already supports these processes, mapping of the said process is reduced to pure and simple configuration in no time. Maintenance and changes are made by high level administrators
• In case native support is not available, the following should be expected: detailed technical specification definition, Data Model updating, policy writing (usually at low level) and tests, changes, complex management, etc….

RBIA: The Great Unknown

An Identity and Access Management project is not always an easy job. It is very difficult to describe in few words why, but one reason for sure is that in the IAM environment procedures are always more important than technology. In other environments, (e.g. Document Management), technology can drive procedures, thus the right technology choice is the most important aspect.

Conversely, in the IAM environment it is quite impossible to find customers willing to change procedures because technology is unable to map these procedures into the product (or achievable only with huge software customisation). Procedures are important and relevant processes have to be mapped into technology without compromises.

On the flip side of the coin, there is another aspect to consider.
AM technology is still evolving. Most “official” IAM technology vendors are coming from the User Provisioning environment; in essence, coming from the bottom. Pure technology. Of course vendors are adding features trying in attempts to raise the bar but they are still conditioned by original sin – They want to add intelligence to technology instead of adding technology to intelligence.

Intelligence, as in many other IT contexts, is represented mostly by the conceptual model standing behind the product and a data model representing the conceptual model.
The secret of product “intelligence” lies in the conceptual model and its relevant data model.
Technology features like a beautiful, rich graphical interface for workflow design or the huge standard support are all important aspects, …. but I suggest that customers intending to acquire an IAM solution verify how complex it could be to implement simple procedures (e.g. user lock/unlock levels or procedure). It turns out to be a mess with customized software development and the writing of many, many technical policies: even if within a nice graphical environment.

This situation has encouraged the founding of companies who start from RBAC and progressively enrich the model to reach complete RBIA (Role based Identity Administration).
The RBIA model intends to integrate all concepts of User Management (including Credential Management), Role Management, Role Engineering, SOD compliance, Audit and Reporting all the way up to Unified Identity Approach, in order to unify Logical and Physical Access Management views.

According to my understanding, customers’ important expectation of an IAM project that easily supports present and future Identity Management procedures and processes, indicates that a field proven RBIA product is a “must”.

Addition of RBIA functionalities could result in an increase in license costs with respect to the budget sum. However, in our experience, this is greatly offset by tremendous savings of time and cost of project implementation along with a heavy reduction of project risks.

BTW, in a following post I’ll try to justify why implementing a lock/unlock account procedure might not be so easy.

Power is nothing without control

As Italian tyre giant Pirelli's advertising reminds us, "Power is nothing without control." But managing identity, roles and access control is often worthless or at least can be a nightmare without the right tools and handling ability.

Last Monday (yes January the 2nd, during Christmas holidays which, in Italy, officially end on January 6th), one of our largest customers decided to activate a complex internal shake-up.
The reorganization consisted of selling-off one of their companies and merging several internal divisions to form new companies. To summarize, 700 new Business Units (out of 20000) were created, and more than 8500 users (out of 85000), mainly employees, were reassigned with modified business responsibilities and access rights.

Of course the IAM system is directly linked to the company HR system, and role management is integrally aligned with identity management. The solution is quite HR-oriented, incorporating business structure and responsibilities. The viable Role management solution addresses resource/responsibilities association and SoD, and is supported by 3 rule engine environments which implement administrative and security policies.
Since HR is directly connected to the IAM systems, each modification in the HR system usually activates an update in the Role management internal repository. The Resource-Provisioning functions then start synchronizing with the relevant target systems (SAP R/3, AD, etc).

Do they like the automatism advantage of such an IM implementation?
The answer is yes and no. In general, if the operation exceeds a certain complexity threshold, the customer wants full control over all the complete chain of input and output events. As this was the case, they wanted to verify, ahead of time, the impact of this complex reorganization.

Specifically, HR modifications instantly affected the model within the Role/IM infrastructure, but the customer deactivated resource provisioning. They wanted more time to evaluate the final reorganization results. Analyzing the new organization model within the IM repository was sufficient enough to evaluate these effects.

Since they were quite concerned about the number of users to be removed across the several targets, they blocked the massive HR-driven operations and then printed a specific report listing users to be removed along with the action type and justification (reason) codes.

This helped them determine whether or not the HR input was correct and if the policies implemented had any bugs. As it turned out, they discovered that a policy rule was, in fact, not well written.

Even though this all happened during Christmas holidays, they used the tools available inside the Role management infrastructure without any intervention from the System integrator.

Of course, while the HR operations were blocked during the analysis, all modification on roles and business responsibilities arriving from the authorization workflow carried on as normal, including the activation of modifications on the targets via Resource Provisioning modules.

Again, as Pirelli’s mantra goes: power is nothing without control…