1 Introduction

Oracle Adaptive Access Manager provides fraud management in multiple ways. Oracle Adaptive Access Manager and its components effectively reduce fraudulent activities by detecting and providing remedial actions in real time.

Oracle Adaptive Access Manager is composed of two primary components: Adaptive Strong Authenticator (ASA) which provides front-end protection against online identify theft and Adaptive Risk Manager (ARM) which provides real-time, fraud detection.

• Adaptive Strong Authenticator: When a user signs in to a Web site, Adaptive Strong Authenticator can present zero, one, or more challenges to the user. The simplest challenge is a password while more complex challenges are questions selected from a list of pre-answered questions. The answer forms may use a physical keyboard or a virtual keyboard or keypad and mouse to prevent malicious keyboard loggers from intercepting keystrokes.

• Adaptive Risk Manager: When User A signs in to Web site B, Adaptive Risk Manager evaluates several criteria to determine how likely the user is who he or she claims to be. A series of scores are calculated based on factors such as whether this is the user's "normal" terminal, the "normal" IP address, the "normal" time-of-day. Each of the scores is then multiplied by a configurable weight for a total risk assessment. As the level of confidence goes down, a stronger challenge is presented to the user beyond the normal password. Certain sensitive transactions after login might also trigger another challenge to reconfirm that the user has not exited the session. This risk assessment can be performed in real time or offline. The application that is being protected can be either aware of the Adaptive Risk Manager through APIs or not. Certain Web servers can be automatically redirected to use the Adaptive Risk Manager using the Universal Installation Option with no modification of the application code.

The audience for the Oracle Adaptive Access Manager Administrator's Guide includes:

• Fraud Analysts—The fraud analyst identifies potential and existing fraudulent activities that could occur against the organization's online applications and defines the parameters for each potential fraudulent activity.

• Rule Designers—The rules designer groups fraud scenarios into logical models and maps potential fraudulent activity into an implementation design to be used by the rules engineer.

• Rules Engineers—The rules engineer configures the fraud management tool to protect against the potential fraudulent activity, monitors the fraud tool to identify fraudulent attempts and opportunities for optimization, and reports fraudulent attempts.

1.1 Concepts

To get started using Oracle Adaptive Access Manager you need to import or create models and rule templates. You configure new models by creating the component rules, defining manual overrides to control the behavior of the rules, and connecting the models to the target groups. Here's an overview of the component parts of models and rules:

• Auto-learning—Auto learning is a feature that analyzes the behavior of user data coming into the system and profiles (creates digest) of the user's data. This data is then stored in a historical data table and used for calculating the risk based on Rules. The best advantage of Auto-learning is that the system learns the changes in user's behavior and slowly adapts to it when calculating risk.

• Buckets—Auto-learning patterns are used to dynamically create and populate profiling buckets to track behavior and transactions.

• Entity—A referencible data structure that can be used in transaction definitions or directly in patterns.

• Groups—Groups allow you to view and administister a collection of like items as a single group. You should assign each group a unique name. The types of groups you can create include User ID, Login ID, Location, Device, Action, and Alert.

• Model—A model is a set of rules that run at a single time. A model contains configured rule instances (copies of rules) that when linked to a group, are used to evaluate group members. The rules are added to the model, configured, and linked to groups by the administrator. A new rule instance can be added to an existing model at any time. In a model, you can control the timing and combinations of rule firing with manual overrides.

• Patterns—Profiling is configured by the creation of patterns that define the type and amount of data collection to be done.

• Policy—A policy is a collection of models of the same type. The policy types are Security and Business.

• Policy Sets—A policy set is the collection of all the currently configured policies used to evaluate traffic to identify possible risks. As a fail-safe, an action override or a score override can be created for a policy set so that the override is automatically invoked to override a particular action triggered by a rule when a specific set of circumstance occurs.

• Rule Conditions—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.

• Rules—A rule is also known as a rule instance. A rule triggers an outcome. A rule identifies and reacts to certain information. Rules can be used for security or business purposes. Rules can be added to Models, and Models can be applied to a group of users or all users.

• Rule Template—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.

• Runtime—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.

