9 Managing Policies, Rules, and Conditions

9.1.1 Policies

A policy is a collection of rules that are run in a single checkpoint. The policy is designed to evaluate and handle business activities or potentially risky activities that you may run across in the day-to-day operation of your business. For example, a business activity may be a user making a $15,000 deposit, and a potentially risky activity may be a user making a wire transfer of more than $10,000. The outcome of policy evaluation is a score, actions, and alerts. Policy outcomes are used to enforce business requirements. For information on rules, see Section 9.1.2, "Rules."

Using Oracle Adaptive Access Manager, you can create policies based on your business requirements. The attributes/datapoints 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 9.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.

The score is based on the scoring policy selected. If you do not want a score as the outcome, you can change the outcome to be an action group and alert group by using trigger combinations. An action group is also executed based on the score. For information about trigger combinations, see Section 9.1.10, "Trigger Combinations and Triggers."

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 9-1 illustrates the policy structure.

Figure 9-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.

9.1.2 Rules

A rule is a collection of conditions. When all pre-conditions of the rule are met and all conditions evaluate to true, the rule evaluates to true. Then, the rule is assigned the user-configured score, which is further evaluated by the policy. The rule can also generate specified alerts and trigger associated actions.

9.1.3 Conditions

Conditions are configurable evaluation statements used in the evaluation of historical and runtime data.

They are grouped based on the type of data used in the condition. For example, user, device, and location.

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 9-1.

For information on the conditions available in the system, see Appendix B, "Conditions Reference."

9.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.

Figure 9-2 Checkpoints

Out-of-the-box checkpoints are listed in Table 9-2.

Examples of possible checkpoints during a session are listed as:

• Bill pay

  The policy is executed during a bill pay.

• 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 user's username 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.

9.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, Username, Location, Device, Action, and Alert.

9.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 10, "Managing Groups."

9.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 10, "Managing Groups."

9.1.8 User Group Linking

You can specify for policies to execute for all users or a selected user group through Run mode.

Linking enables the policy to execute/run 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.

The "All Users" option links a policy to all users. If group linking shows "All Users," all the available linking is ignored. If a user selects group linking as "All Users," the link option would be disabled.

9.1.9 Run Mode

Run mode is either "All Users" or "Linked Users." It determines if a policy is evaluated for all users or for the user groups linked to that policy. If a policy is being evaluated as a nested policy then the run mode is ignored.

9.1.10 Trigger Combinations and Triggers

Rules are triggered when their conditions all evaluate to true.

Trigger combinations are additional results and policy evaluation that are generated if a specific sequence of rules trigger.

Trigger combinations can be used to override the outcome of rules. Each trigger combination can specify alerts, actions and either a score or another policy to run. Trigger combinations evaluate sequentially, stopping as soon as a rule return combination is matched. Alerts are added to any actions and alerts triggered by individual rules. Action group replace the actions returned by the individual rules.

When a trigger combination triggers another policy, that policy is said to be nested within the policy. A policy can be nested within other policies and also can be evaluated on its own.

For information on trigger combinations, see Section 9.12, "Working with Trigger Combinations."

For an example of setting up a trigger combination, see Section 9.32.7, "Use Case: Trigger Combination."

9.1.11 Nested Policies

A nested policy is a secondary policy used to further quantify the risk score in instances where the original result output by the system is inconclusive. Nested policies can be assigned to ensure a higher degree of accuracy for the risk score.

A nested policy in a trigger combination is executed only when a specific sequence of rule results is sent from the primary policy. Nested policies therefore reduce false positives and negatives.

9.1.12 Evaluating a Policy within a Rule

Oracle Adaptive Access Manager can evaluate another policy as part of a rule by using the "System: Evaluation Policy" condition. The result of the evaluated policy is propagated. This is called a "condition execution."

9.1.13 Scores and Weight

The score is a number configured by the user that is assigned to a rule when the rule evaluates to true. The user can configure a scoring policy that is used to combine the scores of the rules in a policy and assign a score to the policy. The scores from various policies are combined using a policy set level scoring policy.

Weight is the multiplier values used on policies scores to influence the total score.

For more information on scores and weights and how they are used in risk assessment, see Chapter 12, "Using the Scoring Engine."

9.1.14 Scoring Engine

A scoring engine is provided at the policy level and at the checkpoint level.

The policy scoring engine is applied to rule scores to determine the risk for each policy.

The policy set scoring engine is applied to the scores of the policies under a checkpoint to determines the score for the checkpoint. The default scoring engine at the checkpoint level is "Maximum."

For more information on the scoring engine, see Chapter 12, "Using the Scoring Engine."

9.1.15 Import Policies

The policy is added to the system or it overwrites/updates an existing policy depending on whether the same policy name exists. If the name already exists, the policy is updated. If the name does not exist, the imported policy is added to the system.

The policy and all of the groups attached to the policy are imported.

9.1.16 Policy Type

The concept of policy type has been removed from the product.

Only security policies are available in 11g. Although policy types for the 10g policies will be retained in the OAAM database, OAAM 11g will ignore the policy types of Business, Third-party, and Workflow in the database and treat all policy types as "Security" policies for all purposes.

Since there are no policy types, the policy type scoring engine will be ignored and the scoring engine at the checkpoint level will be applied for all policies.

9.9.1 Linking a Policy to All Users

If you want a policy to be applied to all users, follow these steps:

1. Navigate to the Policy Details page.

   1. In the Navigation tree, select Policies. The Policies Search page is displayed.

   2. Search for the policy that you want.

   3. Click the policy name to open its Policy Details page.

2. From the Policy Details page, click the Group Linking tab.

3. For Run Mode, specify All Users.

   Since All Users is specified, all group linking options and the table are disabled.

