10 OAAM Policies Concepts and Reference

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

10.1 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 out of the box policies are active when imported from the snapshot and linked to the user group called Default. If you have any other groups, you need to change the linking accordingly.

Figure 10-1 Policies Search Page

The Policies search page is shown.

10.2 Basic Concepts

This section introduces you to the terminology and concepts and terminology 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 which datapoints and attributes 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?

When data comes into the system, OAAM runs rules against that data. Oracle Adaptive Access Manager evaluates the level of risk for specific situations by analyzing event/transaction and contextual data from a variety of sources, including application data, user profiles, device fingerprints, IP addresses, geolocation, other network data and third-party data feeds. By looking at various risk factors simultaneously Oracle Adaptive Access Manager can determine the relative risk level, alert investigators and in realtime deployments take steps to proactively prevent fraud using challenge methods and blocking.

Rules compare the datapoints and attributes against the conditions. Conditions are configurable evaluation statements. A rule evaluates the conditions and the outcomes of rules are alerts, an action, and a score. The rule is evaluated to True when all preconditions are met and all conditions evaluate to True. When a rule is evaluated to True, specified alerts are created and the associated actions and score are 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.

For conditions that identify high risk traits, you can apply weights to the rules so that they may be considered as being more risky than other rules. 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.9.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.6.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.8.3, "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.6.2, "Searching for a Policy."

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

    For information on group linking, refer to Section 11.3, "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.1, "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.2, "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.4, "Creating Rules."

    For use cases of OAAM Transaction implementations, refer to Section 20.8, "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.7.5.3, "Specifying the Results for a 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.2, "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.4, "Creating Rules."

    For use cases of OAAM Transaction implementations, refer to Section 20.8, "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.7.5.3, "Specifying the Results for a Rule."

    For information on configuring trigger combinations, refer to Section 11.5, "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 they 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

The policy’s structure is shown.

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

The Policy Details Rules tab is shown.

The attributes/databanks 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 datapoints 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 of all triggered rules divided by count of rules.

 

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

This diagram illustrates the levels in 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

A trigger combination is shown.

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

An example of a trigger combination is shown.

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 based on scoring overrides. If the trigger combination itself is a policy, the score for the parent policy is retained, and the new policy gets its own score to be used for the evaluation of the checkpoint. If m1 has two rules, r1 and r2, and in the trigger combination, r1 contains m2. If the override triggers, r1 is used to calculate m1's score, and m2 is evaluated and used in the evaluation of the checkpoint. In calculating a score for the policy set, the score from m1 is used and the score from m2 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 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 out-of-the-box 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

Policies and their checkpoints are shown.

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 out-of-the-box actions. Users may also create custom actions that are used by their policies and applications.

For information on native integration, refer to "Integrating with Virtual Authentication Devices and Knowledge-Based Authentication" and "Building a Custom Application" in 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 MAC address for devices that users log in from. Hackers replay the user's 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 Quova subscription 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 want to 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.

