10 OAAM Policy Concepts and Reference

This chapter introduces you to the terminology and concepts that relate to policies and rules. It describes the flow for the main scenarios in authentication and the policies and rules that are available with OAAM, including the autolearning policies.

This chapter contains the following sections:

• About Policies Available with OAAM

• Basic Concepts

• About Rule Processing

• About OAAM Authentication, Password Management and Customer Care Flows

• About OAAM Security and Autolearning Policies

• Use Cases

10.1 About Policies Available with OAAM

The OAAM security and autolearning policies are available as part of the base snapshot or as a separate policy zip file. The oaam_base_snapshot.zip is located in the Oracle_IDM1/oaam/init directory of your install. If you want to only import policies, but not the snapshot, import the policies zip file. To import the base snapshot, you need the envAdmin role assigned. If you are importing policies as a separate file, you need the ruleAdmin role assigned. These administrative roles are usually exclusive roles, but depending on your deployment needs, both roles can be assigned to the same user.

The OAAM policies address basic registration and authentication flows in OAAM. KBA as a challenge mechanism and images are available when using the OAAM server if you import these policies. All required entities, patterns, conditions, rules, and actions for the basic registration and authentication flows are part of the snapshot.

In 11.1.2, there are 17 policies and 104 rules of the box. The standard policies are active when imported from the snapshot and linked to the user group called Default. If you have any other groups, you must change the linking accordingly.

Figure 10-1 Policies Search Page

Description of "Figure 10-1 Policies Search Page"

10.2 Basic Concepts

This section introduces you to the terminology and concepts that relate to the OAAM security policies.

10.2.1 What Are Rules?

Rules are used by OAAM to identify suspicious or potentially fraudulent transactions. Security Administrators configure rules so that OAAM knows data to look at for fraud, how to evaluate the data, and the appropriate actions to take after the evaluation.

10.2.2 How Do Rules Work?

Fraud rules are used to evaluate the level of risk at each checkpoint. Rules are made up of configurable evaluation statements called conditions. When data comes into the system, OAAM evaluates the conditions based on the input.

The rule is evaluated to True when all preconditions are met and all conditions evaluate to True. When a rule is evaluated to True, a score is triggered, and depending on how the rules in the policies were configured, specified alerts are created and the associated actions are triggered. Examples of actions are ALLOW, CHALLENGE, and BLOCK. The security team might determine that devices found to be exceptionally high risk should be blocked and login attempts should not even be allowed from these devices. Alerts might be sent to Investigators so they can easily see that a velocity rule, such as User appears to have traveled faster than 500 MPH since last login, was triggered and why.

Other rules can run based on the outcome of other rules. You can implement new rules or edit rules based on new fraud data to fit business needs.

10.2.3 Security Administrator Role in Rule-Related Activity

A Security Administrator devises and configures business and security policies in OAAM. He manages every aspect of policy administration and all its dependent components as seen in the scenarios that follow:

Security Administration Has a New Installation and Needs to Import Policies

The Security Administrator needs to import the policies available with OAAM for business use cases. He browses for the policies zip file from the Oracle_IDM1/oaam/init directory of the install and imports it into the system.

1. He browses for the policies zip file from the Oracle_IDM1/oaam/init directory of the install.

2. He imports it into the system.

For information on browsing and importing policies, refer to Section 11.11.2, "Importing Policies."

Security Administrator Adjusts Rule Parameters of Existing Policies

1. The Security Administrator searches for the policy.

   For information on searching for policies, refer to Section 11.8.2, "Searching for a Policy."

2. In the policy, he selects a rule and modifies rule parameter.

   For information on modifying a rule parameters, refer to Section 11.9.5, "Editing Rule Parameters."

Security Administrator Links User Groups to a Policy to Enable the Policy to Execute for the Set of Users within the Linked Group

1. The Security Administrator searches for a policy.

   For information on searching for policies, refer to Section 11.8.2, "Searching for a Policy."

2. He links a User ID group to that policy.

   For information on group linking, refer to Section 11.4, "Linking a Policy to All Users or a User ID Group."

Security Administrator Models a Fraud Scenario (A Simple Example)

1. The Security Administrator frames the fraud scenario on paper and identifies the groups, rules, transactions, action groups and alerts for the scenario.

   For information on framing the fraud scenario, refer to Section 11.2, "About Discovery and Policy Development."

   For information on creating groups, actions and alerts, refer to Chapter 12, "Managing Groups."

   For information on creating entities and transactions, refer to Chapter 18, "Modeling the Transaction in OAAM."

2. He then creates a new policy.

   For information on creating policies, refer to Section 11.3, "Creating Policies."

3. He selects conditions and creates rules that he adds to the new policy. During rule creation he may add transactions to the rules.

   For information on creating rules, refer to Section 11.5, "Creating Rules."

   For use cases of OAAM Transaction implementations, refer to Section 20.9, "OAAM Transaction Use Cases."

4. He selects appropriate action groups and alerts for the policy.

   For information on adding action groups and alerts, refer to Section 11.5.5, "Specifying Results for the Rule."

Security Administrator Models a Fraud Scenario (A Complex Example)

1. After designing on paper, the Security Administrator realizes that he needs to create custom groups, custom rule, custom entities, custom transactions, custom actions, and so on.

2. He creates appropriate action groups and alerts for the policy.

3. He creates groups that he needs.

   For information on creating groups, actions and alerts, refer to Chapter 12, "Managing Groups."

4. He creates entities that he needs.

   For information on creating entities, refer to Chapter 19, "Creating and Managing Entities."

5. He creates transactions that he needs.

   For information on creating transactions, refer to Chapter 20, "Managing Transactions."

6. He creates configurable actions that he needs.

   For information on creating configurable actions, refer to Chapter 16, "Managing Configurable Actions."

7. He creates the patterns that he needs.

   For information on creating patterns, refer to Chapter 15, "Managing Autolearning."

8. He then creates a new policy.

   For information on creating policies, refer to Section 11.3, "Creating Policies."

9. He selects conditions and creates rules that he adds to the new policy. During rule creation he may add transactions to the rules.

   For information on creating rules, refer to Section 11.5, "Creating Rules."

   For use cases of OAAM Transaction implementations, refer to Section 20.9, "OAAM Transaction Use Cases."

10. He selects appropriate action groups and alerts for the policy.

    For information on adding action groups and alerts, refer to Section 11.5.5, "Specifying Results for the Rule."

    For information on configuring trigger combinations, refer to Section 11.6, "Setting Up Trigger Combinations."

Security Administrator Runs Reports or Queries to Validate Policies

1. He runs various fraud/business scenarios in the customer applications that should trigger various policies and rules within.

   For running OAAM offline for rule evaluation, refer to Chapter 21, "OAAM Offline."

   For running jobs, refer to Chapter 22, "Scheduling and Processing Jobs in OAAM."

2. He searches for the sessions related to those scenarios to verify that proper policies and rules were triggered.

   For information on viewing session information, refer to Section 6.8.2, "Using Session Details to View Runtime Information."

10.2.4 What are Conditions?

Rules are made up of conditions. Conditions are configurable evaluation statements that are the basic building blocks of decision making in the OAAM rule evaluation process and flow. They use datapoints from historical and runtime data to evaluate risk or business logic. Conditions 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. Conditions may take user inputs when adding them to a rule.

10.2.5 What are Policies?

A policy is a collection of rules associated with a checkpoint. Figure 10-2 introduced policy-related components. The policy's structure along with examples of groups are explained in this section.

Figure 10-2 Policy Structure

Description of "Figure 10-2 Policy Structure"

A checkpoint is a decision and enforcement point that control user flow. A group is a collection of like items. Examples, of user groups, excluded groups, groups used as parameters, and action and alert groups are shown.

Figure 10-3 Policy Details Rules Tab

Description of "Figure 10-3 Policy Details Rules Tab"

The attributes/data elements of the activities you are interested in are mapped to conditions and the evaluations to perform are translated into rules. These rules are added to a policy. Checkpoints are set up in the session for when the policy evaluates the activity. For example, a policy can be executed during the Pre-Authentication checkpoint. The Pre-Authentication checkpoint is a point in time before the user enters the password. When the rules are run, data is collected. For information, see Section 10.4.1, "Authentication Flow." The policy outcomes can be used to enforce decisions by client applications.

A rule evaluates to True when all the conditions match. The outcome of a rule is a score and optionally actions or alerts, or answers and alerts. The outcome of a policy evaluation is decided by applying a scoring policy on the rule scores of the policy. In addition to the score, you can optionally configure trigger combinations which are combinations of rule results of the policy and that can invoke actions and/or generate alerts. For more information about trigger combinations, see Section 10.2.13, "What are Trigger Combinations?."

10.2.6 What are Action and Alerts?

During the normal course of business, the system looks for data elements the conditions were mapped to. When the set of conditions are 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.

10.2.7 What is a Policy Set?

A policy set is a logical collection of policies that has been used to assess risk at checkpoints. There is one policy set per application. Through the policy set, you can specify the scoring engine and the weight multiplier that you want to use for evaluating the risk for checkpoints.

10.2.8 What is a 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 "Aggregate."

Table 10-1 Scoring Engines

Scoring Engine	Policy	Checkpoint	When to Use
Maximum	Higher score out of all triggered rules	Higher score out of all policies	Use this engine when you want to score based on the single rule with the highest level of risk. The rule and policy weights are not used by this scoring engine.
Minimum	Lower score out of all triggered rules	Lower score out of all policies	Use this engine when you want to score based on the single rule with the lowest level of risk. The rule and policy weights are not used by this scoring engine.
Aggregate	Sum of the scores for all triggered rules, with 1000 as the maximum score and 0 as the minimum score.	Sum of the scores of the executed policies with 1000 as the maximum score and 0 as the minimum score.	Similar to a percentage evaluation for what rules triggered versus the total number of rules. Use this engine when you do not want to score based on any single rule but instead want to make one based on the average level of risk computed based on the number of rules triggered. The rule and policy weights are not used by this scoring engine. Total score of triggered rules divided by the total number of rules.
Average	Sum of the scores of all triggered rules divided by count of triggered rules	Sum of the scores of all policies within the checkpoint divided by the count of all policies	Use this engine when you do not want to score based on any single rule but instead want to make one based on the average level of risk found. The rule and policy weights are not used by this scoring engine. Total score of triggered rules divided by the total number of triggered rules.
Weighted Average	Sum of the scores (Score * weight modifier specified by the policy) of all triggered rules divided by the count of all rules	Sum of policies (S* weight multiplier specified by the policy set) within the checkpoint divided by count of all policies	Use this engine when you do not want to score based on any single rule but instead want to make one based on the average level of risk found. The weights in this case would be determined by how much each rule or policy indicates a risky situation.
Weighted Maximum	Larger score (S * weight modifier specified by the policy) out of all triggered rules	Larger score out of all policies (s* weight multiplier specified by the policy set)	Use this engine when you want to score based on the single rule with the highest level of risk. The weights in this case would be determined by how much each rule or policy indicates a risky situation.
Weighted Minimum	Lower score (S * weight modifier specified by the policy) out of all triggered rules	Lower score out of all policies (s* weight multiplier specified by the policy set)	Use this engine when you want to score based on the single rule with the lowest level of risk. The weights in this case would be determined by how much each rule or policy indicates a risky situation.