4. Click Apply to save the changes.

   Changes are applied to the policy.

   If Revert is clicked, the changes are discarded.

   Figure 9-6 Policy Linked to All Users

   
   

9.9.2 Linking a Policy to a Group

After the policy is created, you can link the policy to a user ID group or several user ID groups, which enables the policy and rules to execute/run for that set of users.

1. Navigate to the Policy Details page.

   1. In the Navigation tree, select Policies. The Policies Search page is displayed.

   2. Search for the policy that you want.

   3. Click the policy name to open its Policy Details page.

2. From the Policy Details page, click the Group Linking tab.

3. For Run Mode, specify Linked Users.

4. In the table header, click the Link icon.

   
   

   The Link Group screen appears where you can enter details to link a group to the policy.

5. The available target sets appear in the associated box.

   From the Group Name list, select the group you want to link to the policy.

   Only user groups are listed.

   Group Name is a required field.

6. Enter linking notes.

7. Click Link Group.

9.11.1 Starting the Rule Creation Process

To start the rule creation process:

1. In the Navigation tree, select Policies. The Policies Search page is displayed.

2. Search for the policy that you are interested in.

3. In the Search Results table, click the name of the policy. The Policy Details page for that policy is displayed.

4. In the Policy Details page, click the Rules tab.

5. In the Rules tab, click the Add button on the row header or select New Rule from the Action menu.

   
   

   The New Rule page is displayed.

   Figure 9-8 New Rule

   
   

The next steps to the rule creation process are:

1. Specifying General Rule Information

2. Specifying Preconditions

3. Adding Conditions to a Rule

   1. Reorder conditions

   2. Modify parameters

4. Specifying the Results for a Rule

The Rule Status for new rules has the default value of Active.

9.11.2 Specifying General Rule Information

Table 9-5, "New Rule Page" summarizes the general information of a rule.

To add general information about the rule, the procedure is as follows:

1. In the Summary tab, enter the name of the rule and a description. Duplicate rule names are allowed across policies, but not within the same policy.

   If you try to navigate to one of the other tabs before entering a rule name or description, an error message reminds you that a value is required.

   The policy name cannot be changed.

2. If you want to disable the rule, select Disabled. Rule Status has the default value of Active. A rule that is disabled is not run when the policy is enforced.

9.11.3 Configuring Preconditions

To configure preconditions for the rule, follow the procedure in Section 9.20.2, "Specifying Preconditions."

Through preconditions, you can specify the group to exclude and the geolocation confidence factor parameters.

9.11.4 Adding Conditions

To add conditions for the rule, follow the procedure in Section 9.25, "Adding Conditions to a Rule."

9.11.5 Specifying Results for the Rule

To specify the results for if the rule triggers, follow the procedure in Section 9.20.3, "Specifying the Results for a Rule."

You can select from the following types of results:

• Score and Weight

• Actions

  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. For information about action groups, see Chapter 10, "Managing Groups."

• Alerts

  An alert is a message generated when a rule is triggered. For example: login attempt from a new country for this user. For information about alert groups, see Chapter 10, "Managing Groups."

9.11.6 Adding or Copying a Rule to a Policy

The Copy Rule button enables you to copy an existing rule to other policies.

9.12.1 Specifying Trigger Combinations

To specify trigger combinations:

1. In the Navigation tree, select Policies. The Policies Search page is displayed.

2. Search for the policy which you want.

3. Click the policy name to open its Policy Details page.

4. Navigate to the Trigger Combinations tab.

5. Select the return value permutations you want for each rule in the first column.

6. In the Score/Policy row, select Score or Policy to specify whether the result return a score or point to a nested policy.

   • If you selected Score, in the field directly below, specify the score you want to assign to that combination.

   • If you selected Policy, in the field directly below, specify the policy you want to run to further evaluate the risk.

     Only the list of policies of the same checkpoint are available.

7. Set an action outcome.

8. Set an alert outcome:

9. If you want to specify other trigger combinations, click Add to add another column.

10. Repeat Steps 5 through 8 for each trigger combination you want.

11. In the Trigger Combinations tab, click Apply after making all your edits.

You cannot add two trigger combinations of the same combination. When you add new combinations, each combination is saved and validated automatically.

If you navigate away from the tab while editing trigger combinations, the unsaved trigger combinations are saved in the session and available when you navigate back.

9.12.2 Changing the Sequence of the Trigger Combination

To change the order of trigger combinations:

1. In the Navigation tree, select Policies. The Policies Search page is displayed.

2. Search for the policy which you want.

3. Click the policy name to open its Policy Details page.

4. Navigate to the Trigger Combinations tab.

5. To reorder columns, click the Reorder button.

   The Reorder Trigger Combinations screen appears.

   
   

6. Reorder the trigger combinations and click OK.

7. In the Trigger Combinations tab, click Apply.

Reordering of trigger combinations takes effect only after you click Apply. The changes are lost if you close the tab before you click Apply.

9.12.3 Deleting a Trigger Combination

To delete a trigger combination:

1. In the Navigation tree, select Policies. The Policies Search page is displayed.

2. Search for the policy which you want.

3. Click the policy name to open its Policy Details page.

4. Navigate to the Trigger Combinations tab.

5. Select the column header corresponding to the trigger combination and click Delete.

9.16.1 Exporting a Policy

To export policies:

1. In the Navigation tree, select Policies. The Policies Search page is displayed.

2. Enter the search criteria you want and click Search.

3. Select the rows corresponding to the policies you want to export.

4. From the Actions menu, select Export selected or Export Delete Script.

5. When the export screen appears, select Save File, and then OK.

9.16.2 Importing a Policy

Note for Policies Migrated from 10g to 11g

Only security policies are available in 11g. Business, third-party, workflow policy types have been removed from Oracle Adaptive Access Manager.

