Defining policy violations with Quest One Identity Manager

Recently I was asked if Quest One Identity Manager supported the ability to define policy violations within and across applications, resources and target systems and by luck I came across a good explanation by a colleague which I decide to add a couple of screenshots to further explain the topic and blog about it. Defining policy violations is a standard feature of Quest One Identity Manager. Our Auditing subsystem has wizards which can help in the creation of business rules which return true or false to indicate a rule violation. The wizards can use natural language expressions to help non-technical persons build compliance rules. Drop down selects exist for the user to specify the resources.

Diagram 1: Employees from department A may not belong to department B at the same time.

For the more technical individual there is also the option to specify the Rule in technical language and bypass the wizard. Quest One is unique in that the business rules have a full simulation mode whereby the results of the Rule can be viewed without committing the Rule to be live/operational within the system itself.

Diagram 2: Employee objects affected in a single partial condition

Our design enforces Rule versioning such that all changes to compliance rules are fully audited and go through the right level of process review before being enabled as operational. Using this best practice approach we can prevent any 'nasty-surprises' whereby an audit rule no longer works on known test-cases for example. The rule results are previewed, audited, versioned and approved before any rule can go live. Quest One Identity Manager also supports the use-case of Rule attestation whereby a Rule can be periodically reviewed by a static or dynamic set of Rule Owners to verify the continued accuracy of the Rule itself.