| Oracle® Adaptive Access Manager Concepts Release 10g (10.1.4.5) Part Number E12049-03 |
|
|
View PDF |
| Oracle® Adaptive Access Manager Concepts Release 10g (10.1.4.5) Part Number E12049-03 |
|
|
View PDF |
This chapter provides detailed information on Adaptive Risk Manager's Rules and Models.
Adaptive Risk Manager, a core component of Oracle Adaptive Access Manager, enables an enterprise to evaluate and score risk. Oracle Adaptive Risk Manager uses "Rules" to evaluate the traffic running through the system. At Runtime, the specified points in a session where Adaptive Access Manager collects incoming data, and the Rules are run. If the data is evaluated and the specified conditions of the Rule are met, the Rule triggers and a final outcome, such as an action, an alert, or a total score results.
Examples of Runtimes are bill payment, wire transfer, execute trade, request document, and so on.
An Example
If an online grocery store is concerned with customer logins and grocery purchases (two Runtimes), it may create its own grocery Model and customize a set of Rules for this Model.
The grocery store then configures the Rules to trigger during the points in time (customer logins and grocery purchases).
Data is collected and evaluated by Adaptive Risk Manager for possible fraud. If the preconditions set for possible fraud are matched, and the conditions driven by the Rule Template are met, the Rule is triggered.
Based on how the grocery store has configured what it wants for an outcome, an action, an alert, or a total score may result.
The following illustration shows how the Risk Scoring Engine determines actions, scores, and alerts based on Policy.
Concepts and terminology for Rules and Models are provided below.
The following illustration shows the relationship between Rule Templates, Rules, Models, and policies.
Rule conditions are the building blocks for constructing rule templates and make the rule-related functions in Oracle Adaptive Access Manager available to the client. Rule conditions consist of references to various Oracle Adaptive Access Manager objects, APIs (functions), and parameters that are used to evaluate the risk. The parameters could be runtime variables, capture runtime data, time, username, authentication, IP, and so on.
The rule template forms the basis for creating a rule instance. Adding condition instances to rule templates allow you to create the template you need for your use cases. Rule templates must have at least one condition. After you configure a rule template, attach the rule instance to a Model and load it into memory, the rule instance is ready to execute against client data to check fraud activity.
Conditions in the rule template 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 need to 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.
A Rule describes an operation that identifies and reacts to certain information that may indicate fraud.
Rules are housed in Models within a certain Policy and trigger actions, alerts, and scores
A Rule is configured so that it can evaluate the risk involved with the incoming user traffic for specific groups of users or all users accessing the system and trigger an action, an alert, or a final score when all pre-conditions set by the administrator and conditions specific to and driven by the Rule are met.
Each Rule has a name and a valid description. The Rule instance is part of a specific Model and cannot be reused.
The Rule instance has four basic components:
Table 4-1 Rule Instance Components
| Component | Description |
|---|---|
|
Rule Name and Description |
The name and description of the Rule instance. |
|
Preconditions |
Preconditions must be met before continuing on to the actual Rule conditions. |
|
Conditions |
Conditions are specific to the Rule Template. This Conditions section is completely determined by the Rule Template and looks different for the different Rule Templates. |
|
Results |
Results are desired outcomes have been specified to occur when the Rule conditions are met. |
A Runtime is a specified point in a session when rules in a model will run. For example, at pre-authentication, post-authentication, and in-session. Risk can be evaluated at any time specified by a Runtime.
To gain access to sensitive data or transactions a user must successfully pass through multiple security checkpoints.
An action is always used in Rules to specify steps/actions to take for the client application. Standard actions like block, allow, challenge, and others are provided out-of-the-box.
These actions are specified in configuration files and can be added or removed at configuration time.
Alerts are generated by the Rules Engine and typically used for customer care, fraud, and investigational purposes. The Adaptive Risk Manager can also be configured to send alert emails.
The Adaptive Risk Manager provides an interface to view alerts.
The post process is used to determine the final action for the multiple actions that result from Rule processing. Post processing is performed at deployment time using configuration files.
A Group is a collection of related entities that the client wants to monitor.
Examples of different groups are:
User
Location (cities, states, countries, IPs, IP ranges, etc.)
Device
Action (block, challenge, allow, etc.)
Alerts (different messages)
An action group is a group of actions and contains zero or more actions. An action group is typically used to indicate all the actions that need to occur when the Rule is triggered.
An alert group is a group of graded messages that are used as results within Rules so that when a Rule is triggered all of the alerts within the groups are activated.
Score refers to the numeric scoring used to represent the risk level associated with a specific situation. A score is an integer value from 0 to 1000 and one of the outputs for the client application. Models can be configured to generate various scores that a client application can act upon.
Weight refers to the multiplier value applied to the score used to influence the total score at various evaluation levels. The weight is how this Model score is to be weighed compared to other Models in same Policy Type. Weight is only used when a given Policy Type is using a "weighted" Scoring Engine.
Weight is an integer value from 0 to 100.
Risk score is a component of numerous fraud detection inputs, which are weighted and analyzed in real time within Adaptive Risk Manager Engine.
While computing alerts, actions and score, the Model first consults what has been specified for the manual overrides to see if any of the results need to be overridden.
The manual overrides are a way to specify score, alerts and actions based on specific combination of what is triggered and what isn't triggered for the Rule instance.
You can also use a manual override to trigger another Model based on certain conditions. Example Model "m1" has three Rules m1r1, mar2 and m1r3 and consider the following overrides:
| m1r1 | m1r2 | m1r3 | Model/Score | Alert Group | Action Group | |
|---|---|---|---|---|---|---|
| True | False | Any | Score | 900 | ||
| False | False | False | Model | m2 | Alert1 |
When m1r1 is triggered and m1r2 is not-triggered, a score of 900 is generated and all the alerts and actions generated at Rule instance level become part of the Model result.
When m1r1, m2r2 and m3r3 all Rules are not not-triggered new Model "m2" is called. All Alerts generated at the Rule instance level are ignored and alerts in Alert1 group are generated. All actions from the Rule instances are included in the Model result as action group is not overridden in manual override.
A Model is a container for a collection of related rules and is created based on the policy type. The policy type could be for business, security, or a custom category. A Model is an important building block for a Runtime since Models contain all the information needed to generate the score, list of actions, and alerts.
Models can execute at any time during a user's session.
Model Runtimes include:
Pre-Authentication Models-Pre-authentication Models contain Rules that are invoked before the user logs in. For example, the user name might not be available at the time that a Rule is invoked. If so, it can't be used to validate whether the user should be allowed to login from the device he/she is using and/or the location from where the user is trying to login.
Post-Authentication Models-Post authentication Models contain Rules that run after the user enters his/her credentials. These Rules can complement the pre-authentication Rules and are designed to execute after the user attempts to log in.
In-Session/Transaction Models-Rules from In-Session Models are executed during transactions after the user has completed login successfully. For example, an in-session Rule can be used to reevaluate a user if he/she attempts to transfer funds from one account to another.
Model can be linked to all users or a user group from the Run Mode dropdown of the Model Details page. Run Mode provides "All Users" and "Linked Users" as options. The "All Users" option links a Model to all users.
The default is "Linked Users." If there is a group linking in the model to a specific user group, then the linked users selection will denote that the model will only act upon that user group.
Once a Model is linked to all users or a group of users, the Rules will be used to evaluate user activity.
Note:
If there are no group linkings, but "Linked Users" have been selected, then this model will not be executed at all.Model can be linked to a user group or all users.
Each user belongs to one or more groups. When a user is evaluated for a given Runtime, the Rules Engine builds a Policy Set (set of Models of the same type) based on the user group that the user is associated with and the Model that is linked to the user group.
Examples are provided below.
For the examples, assume that there are four Models--m1, m2, m3 and m4--for the "pre-authentication" Runtime.
Model m1 is linked to the user group, "usergroup1," and model m4 is linked to user groups "user group2" and "user group 3". m2 and m3 are linked to "All users."
All Models belong to same Policy Type.
Case 1
When a user u1 that belongs to user group2 and user group3 is evaluated for the "pre-authentication" Runtime, the Rules Engine builds a Policy set with the following Models and evaluates the Policy Set:
m2
m3
m4
Case2
When a user u2 that belongs to user group1 and user group2 is evaluated for the "pre-authentication" Runtime, the Rules Engine builds a Policy Set with the following Models and evaluates the Policy Set:
m1
m2
m3
m4
Case3
When a user u2 that belongs to user group4 is evaluated for the "pre-authentication" Runtime, the Rules Engine builds a Policy Set with the following Models and evaluates the Policy Set:
m2
m3
There are two ways to link a Model to users:
by linking the Model to user groups
by linking the Model to all users
When should you link a Model to a user group or link the Model to all users?
Linking a Model to all users facilitates evaluation because the Model is evaluated for all users. Group linking allows Model evaluation to be targeted. For example, you can run Model "m" for a certain category of users. Linking Models to a user group is particularly useful when a single Adaptive Risk Manager is used for multiple client applications since Models target each application.
For example, Bank A wants to use Adaptive Risk Manager to prevent fraud for their retail banking and also for their loan approval process. In this example, the client applications are "Loan Approval" and "Retail Banking." Bank A can have some Models for Loan Approval and a different set of Models for "Retail Banking."
Policy Type defines a Model. All Models of the same type are grouped as a Policy. Policy Type is mainly used for scoring purposes.
A Policy Set is for logical grouping of policies used to evaluate traffic in order to identify possible risk and to take action to counter fraud.
A Runtime is a specified point in a session when Adaptive Access Manager collects and evaluates security data using the Rules Engine.
Example Runtimes are:
View Check Image
Forgot Password
Forgot Username
User Preferences
Request Secure Document
Edit Records
The Rules Engine returns a Rules result for each Runtime and contains the final action, list of actions, and score. An example of the final action is "block" / "challenge". An example action list is "block, challenge, background check" and an example score is 800. The typical usage is when the client application acts based on the final action. However, it is possible for the client application to see the other actions that are generated and perform different actions based on those. It is also possible for the client application to create Models a certain way in which the Models generate scores and act on these scores.
|
 Copyright © 2008, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