In 10g, scoring was not used by business policies. In 11g, when business policies are loaded from the Oracle Adaptive Access Manager database, the policy set scoring engine is applied by default and these policies are treated as security policies from 11g onward.

To import policies:

1. Create a \tmp folder in the drive where you have installed Weblogic if OAAM Admin is installed on the Windows platform.

   For example, if the Weblogic domain is on the C drive, you would create a c:\tmp folder.

   This folder will be used as a temporary folder for uploading large files into the OAAM Admin application.

2. In the Navigation tree, select Policies. The Policies Search page is displayed.

3. In the Policies Search page, click the Import Policy button. The Import Policy screen appears.

   Figure 9-12 Import Policy

   
   

4. In the Import Policy dialog box, type the path and name of the file; or use the Browse (...) button to locate the ZIP file that contains the policies, and then select the file.

   Note: a validation is performed for the imported file's MIME type. The MIME type of the export file should be "Application/ZIP."

5. Click Open and then click OK.

   A confirmation dialog appears with the list of policies and the number of policies that were added, updated, not updated, or not deleted in the system after the import.

   The policies are imported into the system unless the ZIP file contains a delete script or files in an invalid format or the ZIP file is empty.

   If you are importing a delete script, the policies are deleted from the system.

   An error occurs if you try to import policies in an invalid format or an empty ZIP file.

6. Click Done to dismiss the confirmation dialog.

9.20.1 Modifying the Rule's General Information

From the Summary tab, you can modify the rule name, status, and description.

Figure 9-15 Rule Details Summary Tab

The fields displayed are listed in Table 9-10.

9.20.2 Specifying Preconditions

From the Preconditions tab, you can specify the group to exclude and the geolocation confidence factor parameters.

All preconditions filter whether or not a rule evaluates. The conditions do not process the rule if the preconditions are not met. The process stops at the preconditions level.

To specify preconditions for the rule:

1. Navigate to the Rule Details page.

   1. In the Navigation tree, select Rules. The Rules Search page is displayed.

   2. Search for the rule in which you want to specify preconditions for.

   3. In the Search Results table, click the name of the rule. The Rule Details page for that rule is displayed.

2. In the Rule Details page, click the Preconditions tab.

3. Excluded User Group: In the Excluded User Group field, select the user ID group you do not want the policy to applied to.

4. Device Risk Gradient: Device fingerprinting is a mechanism to recognize the device a customer typically uses to log in. Identification is based on combinations of the device ID attributes, secure cookie, flash object, user agent string, browser characteristics, device hardware configuration, network characteristics, geo-location and historical context.

   Different use cases and exceptions are taken into account and help to define the device risk gradient. The device risk gradient specifies the certainty of the device being identified. It is standard in almost all rules as a precondition.

   The score ranges to specify the amount of device identification risk are:

   • 400 and lower - low risk

   • 401-700 - moderate risk

   • 701 and higher - high risk

   For example, a device risk gradient of 0 is an exact match whereas a device gradient of 500 is a "similar" device, and a score of 1000 a "different" device.

5. Country Confidence Factor, State Confidence Factor, and City Confidence Factor: The IP location vendor can assign a confidence level to each of the three elements: city, state, and country. This confidence factor is based on IP geolocation information.

   The higher the value, the higher the level of confidence from Quova that the mapping of the location is correct.

   If you want the rule you are creating to be dependent on IP location identification accuracy, specify the amount of geolocation accuracy with which you want to run the rule.

   For example, if the range is 60 to 100, you may specify for the rule to run only if the IP location is greater than 60% positive.

9.20.3 Specifying the Results for a Rule

Results are the responses, such as the activation of an action and message, when a rule is triggered. For example, action (event activated) and alert (message activated).

As part of the process, specify:

• Rule score and weight value

• Actions

• Alerts

To specify the results for if the rule triggers, follow these steps:

1. Navigate to the Rule Details page if you are not on the Rule Details page of the rule you want.

   1. In the Navigation tree, select Rules. The Rules Search page is displayed.

   2. Search for the rule for which you want to specify the results.

   3. In the Search Results table, click the name of the rule. The Rule Details page for that rule is displayed.

2. In the Rule Details page, click the Results tab.

3. Enter a rule score and weight value.

   You can change the weight value for a rule to instruct OAAM Admin to give more or less value to the total score.

   By default the score is 1000 and the weight is 100.

4. In the Actions Group list, select the actions you want triggered by this rule, if actions are required.

   By default, an Actions Group is not selected.

5. In the Alerts Group list, select the alerts you want sent if this rule is triggered.

   By default, an Alerts Group is not selected.

6. Click Apply to save the modified rule details.

The rules engine takes the information you specify for the rule and information specified in other rules in the policy and returns rule results to the policy. All the policies in the policy set results in multiple actions and multiple scores and multiple alerts. All these are propagated to the checkpoint. The score, the weight, and so on result in one final score, one final action, and a couple of alerts.

An example of a final action is Block. An example action list is Block, Challenge, Background Check and an example score is 800.

9.32.1 Use Case: Rule Exception Group

Jeff, a Security Administrator, must create an exception user group to be used as a rule precondition. Jeff is creating a blacklisted country rule and realizes he should have an exception group so he creates a new user group named "BLC: exception users." In the description he enters a note that CSR managers can add users that need to be permanently allowed access from a blacklisted country. When created, the user group is added as the precondition. After the rule is in production a CSR manager assists a user who has moved to a blacklisted country. He manually adds his User ID to the group so he has an exception to the rule and adds a note in his case to this effect.

1. Create a new user group named "BLC: exception users."

   Group name: BLC: exception users

   Group type: User ID

   In the description, enter a note to tell investigators, Add users that need to be permanently allowed access from a blacklisted country.

2. Select existing User IDs to add to the BLC: exception users group.

   For information on creating user groups and then adding members, refer to Section 10.12, "Searching for and Adding Existing Elements or Creating and Adding a New Element."

