Scoring engines are used at the policy and policy set levels. The Policy Scoring Engine is used to calculate the score produced by the different rules in a policy. The Policy Set Scoring Engine is used to calculate the final score based on the scores of policies.
Where there are numerous inputs, scoring is a able to summarize all these various points into a score that decisions can be based on.
This chapter describes how the scoring engine calculates scores.
Oracle Adaptive Access Manager incorporates risk scoring into its decision making. When a user logs in to the online application, Oracle Adaptive Access Manager evaluates dozens of criteria. The transaction is scored according to their level of risk. The scores are then used to calculate a final score. Institutions can determine the level of risk they are willing to accept. Then, all the scores are used to calculate the final score as a summary.
Important term that you should know about are listed in this chapter.
The score is a number configured by the user that is assigned to a rule when the rule evaluates to true. The user can configure a scoring engine that is used to combine the scores of the rules in a policy and assign a score to the policy. The scores from various policies are combined using a policy set level scoring engine.
Higher scores indicate higher risk. The maximum score is 1000. The lowest score is 0, which means that the situation is safe.
The Weighted Scoring Engines 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 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.
Only security policies are available in 11g. Business, third-party, workflow policy types have been removed from Oracle Adaptive Access Manager.
In 11g, all policies will be treated as security policies.
The concept of policy type has been removed from the product. All policies are treated as security policies in 11g.
Checkpoints are the points before and during the session when specific rules are run to evaluate the risk for the user actions. There are multiple policies under one checkpoint. The scores of these policies are used to determine a score for the checkpoint.
Oracle Adaptive Access Manager performs a separate evaluation for each checkpoint and provides a score for each. The score for a particular checkpoint must be between 0-1000.
The checkpoint score is evaluated from the score results of its policies.
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 you want to use for evaluating risk for the 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."
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.
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.
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
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
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.
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.
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.
To determine a risk score, each level applies its scoring engine to the results from one level below.
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.
In Figure 12-1, 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.
Risk scoring (risk assessment) is useful in detecting the probability of fraud or business scenarios and in decision making. Oracle Adaptive Access Manager provides risk scoring at many levels and multiple gateways (checkpoints). From an aggregate of the risk scores, the Rules Engine generates a single, high-level risk score to evaluate the total risk of a transaction.
There are multiple policies under one checkpoint. There are multiple rules under one policy. A score is determined at the policy level and then at the checkpoint level.
The result from the 1st level is used to determine the result for the 2nd level and so on until the final level is reached.
Scores at these levels are determined by applying the scoring engine from these levels to the scores a 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.
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.
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.
Sum of the scores (Score * weight modifier specified by the policy) of all triggered rules divided by the count of all rules
larger score (S * weight modifier specified by the policy) out of all triggered rules
Sum of the scores of all policies within the checkpoint divided by the count of all policies
sum of policies (S* weight multiplier specified by the policy set) within the checkpoint divided by count of all policies
larger score out of all policies (s* weight multiplier specified by the policy set)
This section outlines a few examples on when certain scoring engines are used.
Whether a high score or low score is considered "bad" is dependant on the policy and how the developer models the policy. For example, the higher the score in device policies, the higher the risk for the situation.
For example, if you want "1000" to be considered a "bad" score, use the Maximum scoring engine. Then, model the rules so that whatever generates a maximum score is "bad." For example, you can model the policy such that if a user logs in from a particular location, the score is 200 points, and if a user logs in from a bad device, the score is 500 points. In this case, the one that has the maximum score is considered the worse of the two.
If you do not know how risky a situation is, you can use an aggregate scoring engine. For example, for a device ID, you can apply six or seven rules. For each rule, specify a score of 200 or 300 weight. If you the scores are more than this, it is considered "bad." If there are six rules, and two of them trigger, you would get the lower aggregate. If six rules triggers, you get the higher aggregate, which means that this situation is the riskier.
Use the Average scoring engine when none of the rules are more important than the others or there are a lot of rules that trigger for the evaluation. For example, each rule can look at a particular part of a situation, but each part is not enough for you to base a decision on.
If there are multiple policies in a checkpoint and if the score does not matter for some of the policies, set the rule score to 0 for these policies, so that they will be ignored when scores are aggregated.