10.2.9 What is a Score?

Oracle Adaptive Access Manager incorporates risk scoring into its decision making. OAAM risk scoring is a product of numerous fraud detection inputs such as a valid user, device, location, and so on. These inputs are weighted and analyzed within the OAAM fraud analytics engine. The policy generates a risk score based on dozens of attributes and factors. Depending on how the rules in a policy are configured, the system can yield an elevated risk score for more risky situations and lower scores for lower-risk situations. The degree of elevation can be adjusted with the weight assigned to the particular risk. The risk score is then used as an input in the rules engine. The rules engine evaluates the fraud risk and makes a decision on the action to take.

The score is expressed as a number the user configured as an outcome to the rule if the rule evaluates to TRUE. The checkpoint score is a combination of the scores from the policies with that particular checkpoint. Higher scores indicate higher risk. The maximum score is 1000. The lowest score is 0, which means that the situation is safe.

10.2.10 What is Weight?

Weight is the multiplier values that are applied to policy scores to influence the impact the policy has on determining the total score. Policies have default weights. Weight is used only when a given policy or checkpoint uses a "weighted" scoring engine. The weighted scoring engine uses weights from subcomponents. For example, if you choose the weighted scoring engine at the policy level, Oracle Adaptive Access Manager uses the weight specified for each rule level when calculating the policy score. Similarly, when you choose a weighted scoring engine at the policy set level, Oracle Adaptive Access Manager uses weights specified for each policy. The score of each policy multiplied by weight is divided by total number of policies multiplied by 100. The range is 0 to 1000.

10.2.11 What is Score Propagation?

A rule defines datapoints for suspicious patterns or practices, or specific activities, and the outcome when the pattern, practice or specific activity is detected. The possible outcomes of a rule are actions, a list of actions, alerts, a list of alerts, and a score. A rule score is always calculated; the other outcomes are optional.

A policy is a collection of rules specifically assembled and tuned to run inside a specific checkpoint and at a single time. The policy score is evaluated from the score results of the policy's rules.

There are multiple policies under one checkpoint. The scores of all policies in the checkpoint are "picked up" and the policy set scoring engine is applied to the scores to determine the checkpoint score. For example, if the policy set defines the scoring engine as Aggregate and two policies in the checkpoint result in a score of 100 and 200 each, the score of the checkpoint will be 300. Oracle Adaptive Access Manager performs a separate evaluation for each checkpoint and provides a score for each. The default scoring engine at the checkpoint level is "Aggregate." The score for a particular checkpoint must be between 0-1000.

The checkpoint score and action are the final score and action in the assessment. The alerts are propagate from the rules level to the final level.

10.2.12 How Does Risk Scoring Work?

To determine a risk score, each level applies its scoring engine to the results from one level below. For example, to determine the policy score, the scoring engine of the policy is applied to the scores of the rules within the policy. To determine the checkpoint score, the scoring engine of the checkpoint is applied to the scores of the policies within the checkpoint. The checkpoint score and action are the final score and action in the assessment. The alerts are propagate from the rules level to the final level.

Example

If three rules in policies had scores 100, 200, and 300 and policy scoring engine is Maximum, the score of the policy will be 300. If three policies had scores of 300, 200 and 100 respectively in the checkpoint and policy set scoring engine is Aggregate then the checkpoint score will be sum of those three that is 600.

Example

Checkpoint = Policy A + Policy B +Policy C

Policy = Rule A + Rule B + Rule C

Policy C = Policy D + Policy F (if nested policies)

1. Each triggered rule returns a score.

   Each rule has its own default score and weight. The score and weight are used for the calculation of the rule score.

   The alerts configured at the rule level are propagated to the final level.

2. Each policy returns a score.

   To obtain the policy score, the policy scoring engine is applied to the scores of the rules underneath.

   If the policy does not use a "weighted" scoring engine, the scores of the individual rules are used in determining the policy score.

   If the policy uses a "weighted" scoring engine, a percentage value is applied to the individual rule scores before the policy score is determined. The "weight" is specified in the policy.

   As seen in Figure 10-4, if a weighted policy scoring engine is used, the score for Policy A would be:

   Scoring Engine (Rule A * weight, Rule B * weight)

   For example, if the policy scoring engine is "Weighted Maximum Score" and the policy weight is 50% and if Rule A returned 1000 and Rule B returned 500, the policy score for Policy A is 500.

   Policy A = Maximum of (1000* 50%, 500*50%)

   Policy A = Maximum of (500, 250)

   Policy A = 500

3. The checkpoint returns a score

   The checkpoint score is determined by applying the policy set scoring engine to the score result of the policies underneath the checkpoint.

   The default scoring engine at the checkpoint level is Aggregate.

   The checkpoint score and the action is the final score and action returned.

   All the alerts are propagated from rule configurations.

Figure 10-4 Scoring

Description of "Figure 10-4 Scoring"

10.2.13 What are Trigger Combinations?

Trigger combinations are additional results and policy evaluation that are generated if a specific set of rules trigger. Figure 10-5 shows the structure of a trigger combination.

Figure 10-5 Trigger Combination Structure

Description of "Figure 10-5 Trigger Combination Structure"

Trigger combinations are used to override the outcome of rules. Policies may or may not contain trigger combinations. If the policy contains trigger combinations, the Trigger Combinations tab contains a table with all the trigger combinations possible in the policy. Each trigger combination (vertical column) represents a combination of rules that are triggering or not triggering and can specify alerts, actions and either a score or another policy to run. Each row represents a rule. Trigger combinations evaluate sequentially, stopping as soon as a Trigger Combination is matched. For example, if the rule returns in Combination A are met, Combination B is not evaluated.

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.

10.2.14 How Do Trigger Combinations Work?

An example of how trigger combinations work is presented in this section. Figure 10-6 shows a trigger combination

Figure 10-6 Trigger Combination Example

Description of "Figure 10-6 Trigger Combination Example"

Each column in the table represents a unique trigger combination. The trigger combinations evaluate sequentially, moving from column 1 to columns 2, 3, 4 and so on, and stop as soon as a trigger combination is matched. The columns are rules that can have a value of False, True, or Any. False means that the rule evaluates to False. In the illustration, the Challenge SMS Available, and Email Available, and Question Active rules are False which means that the user is not registered; The Check for High Risk rule is False which means "if the risk is low"). The Any value for a rule means that the rule can be either False or True.

Note: All rules (or rows) are joined with "AND." Therefore, trigger combination 1 in the example means: "If user is not registered and the risk is low, no challenge."

The last three rows in the trigger combination define the outcome of the trigger combination. The outcome could be a score or a nested policy or an action or alert group (or a combination of any of these). The example of the trigger combination in column 1, translates to "if user is not registered and the risk is low, Action Group OAAM Allow is assigned (which means no challenge).

Trigger combinations are useful because they allow administrators to create dependencies between various rules and provide outcomes that are based on the net result of all those dependencies. The rules on the Rules tab, on the other hand, are evaluated independent of each other, with their own unique independent outcomes.

Note:

The rules specified in the Rules tab are evaluated before trigger combinations.

10.2.15 What are 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. You see nested policy being used as an output of a trigger combination.

Nested policies are evaluated. If the trigger combination itself is a policy, the score for the parent policy is retained, and the new policy generates its own score to be used for the evaluation of the checkpoint. If policy1 has two rules, rule1 and rule2, and in the trigger combination, rule1 contains policy2. If the override triggers, rule1 is used to calculate policy1's score, and policy2 is evaluated and used in the evaluation of the checkpoint. In calculating a score for the policy set, the score from policy1 is used and the score from policy2 is evaluated and used for the checkpoint score.

For example the scores for s1 and s2 from two policies are obtained and a scoring engine of policy set is used to determine the checkpoint score. If S1 was 100 and S2 was 300 and policy set specified the scoring engine is Maximum, then 300 will be the outcome of the checkpoint score.

10.2.16 What is a Scoring Override?

Score overrides are used within a policy and within a policy set.

In policies, score overrides are specified in trigger combinations. Each rule has scores assigned. In trigger combinations, you can specify scores that are different from the defaults for the rules. Then, if the trigger combination is executed (triggered), the score of the trigger combination places the default score. If the trigger combination does not trigger, then the default score is used.

In a policy set, you can create a score override in which you specify an action group, or an alert group, or an action and an alert group you want to be triggered when a score falls within a specific range.

10.2.17 What are Action and Alert Overrides?

You can create an Action or Alert Override to specify the action or alert to triggered as a final alert or action for a checkpoint.

10.2.18 What are Groups?

Groups simplify configuration workload and help to administer a collection of similar items as a single group instead of administering the individual members of a group. Types of groups include User ID, User Name, Location, Device, Action, and Alert.

10.2.18.1 Using Groups

Groups are used in the following ways:

1. Policies: A policy is linked to all users or a set of user ID groups. The Policy Tree shows the linking of User ID groups to policies.

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

3. Conditions: Some conditions use groups as a parameter type—for example, IP in IP Group. The condition takes IP Group name or IP as a parameter.

4. Trigger combinations: Alerts in groups are specified in the trigger combination.

5. Pre-condition: User groups can be excluded in a policy. Rules can also be configured such that it will not be evaluated for certain userID group, in spite of the group linking of the policy that contains it.