3. Create a rule in a post-authentication blacklisted country policy.

   • For rule condition, choose Location: IP in group.

   • In Pre-condition, select BLC: exception users as the exception group.

4. After the rule is in production an investigator assists a user who has moved to a blacklisted country. He manually adds his user ID to the group so he has an exception to that rule and adds a note in his case to this effect.

9.32.2 Use Case: Import Policy

You are Jennifer, a member of the security team at Acme Corp. You must configure Oracle Adaptive Access Manager to accomplish one of the use cases the team came up with focusing on high risk countries. Chuck, another team member, configured a pre-authentication policy in the Oracle Adaptive Access Manager offline environment to block login requests from high risk countries before authentication. You know this policy can work for your purposes. Chuck already exported the policy and now you must import it into production. Directions: Import the ZIP file that contains Chuck's configured policies. He has name the file, PreAuth_Block_policy.zip.

To import a policy:

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, select Policies. The Policies Search page is displayed.

3. Click Import Policy in the Policies Search page. The Import Policy screen is displayed.

4. Click Browse and search for PreAuth_Block_policy.zip.

5. Click OK to upload PreAuth_Block_policy.zip.

   A confirmation dialog displays the status of the operation.

   A list also appears showing numbers for Number of Policies Added, Number of Policies Updated, Number of Policies Not Updated, and Number of Policies Deleted.

   The imported policy is listed in the Imported List section.

   The policy will be added to the system or it will overwrite/update an existing policy depending on whether the same policy name exists. If the name already exists, the policy is updated. If the name does not exist, the imported policy is added to the system.

   An error is displayed if you try to import files in an invalid format or an empty ZIP file.

6. Click OK to dismiss the confirmation dialog.

7. In the Policy Search page, verify that the policy appears in the Search Results table.

9.32.3 Use Case: Create a Policy

You must configure a login use case that can result in a KBA challenge. It is usually best practice to use KBA challenges only after successful authentication by the primary method. A post-authentication KBA challenge policy did not already exist so you must create a new one. The security team wants this policy to be applied to all users in the deployment. Directions: Create a new post-authentication KBA challenge policy that applies to all users. Name the policy, KBA Challenge.

To create a policy:

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, double-click Policies.

3. In the Policies Search page, click the New Policy button.

   The New Policy page appears. In the Summary tab, the default values for the new policy are displayed as follows:

   • Policy Status: Active

   • Checkpoint: Pre-Authentication

   • Scoring Engine: Average

   • Weight: 100

4. Create a new post-authentication security policy.

   1. For Policy Name, enter KBA Challenge.

   2. For Description, enter a description for the KBA Challenge policy.

   3. For Checkpoint, select Post-Authentication.

      For information on checkpoints, see Section 9.1.4, "Checkpoints."

   4. Modify the policy status, scoring engine, and weight according to your requirements.

      By default, the policy status is Active. A policy that is disabled is not enforced at the checkpoint.

      For more information on the Scoring Engine, see Chapter 12, "Using the Scoring Engine."

   5. Click Apply.

      A confirmation dialog displays the status of the operation.

      If you click Apply and the required fields are not filled in an error message is displayed.

   6. Click OK to dismiss the confirmation dialog.

5. Configure the policy to run for all users.

   1. Click the Group Linking tab.

   2. For Run Mode, select All Users.

      Since All Users is selected for the run mode, the policy is executed (run) for all users.

      Specifying a run mode is a mandatory step in order for the policy to execute. It enables the policy to execute/run for a set of users or all users. For information, see Section 9.9, "Linking Policy to All Users or a User ID Group."

   3. Click Apply.

      A confirmation dialog displays the status of the operation.

   4. Click OK to dismiss the confirmation dialog.

If the KBA Challenge policy was created successfully, it would be listed in the Search Results table of the Policies Search page.

Although not covered in this use case, for the policy to function, you must add a rule to the policy either by creating a new rule within a policy (Section 9.11, "Adding a New Rule") or by copying an existing one (Section 9.14, "Copying a Rule to a Policy") to the policy.

9.32.4 Use Case: Add New Rule

After you have created a security policy (see Section 9.32.3, "Use Case: Create a Policy.") you are ready to create a new rule to perform the risk evaluation in your use case. The use case requires an evaluation of the physical distance between the location a user is logging in from now verses the last location he came from. This rule calculates the velocity/speed required to travel between the location given the time. The security team has determined that if the user appears to travel faster then 500 miles per hour between location and the device used is different then the user should be given a KBA challenge. Directions: Create a new rule, User Velocity and use the out-of-the-box condition, User: Velocity from last successful login.

To add a new rule:

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, double-click Policies. The Policies Search page is displayed.

3. Search for KBA Challenge.

4. In the Search Results table, click KBA Challenge. The Policy Details page for KBA Challenge is displayed.

5. In the Policy Details page, click the Rules tab.

6. In the Rules tab, click Add to add a new rule.

   
   

   The New Rule page is displayed.

7. Enter User Velocity as the rule name.

8. Enter a description for the rule.

9. Select the rule status.

   When the New Rule page first appears, the default value for the rule status is Active.

10. Add the User: Velocity from last successful login rule condition to create the new rule.

    1. To add the User: Velocity from last successful login condition, click the Conditions tab.

    2. In the Conditions tab, click Add. The Add Condition page appears.

    3. Search for the User: Velocity from last successful login condition by entering velocity in the Condition Name field and then clicking Search.

    4. In the Results table, select that condition and click OK.

    5. In the New Rule/User Velocity page, select User: Velocity from last successful login in the top panel.

       The bottom panel displays the parameters of the condition.

    6. In the bottom panel, modify the parameters.

       1. Enter 500 for Miles per Hour is more than.

       2. Select true for Ignore if last login device is same.

    7. Click Save to save your changes. A confirmation dialog appears with a message that the modified rule parameters were saved successfully.

    8. Click OK to dismiss the confirmation dialog.

