| Oracle® Adaptive Access Manager Administrator's Guide Release 10g (10.1.4.5) Part Number E12055-03 |
|
|
View PDF |
| Oracle® Adaptive Access Manager Administrator's Guide Release 10g (10.1.4.5) Part Number E12055-03 |
|
|
View PDF |
Auto-learning is a profiling process in which an administrator defines behavior patterns. These patterns are in turn used by Adaptive Risk Manager to dynamically create and populate buckets based on the pattern parameters.
Adaptive Risk Manager automatically records/maintains the bucket memberships of the users/devices/locations (entities in general) over time so that the profiles created can be used to evaluate risk. Entities—users, devices, and locations—are pattern members, and sometimes referred to as actors.
This chapter will focus on creating and using patterns. Information will also be provided on listing, importing, exporting, and activating and deactivating patterns.
For conceptual information on Auto-learning and patterns, refer to Oracle Adaptive Access Manager Concepts.
This section introduces you to the concept of patterns and how they are used in Adaptive Risk Manager.
Patterns are a composite of traits or features characteristic of an individual or a group. Patterns are created as buckets (groupings of behaviors) by Adaptive Risk Manager.
Adaptive Risk Manager collects data and populates these buckets with members based on pattern parameters. Auto-learning, a feature of Oracle Adaptive Access Manager, profiles transactions and authentications being performed by different actors (entities).
For example, if we want to find out the typical log in times (time of day) for users, we would set up a pattern. The pattern would be set up so that the user is a member and time is a parameter.
We would choose to create a multi-bucket pattern and set start time=00 and endtime=23 (these are hours of the day). We choose to create a multi-bucket pattern since it will create multiple range buckets rather than a single-bucket pattern, which has single data points and value ranges.
When users log in, profiles will automatically be created for each user at log in time. When Adaptive Risk Manager gathers this data for a few days or months, Adaptive Risk Manager can use this data to challenge the user if he logs in at a time at which he does not usually log in.
The Auto-learning feature profiles transactions and authentications being performed by different actors (entities). This process establishes what is normal or average behavior for an individual or a population.
In turn this allows evaluations to be made that can determine if a situation is an anomaly and therefore potentially fraudulent.
The task is accomplished by
capturing the transaction and authentication data and passing it through various patterns thereby creating/populating various buckets to profile behavior in a granular way.
capturing the behavioral and transaction data, based on the actors (entities), and then creating the statistics for the entities based on their memberships to various patterns and hour/day/month/year time samples.
Patterns are created as single-buckets or multi-buckets. Buckets are groupings of behaviors that enables Auto-learning to profile behavior in a granular way.
Single-bucket patterns will create and populate one bucket with the exact data points and value ranges specified in the pattern.
For example, if you choose to create an authentication pattern for users (member type) with the country United States (attribute), exactly one bucket will be created and populated with users. If a user logs in from the United States, he becomes a member of the bucket and his counts are incremented; if he does not log in from the Untied States, his member count is not incremented for this bucket.
Multi-bucket patterns have buckets for sub-ranges of a parameter range. For example, if you choose user logins for a 24-hour range with a step size of 8, there will be 3 buckets for 8-hour time slots in which logins can occur.
To use the Auto-learning feature, you must perform the following procedures.
You must import default entities into your system. Auto-learning data collection and rules will not run properly without them. Default entities are shipped along with Oracle Adaptive Access Manager in the Auth_EntityDefinition.zip file in oaam_init.
To import the entities:
On the Admin menu, point to Entities, then click Import Entities.
Click Browse and locate Auth_EntityDefinition.zip.
Click Import.
Adaptive Risk Manager will show the entities in that file.
Select and import all of them.
Enable Auto-learning so that Adaptive Risk Manager Online/Offline collects data.
Ensure that vcrypt.tracker.autolearning.enabled is set to true.
This property must always be set to true. It is like a "master (on/off) switch" for Auto-learning.
Using the Properties Editor, set the following properties to true:
vcrypt.tracker.autolearning.use.auth.status.for.analysis
This property must be set to true for the auth patterns to work.
vcrypt.tracker.autolearning.use.tran.status.for.analysis
This property must be set to true for all transaction patterns to work.
If the properties are needed and do not exist, create them using the Properties Editor.
Before auto-learning can perform monitoring of transactions and authentications, patterns must be configured and clients must use the correct API for updateStatus. For more information on Auto-learning APIs, refer to "Auto-learning" in the Oracle Adaptive Access Manager Developer's Guide.
Pattern-based Rule Template and related conditions are available out-of-the-box.
For a pattern to be used in Adaptive Risk Manager, you would
Determine what you want Adaptive Risk Manager to watch for (as a potential fraud behavior).
Create the pattern using the Create Patterns user interface.
Refer to the "Creating a Pattern" section.
Configure a Rule Template for patterns (or pick an existing one).
This chapter will provide an example for creating a Rule Template for patterns. Refer to the "Creating a Rule Template for Patterns" section.
Create a Model (or pick an existing Model) that uses patterns.
Pick the Rule Template from step 3.
Select the pattern you want the Rule to act upon.
This chapter will provide an example for creating a Model that uses patterns. Refer to the "Creating a Model that Uses Patterns" section.
Log in to Adaptive Risk Manager.
On the Admin menu, point to Patterns, and then click Create Patterns.
Choose a Transaction Type.
The transaction types shown will be whatever Transaction Definitions have been configured in the specific Adaptive Risk Manager installation. Examples of Transaction Types are authentication, bill pay, money transfer, merchant purchase, credit card, and others. For example, if you pick merchant purchase as the Transaction Type, you want to gather data on the activity of all the members during merchant purchases.
From the Creation Method list, choose which method you want to use to create the pattern.
For Pattern Name, select Create New Pattern.
Type in the pattern name.
The pattern name must be unique.
Choose Status
Active
If data needs to be collected, the pattern must be in the active state.
Inactive
If the pattern is complete, but you don't want to collect data, pick "Inactive."
Incomplete
If pattern creation has started, but you need to save it for completion later, choose "Incomplete." Data is not collected for this state.
Invalid
The administrator may choose to mark the pattern as invalid if he does not want the pattern used. Data is not collected for this state.
Choose Member Type.
The member type is the actor for which data needs to be captured.
Choose a Evaluation Priority
First
The data is evaluated in realtime (highest priority)
Second
The data is evaluated in near-realtime (low priority). If the server has a large system load, the patterns marked as "second" can be skipped. The system load is the number of authentication, transaction, rule processing (and other) reports and requests served by the Oracle Adaptive Access Manager server.
Enter a description.
Click Save
If you try to create a pattern with the same entities as another pattern, a message will appear: "A pattern with the same entity configuration already exists. Are you sure you want to create a new pattern? If you answer "yes," you will be allowed to create the pattern.
Add Attributes
Pick attributes related to the member type. Adaptive Risk Manager will collect data on the attributes to be used in the pattern membership.
For example, if you pick "user" as the member type and the attributes: IP (NNN.N.N.N), City (Redwood City) and Is Registered (False); Adaptive Risk Manager will record when users match all of these attributes. This profiling can then be used to evaluate risk for the "user."
The following attributes are available:
ASN: A unique identifier of an autonomous system on the Internet. Along with other comparators, "for each" is available because if you come from another ASN, you could track that as another bucket. For this attribute, the "equal to" comparator is not available because users will not know the ASN since it is not exposed.
City
Country
Device Id
Group Id
IP: This is the IP address where the authentication is coming in from. It could be the real IP of the user, anonymizer, proxy, or gateway, and so on, to which the end user is connected to.
ISP: The ID for an Internet connection service provider.
Is Registered: This attribute tracks if the user needs to be tracked on the "isRegistered" criterion. So if the user is a registered user (completed registration), he is treated in the pattern one way, and if he is not a registered user (has not completed registration), he is treated another way.
Login Id: User Id
State
Time
Username
Enter the Status.
Active
Data is collected on the attribute. For example, if you have 5 attributes and you want data collected on all of them, all 5 attributes would be in the active state.
Inactive
Data is not collected on the attribute. For example, if you have 5 attributes and you only want to collect data for 2 of them. You would mark the 3 you don't want to collect data on as inactive.
Enter a description.
Enter an order.
Select a compare operator.
The list of compare operators depends on the value of the attribute and the type of pattern (multi-bucket or single bucket) you have chosen.
Enter a value to compare the incoming data with.
For the operators, "Like" and "Not Like," data can be separated with commas.
To be able to use a pattern, you can create a Rule Template with conditions for patterns.
Refer to the Rule Template for detail information on creating a Rule Template and modifying Rule conditions.
Create a Rule with at least one condition for patterns.
For example, you could create a Rule Template with the condition, USER: User is member of pattern N times.
Other Rule conditions for patterns are also available out-of-the-box.
During Rule creation, you can customize conditions if you want.
Parameters for the USER: User is member of pattern N times condition is shown below as an example.
| Label | Name | Default |
|---|---|---|
| Pattern Hit Count More than | patternHitCountForUser | 0 |
| Pattern Name | patternNameForUser | |
| Time period for pattern membership | timePeriod | 1 |
| Time period type for pattern membership | timePeriodType | time.unit.enum.hour |
| Is Membership Count More than patternHitCountForUser | isMoreThan | true |
Labels are the names the client will see in the condition section when he is adding a Rule to a Model. For example, you can change "Pattern Hit Count More than" to "Behavior Count More than."
Names are for internal use to identify the parameter if the label has been changed. Names can also be changed.
Defaults are ones that will be used for the condition if the user does not change them when adding the Rule to a Model. If the defaults are changed, the new values will be seen in the condition section when the user is adding a Rule to a Model.
As an example, the parameter descriptions for the "USER: User is member of pattern N times" condition are provided below:
Pattern Hit Count More than: The number you want to compare your data against. If Pattern appears more than "x" number of times, trigger the Rule.
Pattern Name: The pattern you want to use to profile all specified member types.
Time period for pattern membership: The numeric value to be used in specifying the time range to check the data against for pattern membership. For example, "3" in 3 months.
Time period type for pattern membership: The unit to be used in specifying the time range to check the data against for pattern membership. For example, "months" in 3 months.
Is Membership Count More than patternHitCountForUser: For most cases, if this parameter is set to true, the rule (that the condition belongs to) will trigger if the condition is true. For example, if the condition is for a user to log in from a certain city and you set the pattern hit count as more than 30. If you set the parameter to true, if the condition is met and the hit count has been more than 30, the rule will be triggered. Another example, suppose a user doesn't log in. If the condition is for a user to log in and you set the pattern hit count to be 0. If you set the parameter to false, if the condition is not met and the hit count is 0, the rule will trigger.
When you create the rule template with the conditions, you will have to specify the order in which the condition will be used to check data against.
For example, you may have more than one condition.
The order check box is found in the Create Rule Template page.
For detail information on creating a Model, refer to Chapter 3, "Rules and Models."
To create a Model that uses patterns, you would
Pick a Rule that is used specifically for patterns. For example, a Rule that has the condition, USER: User is member of pattern N times.
Select the pattern you want the Rule to act upon. For example, in the "USER: User is member of pattern N times" section in the Add Rule box, select your pattern from the Pattern Name list.
If you do not like the defaults given in the Conditions section, change them.
As an example, the parameter descriptions for the "USER: User is member of pattern N times" condition are provided in the "Creating a Rule Template for Patterns" section.
Log in to Adaptive Risk Manager.
On the Admin menu, point to Patterns, and then click List Patterns.
Select the criteria you want to filter the patterns on.
Click the Run Query button.
Log in to Adaptive Risk Manager.
On the Admin menu, point to Patterns, and then click Export Patterns.
Select the criteria you want to filter the patterns on.
Click the Run Query button.
Select the pattern you want to export.
Click the Export button.
Click OK.
Click Save To Disk and then click OK.
Log in to Adaptive Risk Manager.
On the Admin menu, point to Patterns, and then click Import Patterns.
Browse for your patterns zip file.
Click the Import button.
To deactivate or activate patterns
Log in to Adaptive Risk Manager.
On the Admin menu, point to Patterns, and then click List Patterns.
Select the criteria you want to filter the patterns on.
Click the Run Query button.
Select the pattern you want to deactivate or activate.
Press the Inactive or the Active button.
When Patterns are disabled, the data collection stops.
Also when rules are executed and the pattern being used by the rule condition is not active, the condition evaluates to false (unless you have configured it to return true).
You should be extremely careful when disabling patterns. The system does not check if the pattern being disabled is used in any model.
To delete a pattern
Log in to Adaptive Risk Manager.
On the Admin menu, point to Patterns, and then click List Patterns.
Select the criteria you want to filter the patterns on.
Click the Run Query button.
Select the pattern you want to deactivate or activate.
Press the Delete button.
Patterns can be deleted only if there is no association with data and rules. If you have an active pattern and it has collected data, you will not be able to delete the pattern.
The following message appears:
There might be pattern data or associated rules using the data and may become out of sync. Are you sure you want to update?
An administrator creates a pattern for behavior-based profiling on time. Adaptive Risk Manager creates buckets through post processing for the behavior.
To find out if Auto-learning pattern analysis is working, follow the steps below:
Make sure you have the default entities set up.
On the Admin menu, point to Entities, then click List Entities. You must see entities like the ones shown below.
If you are not seeing these entities, you will need to import them.
The Auth_Entities.zip file is shipped along with the Oracle Adaptive Access Manager binaries. Locate that file and import it as entities using the Admin->Entities->Import Entities menu.
Make sure the Auto-learning properties are set correctly on your system as described below.
Of particular importance are the following properties:
| Property | Default Value | Property Type | Is Dynamic | Comments |
|---|---|---|---|---|
| vcrypt.tracker.autolearning.enabled | true | Boolean | Yes | Make sure this is set to true. |
| vcrypt.tracker.autolearning.use.auth.status.for.analysis | false | Boolean | Yes | Make sure this is set to true.
This flag is used where client code does not explicitly call the Auto-learning API. So if you want Auto-learning (post processing) to take place but do not want to change the client code; then, setting this flag to true will result in Auto-learning processing for authentication type of updateAuthStatus requests; if the status is success for that auth request. However, if status is not success Auto-learning will not occur anyway. Running Auto-learning rules with this flag set to false will mean that you are running the rules on the data that is stale. |
| vcrypt.tracker.autolearning.use.tran.status.for.analysis | false | Boolean | Yes | Make sure this is set to true.
This flag is used where client code does not explicitly call Auto- learning API. So if you want Auto-learning (post processing) to take place but do not want to change the client code; then, setting this flag to true will result in Auto-learning processing for updateTransactionStatus requests; if the status is success for that transaction request. However if status is not success, Auto-learning will not occur. Running Auto-learning rules with this flag set to false will mean that you are running the rules on the data that is stale. |
|
 Copyright © 2008, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
