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!
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!
