11 Managing Policies, Rules, and Conditions

11.1 Familiarizing Yourself with OAAM Policies

OAAM provides a set of standard policies that address basic registration and authentication flows in OAAM. The OAAM security and autolearning policies are available as part of the base snapshot or as a separate policy zip file. For detailed information on the security and autolearning policies, refer to Chapter 10, "OAAM Policy Concepts and Reference." When working with policies, it is important that you understand how they work, and how to create new policies to suit your business.

To view the OAAM policies:

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click the Policies node. The Policies Search page is displayed.

3. Click Search to populate the Search Results table with the standard set of policies.

   In 11.1.2, there are 17 policies and 104 rules standard with OAAM.

   Figure 11-1 Policies Search Page

   
   Description of "Figure 11-1 Policies Search Page"
   
   

4. In the Search Results table, click the relevant policy name to view the details of what the policy does. The Policy Details page displays the various parameters and configurations of the policy.

   The Policy Details fields are as follows:

   • Policy Name: Name assigned to the policy.

   • Policy Status: The option to activate the policy. These policies are active when imported from the snapshot. If you want the policy to function, keep the default, Active, for the Policy Status.

     If you want to policy to be disabled, select Disabled. A policy that is disabled is not enforced at the checkpoint.

   • Checkpoint: The point when the policy is to be executed. For information on checkpoints, see Section 10.3.4, "Checkpoints."

   • Scoring Engine: The fraud analytic engine that is to be used to calculate the numeric score that determines the risk level. For information on the scoring engine, see Section 10.2.8, "What is a Scoring Engine?."

   • Weight: A value from 0 to 100 as the multiplier if a weighted scoring engine is used to influence the total score.

     If the policy uses a "weighted" scoring engine, both score and weight (multiplier value) are used to influence the total score calculations. If the policy is not using a "weighted" scoring engine, only the score is used to influence the total score. For information on weight, refer to Section 10.2.10, "What is Weight?."

   • Description: A description of the policy.

   • Run Mode: The group the policy is to be run for. When imported from the OAAM snapshot the policies are linked to the user group called Default. If you have any other groups, you must change the linking accordingly

Each of the policies have these elements configured. You may want to review some of the standard policies and rules to familiarize yourself with how each parameter can be configured. For details on how the standard policies are configured, see Chapter 10, "OAAM Policy Concepts and Reference."

11.2 About Discovery and Policy Development

You can create new policies and rules specific to your business. This section shows the security policy development and modeling process in which high-level requirements are translated into security policies.

11.3 Creating Policies

OAAM provides standard security policies and rules, but you may want to create new policies and rules depending on business requirements. This section provides basic instructions to create a policy. Figure 11-2 illustrates the pages that you will configure for the policy.

Figure 11-2 Policy Pages

Description of "Figure 11-2 Policy Pages"

Table 11-6 provides brief descriptions of the configuration pages.

To start creating a policy, proceed as follows:

1. After you have logged into the OAAM Administration Console, double-click Policies in the Navigation pane on the left. The Policy page is displayed.

2. Click the New Policy button. The New Policy page is displayed where you can specify details to create a policy.

   Alternatively, you can open a New Policy page by:

   • Right-clicking the Policies node and selecting New Policy from the context menu.

   • Selecting the Policies node and then choosing New Policy from the Actions menu.

   • Clicking the Create new Policy button in the Navigation toolbar.

   • Selecting the Create New Policy button from the Search Results toolbar.

   • Selecting New Policy from the Actions menu in Search Results.

   Figure 11-3 New Policy

   
   Description of "Figure 11-3 New Policy"
   
   

   Details you must provide are as follows:

   • Policy Name: Enter a name that is meaningful and relevant to the policy.

   • Policy Status: The option to activate the policy. If you want the policy to function as soon as it is created, keep the default, Active, for the Policy Status.

     If you want to policy to be disabled, select Disabled. A policy that is disabled is not enforced at the checkpoint. Disabling a policy does not remove it from the system. You can enable the policy at a later date.

   • Checkpoint: Select the point when you want the policy to be executed. For example, set the checkpoint to post-authentication if you want to initiate an action after successful authentication. For information on checkpoints, see Section 10.3.4, "Checkpoints."

   • Scoring Engine: Select the fraud analytic engine that you want to use to calculate the numeric score that determines the risk level. For information on the scoring engine, see Section 10.2.8, "What is a Scoring Engine?."

   • Weight: Enter a value from 0 to 100 as the multiplier if you want to use a weighted scoring engine to influence the total score.

     If the policy uses a "weighted" scoring engine, both score and weight (multiplier value) are used to influence the total score calculations. If the policy is not using a "weighted" scoring engine, only the score is used to influence the total score. For information on weight, refer to Section 10.2.10, "What is Weight?."

   • Description: Enter a description that is meaningful and relevant.