• Scores & Weights—Score refers to the numeric scoring used to evaluate the risk level associated with a specific situation. Weight refers to the multiplier used to influence the total score at various evaluation levels. Weight is only applied to a score when a given Policy Type is using a "weighted" scoring engine.

• Transaction Definition—Application data is mapped using the transaction definition before transaction monitoring and profiling can begin. Each type of transaction Oracle Adaptive Access Manager deals with should have a separate transaction definition.

1.2 Fraud Management Steps

The following steps are best practices for the discovery/planning process. They are not actual steps to be taken in the application's user interface.

1. Identify fraud scenarios and derivative scenarios.

2. Define parameters for each derivative fraud scenario.

3. Group the relevant fraud scenarios, or derivatives, or both.

4. Map parameter and group details into implementation design.

5. Use mappings to configure Oracle Adaptive Access Manager.

1.2.1 Identify Fraud Scenarios and Derivatives

A fraud scenario is a potential or actual deceptive situation involving malicious activity directed at a company's online application. Fraud scenario derivatives are the different sub-scenarios that support the existence of the parent fraud scenario. These fraud scenario and derivatives must be mapped into rules to protect against fraudulent behavior.

To identify a fraud scenario derivative, start by doing the following:

• Identify gated security checkpoints and Runtimes

• Define transaction entities and attributes using data models for each of those Runtimes

1.2.2 Define Parameters for Each Derivative Fraud Scenario

The parameters are the details in the derivatives. These details specifically are the datapoints that are used to compare against a threshold to determine an outcome.

A threshold is the quantitative point at which an action is triggered. For example, a threshold might be ten authentication attempts within 24 hours. An outcome is the response initiated when a threshold is satisfied and a rule is triggered. For example, an outcome might be twofold: an action event activated and an alert message activated.

Datapoints are classified in one of two categories:

• Runtime Datapoints—Runtime datapoints are the entities and attributes that exist in a current transaction.

• Historical Datapoints—Historical datapoints are the entities and attributes that exist in past transactions.

1.2.3 Group the Relevant Fraud Scenarios, or Derivatives, or Both

You first group the fraud scenarios into models and then you assign the models to an Oracle Adaptive Access Manager policy.

1.2.3.1 Grouping Derivatives into Models

Fraud scenario derivatives are grouped into models based on the following considerations:

1. Identify the derivatives that logically fit together:

   • Manageability: derivatives have like policies (for example, application specific).

   • Similarity: derivatives are trying to detect or prevent like fraud instances (for example, Brute Force).

   • Dependencies: derivatives have relationships (for example, if this and this is true do this).

   • Risk: derivatives are evaluated based on previous risk scores.

2. Validate each model based on a single Runtime.

3. Evaluate models to eliminate redundancies.

1.2.3.2 Assigning Models to Policies

After you define the models and assign the fraud scenario derivatives to the models, the models need to be assigned to an Oracle Adaptive Access Manager policy. These Policies include:

• Security Policy—A Security Policy is based on cross-industry best practices.

• Business Policy—A Business Policy is based upon parameters established for mitigation of transaction risk

1.2.4 Map Parameters and Group Details into an Implementation Design

The Implementation Design includes all the fields necessary to configure Oracle Adaptive Access Manager. This requires a mapping of the existing data to the Oracle Adaptive Access Manager fields.

Existing data include:

• Fraud Scenario Derivatives

• Parameters, Thresholds & Outcomes

• Policies & Models

Oracle Adaptive Access Manager fields include:

• Rule Template Name

• Model Name

• Alert Group

• Action Group

• Affected Group(s)

• Score

1.2.5 Use Mappings to Configure Oracle Adaptive Access Manager

Finally the Implementation Design is used to configure Oracle Adaptive Access Manager.

1.3 Knowledge-Based Authentication

Oracle Adaptive Access Manager provides out of the box secondary authentication in the form of knowledge based authentication questions. The KBA infrastructure handles registration, challenge and customer service of questions. KBA challenges can be presented online or over the phone by a customer service representative.

You can extend or customize the base models to support additional business and security requirements. Additionally, models can be easily configured for exceptions.

1.4 Reporting

Limited reporting is available through the Adaptive Risk manager application. In addition, a limited license of Oracle Business Intelligence Publisher is included for customizable reporting capabilities.