11. Add a KBA challenge as a result of the User Velocity rule.

    1. Click the Results tab.

       The Results tab enables you to specify the results for the rule if the conditions are met.

    2. To set up a KBA challenge to occur if the rule is triggered, select ChallengeQuestionPad in the Actions Group list.

12. Click Apply. A confirmation dialog appears with a message that the modified rule details were saved successfully.

    If the required fields are not filled in and the user clicks Apply, an error is displayed.

    If the rule was successfully created, the new rule should be listed in the Rules tab of the Policy Details page.

13. Click OK to dismiss the confirmation dialog.

9.32.5 Use Case: Link Group to Rule Condition

In this use case, you must link an existing high risk countries group used for various purposes to a rule in the policy, System - Pre Blocking, you imported in Section 9.32.2, "Use Case: Import Policy."

Directions: Find a high risk countries group and link it to the rule in the KBA Challenge policy, you created.

To link a group to a rule condition:

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, double-click Rules. The Rules Search page is displayed.

3. Search for the Blacklisted countries rule.

4. In the Search Results table, click Blacklisted countries. The Rule Details page for the Blacklisted countries rule is displayed.

5. Select the in group rule condition in the Blacklisted countries rule.

   1. In the Rule Details page, click the Conditions tab.

   2. In the Conditions tab, click Add. The Add Conditions page appears.

   3. Search for the condition, Location: In Country group.

      The condition checks to see if the IP is in the given country group.

   4. In the Search Results table, select the Location: In Country group condition and click OK.

6. Link the existing high risk countries group to the rule condition.

   1. In the Conditions edit page, select the Location: In Country group condition in the top panel.

      The bottom panel displays the parameters of the condition.

   2. In the bottom panel, modify the parameters by setting:

      Is in list: true

      Country in country group: Restricted countries.

7. Click Save to save your changes. A confirmation dialog appears with a message that the modified rule parameters were saved successfully.

8. Click OK to dismiss the confirmation dialog.

9. Click Apply. A confirmation dialog appears with a message that the modified rule details were saved successfully.

9.32.6 Use Case: Copy Rule

The security team has determined that devices found to be exceptionally high risk should be blocked. Right now there is a rule to accomplish this but it was configured in a post-authentication checkpoint. The team feels login attempts should not even be allowed from these devices. Therefore you must move the rule to a pre-authentication checkpoint policy. Directions: Find the Black-Listed Devices rule in the System -Post Blocking policy and copy it to the pre-authentication policy, System - Pre Blocking policy. Then delete the rule from the post-authentication policy.

To copy a rule:

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, double-click Rules. The Rules Search page is displayed.

3. In Search filter, search for:

   • Rule Name: Blacklisted device rule

   • Checkpoint: Post-Authentication

4. Click Search.

   The System -Post Blocking policy contains the Blacklisted devices rule.

5. In the Search Results table, click Blacklisted devices in the Rule Name column.

6. In the Rules Details page for that rule, click the Copy Rule button. The Copy Rule screen is displayed.

7. For Policy, select System - Pre Blocking as the pre-authentication policy you want to copy the rule to.

8. For Rule Name, keep Blacklisted devices or enter a new name for the rule that you are copying.

9. For Description, keep This rule will trigger if the device used has been blacklisted in the past or enter a new description.

10. Click OK to copy the rule to the pre-authentication policy, System - Pre Blocking.

    A confirmation dialog appears with the message, "Rule has been copied successfully."

11. Click OK to dismiss the dialog.

12. Navigate to the Rules Search page and check in the Search Results table to verify that the Blacklisted device rule appears in the System - Pre Blocking policy.

13. Navigate to the Policies Search page and search for the System -Post Blocking policy.

14. Click System -Post Blocking in the Search Results table.

15. In the Policy Details page, click the Rules tab.

16. In the Rules tab, select Blacklisted devices and click Delete.

    A screen appears asking, "Are you sure you want to delete the selected rules?" The Blacklisted devices rule is listed in the screen.

17. Click Yes.

    Another confirmation appears with the message, "Selected rules are deleted successfully."

18. Click OK to dismiss the dialog.

9.32.7 Use Case: Trigger Combination

To KBA challenge a user Oracle Adaptive Access Manager must check two things:

• First, check to see whether the user has challenge questions registered.

• Second, if the user has a questions set active challenge him if a challenge scenario has to be performed.

To configure this behavior you must nest your new security policy, which contains rules that can result in a KBA challenge, under the policy, which contains KBA business rules to check for registration status.

Directions: Nest the KBA Challenge policy under the System - Questions check policy using policy trigger combinations.

The KBA Challenge policy was created in Section 9.32.3, "Use Case: Create a Policy."

To create a trigger combination:

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, double-click Policies. The Policies Search page is displayed.

3. Search for the System - Questions check policy.

4. In the Search Results table, click System - Questions check. The Policy Details page for the System - Questions check policy is displayed.

5. In the Policy Details page, click the Trigger Combinations tab.

6. In the Trigger Combinations tab, click Add.

   The column added to the table corresponds to a trigger combination.

   By default, trigger combinations are created with all the rules in the policy. The rules used in the policy are represented by a row name.

   For example, the rules to check for registration status would appear as rows:

   • Registered User with condition User: Account Status

   • Question Registered

   • Unregistered User

7. In the trigger combination, enter a description in the Description field.

8. For each rule specify the rule result based on which trigger combination must be executed (performed)

   • True: The rule is triggered

   • False: the rule is not triggered

   • Any: Ignore the rule whether or not it triggers

   By default, a trigger combination will be executed for a rule result of Any.

