7.1 Configuring and Leveraging Policies

Configuring and Leveraging Policies

Objective 3.3 is configure and leverage policies. A policy describes a condition an identity should never have, such as the same person both creating and approving payments. When an active policy finds that condition, IdentityIQ creates a policy violation for someone to act on (section 7.2). Policies are defined on Setup > Policies. That page is usually limited to System Administrators and Policy Administrators.

The Seven Policy Types

A policy can contain many rules. For example, one Finance Role Conflicts policy might hold a dozen SOD rules. SailPoint's best practice is to group related rules under one well-named policy and give every rule a name that says what it checks.

Policy-Level Settings

• Owner – maintains the policy and is the fallback violation owner. If alerts are enabled, the owner is emailed about each violation by default.
• Policy Violation Owner – who acts on violations: a specific identity or workgroup, the manager of the violating identity, or someone chosen by a rule. A violation owner set on a rule overrides the policy-level one.
• Scope – limits who can see the policy on the Policies page. It does not change how violations are shown or monitored.
• Description – can be entered in several languages. Rule descriptions cannot be localized.
• Violation formatting rule – adds detail to the violation, such as the applications involved, which is especially useful for Advanced policies.
• Violation business process – a workflow that assigns or handles violations. A business process set on a rule overrides the policy's.
• State – Active policies are evaluated. Inactive policies are not.
• Send Alerts – initial notification template, an Open Work Item option, and an escalation style: None, Send Reminders, Reminders then Escalation, or Escalation Only. You also set reminder frequency, reminders before escalation, an Escalation Owner Rule, and Observers. Observers get emails only, and only the owner gets a work item.

Rule-Level Settings

Each rule has a summary, description, violation owner, formatting rule, business process, and Disabled flag. It also has two informational text fields:

• Compensating Control – documents exceptions, such as executives being exempt. It is documentation only and does not change risk scoring or reporting.
• Correction Advice – shown to a certifier or violation owner who is deciding which access to revoke.

Detective vs. Preventive Evaluation

Policies are evaluated per identity.

• Detective: finds violations that already exist. Select Check active policies in an Account Aggregation or Identity Refresh task. Refresh adds Keep previous violations (retain history of resolved violations) and a comma-separated list of policy names to check only those active policies. Inactive policies are never evaluated, even if listed.
• Preventive: catches violations at request time. The LCM Provisioning and LCM Create and Update business processes have policy-checking settings: Disable Policy Checking, Continue on Policy Violations (approvers see them), Present Failures to Requester (requester can remove items), or Fail Workflow. They also let you check All or Selected policies. Preventive checking is optional because you may not want to reveal which combinations enable fraud.

Testing Safely with Simulation

Run Simulation checks a policy, or a single rule, against every identity. It reports only a count of violators. It does not create violations, work items, or a list of names. It can be slow on large systems.

Side effects to remember:

• Simulating the whole policy saves it and sets it to Inactive. Set the state back to Active and save when done.
• Simulating one rule disables only that rule. The policy state does not change.
• Make sure rule names are unique within the policy before simulating.

Worked Example: A Payment SOD Policy

1. Create a Role SOD policy named Finance Payment Controls. The owner is the Compliance workgroup, and the violation owner is the manager of the violating identity.
2. Add a rule, Payment Prep vs Payment Approval. Put Payment Preparation on the left and Payment Approval on the right, and add correction advice ("revoke the role not tied to the person's job code").
3. Run Simulation to see how many identities already violate it. Review the count, then set the policy back to Active.
4. Enable Check active policies on the nightly refresh (detective), and set LCM Provisioning to Present Failures to Requester (preventive).