6. Configurable Actions: Members of a User ID group can be added to a User ID group dynamically using configurable actions.

10.2.18.2 User Group Linking

In Group Linking, the Run mode can be specified to execute policies for all users or selected user groups. Group 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.

10.2.18.3 Using Action and Alert Groups

Action groups are used as results within rules so that when a rule is triggered all of the actions within the groups are activated.

Alert groups are used as results within rules so that when a rule is triggered all of the alerts within the groups are created.

10.3 About Rule Processing

This section describes how rules and policies are executed in the basic authentication flow.

10.3.1 Rules Engine

The rules engine takes the information that you specify for the rule and the information specified in other rules in the policy and returns rule results to the policy. All the policies in the policy set result 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.

10.3.2 Order of 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.

10.3.3 Condition Evaluation

Conditions evaluate to True or False based on the available data. When multiple conditions are added, the conjunction between the conditions is always AND, that is, Condition A (True) and Condition B (True) result in an outcome of True (rule is triggered), whereas for Condition A and B being False, the outcome is False (rule is not triggered). If one of the conditions is True and the other is False, the outcome is always False.

Refer to the example in Table 10-2.

Table 10-2 Multiple Conditions

Condition 1	Condition 2	Rule Result
True	True	True
False	False	False - Rule is not triggered
True	False	False
False	True	False

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

10.3.4 Checkpoints

The checkpoint is a decision and enforcement point when policies are called to run specific rules to evaluate the risk for user actions. OAAM Server uses standard policies and checkpoints to control user flow. API-based integrations can create new checkpoints, configure policies, and drive the flow. There can be multiple policies in the checkpoint.

Figure 10-7 Policies and Checkpoints

Description of "Figure 10-7 Policies and Checkpoints"

All policies that are configured for a checkpoint are evaluated and the outcome is a score, an action, or both. The scores of these policies are used to determine a score for the checkpoint. The score for a particular checkpoint must be between 0–1000.

10.3.5 Controlling the Application Flow

Actions are used to control the application flow. An action is an event that is 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 standard actions. Users may also create custom actions that are used by their policies and applications.

For information on native integration, refer to Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.

10.3.6 Messaging

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.

For information on creating an alert, see Chapter 12, "Managing Groups."

10.3.7 Rule Processing Example: How the OAAM Device Max Velocity Rule Settings Work?

The Device Max Velocity rule is used to detect man-in-the-middle attacks where a hacker obtains the media access control address (MAC address) for devices that users log in from. Hackers replay the user login and provide the user's computer MAC address. By doing this, they fool the system into thinking the user is logging in from a known and trusted device that is in the user's OAAM profile.

The Device Max Velocity rule can detect this type of attack, trigger an alert, and block the hacker from successfully signing in. This is accomplished in conjunction with the IP geolocation data.

The rule checks to see if the MAC address is in the list of known devices the user is logged in from. Then it examines the IP address location where the user is logged in from. If a hacker then tries to log in by replaying the user's session and also using the user's device MAC address from another location, such as 100 miles away, the rule uses a formula that determines the possibility of that user's device traveling at that velocity.

It is possible for a user to log in to his application, then take a Jet to fly to another city and once again log in to the same application. Therefore, you must be able to adjust the variables of the formula to allow for a portable device to travel at least the speed of a Jet. The Device Max Velocity rule has two values that the administrator can configure. Those value fields are called Last Login Within (Seconds) and Miles Per Hour is More Than. Using these two field values you can customize the allotted velocity that a physical device can travel before an alert is triggered.

Note:

Assumptions are:

• IP geolocation data must have been loaded in the OAAM server.

• The user must log in from same device.

• The user's authentication status is "success" in the previous login (N seconds ago)

How the Rule Formula Works

