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!

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…