This chapter introduces you to the terminology and concepts that relate to policies and rules. It describes the flow for the main scenarios in authentication and the policies and rules that are available with OAAM, including the autolearning policies.
This chapter contains the following sections:
The OAAM security and autolearning policies are available as part of the base snapshot or as a separate policy zip file. The oaam_base_snapshot.zip
is located in the Oracle_IDM1/oaam/init
directory of your install. If you want to only import policies, but not the snapshot, import the policies zip file. To import the base snapshot, you need the envAdmin
role assigned. If you are importing policies as a separate file, you need the ruleAdmin
role assigned. These administrative roles are usually exclusive roles, but depending on your deployment needs, both roles can be assigned to the same user.
The OAAM policies address basic registration and authentication flows in OAAM. KBA as a challenge mechanism and images are available when using the OAAM server if you import these policies. All required entities, patterns, conditions, rules, and actions for the basic registration and authentication flows are part of the snapshot.
In 11.1.2, there are 17 policies and 104 rules of the box. The standard policies are active when imported from the snapshot and linked to the user group called Default
. If you have any other groups, you must change the linking accordingly.
This section introduces you to the terminology and concepts that relate to the OAAM security policies.
Rules are used by OAAM to identify suspicious or potentially fraudulent transactions. Security Administrators configure rules so that OAAM knows data to look at for fraud, how to evaluate the data, and the appropriate actions to take after the evaluation.
Fraud rules are used to evaluate the level of risk at each checkpoint. Rules are made up of configurable evaluation statements called conditions. When data comes into the system, OAAM evaluates the conditions based on the input.
The rule is evaluated to True
when all preconditions are met and all conditions evaluate to True
. When a rule is evaluated to True
, a score is triggered, and depending on how the rules in the policies were configured, specified alerts are created and the associated actions are triggered. Examples of actions are ALLOW
, CHALLENGE
, and BLOCK
. The security team might determine that devices found to be exceptionally high risk should be blocked and login attempts should not even be allowed from these devices. Alerts might be sent to Investigators so they can easily see that a velocity rule, such as User appears to have traveled faster than 500 MPH since last login
, was triggered and why.
Other rules can run based on the outcome of other rules. You can implement new rules or edit rules based on new fraud data to fit business needs.
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.
He browses for the policies zip file from the Oracle_IDM1/oaam/init
directory of the install.
He imports it into the system.
For information on browsing and importing policies, refer to Section 11.11.2, "Importing Policies."
Security Administrator Adjusts Rule Parameters of Existing Policies
The Security Administrator searches for the policy.
For information on searching for policies, refer to Section 11.8.2, "Searching for a Policy."
In the policy, he selects a rule and modifies rule parameter.
For information on modifying a rule parameters, refer to Section 11.9.5, "Editing Rule Parameters."
Security Administrator Links User Groups to a Policy to Enable the Policy to Execute for the Set of Users within the Linked Group
The Security Administrator searches for a policy.
For information on searching for policies, refer to Section 11.8.2, "Searching for a Policy."
He links a User ID group to that policy.
For information on group linking, refer to Section 11.4, "Linking a Policy to All Users or a User ID Group."
Security Administrator Models a Fraud Scenario (A Simple Example)
The Security Administrator frames the fraud scenario on paper and identifies the groups, rules, transactions, action groups and alerts for the scenario.
For information on framing the fraud scenario, refer to Section 11.2, "About Discovery and Policy Development."
For information on creating groups, actions and alerts, refer to Chapter 12, "Managing Groups."
For information on creating entities and transactions, refer to Chapter 18, "Modeling the Transaction in OAAM."
He then creates a new policy.
For information on creating policies, refer to Section 11.3, "Creating Policies."
He selects conditions and creates rules that he adds to the new policy. During rule creation he may add transactions to the rules.
For information on creating rules, refer to Section 11.5, "Creating Rules."
For use cases of OAAM Transaction implementations, refer to Section 20.9, "OAAM Transaction Use Cases."
He selects appropriate action groups and alerts for the policy.
For information on adding action groups and alerts, refer to Section 11.5.5, "Specifying Results for the Rule."
Security Administrator Models a Fraud Scenario (A Complex Example)
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.
He creates appropriate action groups and alerts for the policy.
He creates groups that he needs.
For information on creating groups, actions and alerts, refer to Chapter 12, "Managing Groups."
He creates entities that he needs.
For information on creating entities, refer to Chapter 19, "Creating and Managing Entities."
He creates transactions that he needs.
For information on creating transactions, refer to Chapter 20, "Managing Transactions."
He creates configurable actions that he needs.
For information on creating configurable actions, refer to Chapter 16, "Managing Configurable Actions."
He creates the patterns that he needs.
For information on creating patterns, refer to Chapter 15, "Managing Autolearning."
He then creates a new policy.
For information on creating policies, refer to Section 11.3, "Creating Policies."
He selects conditions and creates rules that he adds to the new policy. During rule creation he may add transactions to the rules.
For information on creating rules, refer to Section 11.5, "Creating Rules."
For use cases of OAAM Transaction implementations, refer to Section 20.9, "OAAM Transaction Use Cases."
He selects appropriate action groups and alerts for the policy.
For information on adding action groups and alerts, refer to Section 11.5.5, "Specifying Results for the Rule."
For information on configuring trigger combinations, refer to Section 11.6, "Setting Up Trigger Combinations."
Security Administrator Runs Reports or Queries to Validate Policies
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."
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."
Rules are made up of conditions. Conditions are configurable evaluation statements that are the basic building blocks of decision making in the OAAM rule evaluation process and flow. They use datapoints from historical and runtime data to evaluate risk or business logic. Conditions are grouped based on the type of data used in the condition. For example, user, device, and location. Conditions are pre-packaged in the system and cannot be created by a user. Conditions may take user inputs when adding them to a rule.
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.
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.
The attributes/data elements of the activities you are interested in are mapped to conditions and the evaluations to perform are translated into rules. These rules are added to a policy. Checkpoints are set up in the session for when the policy evaluates the activity. For example, a policy can be executed during the Pre-Authentication checkpoint. The Pre-Authentication checkpoint is a point in time before the user enters the password. When the rules are run, data is collected. For information, see Section 10.4.1, "Authentication Flow." The policy outcomes can be used to enforce decisions by client applications.
A rule evaluates to True when all the conditions match. The outcome of a rule is a score and optionally actions or alerts, or answers and alerts. The outcome of a policy evaluation is decided by applying a scoring policy on the rule scores of the policy. In addition to the score, you can optionally configure trigger combinations which are combinations of rule results of the policy and that can invoke actions and/or generate alerts. For more information about trigger combinations, see Section 10.2.13, "What are Trigger Combinations?."
During the normal course of business, the system looks for data elements the conditions were mapped to. When the set of conditions are met, the system calculates a score, and depending on the policy that you defined earlier for handling the situation, it may generate alerts in real-time, or trigger actions, or both. For example, outcomes can be challenging or blocking the user or activating an alert.
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.
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."
Scoring Engine | Policy | Checkpoint | When to Use |
---|---|---|---|
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. |
|
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. |
|
Sum of the scores for all triggered rules, with 1000 as the maximum score and 0 as the minimum score. |
Sum of the scores of the executed policies with 1000 as the maximum score and 0 as the minimum score. |
Similar to a percentage evaluation for what rules triggered versus the total number of rules. Use this engine when you do not want to score based on any single rule but instead want to make one based on the average level of risk computed based on the number of rules triggered. The rule and policy weights are not used by this scoring engine. Total score of triggered rules divided by the total number of rules. |
|
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. |
|
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. |
|
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. |
|
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. |
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.
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.
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.
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.
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.
Checkpoint = Policy A + Policy B +Policy C
Policy = Rule A + Rule B + Rule C
Policy C = Policy D + Policy F (if nested policies)
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.
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
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.
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
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.
An example of how trigger combinations work is presented in this section. Figure 10-6 shows a trigger combination
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.A nested policy is a secondary policy used to further quantify the risk score in instances where the original result output by the system is inconclusive. Nested policies can be assigned to ensure a higher degree of accuracy for the risk score.
A nested policy in a trigger combination is executed only when a specific sequence of rule results is sent from the primary policy. Nested policies therefore reduce false positives and negatives. You see nested policy being used as an output of a trigger combination.
Nested policies are evaluated. If the trigger combination itself is a policy, the score for the parent policy is retained, and the new policy generates its own score to be used for the evaluation of the checkpoint. If policy1 has two rules, rule1 and rule2, and in the trigger combination, rule1 contains policy2. If the override triggers, rule1 is used to calculate policy1's score, and policy2 is evaluated and used in the evaluation of the checkpoint. In calculating a score for the policy set, the score from policy1 is used and the score from policy2 is evaluated and used for the checkpoint score.
For example the scores for s1 and s2 from two policies are obtained and a scoring engine of policy set is used to determine the checkpoint score. If S1 was 100 and S2 was 300 and policy set specified the scoring engine is Maximum, then 300 will be the outcome of the checkpoint score.
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.
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.
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.
Groups are used in the following ways:
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.
Rules within policies: OAAM Admin applies rules on specified users, devices, or location groups to evaluate whether a fraud scenario occurred and to determine an outcome. A rule can trigger an action group, or an alert group, or both.
Conditions: Some conditions use groups as a parameter type—for example, IP in IP Group
. The condition takes IP Group name or IP as a parameter.
Trigger combinations: Alerts in groups are specified in the trigger combination.
Pre-condition: User groups can be excluded in a policy. 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.
Configurable Actions: Members of a User ID group can be added to a User ID group dynamically using configurable actions.
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.
This section describes how rules and policies are executed in the basic authentication flow.
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.
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.
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."
The checkpoint is a decision and enforcement point when policies are called to run specific rules to evaluate the risk for user actions. OAAM Server uses standard policies and checkpoints to control user flow. API-based integrations can create new checkpoints, configure policies, and drive the flow. There can be multiple policies in the checkpoint.
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.
Actions are used to control the application flow. An action is an event that is activated when a rule is triggered. For example: block access, challenge question, ask for PIN or password, and so on. An action can be also activated based on a score for particular checkpoint.
The client applications like OAAM Server or the native integrated client influence the resultant standard actions. Users may also create custom actions that are used by their policies and applications.
For information on native integration, refer to Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
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."
The Device Max Velocity rule is used to detect man-in-the-middle attacks where a hacker obtains the media access control address (MAC address) for devices that users log in from. Hackers replay the user login and provide the user's computer MAC address. By doing this, they fool the system into thinking the user is logging in from a known and trusted device that is in the user's OAAM profile.
The Device Max Velocity rule can detect this type of attack, trigger an alert, and block the hacker from successfully signing in. This is accomplished in conjunction with the IP geolocation data.
The rule checks to see if the MAC address is in the list of known devices the user is logged in from. Then it examines the IP address location where the user is logged in from. If a hacker then tries to log in by replaying the user's session and also using the user's device MAC address from another location, such as 100 miles away, the rule uses a formula that determines the possibility of that user's device traveling at that velocity.
It is possible for a user to log in to his application, then take a Jet to fly to another city and once again log in to the same application. Therefore, you must be able to adjust the variables of the formula to allow for a portable device to travel at least the speed of a Jet. The Device Max Velocity rule has two values that the administrator can configure. Those value fields are called Last Login Within (Seconds)
and Miles Per Hour is More Than
. Using these two field values you can customize the allotted velocity that a physical device can travel before an alert is triggered.
Note:
Assumptions are:IP geolocation data must have been loaded in the OAAM server.
The user must log in from same device.
The user's authentication status is "success" in the previous login (N seconds ago)
The rule first gets the last successful login in the last N seconds. (If there are multiples, the last one with the highest timestamp is used.
The rule looks at cityLastLogin
and currentCurrentLogin
and calculate the distance between them which equal to the distance
.
Then it calculates thisDistance
divided by the difference in login times. That value is the velocityCalculated
.
If velocityCalculated
is more than velocityConfigured
in the rule (from OAAM Admin), the rule triggers.
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.
Set your Miles Per Hour is More Than
to 54000
Set the Last Login Within (Seconds)
to 60
seconds.
Setting up the Test:
Pick two IP addresses for the test that you know are far away from each other from the IP geolocation data. For example:
172.16.0.0 City1, State1
172.16.1.1 City2, State2
To illustrate this example, let us say, the two cities are a distance of 867 miles apart.
Make sure that the rule is not triggered by logging in twice and not exceeding the Device Max Velocity settings you already set to 60
seconds and 54000
miles per hour. Log in twice with the same user and device with logins no less than 75 seconds apart. Make sure that each time you log in you use a tool like Mozilla Firefox Web Browser "Modify Headers" to change the IP address between log ins using the two IP Addresses mentioned earlier in this section. This simulates a device logging in from two different locations 867 miles apart. The Device Max Velocity alert does not trigger.
Now perform the same test again where you log in twice less than 30 seconds apart, again, changing the IP address between logins. The Device Velocity alert is triggered.
Understanding the relationship between the Miles Per Hour is More Than
and the Last Login Within (Seconds)
settings: You cannot change one of these settings and not consider what the other needs to be set to. In other words, you cannot only set the Mile Per Hour is More Than
setting and not properly adjust the Last Login within (Seconds)
setting. These two settings work together with the formula to calculate a devices velocity. The relationship between these two settings is not an OR
. It is an AND
. Last Login AND
Mile per hour work together. Remember the following two rules before changing these two settings.
You cannot only consider the Miles Per hour
when setting the velocity. You must also consider the Last Login within (Seconds)
setting.
When testing, you must consider and calculate the distance between point A and point B, the time taken to conduct the test, and further factor in the distance between the two points and how long the testing takes. If you want to use one minute as the time allotted for the testing, then make sure you know the distance between point A and Point B. You must also know how long it takes to travel from point A and point B in 60 seconds, again, if you plan to conduct your test in less than one minute.
If the then trigger
setting is set to True
, the rule condition triggers if the condition is met.
If the then trigger
setting is set to False
, the rule condition will only trigger if the condition is not met.
The following conditions will trigger:
If the user comes from Seattle and if the condition parameters are set as follows: then trigger
is True
and city
equals Seattle
.
If the user comes from San Jose and if the condition parameters are set as follows: then trigger
is False
and city
is equal to Seattle
.
The following conditions will not trigger:
If the user comes from San Jose and if the condition parameters are set as follows: then trigger
is True
and city
is equal to Seattle
.
If the user comes from Seattle and if the condition parameters are set as follows: then trigger
is False
and city
is equal to Seattle
.
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
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
The flag is set to false
|
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. |
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
Log in from device from IP1
Log in from the same device from IP2 (which is 60 miles away). There is no alert generated.
Log in from the same device and IP2 (which is 60 miles away). There is no alert generated.
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
Log in from the same device from IP1.
Log in from the same device from IP2 (which is 60 miles away). There is no alert triggered.
Log in from the same device and IP2 (which is 60 miles away). There is no alert triggered.
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
Log in from Device 2108 from IP1.
Log in from Device 2109 from IP2 (which is 60 miles away). Alerts are triggered.
Log in from the same device (Device 2109) and IP2 (which is 60 miles away). No alert is triggered.
This section describes Oracle Adaptive Access Manager authentication, password management, and customer care flows.
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:
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.
Oracle Adaptive Access Manager runs the Device Identification checkpoint to fingerprint and identify the user device and the Pre-authentication checkpoint to determine if the user should be allowed to proceed to the OAAM password page. Does this user need to be blocked? For example, if the session is logging in from a risky IP address or if the device is not to be trusted, OAAM will block the user and take the user to the Lockout page.
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.
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.
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.
If the outcome of Post-Authentication is CHALLENGE, the user is taken to the Challenge page. The Challenge checkpoint is run to determine the type of challenge to run. If the user can answer the challenge (the challenge flow is successful) then he would be allowed to the Registration checkpoint. If he cannot answer the challenge, he can be locked or challenged again. He can also be blocked by the Challenge checkpoint. For example, he does not have KBA, OTP, or appropriate profile registered, but he is not necessarily log in from a good score, depending on registry so far, he actually could be locked or he will be shown the challenge question. If correct he gives the correct answer, he proceeds to the landing page.
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.
New User Authentication and Registration Flows Example
The following screens are used to illustrate these tasks from a new user-experience perspective. The screens are only example as the user interface provided by the OAAM Server Web application can be easily customized to achieve the look and feel of the customer applications. For information, see "Customizing OAAM Web Application Pages" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
The user is presented with a page in which he is asked to submit his user name.
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 user fills in the password and clicks the Enter button on the device. OAAM verifies the user's password.
If the user is not register, he sees a registration information page that describes the registration process.
He can continue through the registration process or "skip" registration and perform the process at another time.
A mobile example is shown to illustrate a mobile friendly page. OAAM provides a base mobile CSS (external stylesheet) file to enable users to view the Web pages on mobile devices. Because significant differences exist between the browsers found on devices supported by OAAM and the native look-and-feel of each device varies greatly, OAAM Server supports a custom override to the mobile CSS. Device-specific CSS can be defined in addition to generic mobile CSS to allow for more fine grade customizations. Mobile devices include iPhone, iPad, Android, Windows Phone, and Blackberry. For information, see "Customizing User Interface for Mobile Devices" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
The non-mobile page shows illustrations for the Security Image and Phrase page and the Security Questions and Answers page.
The mobile page does not show illustrations from the Security Image and Phrase page or the Security Questions and Answers page.
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.
Next the user is required to select challenge questions from the menus (dropdown lists) provided, and enter the answers to those questions. For a non-mobile page, the user enters the answer in the authentication device. Also, the selected image and phrase is embedded in the device along with a current timestamp of his local timezone.
In the mobile Security Questions page, the virtual authentication device does not appear. He enters answers into a field under the question list.
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.
The next time the user tries to log in, he is presented with the user name page in which to enter his user name.
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 user fills in the password and clicks the Enter button on the device. OAAM verifies the user's password.
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.
The user is presented with a page in which he is asked to submit his user name.
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 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 user answers the question correctly and is then logged in to the system.
The Forgot Password flow allows the users to reset their password after successfully answering all challenge questions.
Note:
The Forgot Password feature requires Oracle Identity Manager integration. For more information on Access Manager, Oracle Adaptive Access Manager, and Oracle Identity Manager integration, see Oracle Fusion Middleware Integration Guide for Oracle Identity Management Suite.The forgot password feature is made available as a link from the OAAM password page. The flow starts when the user is at the OAAM password page and clicks the Forgot your password link.
Note:
For a single-login page deployment, the Forgot Password flow is unavailable if the Where is my password link is disabled.The flow is as follows:
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.
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.
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.
Because the user cannot remember his password during the authentication, he clicks the Forgot your password? link below the password authentication device.
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.
If the user answers the challenges incorrectly, he will be challenged again and locked out of his account after "n" number of failed attempts.
If the user provides correct responses, he is redirected to the Password Reset page.
The user enters and confirms the new password. If the user's new password fulfills the password rules, his password is reset.
Challenge Reset enables users to reset their challenge registration.
A mobile device is a device that runs a mobile operating system, such as the iOS mobile operating system from Apple, while a non-mobile device is a device that runs a non-mobile operating system, such as Mac OS X, Windows 7, and Linux desktop. Because mobile devices and non-mobile devices present different security challenges, mobile authentication and non-mobile authentication are managed separately in Mobile and Social. New mobile devices come online much more frequently and therefore require greater scrutiny, including fraud detection measures.
OAAM can be used to make runtime authentication decisions, such as blocking authentication if the user is authenticating from an unauthorized country or location. The following functionality is also supported:
Multi-part login flows: OAAM can challenge the user with knowledge-based authentication (KBA) questions, or require the user to authenticate using one-time password (OTP) functionality if OAAM detects a risky or unusual usage pattern (using the device at unusual hours or if the user is geographically distant from the place where authentication last took place).
Check device attributes (such as the MAC Address assigned to a device) and verify that the device is not jail broken. Based on device attributes, OAAM can allow or deny access.
Device-selective wipeouts are also an option when using OAAM together with Mobile and Social.
Based on registered device information, OAAM can white-list or black-list specific devices.
OAAM comes standard with standard policies pre-built to detect suspicious activity.
Note:
In the tables, bold text is used to indicate parameters driving the outcome of the policies.Table 10-6 presents the OAAM standard checkpoints and policies.
Table 10-6 OAAM Checkpoints and Responsibilities
CheckPoint Name | Responsibilities | Policies |
---|---|---|
Pre-Authentication |
Determine if the request must be BLOCKED |
OAAM Pre-Authentication. For information, see Section 10.5.1.1, "OAAM Pre-Authentication." |
Device Identification |
Determine how to identify the device |
|
AuthentiPad |
Determine which authentication pad to use |
OAAM AuthenticationPad. For information, see Section 10.5.3.1, "OAAM AuthentiPad." |
Post Authentication |
Determine if the user must be ALLOWED or BLOCKED |
|
Registration |
Determine which pieces of user information is pending registration |
OAAM Registration. For information, see Section 10.5.5.1, "OAAM Registration." |
Challenge |
Determine which mechanism to use to challenge the user |
OAAM Challenge. For information, see Section 10.5.6.1, "OAAM Challenge." |
CSR KBA Challenge |
Applicable when customer calls in for service. Reset settings is performed through CSR KBA Challenge. |
OAAM Customer Care Ask Question. For information, see Section 10.5.7.1, "OAAM Customer Care Ask Question." |
Forgot Password |
Activity to reset password performed based on challenge. |
|
Preferences |
Sets the user information (Image, phrase, OTP settings, and so on). |
Pre-authentication policies are summarized in this section.
This policy stops fraudulent login attempts before the password is entered.
Figure 10-11 OAAM Pre-Authentication Flow
The table below shows the rule conditions and parameters in the OAAM Pre-Authentication Policy.
Table 10-8 OAAM Pre-Authentication Policy Rules Details
Rule | Rule Condition and Parameters | Results |
---|---|---|
Blacklisted countries |
Location: In Country group Is In List = TRUE Country in country group=OAAM Restricted Countries |
Action = OAAM Block Alert = OAAM Restricted Country Score = 1000 |
Blacklisted devices |
Device: Device in group Is in group = TRUE Device in group = OAAM Restricted Devices |
Action = OAAM Block Alert = OAAM Restricted Device Score = 1000 |
WebZIP used |
Device: Browser header substring Substring to check = WebZIP Note: WebZip is a source code compressor for web languages, such as HTML, CSS, Javascript, or AJAX. For information, refer to Section 10.6.1, "Use Case: WebZIP Browser." |
Action = OAAM Block Alert = OAAM Restricted Software Score =1000 |
Blacklisted IPs |
Location: IP in group Is in List = TRUE IP List = OAAM Restricted IPs |
Action = OAAM Block Alert = OAAM Restricted IP Score = 1000 |
Blacklisted ISPs |
Location: ISP in group Is in List = TRUE ISP List = OAAM Restricted ISPs |
Action = OAAM Block Alert = OAAM Restricted ISP Score = 1000 |
Blacklisted users |
User: In Group Is in group = TRUE User Group = OAAM Restricted Users |
Action = OAAM Block Alert = OAAM Restricted User Score = 1000 |
The Device Identification policy is summarized in this section.
This policy determines as to which Device ID policy to execute for client device identification.
Figure 10-12 OAAM Base Device ID Flow Diagram
Table 10-10 OAAM Base Device Policy Rules Details
Rule | Rule Condition and Parameters | Results |
---|---|---|
Is Mobile Device |
Device: Check if device is using Mobile Browser Mobile browser group = OAAM Mobile Browser Group The Mobile Browser Group contains names of mobile browsers. Default return value in case of errors = FALSE Device: Browser header substring Substring to check for = OIC Note: You are checking for the substring "OIC". |
Action = None Alert = None Score = 0 |
Table 10-11 OAAM Base Device ID Policy Trigger Combinations
Description | Combination Detail | Result |
---|---|---|
Mobile Device |
Is Mobile Device = TRUE |
Action = None Alert = None Policy = OAAM Mobile Device ID Policy |
Fall through (Is mobile device is not true) |
Is Mobile Device = Any |
Action = None Alert = None Policy = OAAM Device ID Policy |
This policy identifies the mobile devices specific to Oracle Access Management Mobile and Social (Mobile and Social) integrations
Figure 10-13 OAAM Mobile Device ID Flow Diagram
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 |
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 |
The AuthentiPad policy is summarized in this section.
This policy determines the OAAM Authentication Pad to use.
The table below shows the rule conditions and parameters in the OAAM AuthentiPad Policy.
Table 10-16 OAAM AuthentiPad Policy Rules Details
Rule | Rule Condition and Parameters | Results |
---|---|---|
Challenge SMS |
Session: Check value in comma separated values Parameter Key = AvailableChallengeTypes Value to Check = ChallengeSMS Return if in list = TRUE |
Action = OAAM Text Pad Alert = NONE Score = 0 |
Registered Image and Caption |
User: Authentication Image Assigned Is Assigned = TRUE |
Action = OAAM Personalized Pad Alert = NONE Score = 0 |
Key Pad User |
User: Authentication Mode Authentication Mode is = Full Keypad |
Action = OAAM KeyPad Alert = NONE Score = 0 |
Challenge Email |
Session: Check value in comma separated values Parameter Key = AvailableChallengeTypes Value to Check = ChallengeEmail Return if in list = TRUE |
Action = OAAM Text Pad Alert = NONE Score = 0 |
Register Challenge Question |
Session: Check value in comma separated values Parameter Key = AvailableChallengeTypes Value to Check = RegisterChallengeQuestion Return if in list = TRUE |
Action = NONE Alert = NONE Score = 0 |
Check if mobile browser is used |
DEVICE: Check if device is a given type Device Type = Mobile device Return Value when device of given type = TRUE |
Action = NONE Alert =OAAM Mobile Users Score = 0 |
Challenge Question |
Session: Check value in comma separated values Parameter Key = AvailableChallengeTypes Value to Check = ChallengeQuestion Return if in list = TRUE |
Action = OAAM Question Pad Alert = NONE Score = 0 |
Table 10-17 OAAM AuthentiPad Policy Trigger Combinations
Description | Combination Detail | Result |
---|---|---|
Registering challenge questions using mobile browser |
Register Challenge Question = TRUE Check if Mobile Device = TRUE Challenge SMS = FALSE Challenge Email = FALSE Challenge Question = FALSE Registered Image and Caption =Any Key Pad User = Any |
Action = OAAM HTML Pad Alert = NONE Score = 0 |
Registering challenge questions using non mobile browser. |
Register Challenge Question = TRUE Check if Mobile Device = FALSE Challenge SMS = Any Challenge Email = Any Challenge Question = Any Registered Image and Caption =Any Key Pad User = Any |
Action = OAAM Question Pad Personalized Alert = NONE Score = 0 |
Password while upgraded to Key-Pad without registered image. |
Register Challenge Question = FALSE Check if Mobile Device = FALSE Challenge SMS = FALSE Challenge Email = FALSE Challenge Question = FALSE Registered Image and Caption = FALSE Key Pad User = TRUE |
Action = OAAM Key Pad Alert = NONE Score = 0 |
Password while upgraded to KeyPad with registered image. Adds personalized pad sub-action. |
Register Challenge Question = FALSE Check if Mobile Device = FALSE Challenge SMS = FALSE Challenge Email = FALSE Challenge Question = FALSE Registered Image and Caption = TRUE Key Pad User = TRUE |
Action = OAAM Key Pad Personalized Alert = NONE Score = 0 |
Password without registered image |
Register Challenge Question = Any Check if Mobile Device = Any Challenge SMS = FALSE Challenge Email = FALSE Challenge Question = FALSE Registered Image and Caption = FALSE Key Pad User = Any |
Action = OAAM Text Pad Alert = NONE Score = 0 |
Password with registered image. Adds personalized pad sub-action. |
Register Challenge Question = Any Check if Mobile Device = Any Challenge SMS = FALSE Challenge Email = FALSE Challenge Question = FALSE Registered Image and Caption = TRUE Key Pad User = Any |
Action = OAAM Text Pad Personalized Alert = NONE Score = 0 |
This section summarizes the Post-Authentication policies.
This policy evaluates the level of risk after authentication is successful. The possible actions are allow block or challenge.
Figure 10-15 OAAM Post Authentication Security Flow
The table below shows the rule conditions and parameters in the OAAM Post-Authentication Security Policy.
Table 10-19 OAAM Post Authentication Security Policy Rules Details
Rule | Rule Condition and Parameter Values | Results |
---|---|---|
Active Anonymizer |
Location: IP in Group Is in List = TRUE IP in group = anonymizer_active |
Action = OAAM Block Alert = OAAM Active Anonymizer IP Score = 1000 |
Suspect Anonymizer |
Location: IP in Group Is in List = TRUE IP in group = anonymizer_suspect |
Action = OAAM Challenge Alert = OAAM Suspected Anonymizer IP Score = 700 |
Unknown Anonymizer |
Location: IP in Group Is in List = TRUE IP in group = anonymizer_active |
Action = OAAM Challenge Alert = OAAM Unknown Anonymizer IP Score = 600 |
Private Anonymizer |
Location: IP in Group Is in List = TRUE IP in group = anonymizer_private |
Action = OAAM Challenge Alert = OAAM Private Anonymizer IP Score = 700 |
Risky Connection Type |
Location: IP Connection Type in Group Is in List = TRUE Connection type in group = OAAM High Risk Connection Types |
Action = OAAM Challenge Alert = OAAM Risky Connection type Score = 700 |
User Blocked Recently |
User: Action Timed Check Action = BLOCK In seconds = 28800 More than = 2 |
Action = OAAM Challenge Alert = User Blocked Recently Score = 700 |
Maximum Users per Device |
Device: User Count Seconds Elapsed = 2592000 Max number of users allowed = 5 |
Action = OAAM Challenge Alert = OAAM Device Multiple Users Score = 500 |
Dormant IP |
Location: IP Connection type in group Is in List = FALSE Connection type group = OAAM Mobile Connections Location: IP Excessive Use Number of Users = 4 Within (hours) = 24 And not used in days = 30 |
Action = OAAM Challenge Alert = OAAM Dormant IP Score = 500 |
Surge of Users from IP |
Location: IP Connection type in group Is in List = FALSE Connection type group = OAAM Mobile Connections Location: IP is AOL Is AOL = False Location: IP Maximum Users Seconds Elapsed = 300 Max number of users = 3 |
Action = OAAM Challenge Alert = OAAM IP Multiple Users Score = 600 |
Risky countries |
Location: In Country Group Is in List = TRUE Country in country group = OAAM Monitoring Countries |
Action = OAAM Challenge Alert = OAAM Monitored Country Score = 500 |
Dormant Device |
Device: Excessive Use Number of Users = 4 Within (hours) = 24 And not used in (days) = 30 |
Action = OAAM Challenge Alert = OAAM Dormant Device Score = 500 |
Device with Many Failures |
Device: Timed not status Authentication status is not = SUCCESS Within duration (seconds) = 28800 For more than 4 (times) |
Action = OAAM Challenge Alert = OAAM Many Failures from Device Score =600 |
Maximum Devices per User |
User: Check Devices Used Maximum number of devices = 2 Within duration (seconds) = 28800 |
Action = OAAM Challenge Alert = OAAM Max Devices for User Score =300 |
Risky Device |
Device: In List Is in group= TRUE Device in group = OAAM Risky Devices |
Action = OAAM Challenge Alert = OAAM Risky Device Score = 700 |
Device Maximum Velocity |
Device: Velocity from last login Last Login within (Seconds) = 72000 Miles per Hour is more than = 600 |
Action = OAAM Challenge Alert = OAAM Device Maximum Velocity Score =700 |
Risky IP |
Location: IP in group Is in List = TRUE IP List = OAAM Risky IPs |
Action = OAAM Challenge Alert = OAAM Risky IP Score = 700 |
Too many mobile devices |
Device: Check if device is of given type Device Type = Mobile Device Return Value = True DEVICE: Is registered Is Registered then return = False User: Check Number of Registered Devices of a Given Type Number Of Devices = More than Number Of Devices to compare = 4 Device Of Type = Mobile Device |
Action = OAAM Too Many Mobile Devices Alert = OAAM More Mobile devices used than allowed Score = 1000 |
Lost or Stolen Device |
Device: Check if device is of given type Device Type = Mobile Device Return Value = True Device: Device in group Is in group = True Device in group = OAAM Lost or stolen Device |
Action = OAAM Lost Device Alert = OAAM Lost or Stolen Device Score = 1000 |
Jail broken Mobile Device |
Device: Check if device is of given type Device Type = Mobile Device Return Value = True Session: Check string parameter value Parameter Key = isJailBroken Value = true |
Action = OAAM Challenge Alert = OAAM Jailbroken Device Score = 500 |
Hardware Identifier same but Operating System mismatch |
Precondition: Device Risk Score between 599 and 601 Device: Check if device is of given type Device Type = Mobile Device Return Value = True Device: Browser Header Substring Substring = "OIC" |
Action = OAAM Mobile Device OS Mismatch Alert = OAAM Mobile Device with Different OS Score = 1000 |
Mobile device is not registered |
Device: Check if device is of given type Device Type = Mobile Device Return Value = True Device: Is registered If registered then, return = False |
Action = OAAM Challenge Alert = None Score = 300 |
This policy harnesses the predictive capabilities of Oracle Data Miner. The rules in this policy are only functional if Oracle Data Miner is configured.
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 |
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 |
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.
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 |
Figure 10-17 Autolearning (Pattern-Based) Policy: OAAM Does User Have Profile Flow
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 |
Table 10-24 Autolearning (Pattern-Based) Policy: OAAM Does User Have Profile Trigger Combination
Description | Combination Detail | Result |
---|---|---|
If a user has enough recorded behavior in their profile they will be evaluated by this policy |
Does user have profile = TRUE Is enough pattern data available = TRUE |
Policy = OAAM users vs. themselves Alert = None |
If a user does not have enough recorded behavior in their profile they will be evaluated by this policy. |
Does user have profile = ANY Is enough pattern data available = TRUE |
Policy = OAAM users vs. all users Alert = None |
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.
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) |
Table 10-26 Auto-learning (Pattern-Based) Policy Rules Details: OAAM Users vs. Themselves
Rule | Rule Condition and Parameters | Results |
---|---|---|
ISP |
Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 6 Pattern name for membership = User: ISP profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User |
Action = OAAM Challenge Alert = OAAM User: ISP Score = 600 |
Connection type |
Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 6 Pattern name for membership = User: ASN profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User |
Action = OAAM Challenge Alert = OAAM User: connection type Score = 600 |
Routing type |
Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 6 Pattern name for membership = User: Routing type profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User |
Action = OAAM Challenge Alert = OAAM User: Routing type Score = 600 |
Device |
Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 10 Pattern name for membership = User: Device profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User |
Action = OAAM Challenge Alert = OAAM User: Device Score = 700 |
Day of the week |
Pattern (Authentication): Entity is member of pattern bucket for firsttime in certain time period Pattern name for membership = User: Day of Week profiling pattern Is ConditionTrue = True Time period type for pattern membership = Months Time period for pattern membership = 3 Member type for pattern membership = User First time count = 1 |
Action = OAAM Challenge Alert = OAAM User: day of the week Score = 500 |
Country and State |
Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 10 Pattern name for membership = User: State profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User |
Action = OAAM Challenge Alert = OAAM User: state Score = 600 |
Time of Day |
Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 3 Pattern name for membership = User: timerange profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User |
Action = OAAM Challenge Alert = OAAM User: time of day Score = 500 |
ASN |
Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 6 Pattern name for membership = User: ASN profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 1 Member type for pattern membership = User |
Action = OAAM Challenge Alert = OAAM User: ASN Score = 600 |
Country |
Pattern (Authentication): Entity is member of pattern less than some percent times Pattern Hit Percent less than = 20 Pattern name for membership = User: Country profiling pattern Is Membership Count Less than patternHitPercent = True Time period type for pattern membership = Months Time period for pattern membership = 3 Member type for pattern membership = User |
Action = OAAM Challenge Alert = OAAM User: Country Score = 700 |
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.
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) |
Table 10-28 Auto-learning (Pattern-Based) Policy Rules Details: OAAM Users vs. All User
Rule | Rule Condition and Parameters | Results |
---|---|---|
Users: Day of the week |
Pattern (Authentication): Entity is member of pattern bucket less than some percent with all entities in picture Pattern Bucket Hit Percent less than = 5 Pattern name for membership= User: Day of the week profiling pattern Is membership count less than pattern hit percent = true Time period type for pattern membership = Months Time period for pattern membership = 6 Member Type for pattern membership = User |
Action = OAAM Challenge Alert = Users: Day of the week Score = 500 |
Users: Country |
Pattern (Authentication): Entity is member of pattern bucket less than some percent with all entities in picture Pattern Bucket Hit Percent less than = 3 Pattern name for membership= User: Country profiling pattern Is membership count less than pattern hit percent = true Time period type for pattern membership = Months Time period for pattern membership = 6 Member Type for pattern membership = User |
Action = OAAM Challenge Alert = Users: Country Score = 700 |
Users: Time of Day |
Pattern (Authentication): Entity is member of pattern bucket less than some percent with all entities in picture Pattern Bucket Hit Percent less than = 5 Pattern name for membership= User: Time of day profiling pattern Is membership count less than pattern hit percent = true Time period type for pattern membership = Months Time period for pattern membership = 6 Member Type for pattern membership = User |
Action = OAAM Challenge Alert = Users: Time of day Score = 500 |
Users: Connection type |
Pattern (Authentication): Entity is member of pattern bucket less than some percent with all entities in picture Pattern Bucket Hit Percent less than = 5 Pattern name for membership= User: Connection type profiling pattern Is membership count less than pattern hit percent = true Time period type for pattern membership = Months Time period for pattern membership = 6 Member Type for pattern membership = User |
Action = OAAM Challenge Alert = Users: Connection type Score = 600 |
Users: Locale |
Pattern (Authentication): Entity is member of pattern bucket less than some percent with all entities in picture Pattern Bucket Hit Percent less than = 3 Pattern name for membership= User: Time of day profiling pattern Is membership count less than pattern hit percent = true Time period type for pattern membership = Years Time period for pattern membership = 6 Member Type for pattern membership = User |
Action = OAAM Challenge Alert = Users: Locale Score = 700 |
Registration policies are summarized in this section.
This policy is used to determine the user information that needs to be registered.
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 |
Challenge policies are presented in this section.
Policy to determine how the user must be challenged. All the decision making in this policy is achieved using trigger combinations.
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 |
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 |
Customer care policies are presented in this section.
This policy determines if the user has active questions, more questions left for the challenge, and how many challenges have failed.
Table 10-35 OAAM Customer Care Ask Question Rule Details
Rule | Rule Condition and Parameters | Results |
---|---|---|
No Questions |
Triggers when users do not have questions registered. Two possible scenarios are un-registered users and users with questions reset by customer care. User: Question Status Description: Question status of the user User Question Status: Not set Is: True |
Action = OAAM No User Questions Alert = none Score = 100 |
Maximum Answers Failed |
Triggers when user failed maximum allowed answers with current question. Count is combination of customer care and online challenge. User: Challenge Channel Failure Description: If a user has a failure counter value over a specified value from specific channel Challenge Channel: Cases or Online Current Question Count only? : True Failures greater than or equal to: 3 |
Action = OAAM Next Question Alert = none Score = 100 |
Question Blocked |
At least one question is blocked for challenge. User: Challenge Questions Failure Description: Checks how many questions have failures. This condition checks for the total number of failures without the options to count the failure for the current question only or specify the challenge channel used. Failures more than or equal to: 1 |
Action = OAAM Reset Questions Alert = none Score = 100 |
Maximum Questions Failed |
Checks how many questions have failures User: Challenge Questions Failure Description: Checks how many questions have failures. This condition checks for the total number of failures without the options to count the failure for the current question only or specify the challenge channel used. Failures more than or equal to : 3 |
The following sections provide security policy use case scenarios.
All users using a WebZIP browser must be blocked from attempting a login.
user1 uses WebZip and tries to log in to the application.
user1 is blocked.
The administrator logs in to the OAAM Administration Console.
The administrator views the session for user1.
The administrator sees that Rule: "WebZIP" used was triggered.
Rule Condition and Parameters | Results |
---|---|
Device: Browser header substring Substring to check = WebZIP Note: WebZip is a source code compressor for web languages, such as HTML, CSS, Javascript, or AJAX. For information, refer to Section 10.6.1, "Use Case: WebZIP Browser." |
Action = OAAM Block Alert = OAAM Restricted Software Score =1000 |
User "test user" is a registered user. He is traveling on business to a different country and does not have access to e-mail or phone. The IP address he logs in from is considered a risky IP address and hence, he is challenged by SMS. Since he cannot access his OTP, he fails to answer the OTP challenge by SMS. He is now challenged via KBA and unfortunately, he forgot the answers to his challenge questions. He guesses and answers the questions incorrectly. He is now locked out of the system. He calls the CSR and proves his identity. The CSR unlocks the user so he can log in again.
OTP is set up for SMS and e-mail.
The auto-learning policy (OAAM does user have profile) is disabled.
The user is registered as User1
.
His IP address is in the Risky IP address group.
User1
tries to log in to the application.
User1
is challenged via SMS.
User1
answers incorrectly 3 times.
User1
is challenged via KBA.
User1
answers challenge question incorrectly 3 times.
User1
is locked out.
CSR must create a case and then unlock challenge questions for the user.
User1
can log in to the application successfully.
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
The administrator logs in to the OAAM Administration Console.
He creates a new action instance using the action template "Create customer care case".
He selects the "post -authentication" checkpoint, the Block action, a score of "1000," and case type "2".
User
New user "anonymizer" tries to log in to the application.
The user is blocked.
A fraud case is automatically created.
Investigator
The investigator logs in to the OAAM Administration Console as an Investigator.
He opens the case and adds notes.
He closes the case with a disposition.
User "test user2" is a registered user. He resides in the United States and hence, all his logins are normally from the United States. He is traveling on business to China and performs a few logins from there. Since OAAM identifies that this is not the normal behavior, it challenges the user.
Rules:
The rule only triggers when the device used appears to have traveled faster than 600 MPH in the last 20 hours. A trigger results in a challenge action and appropriate and informative alerts sufficient enough to determine why the challenge was generated.
The following rule only triggers a challenge action when both conditions are false: Has this user used this country more than 2 times ever?
AND
Has this user used this country more than 10% in the last month?
If a user is challenged Post-Authentication, and he has KBA active, and he does not have OTP active and the risk is above 600, then he should be asked a KBA question.