9. For a trigger combination, specify that if the trigger combination triggers, the result returns a nested policy.

   Select Policy, and in the field directly below, specify KBA Challenge as the policy you want to run to further evaluate the risk.

   A nested policy is a secondary policy used to further quantify the risk score in instances where the original result output by the system is inconclusive. Nested policies can be assigned to ensure a higher degree of accuracy for the risk score.

10. Select the Action Group.

    The action is an event generated when the combination is triggered.

11. Select the Alert Group.

    The alert is a message generated when the combination is triggered.

12. Click Apply. A confirmation dialog is displayed, saying that the policy details were updated successfully.

13. Click OK to dismiss the dialog.

9.32.8 Use Case: Trigger Combination and Rule Evaluation

Jeff, a Security Admin, must configure two levels of authentication to challenge the user using KBA for any single rule trigger and OTP for specific combinations of rules triggering.

The tasks he must perform are the following:

• Create a pattern to profile user login times into 4 hour time range buckets.

• Create a second pattern to profile states users log in from.

• Create the rules to use these patterns in the KBA challenge policy so these evaluations only run if the user has KBA active.

• Create a rule to challenge using KBA if the user falls into a login time bucket he has fallen into less than 10% of the time in the last month.

• Next, create a rule to challenge using KBA if the user logs in from a state he has used less than 20% of the time in the last two weeks.

• Then, create a rule that checks to see if a user has an OTP delivery channel active.

• Finally, configures a trigger combination to OTP challenge the user if all three of these rules returns true.

The steps to accomplish these tasks are:

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, select Patterns. The Patterns Search page is displayed.

3. Click the New Pattern button.

   Create a pattern, Pattern 1, where:

   • Member Type: User

   • Creation Method: Multi-bucket

4. Click the Attribute tab.

5. Click the Add icon.

6. Select Time (Time when the user is logged in) as the attribute.

7. Click Next.

8. Select For Each as the Compare Operator and 4 as the compare value.

9. Press Add.

10. Click the Patterns tab.

11. Create a pattern, Pattern 2, where:

    • Member Type: User

    • Creation Method: Multi-bucket

12. Click the Attribute tab.

13. Click the Add icon.

14. Select State as the attribute.

15. Select compare operator as for each state.

16. Click Next.

17. Create Rule1: Add pattern condition, Entity is member of bucket less than some percentage of times. (Select Pattern 1 and percentage = 10 and select 1 month as time period.)

18. Add condition to rule, User: Question status to check if he has registered questions.

19. Add action, KBA Challenge to Rule 1." (This rule will trigger if the user has registered questions and he has logged in from time bucket less than 10% of time. The Result, he will be challenged with KBA).

20. Create Rule 2: Add pattern condition, Entity is member of bucket less than some percentage of times. (Select Pattern 2, percentage =20 and select 15 days as time period)

21. Create Rule 3: Add pattern condition, User: Is OTP enabled. (Using condition Challenge Channel Status)

22. Create a policy and add all three rules.

23. Add trigger combination to policy such that if all rules are triggering (true) then action is Challenge OTP.

For more information on patterns, see Chapter 14, "Managing Autolearning."

9.32.9 Use Case: Configuring User Flow

Jeff a Security Administrator has a brand new installation and must import the base security policies into the development environment of the Oracle Adaptive Access Manager Server. To support the base policies he also configures a black-listed country group. As well he links user groups to the proper roll-out phase policies to test phase two for a group of test users.

To import a policy:

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, double-click Policies. The Policies Search page is displayed.

3. Click Import Policy in the Policies Search page. The Import Policy screen is displayed.

4. Click Browse and search for oaam_sample_policies_for_uio_integration.zip.

5. Click OK to upload oaam_sample_policies_for_uio_integration.zip.

   A confirmation dialog displays the status of the operation.

   The imported policies are listed in the Imported List section.

   An error is displayed if you try to import files in an invalid forma or an empty ZIP file.

6. Click OK to dismiss the confirmation dialog.

7. In the Policy Search page, verify that the policy appears in the Search Results table.

8. In the Navigation tree, double-click Groups. The Groups Search page is displayed.

9. From the Groups Search page, click the New Group button or icon.

   The New Group screen is displayed.

   You could also open the New Group screen by right-clicking Group in the Navigation tree and selecting Create from the context menu that appears.

10. In the New Group screen, enter Black-listed Country Group as the name and provide a description.

11. From the Group Type list, select Countries.

12. Set the cache policy to Full Cache or None.

13. Click OK to create the Black-listed Country Group.

14. Click OK to dismiss the dialog.

    The Group Details page for the Black-listed Country Group is displayed.

15. In the Countries tab of the Group Details page, click Add.

    The Add Member dialog is displayed.

16. From the Available Countries table, select one or more countries to add to the group.

17. Click Add.

18. Navigate to the Policies Search page.

19. Search for the Post-Authentication policy.

20. In the Results table, click the Post-Authentication policy.

    The Policy Details page appears.

21. Link the Test Users group to the policy.

22. In the Policy Details page, click the Rules tab.

23. In the Rules tab, click Add.

24. In the New Rule page, enter the rule name as Location: In Country Group.

25. Click the Conditions tab.

26. In the Conditions page, click Add.

    The Add Conditions page is displayed where you can search for and select the Location: In Country Group condition and add it to the rule.

27. Click OK.

    The parameters for the condition are displayed in the bottom subpanel.

28. In the parameters area, for Country in country group, select the Blacklisted Country group and for Is In Group, select True.

29. Click Save.

30. In the Results tab, select RegisterUserOptional as the Action group.

    RegisterUserOptional allows the user to opt in or out of selecting a personalized image.

31. Click Apply.

9.32.10 Use Case: Edit Existing Security Policy

Jeff, a Security Administrator wants to change the maximum number of attempts at a challenge question. He must edit a rule parameter to do this.