3. Click Apply to create the policy.

   A confirmation dialog appears with a message that the policy was created successfully. Click OK to dismiss the confirmation dialog.

   The Rules, Trigger Combinations, and Group Linking tabs are enabled after you click OK. You must provide information about the policy in these tabs to fully configure the policy.

Example: Create a Policy where Users are Challenged with KBA

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. Therefore, you must create a new Post-Authentication KBA challenge policy that applies to all users. You can name the policy, KBA Challenge.

To create a policy:

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click the Policies node.

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.

   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.

   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 11.4, "Linking a 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 example, for the policy to function, you must add a rule to the policy either by creating a new rule within a policy (Section 11.5, "Creating Rules") or by copying an existing one (Section 11.8.9, "Copying a Rule to a Policy") to the policy.

11.4 Linking a Policy to All Users or a User ID Group

Group linking enables you to specify the users that a policy links to. You must link the policy to a group for the policy to function. Linking a policy to a group enables the policy to execute or run for the set of users within the linked group. The All Users option links a policy to all users. If group linking shows All Users, all available linking is ignored. If a user selects group linking as All Users, the link option will be disabled.

The total number of groups that are linked in the policy appears in parentheses next to the Group Linking tab title.

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. Open the Policy Details page.

   1. Double-click the Policies node. 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.

11.5 Creating Rules

You can only create a rule from within a policy. The new rule cannot be saved until you add a condition to it.

Figure 11-4 illustrates the pages you will use and information you will provide for each page when creating a rule.

Figure 11-4 Rule Creation

Description of "Figure 11-4 Rule Creation"

Results Tab

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

As part of the process, specify the following:

• Rule score and weight value. For information on score and weight, see Section 10.2.12, "How Does Risk Scoring Work?."

• Actions. For information on actions, see Section 10.2.6, "What are Action and Alerts?."

• Alerts. For information on alerts, see Section 10.2.6, "What are Action and Alerts?."

Action

An action is an event that is activated when a rule is triggered—for example, block access, challenge question, and ask for PIN or password.

Alerts

An alert is a message that is generated when a rule is triggered—for example, login attempt from a new country for this user.

Excluded User Group

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

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

Device Risk Gradient

Device fingerprinting is a mechanism to recognize the device that a customer typically uses to log in. Identification is based on combinations of the Device ID attributes, secure cookie, flash movie, user agent string, browser characteristics, device hardware configuration, network characteristics, geolocation, and historical context. Device risk gradient is a value calculated by the OAAM engine.

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

Device Gradient of 0 means an exact match with the secure cookie; 500 means similar device with reasonable matching attributes; 1000 means similar device with much less confidence.

The Device Risk Gradient is calculated when a device is re-identified. For example, if a device says it is device #1234 and the OAAM logic determines that some of the data points have changed or seem inconsistent with that device in the past, the risk is increased. The higher the number, the lower the confidence that this device is the one it claimed to be. Each rule can use the Device Risk Gradient as a precondition. Therefore, a rule that depends on a strong re-identification of a device could specify that the rule not run at all if the risk is high. For example, an administrator can configure the risk gradient setting of 0 - 400 for a rule that detects if a device has traveled faster than 600 MPH since the last login. This would ensure the rule only run if the device ID is strong.

Country Confidence Factor, State Confidence Factor, and City Confidence Factor

