Use Case 10: OTP Challenge with Multi-Bucket Patterns

10 Managing Policies, Rules, and Conditions 10-1 10 Managing Policies, Rules, and Conditions Policies are used by organizations to monitor and manage fraud or to evaluate business elements. Policies contain security rules and configurations used to evaluate the level of risk at each checkpoint. This chapter introduces you to the concepts behind policies, rules and conditions and provides information about creating and managing them.

10.1 Introduction to Policies, Rules, and Conditions

This section introduces you to the concept of policies and rules and how they are used in Oracle Adaptive Access Manager.

10.1.1 Policies

A policy is a collection of rules associated with a checkpoint. The outcome of the policy evaluation is a score, actions and alerts. The policy outcomes can be used to enforce decisions by client applications. For information on rules, see Section 10.1.2, Rules. Using Oracle Adaptive Access Manager, you can create policies based on your business requirements. The attributesdatapoints of the activities you are interested in are mapped to conditions and the evaluations to perform are translated into rules. These rules are added to a policy. Checkpoints are set up in the session for when the policy evaluates the activity. For example, a policy can be executed during the Pre-Authentication checkpoint. The Pre-Authentication checkpoint is a point in time before the user enters the password. When the rules are run, data is collected. For information, see Section 10.1.4, Checkpoints. During the normal course of business, the system looks for datapoints the conditions were mapped to. When all the conditions met, the system calculates a score, and depending on the policy that you defined earlier for handling the situation, it may generate alerts in real-time, or trigger actions, or both. For example, outcomes can be challenging or blocking the user or activating an alert. A rule evaluates to true when all the conditions match. The outcome of a rule is a score and optionally actions or alerts, or answers and alerts. The outcome of a policy is decided by applying a scoring policy on the rule scores of the policy. In addition to the score, you can optionally configure trigger combinations which are combinations of rule results of the policy and that can invoke actions andor generate alerts. For more information about trigger combinations, see Section 10.1.10, Trigger Combinations and Triggers. 10-2 Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager Because fraud or the business climate is ever-changing, you must re-evaluate policies periodically to reflect new situations and use Oracle Adaptive Access Manager to update and keep them current. Policy Structure Figure 10–1 illustrates the policy structure. Figure 10–1 Policy Structure A checkpoint is when a policy is called to run its rules. Rules contain configurable evaluator statements called conditions. Policies are scoped by linking them to user groups and Organization IDs. Actions, alerts, IP, device, and other groups are associated with conditions, trigger combinations, and checkpoint overrides.

10.1.2 Rules

A rule is a collection of conditions. Exceptions can be specified using preconditions. A rule evaluates the conditions and the outcomes of rules are alerts, an action, and a score. The rule is evaluated to true when all preconditions are met and all conditions evaluate to true. When a rule is evaluated to true, specified alerts are created and the associated actions and score are given to the policy for further evaluation.

10.1.3 Conditions

Conditions are configurable evaluation statements used in the evaluation of historical and runtime data. Conditions use data-points session andor historical to evaluate risk or business logic. They are grouped based on the type of data used in the condition. For example, user, device, and location. Managing Policies, Rules, and Conditions 10-3 Conditions are pre-packaged in the system and cannot be created by a user. Rules are made up of conditions. Conditions may take user inputs when adding them to a rule. Conditions can evaluate to true or false based on the available data. When multiple conditions are added, the conjunction between the conditions is always AND. Refer to the example in Table 10–1 . For information on the conditions available in the system, see Appendix C, Conditions Reference.

10.1.4 Checkpoints

The checkpoint is a decision and enforcement point when policies are call to run their rules. All policies configured for a checkpoint are evaluated and the outcome is a score and an action or both. OAAM Server uses out-of-the-box policies and checkpoints to control the user flow. API-based integrations can create new checkpoints, configure policies, and drive the flow. Table 10–1 Multiple Conditions Condition 1 Condition 2 Rule Result True True True False False False - Rule is not triggered True False False False True False 10-4 Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager Figure 10–2 Checkpoints Examples of possible checkpoints during a session are listed as: ■ Bill pay The policy is executed during a bill pay. Managing Policies, Rules, and Conditions 10-5 ■ Wire transfer The policy is executed when the user is on a wire transfer page. Bill pay and Wire transfer are used as examples of possible points during a session. They are not available in Oracle Adaptive Access Manager out of the box. Checkpoint Example A fraudster has stolen a users user name and password and wants to perform a wire transfer. To accomplish the goal of performing a wire transfer, the fraudster must pass through multiple security gates. The frauster is caught during Post-Authentication. For example, if the frauster is using an anonomyzing proxy to mask the location, a challenge might occur during Post-Authentication. When the frauster fails to provide the correct answers, fraud is prevented.

10.1.5 Groups

Groups are like items that have been gathered together to simplify configuration workloads. Grouping enables you to view and administer the collection of like items as a single group instead of administering the individual members of a group. The types of groups you can create include User ID, User Name, Location, Device, Action, and Alert.

10.1.6 Actions and Action Groups

Actions are used to control the application flow. An action is an event activated when a rule is triggered. For example: block access, challenge question, ask for PIN or password, and so on. An action can be also activated based on a score for particular checkpoint. The client applications like OAAM Server or the native integrated client influence the resultant out-of-the-box actions. Users may also create custom actions that are used by their applications. Action groups are used as results within rules so that when a rule is triggered all of the actions within the groups are activated. For information on action groups, see Chapter 12, Managing Groups.

10.1.7 Alerts and Alert Groups

Alerts are messages that indicate the occurrence of an event. An event can be that a rule was triggered, a trigger combination was met or an override was used. Alert groups are used as results within rules so that when a rule is triggered all of the alerts within the groups are created. For information on creating an alert, see Chapter 12, Managing Groups.

10.1.8 User Group Linking

In Group Linking, the Run mode can be specified to execute policies for all users or selected user groups. Linking enables the policy to executerun for the set of users within the linked group. The Linked Users option links a policy to a User ID group or several User ID groups.