Best practice is to set the maximum number of failed KBA challenges to one less than the total number of challenge questions each user registers. For example, if all users register for four questions the maximum failures allowed should be three.

To edit an existing Security Policy, follow these steps:

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, double-click Policies. The Policies Search page is displayed.

3. In the Search Results table, click Fraud Blocking.

4. In the Rules tab of the Policy Details page, click Maximum Number of Failed Challenges.

5. In the Conditions tab of the Rule Details page, select User: Challenge Maximum Failures on the top panel.

   This condition checks to see if the user failed to answer the challenge question for specified number of times.

6. On the bottom panel, change the value of Number of Failures More than or equal to so that it is one less than the total number of challenge questions each user registers.

9.32.11 Use Case: Policy Set Scoring Engine

Jeff is a Security Administrator who wants the final risk score at each checkpoint to be based on the highest individual policy risk score. To meet this requirement he selects Maximum as the scoring engine at the Policy Set level.

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, double-click Policy Set. The Policy Set page is displayed.

3. Click the Summary tab.

4. Select Maximum from the Scoring Engine list.

   The Maximum Scoring Engine takes the highest policy score and uses it as the checkpoint score. This scoring engine ignores the policy weights.

5. Click Apply.

   A confirmation dialog appears with the message, "Policy Set details updated successfully."

6. Click OK.

9.32.12 Use Case: Copy Policy

The security team has decided some of the risk evaluations would work better before a user logs in. Jack, a Security Administrator must move a policy from the post-authentication checkpoint to the pre-authentication checkpoint to meet this new requirement. He looks through the rules in this policy to make sure they are all functional with the data available in pre-authentication.

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, select Policies. The Policies Search page is displayed.

3. For the Checkpoint filter, select Post-Authentication and click Search.

4. Look through the policy descriptions in the Search Results table for ones that do not occur after the password has been entered and ones that do not use conditions based on challenges.

   The Fraud Can't Challenge seems to be one that fits the criteria. The description for Fraud Can't Challenge is Applied to users with no challenge questions active.

5. Open the Fraud Can't Challenge policy to view its rules.

   The rules involve devices, IPs, locations as inputs and there are no actions to challenge the user. Therefore, the policy can be used in the pre-authentication checkpoint.

6. In the Policy Details page, click Copy Policy.

7. In the Copy Policy dialog, select Pre-Authentication as the checkpoint.

8. Enter a name and description for the policy.

9. Select Active or Disabled as the policy status.

   If you want the policy to be enabled as soon as it is created, select Active for Policy Status.

   If you want to policy to be disabled, select Disabled.

   A policy that is disabled is not enforced at the checkpoint.

10. Click Copy.

    A copy of the policy is added to the Pre-Authentication checkpoint.

9.32.13 Use Case: Conditions: IP: Login Surge

William is a Security Administrator and he must configure a policy and rule to track the number of logins from the same IP and if there are more than 10 logins in 1 hour from an IP, a high alert should be triggered.

1. Log in to OAAM Admin as an administrator.

2. Create a Monitor IP group

   1. In the Navigation tree, double-click Groups.

   2. In the Groups Search page, click the New Group button.

      The Create Group screen appears.

   3. Enter the group name, Monitor IPs, and select IP as the Group type and click Create.

   4. In the Monitor IPs group page, click the IP tab.

   5. In the IP tab, click the Add button.

   6. In the Add IPs screen, select the Search and select from the existing IPs option, enter criteria, then click Search.

   7. From the Search Results table, select one of the IPs that you want to monitor and click Add.

      A confirmation dialog appears.

   8. Click OK.

   9. Add IPs to monitor as needed.

3. Create an IP Surge High Alert group

   1. In the Groups Search page, click the New Group button.

      The Create Group screen appears.

   2. Enter the group name, IP Surge, and select Alerts as the Group type and click Create.

      A confirmation message appears.

   3. Click OK to dismiss the confirmation dialog.

      The new IP Surge alert group is created successfully and the Group Details page is displayed.

   4. Click the Alerts tab to add alerts to the group.

   5. In the Alerts tab, click the Add (Add Member) button.

   6. In the Add Member page, select Create new element.

   7. For Alert Type, select Investigator.

   8. For Alert Level, select High.

   9. For Alert Message, enter "More than 10 logins from the same IP in 1 hour."

   10. Click Add to add the alert to the group.

       A confirmation dialog appears.

   11. Click OK to dismiss the dialog.

4. In the Navigation tree, double-click Policies.

5. In the Policies Search page, click the New Policy button.

   The New Policy page appears. In the Summary tab, the default values for the new policy are displayed as follows:

   • Policy Status: Active

   • Checkpoint: Pre-Authentication

   • Scoring Engine: Average

   • Weight: 100

6. Create a new pre-authentication security policy.

   1. For Policy Name, enter Logins_SameIP.

   2. For Description, enter Track the number of logins from the same IP and if there are more than 10 logins in the last hour from an IP.

   3. Select Active as the policy status; otherwise the policy is not enforced at the checkpoint.

   4. Enter Weighted Maximum Score for the scoring engine and 100 as the weight.

   5. Click Apply.

      A confirmation dialog displays the status of the operation.

      If you click Apply and the required fields are not filled in an error message is displayed.

   6. Click OK to dismiss the confirmation dialog.

7. Configure the policy to run for all users.

   1. Click the Group Linking tab.

   2. For Run Mode, select All Users.

      Since All Users is selected for the run mode, the policy is executed (run) for all users.

      Specifying a run mode is a mandatory step in order for the policy to execute. It enables the policy to execute/run for a set of users or all users. For information, see Section 9.9, "Linking Policy to All Users or a User ID Group."

   3. Click Apply.

      A confirmation dialog displays the status of the operation.

   4. Click OK to dismiss the confirmation dialog.