1. The rule first gets the last successful login in the last N seconds. (If there are multiples, the last one with the highest timestamp is used.

2. The rule looks at cityLastLogin and currentCurrentLogin and calculate the distance between them which equal to the distance.

3. Then it calculates thisDistance divided by the difference in login times. That value is the velocityCalculated.

4. If velocityCalculated is more than velocityConfigured in the rule (from OAAM Admin), the rule triggers.

Solution

Using the following testing assumptions and steps you can make the Device Max Velocity rule alert trigger, and also see how to avoid not triggering the rule alert. Before starting your test:

The user's authentication status should be success in the previous login (N seconds ago).

Assume you only have one minute to test the Device Max Velocity rule. Assuming that point A and point B are 900 miles apart, in order to travel from point A to point B in 60 seconds, you need to be traveling at 54000 miles an hour.

1. Set your Miles Per Hour is More Than to 54000

2. Set the Last Login Within (Seconds) to 60 seconds.

Setting up the Test:

Pick two IP addresses for the test that you know are far away from each other from the IP geolocation data. For example:

172.16.0.0 City1, State1

172.16.1.1 City2, State2

To illustrate this example, let us say, the two cities are a distance of 867 miles apart.

Make sure that the rule is not triggered by logging in twice and not exceeding the Device Max Velocity settings you already set to 60 seconds and 54000 miles per hour. Log in twice with the same user and device with logins no less than 75 seconds apart. Make sure that each time you log in you use a tool like Mozilla Firefox Web Browser "Modify Headers" to change the IP address between log ins using the two IP Addresses mentioned earlier in this section. This simulates a device logging in from two different locations 867 miles apart. The Device Max Velocity alert does not trigger.

Now perform the same test again where you log in twice less than 30 seconds apart, again, changing the IP address between logins. The Device Velocity alert is triggered.

Understanding the relationship between the Miles Per Hour is More Than and the Last Login Within (Seconds) settings: You cannot change one of these settings and not consider what the other needs to be set to. In other words, you cannot only set the Mile Per Hour is More Than setting and not properly adjust the Last Login within (Seconds) setting. These two settings work together with the formula to calculate a devices velocity. The relationship between these two settings is not an OR. It is an AND. Last Login AND Mile per hour work together. Remember the following two rules before changing these two settings.

1. You cannot only consider the Miles Per hour when setting the velocity. You must also consider the Last Login within (Seconds) setting.

2. When testing, you must consider and calculate the distance between point A and point B, the time taken to conduct the test, and further factor in the distance between the two points and how long the testing takes. If you want to use one minute as the time allotted for the testing, then make sure you know the distance between point A and Point B. You must also know how long it takes to travel from point A and point B in 60 seconds, again, if you plan to conduct your test in less than one minute.

10.3.8 How "Then Trigger" Setting Works

If the then trigger setting is set to True, the rule condition triggers if the condition is met.

If the then trigger setting is set to False, the rule condition will only trigger if the condition is not met.

The following conditions will trigger:

• If the user comes from Seattle and if the condition parameters are set as follows: then trigger is True and city equals Seattle.

• If the user comes from San Jose and if the condition parameters are set as follows: then trigger is False and city is equal to Seattle.

The following conditions will not trigger:

• If the user comes from San Jose and if the condition parameters are set as follows: then trigger is True and city is equal to Seattle.

• If the user comes from Seattle and if the condition parameters are set as follows: then trigger is False and city is equal to Seattle.

10.3.9 Condition Evaluation Example: User: Velocity from Last Success

The User: Velocity from Last Success condition evaluates to check to see if

• The user's login was successful earlier, and

• The velocity in miles per hour is more than the specified value, and

• The user belongs to the same Device ID

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Value	Can be Null?
Miles per hour is more than	The velocity in miles per hour is more than specified value	Positive integer Default: 60	No
ignore if last login device is same	See possible value.	True/False The flag is set to true if there are more than one successful login from the same user from the same Device ID. The condition returns false and no action/alert is triggered. if there are more than one successful login from the same user from different Device IDs and the condition returns true and an action/alert is generated. The flag is set to false False ignores the parameter and the condition evaluates based on miles per hour only.	Yes
Exclude IP List	This parameter allows you to specify a list of IPs to ignore. If a user's IP is from that list, then this condition always evaluates to false. If the user's IP is not in that list or if the list is null or empty, then the condition evaluates the velocity of the user or the device from the last login and evaluates to true if the velocity exceeds the configured value.

Scenario

Condition evaluates if the users login was successful earlier and the velocity in miles per hour is more than specified value and user belong to the same Device ID. If there are multiple logins of the same user from the same device, then the parameter "ignore if last login device is same" will act. In order for the condition to be false, there must be multiple logins that are successful from the same user that is using the same Device ID. The location database is used to determine the location of the user for this login and the previous login.

Use Case 1

User: karen1, Device ID: 2106, Previous Device ID: None, rule-flag: true

1. Log in from device from IP1

2. Log in from the same device from IP2 (which is 60 miles away). There is no alert generated.

3. Log in from the same device and IP2 (which is 60 miles away). There is no alert generated.

Table 10-3 Use Case 1

User name	Auth Status	Device ID	Location	IP	Alert
karen1	Success	2106	US, Texas, Austin	IP1	No alert
karen1	Success	2106	US, Arizona, Gila Bend	IP2	No alert. An alert is not generated since the same user has the same device and the flag is set to true.
karen1	Success	2106	US, Arizona, Gila Bend	IP2	No alert. An alert is not generated since the same user has the same device and the flag is set to true.

Use Case 2

User: karen1, Device ID: 2107, Previous Device ID: 2106, rule-flag: true

1. Log in from the same device from IP1.

2. Log in from the same device from IP2 (which is 60 miles away). There is no alert triggered.

3. Log in from the same device and IP2 (which is 60 miles away). There is no alert triggered.

Table 10-4 Use Case 2

User name	Auth Status	Device ID	Location	IP	Alert
karen1	Success	2107	US, Arizona, Gila Bend	IP1	New device
karen1	Success	2107	US, Texas, Austin	IP2	No alert. An alert is not generated since the same user has the same device and the flag is set to true.
karen1	Success	2107	US, Texas, Austin	IP2	No alert. An alert is not generated since the same user has the same device and the flag is set to true.

Use Case 3

User: karen1, Device ID: 2109, Previous Device ID: 2108, rule-flag: false

1. Log in from Device 2108 from IP1.

2. Log in from Device 2109 from IP2 (which is 60 miles away). Alerts are triggered.

3. Log in from the same device (Device 2109) and IP2 (which is 60 miles away). No alert is triggered.

Table 10-5 Use Case 3

User name	Auth Status	Device ID	Location	IP	Alert
karen1	Success	2108	US, Texas, Austin	IP1	New device
karen1	Success	2109	US, Arizona, Gila Bend	IP2	Device High Velocity User High Velocity
karen1	Success	2109	US, Arizona, Gila Bend	IP2	No alert

10.4 About OAAM Authentication, Password Management and Customer Care Flows

This section describes Oracle Adaptive Access Manager authentication, password management, and customer care flows.

10.4.1 Authentication Flow

Figure 10-8 shows the authentication flow of OAAM server when a user logs in to an application that is protected by Oracle Adaptive Access Manager.

The basic authentication flow is presented as follows:

1. The OAAM Server presents the user with the OAAM user name page and the user submits his user name on the OAAM user name page.

2. Oracle Adaptive Access Manager runs the Device Identification checkpoint to fingerprint and identify the user device and the Pre-authentication checkpoint to determine if the user should be allowed to proceed to the OAAM password page. Does this user need to be blocked? For example, if the session is logging in from a risky IP address or if the device is not to be trusted, OAAM will block the user and take the user to the Lockout page.

3. If the user is allowed to proceed, the virtual authentication device rules are run during the Authentication Pad checkpoint. These rules determine if a virtual authenticator is registered and which virtual authenticator to display in the OAAM password page. If none have been registered, a generic textpad is displayed. The user is prompted to enter his password.

4. If the credentials collected are correct, Oracle Adaptive Access Manager runs the Post-authentication checkpoint (policies). It determines the user's risk score and executes any actions (for example, KBA or OTP) or alerts that are specified in the policy. Based on the policies (for example, the risk score), OAAM might allow, challenge, or block the user.

5. If the outcome of Post-Authentication is ALLOW then OAAM runs the Registration checkpoint which determines if the user has KBA and images registered. If the user is not registered, he will be taken to the profile registration pages. If already registered, the user is shown the landing page since he has successfully logged in.

   If the user is not registered, he may be taken to the profile registration page to register, for example, KBA or OTP. Registration is required depending on security requirements, which specify whether the registration is mandatory or optional.

6. If the outcome of Post-Authentication is CHALLENGE, the user is taken to the Challenge page. The Challenge checkpoint is run to determine the type of challenge to run. If the user can answer the challenge (the challenge flow is successful) then he would be allowed to the Registration checkpoint. If he cannot answer the challenge, he can be locked or challenged again. He can also be blocked by the Challenge checkpoint. For example, he does not have KBA, OTP, or appropriate profile registered, but he is not necessarily log in from a good score, depending on registry so far, he actually could be locked or he will be shown the challenge question. If correct he gives the correct answer, he proceeds to the landing page.

7. If the outcome of Post-Authentication is BLOCK then user would be taken to the Lock Out page and blocked and he will not be able to access the web application that he tried accessing. For example, he is blocked because his risk score was sufficiently high and he did not complete registration. Without registration, it was not be possible to take him to the challenge flow.

Figure 10-8 Authentication Flow

Description of "Figure 10-8 Authentication Flow"

New User Authentication and Registration Flows Example

The following screens are used to illustrate these tasks from a new user-experience perspective. The screens are only example as the user interface provided by the OAAM Server Web application can be easily customized to achieve the look and feel of the customer applications. For information, see "Customizing OAAM Web Application Pages" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.

1. The user is presented with a page in which he is asked to submit his user name.

   
   Description of the illustration basic001.gif
   
   

2. The user is prompted to enter his password. Since a profile has not been registered, a generic textpad is displayed. It does not contain an image or phrase, but it does contain a timestamp.

   
   Description of the illustration basic002.gif
   
   

3. The user fills in the password and clicks the Enter button on the device. OAAM verifies the user's password.

4. If the user is not register, he sees a registration information page that describes the registration process.

   He can continue through the registration process or "skip" registration and perform the process at another time.

   A mobile example is shown to illustrate a mobile friendly page. OAAM provides a base mobile CSS (external stylesheet) file to enable users to view the Web pages on mobile devices. Because significant differences exist between the browsers found on devices supported by OAAM and the native look-and-feel of each device varies greatly, OAAM Server supports a custom override to the mobile CSS. Device-specific CSS can be defined in addition to generic mobile CSS to allow for more fine grade customizations. Mobile devices include iPhone, iPad, Android, Windows Phone, and Blackberry. For information, see "Customizing User Interface for Mobile Devices" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.

   The non-mobile page shows illustrations for the Security Image and Phrase page and the Security Questions and Answers page.

   
   Description of the illustration basic003.gif
   
   

   The mobile page does not show illustrations from the Security Image and Phrase page or the Security Questions and Answers page.

   
   Description of the illustration mobile3.gif
   
   

5. The next step in the registration process is the selection of an image and phrase. The user may click the link to Get a new image and phrase, which will generate a new image and phrase.

   
   Description of the illustration basic004.gif
   
   

6. Next the user is required to select challenge questions from the menus (dropdown lists) provided, and enter the answers to those questions. For a non-mobile page, the user enters the answer in the authentication device. Also, the selected image and phrase is embedded in the device along with a current timestamp of his local timezone.

   
   

   In the mobile Security Questions page, the virtual authentication device does not appear. He enters answers into a field under the question list.

   
   Description of the illustration mobile5.gif
   
   

7. After the questions are selected and answers are provided, the user is logged in to the system. The user performs his required tasks and logs out of the system.

8. The next time the user tries to log in, he is presented with the user name page in which to enter his user name.

9. If the session passes the pre-authentication rules, the password page is displayed. Since the user is registered, the password page contains his selected image and phrase embedded in the device along with a current timestamp of his local timezone.

10. The user fills in the password and clicks the Enter button on the device. OAAM verifies the user's password.

11. If the password is correct and the session does not require an additional challenge/response for authentication, the user is logged in to the system.

User Logging In From Different Location Example

The following screens illustrate an example of the user flow when he logs in using a different IP address and he is challenged.

1. The user is presented with a page in which he is asked to submit his user name.

   
   Description of the illustration ip0051.gif
   
   

2. If the user name is accepted and the user is allowed to proceed, he is presented with a password page which contains his selected image and phrase embedded in the device along with a current timestamp of his local timezone.

   
   Description of the illustration ip0052.gif
   
   

3. The user fills in the password and clicks the Enter button on the device. OAAM verifies the user's password. Since OAAM determined the session requires an additional challenge/response for authentication because of the user's location, one of the questions he had selected in registration is displayed. The Challenge Question Authentication Pad device has phishing image and phrase embedded along with a current timestamp.

   
   Description of the illustration ip0054.gif
   
   

4. The user answers the question correctly and is then logged in to the system.

10.4.2 Forgot Password Flow

The Forgot Password flow allows the users to reset their password after successfully answering all challenge questions.

Note:

The Forgot Password feature requires Oracle Identity Manager integration. For more information on Access Manager, Oracle Adaptive Access Manager, and Oracle Identity Manager integration, see Oracle Fusion Middleware Integration Guide for Oracle Identity Management Suite.

The forgot password feature is made available as a link from the OAAM password page. The flow starts when the user is at the OAAM password page and clicks the Forgot your password link.

Note:

For a single-login page deployment, the Forgot Password flow is unavailable if the Where is my password link is disabled.

The flow is as follows:

1. The OAAM Server presents the user with the OAAM user name page and the user submits his user name on the OAAM user name page.

2. Oracle Adaptive Access Manager runs the Device Identification checkpoint to fingerprint and identify the user device and the pre-authentication checkpoint to determine if the user should be allowed to proceed to the OAAM password page. Does this user need to be blocked? For example, if the session is coming in from a bad IP address or if the device is not to be trusted, OAAM will block the user and take the user to the Lockout page.

3. The virtual authentication device rules are run to determine if a virtual authenticator is registered and which virtual authenticator to display in the OAAM password page. If none have been registered, a generic textpad is displayed. The user is prompted to enter his password.

4. Because the user cannot remember his password during the authentication, he clicks the Forgot your password? link below the password authentication device.

5. If the user is already registered, the forgotten password reset process is initiated and the Challenge checkpoint is run to determine the type of challenge to use. Then OAAM presents the user with challenges that must be answered.

6. If the user answers the challenges incorrectly, he will be challenged again and locked out of his account after "n" number of failed attempts.

7. If the user provides correct responses, he is redirected to the Password Reset page.

8. The user enters and confirms the new password. If the user's new password fulfills the password rules, his password is reset.

Figure 10-9 Forgot Password Flow

Description of "Figure 10-9 Forgot Password Flow"

10.4.3 Reset Password (KBA-Challenge) Flow

Challenge Reset enables users to reset their challenge registration.

Figure 10-10 Reset Password

Description of "Figure 10-10 Reset Password"

10.4.4 Mobile Service Flows with OAAM

A mobile device is a device that runs a mobile operating system, such as the iOS mobile operating system from Apple, while a non-mobile device is a device that runs a non-mobile operating system, such as Mac OS X, Windows 7, and Linux desktop. Because mobile devices and non-mobile devices present different security challenges, mobile authentication and non-mobile authentication are managed separately in Mobile and Social. New mobile devices come online much more frequently and therefore require greater scrutiny, including fraud detection measures.

OAAM can be used to make runtime authentication decisions, such as blocking authentication if the user is authenticating from an unauthorized country or location. The following functionality is also supported:

• Multi-part login flows: OAAM can challenge the user with knowledge-based authentication (KBA) questions, or require the user to authenticate using one-time password (OTP) functionality if OAAM detects a risky or unusual usage pattern (using the device at unusual hours or if the user is geographically distant from the place where authentication last took place).

• Check device attributes (such as the MAC Address assigned to a device) and verify that the device is not jail broken. Based on device attributes, OAAM can allow or deny access.

• Device-selective wipeouts are also an option when using OAAM together with Mobile and Social.

• Based on registered device information, OAAM can white-list or black-list specific devices.

10.5 About OAAM Security and Autolearning Policies

OAAM comes standard with standard policies pre-built to detect suspicious activity.

Note:

In the tables, bold text is used to indicate parameters driving the outcome of the policies.

Table 10-6 presents the OAAM standard checkpoints and policies.

Table 10-6 OAAM Checkpoints and Responsibilities

CheckPoint Name	Responsibilities	Policies
Pre-Authentication	Determine if the request must be BLOCKED	OAAM Pre-Authentication. For information, see Section 10.5.1.1, "OAAM Pre-Authentication."
Device Identification	Determine how to identify the device	OAAM Base Device ID Policy. For information, see Section 10.5.2.1, "OAAM Base Device ID Policy." OAAM Mobile Device ID Policy. For information, see Section 10.5.2.2, "OAAM Mobile Device ID Policy."
AuthentiPad	Determine which authentication pad to use	OAAM AuthenticationPad. For information, see Section 10.5.3.1, "OAAM AuthentiPad."
Post Authentication	Determine if the user must be ALLOWED or BLOCKED	OAAM Post-Authentication Security. For information, see Section 10.5.4.1, "OAAM Post-Authentication Security." OAAM Predictive Analysis. For information, see Section 10.5.4.2, "OAAM Predictive Analysis." Auto-learning (Pattern-Based) Policy: OAAM Does User Have Profile. For information, see Section 10.5.4.3, "Autolearning (Pattern-Based) Policy: OAAM Does User Have Profile." Auto-learning (Pattern-Based) Policy: OAAM Users vs. Themselves. For information, see Section 10.5.4.4, "Autolearning (Pattern-Based) Policy: OAAM Users vs. Themselves." Autolearning (Pattern-Based) Policy: OAAM Users vs. All Users. For information, see Section 10.5.4.5, "Autolearning (Pattern-Based) Policy: OAAM Users vs. All Users."
Registration	Determine which pieces of user information is pending registration	OAAM Registration. For information, see Section 10.5.5.1, "OAAM Registration."
Challenge	Determine which mechanism to use to challenge the user	OAAM Challenge. For information, see Section 10.5.6.1, "OAAM Challenge."
CSR KBA Challenge	Applicable when customer calls in for service. Reset settings is performed through CSR KBA Challenge.	OAAM Customer Care Ask Question. For information, see Section 10.5.7.1, "OAAM Customer Care Ask Question."
Forgot Password	Activity to reset password performed based on challenge.
Preferences	Sets the user information (Image, phrase, OTP settings, and so on).

10.5.1 Pre-Authentication Policies

Pre-authentication policies are summarized in this section.

10.5.1.1 OAAM Pre-Authentication

This policy stops fraudulent login attempts before the password is entered.

10.5.1.1.1 Policy Summary

Table 10-7 OAAM Pre-Authentication Policy Summary

Summary	Details
Purpose	This policy stops fraudulent login attempts before the password is entered.
Scoring Engine	Maximum
Weight	100
Group Linking	All Users

10.5.1.1.2 OAAM Pre-Authentication Flow Diagram

Figure 10-11 OAAM Pre-Authentication Flow

Description of "Figure 10-11 OAAM Pre-Authentication Flow"

10.5.1.1.3 OAAM Pre-Authentication: Details of Rules

The table below shows the rule conditions and parameters in the OAAM Pre-Authentication Policy.

Table 10-8 OAAM Pre-Authentication Policy Rules Details

Rule	Rule Condition and Parameters	Results
Blacklisted countries	Location: In Country group Is In List = TRUE Country in country group=OAAM Restricted Countries	Action = OAAM Block Alert = OAAM Restricted Country Score = 1000
Blacklisted devices	Device: Device in group Is in group = TRUE Device in group = OAAM Restricted Devices	Action = OAAM Block Alert = OAAM Restricted Device Score = 1000
WebZIP used	Device: Browser header substring Substring to check = WebZIP Note: WebZip is a source code compressor for web languages, such as HTML, CSS, Javascript, or AJAX. For information, refer to Section 10.6.1, "Use Case: WebZIP Browser."	Action = OAAM Block Alert = OAAM Restricted Software Score =1000
Blacklisted IPs	Location: IP in group Is in List = TRUE IP List = OAAM Restricted IPs	Action = OAAM Block Alert = OAAM Restricted IP Score = 1000
Blacklisted ISPs	Location: ISP in group Is in List = TRUE ISP List = OAAM Restricted ISPs	Action = OAAM Block Alert = OAAM Restricted ISP Score = 1000
Blacklisted users	User: In Group Is in group = TRUE User Group = OAAM Restricted Users	Action = OAAM Block Alert = OAAM Restricted User Score = 1000

10.5.1.1.4 Trigger Combinations

There are no trigger combinations for this policy.

10.5.2 Device Identification Policies

The Device Identification policy is summarized in this section.

10.5.2.1 OAAM Base Device ID Policy

This policy determines as to which Device ID policy to execute for client device identification.

10.5.2.1.1 Policy Summary

Table 10-9 OAAM Base Device Policy Summary

Summary	Details
Purpose	This policy determines as to which Device ID policy to execute for client device identification.
Scoring Engine	Maximum
Weight	100
Group Linking	All Users

10.5.2.1.2 OAAM Base Device ID Flow Diagram

Figure 10-12 OAAM Base Device ID Flow Diagram

Description of "Figure 10-12 OAAM Base Device ID Flow Diagram"

10.5.2.1.3 OAAM Base Device Policy: Details of Rules

Table 10-10 OAAM Base Device Policy Rules Details

Rule	Rule Condition and Parameters	Results
Is Mobile Device	Device: Check if device is using Mobile Browser Mobile browser group = OAAM Mobile Browser Group The Mobile Browser Group contains names of mobile browsers. Default return value in case of errors = FALSE Device: Browser header substring Substring to check for = OIC Note: You are checking for the substring "OIC".	Action = None Alert = None Score = 0

10.5.2.1.4 OAAM Base Device ID Policy: Trigger Combinations

Table 10-11 OAAM Base Device ID Policy Trigger Combinations

Description	Combination Detail	Result
Mobile Device	Is Mobile Device = TRUE	Action = None Alert = None Policy = OAAM Mobile Device ID Policy
Fall through (Is mobile device is not true)	Is Mobile Device = Any	Action = None Alert = None Policy = OAAM Device ID Policy

10.5.2.2 OAAM Mobile Device ID Policy

This policy identifies the mobile devices specific to Oracle Access Management Mobile and Social (Mobile and Social) integrations

10.5.2.2.1 OAAM Mobile Device ID Policy Summary

Table 10-12 OAAM Mobile Device ID Policy Summary

Summary	Details
Purpose	This policy identifies the mobile devices specific to Oracle Access Management Mobile and Social (Mobile and Social) integrations
Scoring Engine	Maximum
Weight	100
Group Linking	All Users

10.5.2.2.2 OAAM Mobile Device ID Flow Diagram

Figure 10-13 OAAM Mobile Device ID Flow Diagram

Description of "Figure 10-13 OAAM Mobile Device ID Flow Diagram"

10.5.2.2.3 OAAM Mobile Device ID Policy: Details of Rules

Table 10-13 OAAM Mobile Device ID Policy Rules Details

Rule	Rule Condition and Parameters	Results
Mobile Cookie Valid	Device ID: Is cookie valid Select cookie type= Mobile Cookie Note: OAAM sends a token to the mobile client or browser. The mobile client or browser sends the token back in the next request.	Action = None Alert = None Score = 0
Mobile Known Header match	Device ID: Header data match Cookie to use= Mobile Cookie Should check history node = true Data Type = Mobile Cookie Negative check = False	Action = None Alert = None Score = 200
Mobile Device Data Present	Device ID: Header data present Data Type = Mobile Cookie	Action = None Alert = None Score = 0

10.5.2.2.4 OAAM Mobile Device ID Policy: Trigger Combinations

Table 10-14 OAAM Mobile Device ID Policy Trigger Combinations

Description	Combination Detail	Result
Device coming in with valid cookie and header match	Mobile Cookie Valid = TRUE Mobile Known Header match = TRUE Mobile Device Data Present = Any	Action = OAAM Device By Mobile Cookie Alert = None Score = 0
Cookie is valid but known header mismatch	Mobile Cookie Valid = TRUE Mobile Known Header match = FALSE Mobile Device Data Present = Any	Action = OAAM Device By Mobile Cookie Alert = None Score = 600
Mobile cookie is invalid	Mobile Cookie Valid = FALSE Mobile Known Header match = Any Mobile Device Data Present = Any	Action = OAAM New Device Alert = None Score = 200
Mobile Data is not present	Mobile Cookie Valid = Any Mobile Known Header match = Any Mobile Device Data Present = FALSE	Action = OAAM New Device with BG Check Alert = None Score = 0

10.5.3 Authentipad Policy

The AuthentiPad policy is summarized in this section.

10.5.3.1 OAAM AuthentiPad

This policy determines the OAAM Authentication Pad to use.

10.5.3.1.1 OAAM AuthentiPad Policy Summary

Table 10-15 OAAM AuthentiPad Policy Summary

Summary	Details
Purpose	This policy determines which OAAM Authentication Pad to use.
Scoring Engine	Average
Weight	100
Group Linking	All Users

10.5.3.1.2 OAAM AuthentiPad Flow Diagram

Figure 10-14 OAAM AuthentiPad Flow

Description of "Figure 10-14 OAAM AuthentiPad Flow"

10.5.3.1.3 OAAM AuthentiPad: Details of Rules

The table below shows the rule conditions and parameters in the OAAM AuthentiPad Policy.

Table 10-16 OAAM AuthentiPad Policy Rules Details

Rule	Rule Condition and Parameters	Results
Challenge SMS	Session: Check value in comma separated values Parameter Key = AvailableChallengeTypes Value to Check = ChallengeSMS Return if in list = TRUE	Action = OAAM Text Pad Alert = NONE Score = 0
Registered Image and Caption	User: Authentication Image Assigned Is Assigned = TRUE	Action = OAAM Personalized Pad Alert = NONE Score = 0
Key Pad User	User: Authentication Mode Authentication Mode is = Full Keypad	Action = OAAM KeyPad Alert = NONE Score = 0
Challenge Email	Session: Check value in comma separated values Parameter Key = AvailableChallengeTypes Value to Check = ChallengeEmail Return if in list = TRUE	Action = OAAM Text Pad Alert = NONE Score = 0
Register Challenge Question	Session: Check value in comma separated values Parameter Key = AvailableChallengeTypes Value to Check = RegisterChallengeQuestion Return if in list = TRUE	Action = NONE Alert = NONE Score = 0
Check if mobile browser is used	DEVICE: Check if device is a given type Device Type = Mobile device Return Value when device of given type = TRUE	Action = NONE Alert =OAAM Mobile Users Score = 0
Challenge Question	Session: Check value in comma separated values Parameter Key = AvailableChallengeTypes Value to Check = ChallengeQuestion Return if in list = TRUE	Action = OAAM Question Pad Alert = NONE Score = 0

10.5.3.1.4 OAAM AuthentiPad: Trigger Combinations

Table 10-17 OAAM AuthentiPad Policy Trigger Combinations

Description	Combination Detail	Result
Registering challenge questions using mobile browser	Register Challenge Question = TRUE Check if Mobile Device = TRUE Challenge SMS = FALSE Challenge Email = FALSE Challenge Question = FALSE Registered Image and Caption =Any Key Pad User = Any	Action = OAAM HTML Pad Alert = NONE Score = 0
Registering challenge questions using non mobile browser.	Register Challenge Question = TRUE Check if Mobile Device = FALSE Challenge SMS = Any Challenge Email = Any Challenge Question = Any Registered Image and Caption =Any Key Pad User = Any	Action = OAAM Question Pad Personalized Alert = NONE Score = 0
Password while upgraded to Key-Pad without registered image.	Register Challenge Question = FALSE Check if Mobile Device = FALSE Challenge SMS = FALSE Challenge Email = FALSE Challenge Question = FALSE Registered Image and Caption = FALSE Key Pad User = TRUE	Action = OAAM Key Pad Alert = NONE Score = 0
Password while upgraded to KeyPad with registered image. Adds personalized pad sub-action.	Register Challenge Question = FALSE Check if Mobile Device = FALSE Challenge SMS = FALSE Challenge Email = FALSE Challenge Question = FALSE Registered Image and Caption = TRUE Key Pad User = TRUE	Action = OAAM Key Pad Personalized Alert = NONE Score = 0
Password without registered image	Register Challenge Question = Any Check if Mobile Device = Any Challenge SMS = FALSE Challenge Email = FALSE Challenge Question = FALSE Registered Image and Caption = FALSE Key Pad User = Any	Action = OAAM Text Pad Alert = NONE Score = 0
Password with registered image. Adds personalized pad sub-action.	Register Challenge Question = Any Check if Mobile Device = Any Challenge SMS = FALSE Challenge Email = FALSE Challenge Question = FALSE Registered Image and Caption = TRUE Key Pad User = Any	Action = OAAM Text Pad Personalized Alert = NONE Score = 0

10.5.4 Post-Authentication Policies

This section summarizes the Post-Authentication policies.

10.5.4.1 OAAM Post-Authentication Security

This policy evaluates the level of risk after authentication is successful. The possible actions are allow block or challenge.

10.5.4.1.1 OAAM Post-Authentication Security Policy Summary

Table 10-18 OAAM Post-Authentication Security Policy Summary

Summary	Details
Purpose	This policy evaluates the level of risk after authentication is successful. The possible actions are allow block or challenge.
Scoring Engine	Maximum
Weight	100
Group Linking	All Users

10.5.4.1.2 OAAM Post-Authentication Security Flow Diagram

Figure 10-15 OAAM Post Authentication Security Flow

Description of "Figure 10-15 OAAM Post Authentication Security Flow"

10.5.4.1.3 OAAM Post-Authentication Security: Details of Rules

The table below shows the rule conditions and parameters in the OAAM Post-Authentication Security Policy.

Table 10-19 OAAM Post Authentication Security Policy Rules Details

Rule	Rule Condition and Parameter Values	Results
Active Anonymizer	Location: IP in Group Is in List = TRUE IP in group = anonymizer_active	Action = OAAM Block Alert = OAAM Active Anonymizer IP Score = 1000
Suspect Anonymizer	Location: IP in Group Is in List = TRUE IP in group = anonymizer_suspect	Action = OAAM Challenge Alert = OAAM Suspected Anonymizer IP Score = 700
Unknown Anonymizer	Location: IP in Group Is in List = TRUE IP in group = anonymizer_active	Action = OAAM Challenge Alert = OAAM Unknown Anonymizer IP Score = 600
Private Anonymizer	Location: IP in Group Is in List = TRUE IP in group = anonymizer_private	Action = OAAM Challenge Alert = OAAM Private Anonymizer IP Score = 700
Risky Connection Type	Location: IP Connection Type in Group Is in List = TRUE Connection type in group = OAAM High Risk Connection Types	Action = OAAM Challenge Alert = OAAM Risky Connection type Score = 700
User Blocked Recently	User: Action Timed Check Action = BLOCK In seconds = 28800 More than = 2	Action = OAAM Challenge Alert = User Blocked Recently Score = 700
Maximum Users per Device	Device: User Count Seconds Elapsed = 2592000 Max number of users allowed = 5	Action = OAAM Challenge Alert = OAAM Device Multiple Users Score = 500
Dormant IP	Location: IP Connection type in group Is in List = FALSE Connection type group = OAAM Mobile Connections Location: IP Excessive Use Number of Users = 4 Within (hours) = 24 And not used in days = 30	Action = OAAM Challenge Alert = OAAM Dormant IP Score = 500
Surge of Users from IP	Location: IP Connection type in group Is in List = FALSE Connection type group = OAAM Mobile Connections Location: IP is AOL Is AOL = False Location: IP Maximum Users Seconds Elapsed = 300 Max number of users = 3	Action = OAAM Challenge Alert = OAAM IP Multiple Users Score = 600
Risky countries	Location: In Country Group Is in List = TRUE Country in country group = OAAM Monitoring Countries	Action = OAAM Challenge Alert = OAAM Monitored Country Score = 500
Dormant Device	Device: Excessive Use Number of Users = 4 Within (hours) = 24 And not used in (days) = 30	Action = OAAM Challenge Alert = OAAM Dormant Device Score = 500
Device with Many Failures	Device: Timed not status Authentication status is not = SUCCESS Within duration (seconds) = 28800 For more than 4 (times)	Action = OAAM Challenge Alert = OAAM Many Failures from Device Score =600
Maximum Devices per User	User: Check Devices Used Maximum number of devices = 2 Within duration (seconds) = 28800	Action = OAAM Challenge Alert = OAAM Max Devices for User Score =300
Risky Device	Device: In List Is in group= TRUE Device in group = OAAM Risky Devices	Action = OAAM Challenge Alert = OAAM Risky Device Score = 700
Device Maximum Velocity	Device: Velocity from last login Last Login within (Seconds) = 72000 Miles per Hour is more than = 600	Action = OAAM Challenge Alert = OAAM Device Maximum Velocity Score =700
Risky IP	Location: IP in group Is in List = TRUE IP List = OAAM Risky IPs	Action = OAAM Challenge Alert = OAAM Risky IP Score = 700
Too many mobile devices	Device: Check if device is of given type Device Type = Mobile Device Return Value = True DEVICE: Is registered Is Registered then return = False User: Check Number of Registered Devices of a Given Type Number Of Devices = More than Number Of Devices to compare = 4 Device Of Type = Mobile Device	Action = OAAM Too Many Mobile Devices Alert = OAAM More Mobile devices used than allowed Score = 1000
Lost or Stolen Device	Device: Check if device is of given type Device Type = Mobile Device Return Value = True Device: Device in group Is in group = True Device in group = OAAM Lost or stolen Device	Action = OAAM Lost Device Alert = OAAM Lost or Stolen Device Score = 1000
Jail broken Mobile Device	Device: Check if device is of given type Device Type = Mobile Device Return Value = True Session: Check string parameter value Parameter Key = isJailBroken Value = true	Action = OAAM Challenge Alert = OAAM Jailbroken Device Score = 500
Hardware Identifier same but Operating System mismatch	Precondition: Device Risk Score between 599 and 601 Device: Check if device is of given type Device Type = Mobile Device Return Value = True Device: Browser Header Substring Substring = "OIC"	Action = OAAM Mobile Device OS Mismatch Alert = OAAM Mobile Device with Different OS Score = 1000
Mobile device is not registered	Device: Check if device is of given type Device Type = Mobile Device Return Value = True Device: Is registered If registered then, return = False	Action = OAAM Challenge Alert = None Score = 300

10.5.4.1.4 OAAM Post-Authentication Security: Trigger Combinations

There are no trigger combinations for this policy.

10.5.4.2 OAAM Predictive Analysis

This policy harnesses the predictive capabilities of Oracle Data Miner. The rules in this policy are only functional if Oracle Data Miner is configured.

10.5.4.2.1 OAAM Predictive Analysis Policy Summary

Table 10-20 OAAM Predictive Analysis Policy Summary

Summary	Details
Purpose	Harnesses the predictive capabilities of Oracle Data Miner. These rules are only functional if Oracle Data Miner is configured.
Scoring Engine	Maximum
Weight	100
Group Linking	Linked Users

10.5.4.2.2 OAAM Predictive Analysis Flow Diagram

Figure 10-16 OAAM Predictive Analysis Policy Flow

10.5.4.2.3 OAAM Predictive Analysis Policy: Details of Rules

Table 10-21 shows the rule conditions and parameters in the OAAM Predictive Analysis Policy.

Table 10-21 OAAM Predictive Analysis Policy Rules Details

Rule	Rule Condition and Parameters	Results
Predict if current session is fraudulent	USER: Check Fraudulent User Request Classification Model = OAAM Fraud Request Model Required Classification = Fraud Minimum Value of Probability required = 0.70 Maximum Value of Probability required = 1.00 Default Value to return if error = FALSE	Action = NONE Alert = OAAM Suspected Fraudulent request Score = 700
Predict if current session is anomalous	USER: Check Anomalous User Request Anomaly Model = OAAM Anomalous Request Model Minimum Value of Probability required = 0.60 Maximum Value of Probability required = 1.00 Default Value to return if error = FALSE	Action = NONE Alert = OAAM Anomalous Request Score = 600

10.5.4.2.4 OAAM Predictive Analysis Policy: Trigger Combination

There are no trigger combinations for this policy.

10.5.4.3 Autolearning (Pattern-Based) Policy: OAAM Does User Have Profile

This policy checks if pattern auto-learning is enabled and if a user has past behavior recorded. Users with enough recorded behavior will be evaluated against their own profile while users without enough recorded behavior will be evaluated against the profiles of all other users.

10.5.4.3.1 OAAM Does User Have Profile Policy Summary

Table 10-22 Auto-learning (Pattern-Based) Policy: OAAM Does User Have Profile Summary

Summary	Details
Purpose	This policy checks if pattern auto-learning is enabled and if a user has past behavior recorded. Users with enough recorded behavior will be evaluated against their own profile while users without enough recorded behavior will be evaluated against the profiles of all other users.
Scoring Engine	Maximum
Weight	100
Group Linking	All Users

10.5.4.3.2 OAAM Does User Have Profile Flow Diagram

Figure 10-17 Autolearning (Pattern-Based) Policy: OAAM Does User Have Profile Flow

Description of "Figure 10-17 Autolearning (Pattern-Based) Policy: OAAM Does User Have Profile Flow "

10.5.4.3.3 OAAM Does User Have Profile: Details of Rules

Table 10-23 Auto-learning (Pattern-Based) Policy Rules Details: OAAM Does User Have Profile

Rule	Rule Condition and Parameters	Results
Does user have a profile	System - Check Boolean Property Property = vcrypt.tracker.autolearning.enabled Value = True Default Return Value = True System - Check Boolean Property Property = vcrypt.tracker.autolearning.use.auth.status.for.analysis Value = True Default Return Value = False User - Check Login Count Check only current user = True Authentication Status = Success In seconds = 0 With Login more than = 7 If Error return = False Consider current request or not = True	Action = None Alert = None Score = 0
Is enough pattern data available	System: Check if enough data is available for any pattern Number of days of data =90 Is Pattern data available = True Error Return Value = False	Action = None Alert = None Score = 0

10.5.4.3.4 OAAM Does User Have Profile: Trigger Combination

Table 10-24 Autolearning (Pattern-Based) Policy: OAAM Does User Have Profile Trigger Combination

Description	Combination Detail	Result
If a user has enough recorded behavior in their profile they will be evaluated by this policy	Does user have profile = TRUE Is enough pattern data available = TRUE	Policy = OAAM users vs. themselves Alert = None
If a user does not have enough recorded behavior in their profile they will be evaluated by this policy.	Does user have profile = ANY Is enough pattern data available = TRUE	Policy = OAAM users vs. all users Alert = None

10.5.4.4 Autolearning (Pattern-Based) Policy: OAAM Users vs. Themselves

If a user has a sufficient amount of historical data captured this policy will be used to evaluate their current behavior against their own historical behavior. This policy uses pattern-based rules to evaluate risk.

10.5.4.4.1 OAAM Users vs. Themselves Policy Summary

Table 10-25 Auto-learning (Pattern-Based) Policy: OAAM Users vs. Themselves Summary

Summary	Details
Purpose	If a user has a sufficient amount of historical data captured this policy will be used to evaluate their current behavior against their own historical behavior. This policy uses pattern-based rules to evaluate risk.
Scoring Engine	Maximum
Weight	100
Group Linking	Linked Users (It is a nested policy)

10.5.4.4.2 OAAM Users vs. Themselves Flow Diagram

Figure 10-18 Auto-learning (Pattern-Based) Policy: OAAM Users vs. Themselves Flow

10.5.4.4.3 OAAM Users vs. Themselves: Details of Rules

Table 10-26 Auto-learning (Pattern-Based) Policy Rules Details: OAAM Users vs. Themselves

Rule	Rule Condition and Parameters	Results
ISP	Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 6 Pattern name for membership = User: ISP profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User	Action = OAAM Challenge Alert = OAAM User: ISP Score = 600
Connection type	Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 6 Pattern name for membership = User: ASN profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User	Action = OAAM Challenge Alert = OAAM User: connection type Score = 600
Routing type	Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 6 Pattern name for membership = User: Routing type profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User	Action = OAAM Challenge Alert = OAAM User: Routing type Score = 600
Device	Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 10 Pattern name for membership = User: Device profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User	Action = OAAM Challenge Alert = OAAM User: Device Score = 700
Day of the week	Pattern (Authentication): Entity is member of pattern bucket for firsttime in certain time period Pattern name for membership = User: Day of Week profiling pattern Is ConditionTrue = True Time period type for pattern membership = Months Time period for pattern membership = 3 Member type for pattern membership = User First time count = 1	Action = OAAM Challenge Alert = OAAM User: day of the week Score = 500
Country and State	Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 10 Pattern name for membership = User: State profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User	Action = OAAM Challenge Alert = OAAM User: state Score = 600
Time of Day	Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 3 Pattern name for membership = User: timerange profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User	Action = OAAM Challenge Alert = OAAM User: time of day Score = 500
ASN	Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 6 Pattern name for membership = User: ASN profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User	Action = OAAM Challenge Alert = OAAM User: ASN Score = 600
Country	Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 20 Pattern name for membership = User: Country profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 3 Member type for pattern membership = User	Action = OAAM Challenge Alert = OAAM User: Country Score = 700

10.5.4.4.4 OAAM Users vs. Themselves: Trigger Combinations

There are no trigger combinations for this policy.

10.5.4.5 Autolearning (Pattern-Based) Policy: OAAM Users vs. All Users

If a user does not have a sufficient amount of historical data captured this policy will be used to evaluate their current behavior against the historical behavior of all other users. This policy uses pattern-based rules to evaluate risk.

10.5.4.5.1 OAAM Users vs. All Users Policy Summary

Table 10-27 Auto-learning (Pattern-Based) Policy: OAAM users vs. All Users Summary

Summary	Details
Purpose	If a user does not have a sufficient amount of historical data captured this policy will be used to evaluate their current behavior against the historical behavior of all other users. This policy uses pattern-based rules to evaluate risk.
Scoring Engine	Maximum
Weight	100
Group Linking	Linked Users (It is a nested policy)

10.5.4.5.2 OAAM Users vs. All Users Flow Diagram

Figure 10-19 Auto-learning (Pattern-Based) Policy: OAAM Users vs. All Users Flow

10.5.4.5.3 OAAM Users vs. All Users: Details of Rules

Table 10-28 Auto-learning (Pattern-Based) Policy Rules Details: OAAM Users vs. All User

Rule	Rule Condition and Parameters	Results
Users: Day of the week	Pattern (Authentication): Entity is member of pattern bucket less than some percent with all entities in picture Pattern Bucket Hit Percent less than = 5 Pattern name for membership= User: Day of the week profiling pattern Is membership count less than pattern hit percent = true Time period type for pattern membership = Months Time period for pattern membership = 6 Member Type for pattern membership = User	Action = OAAM Challenge Alert = Users: Day of the week Score = 500
Users: Country	Pattern (Authentication): Entity is member of pattern bucket less than some percent with all entities in picture Pattern Bucket Hit Percent less than = 3 Pattern name for membership= User: Country profiling pattern Is membership count less than pattern hit percent = true Time period type for pattern membership = Months Time period for pattern membership = 6 Member Type for pattern membership = User	Action = OAAM Challenge Alert = Users: Country Score = 700
Users: Time of Day	Pattern (Authentication): Entity is member of pattern bucket less than some percent with all entities in picture Pattern Bucket Hit Percent less than = 5 Pattern name for membership= User: Time of day profiling pattern Is membership count less than pattern hit percent = true Time period type for pattern membership = Months Time period for pattern membership = 6 Member Type for pattern membership = User	Action = OAAM Challenge Alert = Users: Time of day Score = 500
Users: Connection type	Pattern (Authentication): Entity is member of pattern bucket less than some percent with all entities in picture Pattern Bucket Hit Percent less than = 5 Pattern name for membership= User: Connection type profiling pattern Is membership count less than pattern hit percent = true Time period type for pattern membership = Months Time period for pattern membership = 6 Member Type for pattern membership = User	Action = OAAM Challenge Alert = Users: Connection type Score = 600
Users: Locale	Pattern (Authentication): Entity is member of pattern bucket less than some percent with all entities in picture Pattern Bucket Hit Percent less than = 3 Pattern name for membership= User: Time of day profiling pattern Is membership count less than pattern hit percent = true Time period type for pattern membership = Years Time period for pattern membership = 6 Member Type for pattern membership = User	Action = OAAM Challenge Alert = Users: Locale Score = 700

10.5.4.5.4 OAAM Users vs. All Users: Trigger Combinations

There are no trigger combinations for this policy.

10.5.5 Registration Policies

Registration policies are summarized in this section.

10.5.5.1 OAAM Registration

This policy is used to determine the user information that needs to be registered.

10.5.5.1.1 OAAM Registration Policy Summary

Table 10-29 OAAM Registration Policy Summary

Summary	Details
Purpose	Determines what parts of user information must be registered
Scoring Engine	Weighted Average
Weight	100
Group Linking	All Users

10.5.5.1.2 OAAM Registration Flow Diagram

Figure 10-20 OAAM Registration Flow

Description of "Figure 10-20 OAAM Registration Flow"

10.5.5.1.3 OAAM Registration: Details of Rules

Table 10-30 OAAM Registration Policy Rules Details

Rule	Rule Condition and Parameters	Results
Check Registration	User: Account Status User Account Status = ACTIVE Is = FALSE	Action = OAAM Register Alert = NONE Score = 0
Register Questions	User: Question Status User Question Status = Set Is = FALSE	Action = OAAM Register Challenge Questions Alert = NONE Score = 0
Skipped registration more than 3 times	User: Action Count Timed Checkpoint (Optional) = NONE Action = Register User Optional In seconds = 300 Count Action only once per session? = TRUE More Than = 3	Required Alert = NONE Score = 0
Register User Information	User: Check Information Key to comma separated values to check = RequiredChallengeInfo If Information is set, return = FALSE	Action = OAAM Register User Information Alert = NONE Score = 0
Register Image and Caption	User: Authentication Image Assigned Is Assigned = FALSE	Action = OAAM Register Preferences Alert = NONE Score = 0

10.5.5.1.4 OAAM Registration: Trigger Combinations

There are no trigger combinations for this policy.

10.5.6 Challenge Policies

Challenge policies are presented in this section.

10.5.6.1 OAAM Challenge

Policy to determine how the user must be challenged. All the decision making in this policy is achieved using trigger combinations.

10.5.6.1.1 OAAM Challenge Policy Summary

Table 10-31 OAAM Challenge Policy Summary

Summary	Details
Purpose	Policy to determine how the user must be challenged. All the decision making in this policy is achieved using trigger combinations.
Scoring Engine	Weighted Average
Weight	100
Group Linking	All Users

10.5.6.1.2 OAAM Challenge Flow Diagram

Figure 10-21 OAAM Challenge Flow

10.5.6.1.3 OAAM Challenge: Details of Rules

Table 10-32 OAAM Challenge Policy Rules Details

Rule	Rule Condition and Parameters	Results
Max failed SMS attempts	User: Check OTP failures OTP Challenge Type = ChallengeSMS Failure More than or Equal To = 3 If above or equal = TRUE	Action = NONE Alert = NONE Score = 0
Max failed Email attempts	User: Check OTP failures OTP Challenge Type = ChallengeEmail Failure More than or Equal To = 3 If above or equal = TRUE	Action = NONE Alert = NONE Score = 0
Max failed Question attempts	User: Challenge Maximum Failures Number of Failures More than or equal to = 3 Current Question Count only? = False If above or equal, return = True	Action = NONE Alert = NONE Score = 0
Questions Active	User: Question Status User Question Status = Set Is = True	Action = NONE Alert = NONE Score = 0
Challenge Email Available	Session: Check value in comma separated values Parameter Key = AvailableChallengeTypes Value to Check = ChallengeEmail Return if in list = True	Action = NONE Alert = NONE Score = 0
Challenge SMS Available	Session: Check value in comma separated values Parameter Key = AvailableChallengeTypes Value to Check = ChallengeSMS Return if in list = True	Action = NONE Alert = NONE Score = 0
Check for HIGH Risk Score	Session: Check Risk Score Classification Risk score classification to check = High Risk Default value to return in case of errors = False	Action = NONE Alert = NONE Score = 0

10.5.6.1.4 OAAM Challenge: Trigger Combinations

Table 10-33 OAAM Challenge Trigger Combinations

Description	Combination Detail	Result
If user is not registered and risk is low then no challenge.	Check for High Risk Score = False Questions Active = False Challenge Email Available = False Challenge SMS Available = False Max failed Question Attempts = Any Max failed Email Attempts = Any Max failed SMS Attempts = Any	Policy = NONE Action = OAAM Allow Alert = NONE Score = 0
If risk score is high and user is registered for KBA challenge and has active questions and has not exceeded maximum challenge failures for KBA, then challenge using KBA.	Check for High Risk Score = TRUE Questions Active = TRUE Challenge Email Available = FALSE Challenge SMS Available = FALSE Max failed Question Attempts = FALSE Max failed Email Attempts = FALSE Max failed SMS Attempts = FALSE	Policy = NONE Action = OAAM Challenge Question Alert = NONE Score = 0
If user is registered for KBA and has active questions then KBA challenge.	Check for High Risk Score = FALSE Questions Active = TRUE Challenge Email Available = Any Challenge SMS Available = Any Max failed Question Attempts = FALSE Max failed Email Attempts = Any Max failed SMS Attempts = Any	Policy = NONE Action = OAAM Challenge Question Alert = NONE Score = 0
If user is registered for OTP via SMS only then OTP challenge via SMS.	Check for High Risk Score = Any Questions Active = Any Challenge Email Available = Any Challenge SMS Available = TRUE Max failed Question Attempts = Any Max failed Email Attempts = FALSE Max failed SMS Attempts = FALSE	Policy = NONE Action = OAAM Challenge SMS Alert = NONE Score = 0
If user is registered for OTP via Email only then OTP challenge via Email.	Check for High Risk Score = Any Questions Active = Any Challenge Email Available = TRUE Challenge SMS Available = Any Max failed Question Attempts = Any Max failed Email Attempts = FALSE Max failed SMS Attempts = FALSE	Policy = NONE Action = OAAM Challenge Email Alert = NONE Score = 0
If user is not registered for any challenge method and risk score is high then block. This block can be overridden using "Temp Allow" functionality	Check for High Risk Score = TRUE Questions Active = FALSE Challenge Email Available = FALSE Challenge SMS Available = FALSE Max failed Question Attempts = Any Max failed Email Attempts = Any Max failed SMS Attempts = Any	Policy = NONE Action = OAAM BLOCK Alert = NONE Score = 0
If user has max failures for their registered challenge methods, then challenge-block (locked out). Note: This block cannot be overridden through "Temp Allow" functionality.	All rules with result = ANY	Policy = NONE Action = OAAM Challenge BLOCK Alert = NONE Score = 0

10.5.7 Customer Care Policies

Customer care policies are presented in this section.

10.5.7.1 OAAM Customer Care Ask Question

This policy determines if the user has active questions, more questions left for the challenge, and how many challenges have failed.

10.5.7.1.1 OAAM Customer Care Ask Question Policy Summary

Table 10-34 OAAM Customer Care Ask Question Policy

Summary	Details
Purpose	Determines if the user has active questions, more questions remaining for challenges, and how many challenges have failed.
Scoring Engine	Weighted Maximum
Weight	100
Group Linking	All Users

10.5.7.1.2 OAAM Customer Care Ask Question: Details of Rules

Table 10-35 OAAM Customer Care Ask Question Rule Details

Rule	Rule Condition and Parameters	Results
No Questions	Triggers when users do not have questions registered. Two possible scenarios are un-registered users and users with questions reset by customer care. User: Question Status Description: Question status of the user User Question Status: Not set Is: True	Action = OAAM No User Questions Alert = none Score = 100
Maximum Answers Failed	Triggers when user failed maximum allowed answers with current question. Count is combination of customer care and online challenge. User: Challenge Channel Failure Description: If a user has a failure counter value over a specified value from specific channel Challenge Channel: Cases or Online Current Question Count only? : True Failures greater than or equal to: 3	Action = OAAM Next Question Alert = none Score = 100
Question Blocked	At least one question is blocked for challenge. User: Challenge Questions Failure Description: Checks how many questions have failures. This condition checks for the total number of failures without the options to count the failure for the current question only or specify the challenge channel used. Failures more than or equal to: 1	Action = OAAM Reset Questions Alert = none Score = 100
Maximum Questions Failed	Checks how many questions have failures User: Challenge Questions Failure Description: Checks how many questions have failures. This condition checks for the total number of failures without the options to count the failure for the current question only or specify the challenge channel used. Failures more than or equal to : 3

10.5.7.1.3 OAAM Customer Care Ask Question: Trigger Combinations

The trigger combination for this policy is as follows:

Table 10-36 OAAM Ask Question Trigger Combinations

Description	Combination Detail	Result
Trigger1	No questions = Any Maximum Answers Failed = True Question Blocked = Any Maximum Question Failure = True	Policy = NONE Action = OAAM Question Care Locked Alert = NONE Score = 0

10.6 Use Cases

The following sections provide security policy use case scenarios.

10.6.1 Use Case: WebZIP Browser

All users using a WebZIP browser must be blocked from attempting a login.

1. user1 uses WebZip and tries to log in to the application.

2. user1 is blocked.

3. The administrator logs in to the OAAM Administration Console.

4. The administrator views the session for user1.

5. The administrator sees that Rule: "WebZIP" used was triggered.

Table 10-37 WebZIP Used Rule

Rule Condition and Parameters	Results
Device: Browser header substring Substring to check = WebZIP Note: WebZip is a source code compressor for web languages, such as HTML, CSS, Javascript, or AJAX. For information, refer to Section 10.6.1, "Use Case: WebZIP Browser."	Action = OAAM Block Alert = OAAM Restricted Software Score =1000

10.6.2 Use Case: IP Address Risky User OTP Challenge

User "test user" is a registered user. He is traveling on business to a different country and does not have access to e-mail or phone. The IP address he logs in from is considered a risky IP address and hence, he is challenged by SMS. Since he cannot access his OTP, he fails to answer the OTP challenge by SMS. He is now challenged via KBA and unfortunately, he forgot the answers to his challenge questions. He guesses and answers the questions incorrectly. He is now locked out of the system. He calls the CSR and proves his identity. The CSR unlocks the user so he can log in again.

1. OTP is set up for SMS and e-mail.

2. The auto-learning policy (OAAM does user have profile) is disabled.

3. The user is registered as User1.

4. His IP address is in the Risky IP address group.

5. User1 tries to log in to the application.

6. User1 is challenged via SMS.

7. User1 answers incorrectly 3 times.

8. User1 is challenged via KBA.

9. User1 answers challenge question incorrectly 3 times.

10. User1 is locked out.

11. CSR must create a case and then unlock challenge questions for the user.

12. User1 can log in to the application successfully.

10.6.3 Use Case: Anonymizer IP Address - From the Group

User "anonymizer" logs in using an IP address which is considered an anonymizer in the Quova geolocation database. The user is blocked and a case is automatically created with the proper information. The investigator works on the case, adds a disposition, and closes the case.

Administrator

1. The administrator logs in to the OAAM Administration Console.

2. He creates a new action instance using the action template "Create customer care case".

3. He selects the "post -authentication" checkpoint, the Block action, a score of "1000," and case type "2".

User

1. New user "anonymizer" tries to log in to the application.

2. The user is blocked.

   A fraud case is automatically created.

Investigator

1. The investigator logs in to the OAAM Administration Console as an Investigator.

2. He opens the case and adds notes.

3. He closes the case with a disposition.

10.6.4 Use Case: Pattern Based Evaluation

User "test user2" is a registered user. He resides in the United States and hence, all his logins are normally from the United States. He is traveling on business to China and performs a few logins from there. Since OAAM identifies that this is not the normal behavior, it challenges the user.

Rules:

• The rule only triggers when the device used appears to have traveled faster than 600 MPH in the last 20 hours. A trigger results in a challenge action and appropriate and informative alerts sufficient enough to determine why the challenge was generated.

• The following rule only triggers a challenge action when both conditions are false: Has this user used this country more than 2 times ever?

  AND

  Has this user used this country more than 10% in the last month?

• If a user is challenged Post-Authentication, and he has KBA active, and he does not have OTP active and the risk is above 600, then he should be asked a KBA question.