To achieve a high level of configurability with minimal complexity, Identity Auditor makes judicious use of rules in audit policy and access scan object configuration.
Table 4–13 provides an overview of the rules you can use to customize how audit policy remediation works and how access scans operate.
Table 4–13 Auditor Rule Types Quick Reference
Rule Type |
Example Rules |
subTypes and authTypes |
Purpose |
---|---|---|---|
Attestor |
Default Attestor |
SubType: ATTESTORS_RULE AuthType: AccessScanRule |
Automates the attestation process by specifying a default attestor for manual entitlements. |
Attestor Escalation |
Default EscalationAttestor |
SubType: AttestorEscalationRule AuthType: AccessScanRule |
Automates the attestation process by specifying a default escalation user for manual attestation. |
Audit Policy |
Compare Accounts to Roles |
SubType: SUBTYPE_AUDIT_POLICY_RULE SubType: SUBTYPE_AUDIT_POLICY_SOD_RULE AuthType: AuditPolicyRule |
Compares user accounts to accounts specified by current Roles. |
Compare Roles to Actual Resource Values |
SubType: SUBTYPE_AUDIT_POLICY_RULE SubType: SUBTYPE_AUDIT_POLICY_SOD_RULE AuthType: AuditPolicyRule |
Compares current resource attributes with those specified by current Roles. |
|
Remediation User Form |
SubType: USER_FORM_RULE AuthType: Not specified |
Automates the attestation process by allowing audit policy authors to constrain which part of a User view is visible when responding to a particular policy violation. |
|
Remediator |
Default Remediator |
SubType: REMEDIATORS_RULE AuthType: AccessScanRule |
Automates the remediation process by specifying a remediator for any entitlements created in remediating state. |
Review Determination |
Reject Changed User |
SubType: REVIEW_REQUIRED_RULE AuthType: AccessScanRule |
Automates the attestation process by automatically rejecting user entitlement records. |
Review Changed Users |
SubType: REVIEW_REQUIRED_RULE AuthType: AccessScanRule |
Automates the attestation process by automatically approving user entitlement records. |
|
Review Everyone |
SubType: REVIEW_REQUIRED_RULE AuthType: AccessScanRule |
Automates the attestation process by requiring manual attestation for some user entitlement records. |
|
User Scope |
All Administrators |
SubType: USER_SCOPE_RULE AuthType: AccessScanRule |
Provides flexibility in selecting a list of users to be scanned by an access scan. |
All Non-Administrators |
SubType: USER_SCOPE_RULE AuthType: AccessScanRule |
Provides flexibility in selecting a list of users to be scanned by an access scan. |
|
Users Without a Manager |
SubType: USER_SCOPE_RULE AuthType: AccessScanRule |
Provides flexibility in selecting a list of users to be scanned by an access scan. |
|
ViolationPriority |
ViolationPriority |
SubType: Not specified AuthType: EndUserAuditorRule |
Customization— allows the deployment to specify what are valid violation priorities and the corresponding display strings. |
ViolationSeverity |
ViolationSeverity |
SubType: Not specified AuthType: EndUserAuditorRule |
Customization— allows the deployment to specify what are valid violation severities and the corresponding display strings. |
The following sections provide information about these Identity Auditor rules, how you might customize them, and why:
Every user entitlement that is created in a pending state must be attested by someone. During an access review, Identity Auditor passes each User view to the Attestor rule to determine who gets the initial attestation requests.
The idmManager attribute on the WSUser object contains the Waveset account name and ID of the user’s manager.
If you define a value for idmManager, the Attestor rule returns idmManager as the attestor for the user represented by the entitlement record.
If the idmManager value is null, the Attestor rule returns Configurator as the attestor.
You can use alternate implementations to designate both IdmManager and any Resource owners as attestors (for Resources included in the view). This rule takes the current User view and a LighthouseContext object as inputs, so you can use any data known to Waveset.
Inputs:
Accepts the following arguments:
userEntitlement: Current User view
lhcontext: LighthouseContext
objectowners:
objectapprovers:
You must specify the following for a custom Attestor rule:
A workflow calls the Attestor Escalation rule when an attestation times out because the attestor did not take action within a specified period of time. This rule returns the next person in the escalation chain based on the cycle count.
Inputs:
Accepts the following arguments:
wfcontext: WorkflowContext
userEntitlement: Current view of user entitlement, including User view
cycle: Escalation level. For the first escalation, the cycle is 1.
attestor: Name of attestor who failed to attest before the attestation request timed out.
You must specify the following for a custom Attestor Escalation rule:
An audit policy contains a set of rules that it applies to data representing an object being audited. Each rule can return a boolean value (plus some optional information).
To determine whether a policy has been violated, the audit policy evaluates a logical operation on the results of each rule. If the audit policy has been violated, a compliance violation object might result, with (typically) one compliance violation object per policy, rule, or whatever was being audited. For example, an audit policy with five rules might result in five violations.
Inputs:
None
You must specify the following for a custom Audit Policy rule:
The RULE_EVAL_COUNT value equals the number of rules that were evaluated during a policy scan. Waveset calculates this value as follows:
RULE_EVAL_COUNT = # of users scanned x (# of rules in policy + 1)
The +1 is included in the calculation because Waveset also counts the policy rule, which is the rule that actually decides if a policy is violated. The policy rule inspects the audit rule results, and performs the boolean logic to come up with a policy result.
For example, if you have Policy A with three rules and Policy B with two rules, and you scanned ten users, the RULE_EVAL_COUNT value equals 70 because
10 users x (3 + 1 + 2 + 1 rules)
The Remediation User Form rule allows audit policy authors to constrain which part of a User view is visible when they are responding to a particular policy violation.
When a remediator edits a user during entitlement remediation processing, a JSP (approval/remModifyUser.jsp) calls the Remediation User Form rule. This rule allows the access scan to specify an appropriate form for editing a user. If the remediator has already specified a user form, then the access scan uses that form instead.
Inputs:
Accepts the item argument (Remediation WorkItem)
You must specify the following for a custom Remediation User Form rule:
AuthType |
Not specified |
SubType |
USER_FORM_RULE |
Called |
During JSP form processing after the remediator clicks Edit User on the remediation form. |
Returns |
The name of a User Form or a null. |
Predefined Rules |
None |
Location |
|
During an access review, every User view is passed to the Remediator rule to determine who should get the initial remediation requests. This rule is analogous to the Attestors rule, except the Remediator rule is called when a workitem is created in the remediating state.
Inputs:
Accepts the following arguments:
lhcontext: LighthouseContext
userEntitlement: Current User view
You must specify the following for a custom Remediator rule:
AuthType |
AccessScanRule |
SubType |
REMEDIATORS_RULE |
Called |
During access scan, after evaluating all audit policies and before dispatching the user entitlement |
Returns |
A list of zero or more Waveset remediator names or NamedValue pairs.
Note – If the rule returns NamedValue pair elements, they are passed on without validation. |
Predefined Rules |
Default Remediator |
Location |
Compliance > Manage Policies > Access Scan > Remediator Rule |
During an access review, every User view is passed to the Review Determination rule to determine whether the corresponding user entitlement record can be automatically approved or rejected, automatically placed into remediation state, or if the record must be manually attested. A user entitlement is a complete User view (in which some resources might be omitted) and some tracking data.
You can use the Review Determination rule to significantly increase the efficiency of an access review by
Encapsulating any institutional knowledge that would allow a user to be automatically approved or rejected. If you express that knowledge in this rule, you reduce the number of manual attestations needed and improve overall review performance.
Configuring this rule to return information that is visible to the attestors as a “hint.” For example, when the rule determines that a user has privilege access to a resource, the rule provides a hint to the attestor, as shown in the following example:
<map> <result> <i>1</i> <s>reason</s> <s><reason the attestation was auto-approved/rejected></s> <s>attestorHint</s> <s><hint to attestor></s> </map> |
Configuring the rule to access the User view (including any Compliance Violations) and compare the user’s previous user entitlements, which allows the rule to approve or reject all user entitlements that are the same as (or different from) a previously approved user entitlement.
You can add an argument that allows the rule to compare subsets of the User view. For example:
<set name=’viewCompare’> <!-- compare the entire view (3rd argument can specify sub-path) --> <invoke name=’compareUserViews’ class=’com.sun.idm.auditor.ui.FormUtil’> <ref>userView</ref> <ref>lastUserView</ref> <s>accounts</s> </invoke> </set> |
This argument compares User views and allows the caller to specify a subpath of the complete User view using GenericObject path expressions. If you just want to compare particular account data, the subpath can specify that data. If you compare just the accounts subpath of the User view, you are less likely to encounter differences that are not reflected on a real resource.
Differences found in the User view comparison are returned in the reason element of the output map. The audit log captures this difference data if the rule returns 0 (reject attestation) or 2 (approve attestation), just as the predefined Reject Changed Users rule does.
You can use the Reject Changed Users rule to verify exactly what Waveset thinks is different and you can look at the auditable attributes in the resulting audit log records.
Inputs:
Accepts the following arguments:
context: LighthouseContext
review.scanId: Current access scan ID
review.username: Waveset account name of user being scanned
review.userId: Waveset ID of user being scanned
attestors: Attestors’ Waveset account names
userView: Current User view
You must specify the following for a custom Review Determination rule:
AuthType |
AccessScanRule |
||
SubType |
REVIEW_REQUIRED_RULE |
||
Called |
During access scan, after evaluating all audit policies and before dispatching the user entitlement |
||
Returns |
An integer or a map
|
||
Predefined Rules |
|
||
Location |
Compliance > Manage Access Scans > Access Scan > Review Determination Rule |
If an access scan has users scoped by a rule, the User Scope rule is evaluated to determine a list of users to scan.
Inputs:
Accepts the lhcontext argument
You must specify the following for a custom User Scope rule:
AuthType |
AccessScanRule |
SubType |
USER_SCOPE_RULE |
Called |
At the beginning of an access scan |
Returns |
An Waveset user name or a list of Waveset user names. Each name must be a valid Waveset user name.
Note –
|
Predefined Rules | |
Location |
Compliance > Manage Access Scans > Access Scan > User Scope Rule |
Use the ViolationPriority rule to allow a deployment to specify what the valid violation priorities are, and what the corresponding display strings will be.
Inputs:
None
You must specify the following for a custom ViolationPriority rule:
AuthType |
EndUserAuditorRule |
SubType |
Not specified |
Called |
When displaying the violation list and when changing violation priority. |
Returns |
A list of key/value pairs indicating priority integer value and a corresponding string. The integer values must be contiguous because the rule returns a list, not a map. Note – You can customize this rule to change the display value for any priority setting. When a ComplianceViolation is created, you can change priority values in the Remediation WorkItem list viewer. Select one or more Remediation WorkItems, and then select Prioritize, which enables you to change priority values. To see these values in the Remediation WorkItem list view, you must change the approval/remediate.jsp page by setting the includeCV option to true (default is false). However, enabling the more detailed view affects performance, which may be unacceptable for deployments with lots of Remediations. The custom value expects the ViolationPriority rule to be an array rather than a map. So, if you use 100 as the integer value, the rule must have 200 elements (alternate int/string). The list provides both string mapping for the integer and populates the selection in the form where you changed it. |
Predefined Rules |
ViolationPriority |
Location |
Called from the Remediation List Form |
Use the ViolationSeverity rule to allow a deployment to specify what the valid violation severities are, and what the corresponding display strings will be.
Inputs:
None
You must specify the following for a custom ViolationSeverity rule:
AuthType |
EndUserAuditorRule |
SubType |
Not specified |
Called |
When displaying the violation list and when changing violation severity. |
Returns |
A list of key/value pairs indicating severity integer value and a corresponding string. The integer values must be contiguous because the rule returns a list, not a map. Note – You can customize this rule to change the display value for any priority setting. When a ComplianceViolation is created, you can change severity values in the Remediation WorkItem list viewer. Select one or more Remediation WorkItems, and then select Priority, which enables you to change severity values. To see these values in the Remediation WorkItem list view, you must change the approval/remediate.jsp page by setting the includeCV option to true (default is false). However, enabling the more detailed view affects performance, which may be unacceptable for deployments with lots of Remediations. The custom value expects the ViolationSeverity rule to be an array rather than a map. So, if you use 100 as the integer value, the rule must have 200 elements (alternate int/string). The list provides both string mapping for the integer and populates the selection in the form where you changed it. |
Predefined Rules |
ViolationSeverity |
Location |
Called from the Remediation List Form |
The following example demonstrates how to use the Sample Auditor Rule Multiple Account Types rule. The location of the rule is
sample/rules/SampleAuditorRuleMultipleAccountTypes.xml |
Set up a resource with multiple account types.
<?xml version=’1.0’ encoding=’UTF-8’?> <!DOCTYPE Waveset PUBLIC ’waveset.dtd’ ’waveset.dtd’> <Waveset> <Rule subtype=’IdentityRule’ name=’Administrator Identity’> <concat> <s>adm</s> <ref>attributes.accountId</ref> </concat> </Rule> </Waveset> |
Add a user with two accounts on the resource and set up a user form so that the new resource attributes are directly assigned separately:
account[Simulated Resource].department account[Simulated Resource|admin].department |
Assign different values for each account and test the policy rule.
Location:
sample/rules/SampleAuditorRuleMultipleAccountTypes.xml |