Geolocation confidence factors are specific to Quova geolocation data. This factor is not provided by other vendors so the precondition is only operable when Quova data is being utilized. Quova assigns a confidence level to each of the three elements: city, state, and country. This confidence factor is based on the 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 that 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, the rules are triggered when it is below 60% since we are not sure of the location.

11.5.4 Adding Conditions to a Rule

The Rule page's Condition tab displays the conditions in the rule and enables you to add other conditions and customize them.

Figure 11-6 Adding conditions

Description of "Figure 11-6 Adding conditions"

Follow these steps to add a condition to a rule:

1. If you are not on the Rule Details page of the rule in which you want to add the condition to, navigate to that page.

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

   2. Search for the rule in which you want to add the condition 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 Conditions tab.

3. In the Conditions tab, click the Add Conditions icon. The Add Condition dialog appears.

4. Search for the condition you want for the rule.

5. In the Search Results table, select that condition and click Add.

   Figure 11-7 Add Conditions

   
   Description of "Figure 11-7 Add Conditions"
   
   

6. In the Conditions edit page, select the condition in the top pane.

   The bottom pane displays the parameters of the condition.

7. In the bottom pane, modify the parameters per your requirements.

8. Click Save to save your changes.

   A confirmation dialog displays the status of the operation.

9. Click OK to dismiss the confirmation dialog.

10. Click Apply. The modified rule details were saved successfully.

An example of the Conditions tab is shown in Figure 11-8, "Condition Parameters".

Figure 11-8 Condition Parameters

Description of "Figure 11-8 Condition Parameters"

The top tab displays the conditions in the rule.

Table 11-8 lists the fields in the top pane of the Conditions tab.

Table 11-8 Rule Details Conditions Tab

Fields	Descriptions
Order	Order of the condition. Conditions in the rule are evaluated sequentially. Subsequent conditions are evaluated only if the current one was evaluated to be true. In other words, the evaluation stops when a condition is evaluated to be false. For the rule to be triggered all the conditions that constitute the rule must be evaluated to true; if any of the conditions is evaluated to false, the rule is evaluated to false, and the rule does not trigger.
Condition Name	Name of the condition.
Description	Description of the condition.

You can only view/edit one condition's parameters at a time.

11.6 Setting Up Trigger Combinations

Trigger combinations are additional results and policy evaluation that are generated if a specific set of rules trigger. You can set up trigger combinations using the Policy Details page. There is no limit to the number of trigger combinations that you can add. The total number of trigger combinations in the policy appears in parenthesis next to the tab title. The first column is frozen to enable you to scroll and see all of the data in the table while having the labels available for reference.

By default, if a policy does not have any trigger combination, a table is created with all the rules in the policy and one column for the trigger combination. You can make edits to the combination and then save it. You can edit multiple trigger combinations and save them all at once.

Figure 11-9 Trigger Combinations

Description of "Figure 11-9 Trigger Combinations"

Table 11-10 describes the fields in a trigger combination. For information about Action and Alert groups, see Chapter 12, "Managing Groups."

If you navigate away from the tab while editing the trigger combination, the trigger combination is saved in the session and available when you navigate back.

Table 11-11, "Trigger Combination Toolbar Options" lists the commands that are available through the toolbar.

Table 11-11 Trigger Combination Toolbar Options

Command	Description
Add	This button adds a new column (trigger combination).
Delete	This button is enabled only if a column or row is selected. The Delete button also enables you to delete multiple trigger combinations. When the Delete button is clicked, a warning message appears, asking for confirmation.
Reorder	This button invokes the Reorder screen. Columns can be reordered using the Reorder button.

To specify trigger combinations:

1. Double-click the Policies node. 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. Click 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.

Trigger Combination Example: Nest Policy Containing Rules That Can Result in a KBA Challenge

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 must 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 Example: Create a Policy where Users are Challenged with KBA.

To create a trigger combination:

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click the Policies node. 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 the Add Trigger Combination icon.

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

Example Trigger Combination and Rule Evaluation

Jeff, a Security Administrator, 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 the OAAM Administration Console as an administrator.

2. Double-click the Patterns node. 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. Click 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 triggers if the user has registered questions and he has logged in from time bucket less than 10% of time. The Result, he is 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 15, "Managing Autolearning."