How the Rule Formula Works

  1. The rule first picks up the last successful login in the last N seconds. (If there are multiples, the last one (with the highest timestamp) is picked.

  2. The rule looks at cityLastLogin and currentCurrentLogin and calculate the distance between them which "= the distance."

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

  4. If velocityCalculated is more than velocityConfigured in the rule (from the user interface), 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. You are using the following IP addresses from the Quova data:

63.232.120.161 Austin, Texas

63.229.250.34 Phoenix, Arizona

These 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 Firefox "Modify Headers" to change the IP address between logins 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 get 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 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 OAAM 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 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. 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 is able to answer the challenge (the challenge flow is successful) then he would be allowed to the Registration checkpoint. If he is unable to 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 coming 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

The authentication flow is shown.

New User Authentication Flow Example

The following screens illustrate these tasks from a new user-experience perspective.

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

    The login page is shown.
  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.

    The generic textpad is shown.
  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.

    The registration information page is shown.
  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.

    The profile registration page is shown.
  6. Next the user is required to select challenge questions from the drop-down menus provided, and enter the answers to those questions in the authentication device. His selected image and phrase is embedded in the device along with a current timestamp of his local timezone.

    The Security Questions page is shown.
  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.

    The Sign In page is shown.
  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.

    The password page is shown.
  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.

    The Sign In page is shown.
  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.

    The password page is shown.
  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.

    The question pad is shown.
  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.

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:

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 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 is unable to 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

The Forgot Password flow is shown.

10.4.3 Reset Password (KBA-Challenge) Flow

Challenge Reset enables users to reset their challenge registration.

Figure 10-10 Reset Password

Reset password flow is shown.

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 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 OAAM Security Policies

OAAM comes standard with out-of-the-box 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 out of the box checkpoints and policies.

Table 10-6 OAAM Checkpoints and Responsibilities

CheckPoint Name Responsibilities Policies

Pre-Authentication

Determine if the request has to be BLOCKED

OAAM Pre-Authentication. For information, see Section 10.6.1, "OAAM Pre-Authentication."

Device Identification

Determine how to identify the device

AuthentiPad

Determine which authentication pad to use

OAAM AuthenticationPad. For information, see Section 10.8.1, "OAAM AuthenticationPad."

Post Authentication

Determine if the user has to be ALLOWED or BLOCKED

Registration

Determine which pieces of user information is pending registration

OAAM Registration. For information, see Section 10.10.1, "OAAM Registration."

Challenge

Determine which mechanism to use to challenge the user

OAAM Challenge. For information, see Section 10.11.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.12.1, "OAAM Customer Care Ask Question."


10.6 Pre-Authentication Policies

Pre-authentication policies are summarized in this section.

10.6.1 OAAM Pre-Authentication

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

10.6.1.1 Policy Summary

Table 10-7 summarizes the OAAM Pre-Authentication Policy.

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.6.1.2 OAAM Pre-Authentication Flow Diagram

Figure 10-11 shows the OAAM Pre-Authentication flow.

Figure 10-11 OAAM Pre-Authentication Flow

OAAM Pre-Authentication Block is shown.

10.6.1.3 OAAM Pre-Authentication: Details of Rules

Table 10-8 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 groupName 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.13.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.6.1.4 Trigger Combinations

There are no trigger combinations for this policy.

10.7 Device Identification Policies

The Device Identification policy is summarized in this section.

10.7.1 OAAM Base Device ID Policy

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

10.7.1.1 Policy Summary

Table 10-9 summarizes the OAAM Base Device ID Policy.

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.7.1.2 OAAM Base Device ID Flow Diagram

Figure 10-12 shows the OAAM Base Device ID flow.

Figure 10-12 OAAM Base Device ID Flow Diagram

The OAAM Base Device ID flow diagram is shown.

10.7.1.3 OAAM Base Device Policy: Details of Rules

Table 10-10 shows the OAAM Base Device Policy rule conditions and parameters.

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

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.7.1.4 OAAM Base Device ID Policy: Trigger Combinations

Table 10-11 shows the OAAM Base Device ID Policy trigger combinations.

Table 10-11 OAAM AuthenticationPad 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.7.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.7.2.1 OAAM Mobile Device ID Policy Summary

Table 10-12 summarizes the OAAM Mobile Device ID Policy.

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.7.2.2 OAAM Mobile Device ID Flow Diagram

Figure 10-13 shows the OAAM Mobile Device ID flow.

Figure 10-13 OAAM Mobile Device ID Flow Diagram

The OAAM Mobile Device ID flow diagram is shown.

10.7.2.3 OAAM Mobile Device ID Policy: Details of Rules

Table 10-13 shows the OAAM Mobile Device ID Policy rule conditions and parameters.

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.7.2.4 OAAM Mobile Device ID Policy: Trigger Combinations

Table 10-14 presents the 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.8 Authentipad Policies

The Authentication Pad policy is summarized in this section.

10.8.1 OAAM AuthenticationPad

This policy determines the OAAM Authentication Pad to use.

10.8.1.1 OAAM AuthenticationPad Policy Summary

Table 10-15 summarizes the OAAM AuthenticationPad Policy.

Table 10-15 OAAM AuthenticationPad Policy Summary

Summary Details

Purpose

This policy determines which OAAM Authentication Pad to use.

Scoring Engine

Average

Weight

100

Group Linking

All Users


10.8.1.2 OAAM AuthenticationPad Flow Diagram

Figure 10-14 shows the OAAM AuthenticationPad flow.

Figure 10-14 OAAM AuthentiPad Flow

OAAM Authentication Pad is shown.

10.8.1.3 OAAM AuthenticationPad: Details of Rules

Table 10-16 shows the rule conditions and parameters in the OAAM AuthenticationPad Policy.

Table 10-16 OAAM Authentication Pad 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.8.1.4 OAAM AuthenticationPad: Trigger Combinations

Table 10-17 presents the OAAM AuthenticationPad trigger combinations.

Table 10-17 OAAM AuthenticationPad 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.9 Post-Authentication Policies

This section summarizes the Post-Authentication policies.

10.9.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.9.1.1 OAAM Post-Authentication Security Policy Summary

Table 10-18 summarizes the OAAM Post-Authentication Security Policy.

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.9.1.2 OAAM Post-Authentication Security Flow Diagram

Figure 10-15 shows the OAAM Post Authentication Security flow.

Figure 10-15 OAAM Post Authentication Security Flow

OAAM Post Authentication Security is shown.

10.9.1.3 OAAM Post-Authentication Security: Details of Rules

Table 10-19 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.9.1.4 OAAM Post-Authentication Security: Trigger Combinations

There are no trigger combinations for this policy.

10.9.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.9.2.1 OAAM Predictive Analysis Policy Summary

Table 10-20 summarizes the OAAM Predictive Analysis Policy.

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.9.2.2 OAAM Predictive Analysis Flow Diagram

Figure 10-16 shows the OAAM Predictive Analysis flow.

Figure 10-16 OAAM Predictive Analysis Policy Flow

OAAM Predictive Analysis Policy is shown.

10.9.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.9.2.4 OAAM Predictive Analysis Policy: Trigger Combination

There are no trigger combinations for this policy.

10.9.3 Auto-learning (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.9.3.1 OAAM Does User Have Profile Policy Summary

Table 10-21 summarizes the OAAM Does User Have Profile Policy.

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.9.3.2 OAAM Does User Have Profile Flow Diagram

Figure 10-17 shows the OAAM Does User Have Profile flow.

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

The OAAM Does User Have Profile policy is shown.

10.9.3.3 OAAM Does User Have Profile: Details of Rules

Table 10-23 shows the OAAM Does User Have Profile rule conditions and parameters.

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.9.3.4 OAAM Does User Have Profile: Trigger Combination

Table 10-24 shows the OAAM Does User Have Profile trigger combinations.

Table 10-24 Auto-learning (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 v/s 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 v/s all users

Alert = NONE


10.9.4 Auto-learning (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.9.4.1 OAAM Users vs. Themselves Policy Summary

Table 10-25 summarizes the OAAM Users vs. Themselves Policy.

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.9.4.2 OAAM Users vs. Themselves Flow Diagram

Figure 10-18 shows the OAAM Users vs. Themselves flow.

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

The OAAM Users vs. Themselves policy is shown.

10.9.4.3 OAAM Users vs. Themselves: Details of Rules

Table 10-26 shows the OAAM Users vs. Themselves rule conditions and parameters.

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

Rule Rule Condition and Parameters Results

ISP

ENTITY: 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

ENTITY: 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

ENTITY: 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

ENTITY: 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

ENTITY: 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

ENTITY: 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

ENTITY: 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

ENTITY: 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

ENTITY: 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.9.4.4 OAAM Users vs. Themselves: Trigger Combinations

There are no trigger combinations for this policy.

10.9.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.9.5.1 OAAM Users vs. All Users Policy Summary

Table 10-27 summarizes the OAAM Users vs. All Users Policy.

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.9.5.2 OAAM Users vs. All Users Flow Diagram

Figure 10-19 shows the OAAM Users vs. All Users flow.

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

The OAAM Users vs. All Users flow is shown.

10.9.5.3 OAAM Users vs. All Users: Details of Rules

Table 10-28 shows the OAAM Users vs. All Users rule conditions and parameters.

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

ENTITY: 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

ENTITY: 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

ENTITY: 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

ENTITY: 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

ENTITY: 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.9.5.4 OAAM Users vs. All Users: Trigger Combinations

There are no trigger combinations for this policy.

10.10 Registration Policies

Registration policies are summarized in this section.

10.10.1 OAAM Registration

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

10.10.1.1 OAAM Registration Policy Summary

Table 10-29 summarizes the OAAM Registration Policy.

Table 10-29 OAAM Registration Policy Summary

Summary Details

Purpose

Determines what parts of user information has to be registered

Scoring Engine

Weighted Average

Weight

100

Group Linking

All Users


10.10.1.2 OAAM Registration Flow Diagram

Figure 10-20 shows the OAAM Registration flow.

Figure 10-20 OAAM Registration Flow

The OAAM Registration flow is shown.

10.10.1.3 OAAM Registration: Details of Rules

Table 10-30 shows the OAAM Registration rule conditions and parameters.

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.10.1.4 OAAM Registration: Trigger Combinations

There are no trigger combinations for this policy.

10.11 Challenge Policies

Challenge policies are presented in this section.

10.11.1 OAAM Challenge

Policy to determine how the User has to be Challenged. All the decision making in this policy is achieved using trigger combinations.

10.11.1.1 OAAM Challenge Policy Summary

Table 10-31 summarizes the OAAM Challenge Policy.

Table 10-31 OAAM Challenge Policy Summary

Summary Details

Purpose

Policy to determine how the User has to 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.11.1.2 OAAM Challenge Flow Diagram

Figure 10-21 shows the OAAM Challenge flow.

Figure 10-21 OAAM Challenge Flow

OAAM Challenge flow is shown.

10.11.1.3 OAAM Challenge: Details of Rules

Table 10-32 shows the OAAM Challenge rule conditions and parameters.

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.11.1.4 OAAM Challenge: Trigger Combinations

Table 10-33 shows the 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.12 Customer Care Policies

Customer care policies are presented in this section.

10.12.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.12.1.1 OAAM Customer Care Ask Question Policy Summary

Table 10-34 summarizes the OAAM Customer Care Ask Question Policy.

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.12.1.2 OAAM Customer Care Ask Question: Details of Rules

Table 10-35 describes the OAAM Customer Care Ask Question rule conditions and parameters.

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

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

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

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

Failures more than or equal to : 3

 

10.12.1.3 OAAM Customer Care Ask Question: Trigger Combinations

Table 10-36 shows the OAAM Customer Care Ask Question trigger combinations.

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.13 Use Cases

The following sections provide security policy use case scenarios.

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

10.13.2 Use Case: IP Address Risky User OTP Challenge

User "User1" is a registered user. He is traveling on business to a different country and does not have access to email 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 Email.

  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 is able to log in to the application successfully.

10.13.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.13.4 Use Case: Pattern Based Evaluation

User "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.