8. Create IP Excessive Use rule for the policy.

   1. Click the Rules tab.

   2. In the Rules tab, click Add to add a new rule.

      The New Rule page is displayed.

   3. In the Summary tab, enter IP Excessive Use as the rule name.

   4. Enter a description for the rule.

   5. Select Active as the rule status.

   6. Add the Location: IP excessive use rule condition to create the new rule.

      1. To add the Location: IP excessive use condition, click the Conditions tab.

      2. In the Conditions tab, click Add. The Add Condition page appears.

      3. Search for the Location: IP excessive use condition by entering IP in the Condition Name field and then clicking Search.

      4. In the Search Results table, select that condition and click OK.

      5. In the New Rule/IP page, select Location: IP excessive use in the top panel.

         The bottom panel displays the parameters of the condition.

      6. In the bottom panel, modify the parameters.

         Enter 10 for "Number of Users."

         Select 1 for "Within (hours)."

         Enter 0 for "and not used in (days)."

9. Create the Location: IP in Group rule for the policy.

   1. Click the Rules tab in the Policy Details page.

   2. In the Rules tab, click Add to add a new rule.

      The New Rule page is displayed.

   3. In the Summary tab, enter IP in Group as the rule name.

   4. Enter a description for the rule.

   5. Select Active as the rule status.

   6. Add the Location: IP in Group rule condition to create the new rule.

      1. To add the Location: IP in Group condition, click the Conditions tab.

      2. In the Conditions tab, click Add. The Add Condition page appears.

      3. Search for the Location: IP in Group condition by entering IP in the Condition Name field and then clicking Search.

      4. In the Search Results table, select that condition and click OK.

      5. In the New Rule/IP page, select Location: IP in Group in the top panel.

         The bottom panel displays the parameters of the condition.

      6. In the bottom panel, modify the parameters.

         Select true for "Is in List."

         Select the Monitor IPs group.

10. Create a trigger combination in which if both conditions are true, trigger the Block action and the IP Surge Alert.

    1. In the Policy Details page, click the Trigger Combination tab.

    2. Click the Add button.

    3. For the IP Excessive Use, select True.

    4. For the IP in Group, select True.

    5. For Action Group, select Block.

    6. For Alert Group, select IP Surge High Alert.

    7. Click Apply.

9.32.14 Use Case: Canceling Rule Creation

William is a Security Administrator and he creates a new policy. He is not sure which rule condition would apply for his business use case. Hence he decides to close the rule without adding any condition.

1. Log in to OAAM Admin as an administrator.

2. In the Navigation tree, double-click Policies.

3. In the Policies Search page, click the New Policy button.

4. Create a new policy.

5. In the Policy Details page, click the Rules tab.

6. In the Rules tab, click Add to add a new rule.

   The New Rule page is displayed.

7. Enter the rule name.

8. Enter a description for the rule.

9. To add the condition, click the Conditions tab.

10. In the Conditions tab, click Add. The Add Condition page appears.

11. Search for the condition by entering a name into the Condition Name field and then clicking Search.

12. In the Results table, select that condition.

13. Click Cancel.

    You are not sure which rule condition would apply for your business use case.

14. Click the Delete button in the upper-right corner.

    An Unsaved Data Warning dialog appears with the message, "You have unsaved data. Are you sure you want to continue?"

15. Click Yes.

    You are returned to the Rules page.

16. Click the Delete button in the upper-right corner again.

    You are returned to the Policies Search page.

17. In the Search Results table, click the policy you created.

    The rule has not been created.

9.32.15 Use Case: Disable Trigger Combinations

Jim is a Security Administrator. He wants to inactivate his trigger combinations and enable them later, but he does not want to lose his settings.

He can accomplish that by not setting the Score/Policy, Actions, and Alerts for the combinations and they are automatically in disabled state. No action would be taken based on these combinations.

To disable trigger combinations:

1. In the Navigation tree, select Policies. The Policies Search page is displayed.

2. Search for the policy which you want.

3. Click the policy name to open its Policy Details page.

4. Navigate to the Trigger Combinations tab.

5. Select 0 as the score or make sure no nested policy is specified.

6. Deselect the actions in the action group lists.

7. Deselect the alert sin the alert group lists.

8. In the Trigger Combinations tab, click Apply after making all your edits.

9.32.16 Use Case: Condition: Evaluate Policy

Jeff has two policies. One of the policies Policy B is like a pre-cursor to Policy A so this policy should be executed every time, no matter what the other rule evaluations turn out to be. Hence nesting this policy under Policy A may not work all the time. (trigger combinations)So Jeff decides to add a new rule condition to Policy A such that it executes Policy B every time.

1. Open Policy A.

2. In the Rules tab of the Policy Details page, click the Add Rule button.

3. Create a rule, Rule C.

4. In the Condition tab of the Rule Details page, click Add Condition.

5. Add System: Evaluation Policy condition.

6. In Trigger Combination, select Policy B as action.

9.33.1 Adding or Editing Policies/Rules

These general steps outline the process for adding or updating of policies or rules into a production environment:

1. Develop the new rule using your offline system (a separate installation of Oracle Adaptive Access Manager set up for testing or staging).

2. Test the rule to ensure that it is functioning as expected by running predictable data through it using your offline system.

3. When you are satisfied that the policy is functioning as expected, migrate the policy in pre-production where performance testing can be run.

   This is an important step since the new rule, or policy, or both can potentially have a performance impact. For example, if you define a new policy to check that a user was not using an email address that had been used before (ever). If the customer has more than 1 billion records in the database, performing that check against all the records for every transaction has great impact on performance. Therefore, testing the policy under load is important.

4. Only when you are satisfied that your new rule/policy is functioning as expected and does not adversely affect performance should it be migrated into production.