Example: Disable Trigger Combination

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. Double-click the Policies node. 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. Click 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.

11.7 Using Groups in Policies, Rules, and Conditions

Groups are used in the following items:

• Policies

  A policy is linked to a User ID group or all users and members of the user group or all users that are evaluated.

  The Policy Tree shows the linking of User ID groups to policies.

• Rules within policies

  OAAM Admin applies rules on specified users, devices, or location groups to evaluate whether a fraud scenario occurred and to determine an outcome.

  A rule can trigger an action group, or an alert group, or both.

• Conditions

  Some conditions use groups as a parameter type. For example, IP in IP Group. The condition takes IP Group name / IP as a parameter.

• Trigger combinations

  Alerts in groups are specified in the trigger combination.

• Pre-condition

  User groups can be excluded in a policy.

• Configurable Actions

  Members of a User ID group can be added to a User ID group dynamically using configurable actions.

Example: IP Login Surge

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

1. Log in to the OAAM Administration Console as an administrator.

2. Create a Monitor IP Addresses group

   1. Double-click the Groups node.

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

      The Create Group screen appears.

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

   4. In the Monitor IP addresses 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 IP addresses that you want to monitor and click Add.

      A confirmation dialog appears.

   8. Click OK.

   9. Add IP addresses 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 address 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. Double-click the Policies node.

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 address and if there are more than 10 logins in the last hour from an IP address.

   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 11.4, "Linking a 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 the Add Rule icon 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 the Add Condition icon. 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 the Add Rule icon 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 the Add Condition icon. 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 IP addresses 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 Trigger Combination icon.

    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.

Example: Link Group to Rule Condition

As a requirement you are given a task to link an existing high risk countries group used for various purposes to a rule in the policy, System - Pre Blocking. See Section 11.11.2, "Example: Importing a 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 the OAAM Administration Console as an administrator.

2. Double-click the Rules node. 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 the Add Condition icon. The Add Conditions page appears.

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

      The condition checks to see if the IP address 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.

Example: Checking for Blacklisted Country

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. To support the base policies he also configures a blacklisted 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 the OAAM Administration Console as an administrator.

2. Double-click the Policies node. 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 the policies ZIP file.

5. Click OK to upload the policies ZIP file.

   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 Policies Search page, verify that the policy appears in the Search Results table.

8. Double-click the Groups node. 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 the Groups node 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. Open 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 the Add Rule icon.

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 the Add Condition icon.

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

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.

11.8 Managing Policies

This section explains how to manage policies.

11.8.1 Navigating to the Policies Search Page

To open the Policies Search page, double-click the Policies node. The Policies Search page is displayed.

Alternatively, you can open the Policies Search page by:

• Right-clicking the Policies node and selecting List Policies from the context menu.

• Selecting the Policies node and then choosing List Policies from the Actions menu.

• Clicking the List Policies button in the Navigation toolbar.

The Policies Search page is the starting place for managing your policies. It is also the home page for the Security Administrator.

From the Policies Search page, you can:

• Search for a policy

• View a list of policies

• Create a new policy

• Import a policy

• Export policies

• Export policies and create a delete script

• Delete policies

• Open the Policy Details page

An example of a Policies Search page is shown in Figure 11-10, "Policies Search Page".

Figure 11-10 Policies Search Page

Description of "Figure 11-10 Policies Search Page"

11.9 Managing Rules

This section explains how to manage rules.

11.9.1 Navigating to the Rules Search Page

To open the Rules Search page, right-click the Rules node. The Rules Search page is displayed.

Alternatively, you can open the Rules Search page by:

• Right-clicking the Rules node and selecting List Rules from the context menu.

• Selecting the Rules node and then choosing List Rules from the Actions menu in the Navigation panel toolbar.

• Clicking the List Rules icon in the Navigation panel toolbar.

An example of a Rules Search page is shown in Figure 11-13, "Rules Search Page".

Figure 11-13 Rules Search Page

Description of "Figure 11-13 Rules Search Page"

11.10 Managing Conditions

This section explains how to manage conditions.

11.11 Exporting and Importing

Policies can be exported and imported.

For example, you can export the policies defined in a system and import them into another system.

11.12 Evaluating a Policy within a Rule

The System: Evaluate Policy condition can be used to evaluate the policy (execute the policy by name) and then see if the actions returned by the policy contains a particular action. This condition is added to rule and works as follows.

1. Create a rule and add this as only condition.

2. Specify the name of some policy and expected action (for example, Block) for the condition parameters.

3. If at runtime this policy returns a list of actions and one of the actions is Block, then this rule will trigger.

Example: 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 icon.

3. Create a rule, Rule C.

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

5. Add System: Evaluation Policy condition.

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

11.13 Best Practices

This section outlines some best practices for using policies, rules, and conditions.

Simple Conditions First in the Rules

Order conditions within a rule such that the conditions that are simple are first in the rule. Usually Session type conditions are ones that are more efficient. Usually Autolearning type conditions and conditions that use location data are more expensive--they should be placed after the simple ones.

Organize Policies So Conditions Do Not Evaluate Many Times in the Flow

Organize the policies such that you do not have to evaluate the same condition again and again in the flow. This could help prevent getting the same result at different checkpoints in the same session. Use nested policies to prevent evaluating the same conditions.

Adding and Editing Policies and 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 e-mail 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.

Testing Policies and Rules

You can test OAAM policies and rules in a few different ways.

• New deployment using OAAM offline: You can use a combination of OAAM "offline" and BIP reports to test the effect of policies/rules on end users. To do this you deploy an "offline" instance of OAAM to perform batch analysis. You either configure the standard OAAM loader or develop a custom loader to load a set of production data into the offline environment to use as the test set. Policies and rules can be run against the test set of data multiple times to view the impact of policy changes.

  For example, in a new deployment, you can load a month of your production data into OAAM and run the base policies to see how many alerts and actions would have been generated if OAAM had been live in production for one month. The BIP reports are useful to gather aggregate values for the rules and outcomes. In the results, you will see that as OAAM learns the behaviors, users will generate fewer alerts and actions. If you add any new rules or edit any rule thresholds, you can perform another run and compare BIP report outcomes to those from the original run.

• Existing deployment using OAAM offline: If OAAM is already in production, you can export a set of production data on which to test the effect of policy/rule changes. For example, you can set up a scheduled data load to update the offline environment data every 24 hours. When the security team wants to add a new rule or edit a rule threshold they can first run 24 hours of data against the current policies in production and run BIP reports exported to an EXCEL worksheet. Then the team can make the edits and perform a second run on the same data set and run the same BIP reports. Comparing the reports from Run 1 and Run 2 will reflect how the user population was affected by the policy changes. In other words if the first run generated 100 alerts and the second run generated 125 alerts, the effect of the edits was 25 additional alerts.

Using a Maximum Scoring Engine

Whether a high score or low score is considered "bad" is dependant on the policy and how the developer models the policy. For example, the higher the score in device policies, the higher the risk for the situation.

For example, if you want "1000" to be considered a "bad" score, use the Maximum scoring engine. Then, model the rules so that whatever generates a maximum score is "bad." For example, you can model the policy such that if a user logs in from a particular location, the score is 200 points, and if a user logs in from a bad device, the score is 500 points. In this case, the one that has the maximum score is considered the worse of the two.

Using an Aggregate Scoring Engine

If you do not know how risky a situation is, you can use an aggregate scoring engine. For example, for a Device ID, you can apply six or seven rules. For each rule, specify a score of 200 or 300 weight. If you the scores are more than this, it is considered "bad." If there are six rules, and two of them trigger, you would get the lower aggregate. If six rules triggers, you get the higher aggregate, which means that this situation is the riskier.

Using an Average Scoring Engine

Use the Average scoring engine when none of the rules are more important than the others or there are a lot of rules that trigger for the evaluation. For example, each rule can view a particular part of a situation, but each part is not enough for you to base a decision on.

Score Does Not Matter for Some Policies in a Checkpoint

If there are multiple policies in a checkpoint and if the score does not matter for some of the policies, set the rule score to 0 for these policies, so that they are ignored when scores are aggregated.