17 Managing Autolearning

Autolearning is a set of features in Oracle Adaptive Access Manager that dynamically profile behavior in real-time. The behavior of users, devices and locations are recorded and used to evaluate the risk of current behavior.

This chapter focuses on managing and using the Autolearning features in the following sections:

Introduction and Concepts
Before You Begin to Use Autolearning
User Flows
Navigating to the Patterns Search Page
Searching for a Pattern
Viewing Pattern Details
Creating and Editing Patterns
Importing and Exporting Patterns
Activating and Deactivating Patterns
Deleting Patterns
Using Autolearning Data/Profiling Data
Use Cases
Pattern Attributes Operators Reference

17.1 Introduction and Concepts

This section introduces you to the concepts of autolearning and how they are used.

17.1.1 Autolearning

The Autolearning feature tracks transactions and authentications being performed by different actors based on patterns you create. This process establishes what is normal or average behavior for an individual or a population.

17.1.2 Patterns

Patterns record the behavior of the users, device and locations accessing the system by creating a digest of the access data. The digest or profile information is then stored in a historical data table and used for calculating the current risk using rules.

Patterns require that bucketing, member types, and attributes to be defined. As well, rules must be configured to harness the profiling conducted by the patterns.

Patterns are used by Oracle Adaptive Access Manager to either define one bucket or dynamically create buckets. Oracle Adaptive Access Manager collects data and populates these buckets with members based on pattern parameters, and rules perform risk evaluations on dynamically changing membership and distributions of the buckets. Pattern evaluation and population occurs only when the result of the transaction is successful.

Bucket Creation and Population

Figure 17-1 shows a bucket creation and population example.

Figure 17-1 Login Times

If you want to track employee login times, you would:

Set up a pattern where the member type is User and the attribute is Time.
Choose multi-bucket as the creation method for the pattern. A multi-bucket pattern creates as many buckets as required to capture behaviors as opposed to a single-bucket pattern which only creates one to capture a specific behavior.
Set start time=0:00 and end time=23:59, which are the hours of the day, and a increment step size of 8 hours.

During the processing of the transaction/login data, Oracle Adaptive Access Manager creates the buckets as required and populates them with counts for each member. Each bucket automatically keeps from overlapping with each other based on the other buckets already in the system. As shown in Figure 17-1, Oracle Adaptive Access Manager builds a maximum of 3 buckets with 8-hour periods in which logins have occurred.

For example, if Jeff logs in at 8:27, his counter in the 7:00 and 14:59 bucket is incremented by one. If no user has ever logged into this system between 7:00 and 14:59 then Oracle Adaptive Access Manager also creates that bucket as part of the processing. This 7:00 and 14:59 bucket then is used to record login time behavior for all users going forward.

After creation, the buckets are populated with the logins of users that have fallen within each 8-hour time range.

Oracle Adaptive Access Manager only records that Jeff used this computer if he logs in successfully. This validates that what is recorded is most likely Jeff's real behavior and not a fraudulent attempt to log in using Jeff's credentials. The memberships and associated statistics are saved in each user profile.

17.1.3 Member Types and Attributes

To profile behavior, members and attributes are required.

Members and attributes act as a guide for Oracle Adaptive Access Manager to analyze data. Member is the actor in the system. Examples of actors are user, IP address used for logging in, and so on.

Attributes are the particular pieces of information associated with the activity being tracked. An example is the time of day for a login. Patterns collect data about members. If the member type is User, the pattern collects data about users.

In defining the Pattern you specify which data points you are interested in for the members.

For example, if Joe lives in San Francisco, logs into a protected application from home at 9:00 am on a Friday; City, Time, and Day of Week are attributes associated with the user, Joe. A pattern could be configured to capture all the city, time, and day of the week combinations Joe uses to log in. Or separate patterns could be created for time, city and day of the week to be evaluated together or independently. The configuration you choose is based on the business use cases.

If you are interested in profiling the cities that users log in from, the attribute to profile would be City.

Another example, if you want to track users based on the devices they use, you would set up a pattern with User as the member type since you want to collect information about users. You would then select Device ID as the attribute since you want to know the devices each user is using.

Because members and their attributes are tracked by Oracle Adaptive Access Manager when configured to do so, it is possible to capture complex behavior. However, often times the best practice is to keep the patterns relatively simple in terms of the number of attributes and then use rules to perform complex evaluations involving multiple patterns tracking different attributes. This strategy is more flexible and manageable in the long run.

17.1.4 Buckets

Patterns are configured by an administrator and Oracle Adaptive Access Manager uses that configuration to create buckets as it needs them. Administrators do not deal or see buckets directly in any way.

Patterns are configured to create either one bucket or multiple buckets. Buckets are containers that are used to capture the frequency of behaviors. Rules evaluate the counters in these buckets for specific members to determine if a situation is anomalous.

Single-Bucket

Single-bucket patterns 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 is created and populated with users. If a user logs in from the United States, he or she becomes a member of the bucket and the bucket counts are incremented; if he or she does not log in from the United States, the bucket count is not incremented.

Another example, if you choose to create an authentication pattern for users (member type) with time 8am to 5pm (attribute), exactly one bucket is created and populated with users. If a user logs in from 8am to 5pm, he or she becomes a member of the bucket and the bucket counts are incremented; if the user does not log in between 8am to 5pm, the bucket count is not incremented.

Figure 17-2 Single Bucket
Multi-Bucket

Multi-bucket patterns usually create more buckets than single-bucket patterns. They create buckets as required based on the parameter configurations.

You configure the data types and samples you want Oracle Adaptive Access Manager to generate buckets from, and then during pattern processing Oracle Adaptive Access Manager creates buckets as needed to capture behaviors.

For example:
- If you specify "For each" as the compare operator and country as the attribute, Oracle Adaptive Access Manager creates a bucket dynamically for each country as activity occurs from the country. The first time any user logs in from Canada, Oracle Adaptive Access Manager creates a Canada bucket and adds that user as a member with a count of one. The next user to log in from Canada is added to that same bucket as a member with a count of one. Each subsequent time a user logs in from Canada his Canada bucket counter is incremented.
  
  Figure 17-3 Countries Multi-Bucket
- Buckets are not created until they are needed. If you choose user logins for a 24-hour range with an increment step size of 8 then up to 3 buckets are created, one for each 8-hour time slot in which logins occur.
  
  Figure 17-4 Time Multi-Buckets

17.1.5 Pattern Rules Evaluations

OAAM uses patterns and the buckets they generate to capture the frequencies at which specific behaviors occur for each individual user, device, location, and so on. Since the pattern buckets are updating in real-time rules can be run against them to dynamically determine if the current behavior seems abnormal. The rules evaluations can view either the individual's current behavior versus his past behavior or the individual's current behavior versus the past behavior of all individuals.

The Autolearning feature tracks transactions and authentications being performed by different actors (entities) based on patterns you create. This process establishes what is normal or average behavior for an individual or a population.

Figure 17-5 Bucket Evaluation

This diagram illustrates bucket evaluation

In this example John's login behavior is being evaluated against his own profile and the profile of all users.

Bucket Evaluation Example

In this example a pattern was created to capture user, device and IP login time behavior. The multi-bucket pattern was configured to create buckets to cover the entire 24 hours of the day in four hour samples. Consequently, OAAM ended up creating four time buckets as login activity occurred within each time range.

Buckets	Time Range
Bucket #1	0:00 to 4:59
Bucket #2	5:00 to 8:59
Bucket #3	9:00 to 16:59
Bucket #4	17:00 to 23:59

After a month of recording, the system has created four time buckets and populated them with members and counters for each member. The three entities now have the following bucket memberships.

Entity	Membership
User A	#3
Device X	#2, #3, #4
IP Y	#2, #3

Evaluation of the memberships produces the following conclusions:

Note:

These scenarios are not a sequence; each is a distinct scenario.

Scenarios	Risk
If User A logs in at 3:37 using Device X from IP Y	very high risk (none are in #1)
If User A logs in at 18:07 using Device X from IP Y	medium - high risk (device in #4)
If User A logs in at 8:27 using Device X from IP Y	medium risk (device and IP in #2)
If User A logs in at 11:15 using Device X from IP Y	very low risk (all in #3)

The following paragraph describes the first scenario in more granular detail.

If User A logs in at 3:37 and he has previously only logged in between 9:00 and 16:59 that elevates the risk because he is not a member of the Bucket #1. If Device X is used and it has previously only been used between 5:00 to 23:59 that elevates the risk because User A and Device X are not members of Bucket #1. And, if IP Y is used and it has previously only been used between 5:00 to 16:59 that elevates the risk as well since User A, Device X, and IP Y are all not members of Bucket #1. Since all three of the major components involved in the risk evaluation are not in bucket #1 the overall risk level is very high. It is important to emphasize that each of these elements is evaluated for membership in the time profiles independently in this example.

17.1.6 Bucket Population

Buckets are created, populated and the counters incremented only after the transaction is successful.

Example

Joe logs in from three cities (home, office A and office B). A city pattern records how often he logs in from each.

Bucket	Location
City Bucket #1	home
City Bucket #2	office A
City Bucket #3	office B

Joe's company wants users to be challenged with an OTP two sessions in a row if they are logging in from a city they have not used in the last month. If Joe stops working at office B for 37 days and does not access from anywhere else in that city he is challenged for an OTP the next time he logs in from that city. To accomplish this use case a rule is configured to check on the membership count for the current city bucket in the last month. The count threshold is set to two so the rule triggers until the user has been a member at least twice in the last rolling month window.

17.2 Quick Start for Enabling Autolearning for Your System

The chapter has been organized into sections by topic. If you have used autolearning before, use this chapter effectively in any order that is convenient for you.

If you want profiling and autolearning enabled in your system, follow this procedure:

Make sure entities are imported.

See Section 17.3.1, "Importing Base Authentication-Related Entities."
Enable autolearning properties.

See Section 17.3.2, "Enabling Autolearning Properties."
Import autolearning policies into the server.
Create patterns.

Define patterns, add attributes, and activate /enable the patterns so that the system can start collecting pattern data.

See Section 17.9, "Creating and Editing Patterns."
Finally, use the patterns in rule evaluation.

For information on using autolearning, see Section 17.12, "Using Autolearning Data/Profiling Data."

To verify that autolearning is turned on and working, see Chapter 31, "FAQ/Troubleshooting."

17.3 Before You Begin to Use Autolearning

Before using the Autolearning feature, read through Section 17.1, "Introduction and Concepts." The section is useful in helping you to understand the concepts presented in this chapter.

To use the Autolearning feature, you must perform the following procedures.

17.3.1 Importing Base Authentication-Related Entities

The actors that are tracked during authentication are called authentication entities and include user, city, device, and so on. These base entities are required to enable conditions that are used for patterns. Before you begin using the Autolearning feature, you must import these base entities into your system. Refer to Section 2.6, "Importing the OAAM Snapshot."

To import the entities into the server:

Navigate to the Entities Search page, as described in Section 20.2, "Navigating to the Entities Search Page."
Click Import Entities.
In the Import Pattern dialog, click Browse and locate Auth_EntityDefinition.zip.
Click OK.

OAAM Admin shows the entities in that file.
Select and import all of them.

17.3.2 Enabling Autolearning Properties

Enable autolearning so that OAAM collects profiling data.

Ensure that vcrypt.tracker.autolearning.enabled is set to true.

The default value is true. It is like a "master (on/off) switch" for autolearning.

If this property is absent, this default value is used. If the property is present, the assigned value is used.
Set the following properties to true:

If the properties do not exist, create them.
- vcrypt.tracker.autolearning.use.auth.status.for.analysis
  
  This property must be set to true for the authentication patterns to work. Authentication patterns are the patterns that are used in processing the data relevant to authentication (login) related information only.
- vcrypt.tracker.autolearning.use.tran.status.for.analysis
  
  This property must be set to true for the transaction-related patterns to work. Transaction related patterns are the one that process the transaction related data for autolearning. An example is a pattern that profiles users who are performing wire transfer operations.

17.3.3 Importing Autolearning Policies into the Server

Import the out-of-the-box autolearning policies, refer to Section 2.6, "Importing the OAAM Snapshot."

17.3.4 Using Autolearning in Native Integration

Before autolearning can be used for monitoring of transactions and authentications, native integration clients need to use updateStatus or updateTransaction APIs which use the autolearning flags.Alternatively native integration can also use the processPatternAnalysis API for processing the session data for autolearning.

The API helps to provide OAAM with information about user activity (logins or transactions). For example, updateAuthStatus or updateTransaction is called when a customer login is complete or a login is blocked, and so on.

For the UpdateAuth Status API, an analyzePatterns value of "true" triggers the pattern processing for the login. If no value is passed, a value of false is assumed. If the authentication status value, resultStatus, is "success" and the analyzePatterns value is "true," OAAM processes the users's data and autolearning/profiling data is collected for the user. For any login, autolearning is performed only once if the authentication status is "success." If the authentication or transaction status is not "success," the buckets are not updated. If the buckets are not updated, the data that autolearning rules use may not be accurate.

For information on autolearning APIs, see Appendix B, "Pattern Processing."

17.4 User Flows

User flows are presented for:

Creating a New Pattern
Editing a Pattern

17.4.1 Creating a New Pattern

These steps describe the Create New Pattern flow:

Search for a pattern.
If pattern exists, view pattern details.
If pattern does not exist, create new pattern.
Specify pattern name, member type, evaluation priority, and description.
Add attributes.

If there are no validation errors, the new Pattern is created successfully.

17.4.2 Editing a Pattern

The following steps describe the Edit Pattern flow.

Note:

If you edit a Pattern the data that is already collected based on that pattern could potentially become unusable. For example, if a user edits a Pattern and removes one of the attributes, the data that was collected previously may not be usable since the buckets created in the past for this Pattern would have taken into account the attribute that is now being removed.

Search for a pattern.
If Pattern exists, view pattern details.
Change details.
Add attributes.

If there are no validation errors, the pattern is edited successfully.

17.5 Navigating to the Patterns Search Page

To navigate to the Patterns Search page:

In Fraud Prevention, expand the Navigation tree.
Double-click Patterns.

The Patterns Search page is displayed with results based on the default search criteria.

Alternative methods to open the search page are listed in Section 3.9, "Search, Create, and Import."

The Patterns Search page is the starting place for managing your patterns. From the Patterns Search page, you can:

search patterns
view a list of patterns
create new patterns
delete patterns
activate patterns
deactivate patterns
import patterns
export patterns

17.6 Searching for a Pattern

To search for a Pattern:

Navigate to the Patterns Search page, as described in Section 17.5, "Navigating to the Patterns Search Page."

An example Patterns Search page is shown in Figure 17-6.

Figure 17-6 Patterns Search Page

The Pattern Search page displays a Search section and a Results table that shows a summary of the patterns that match your search criteria.

Specify criteria in the Search Filter to locate the pattern and click Search.

The search filter criteria are described in Table 17-1.

If you want to reset the search parameters to the default setting, use the Reset button.

Table 17-1 Search Filter Criteria

Field	Description
Pattern Name	The name of the pattern. You can enter the complete name or part of a Pattern name.
Evaluation Priority	The priority in which the collected data is evaluated. High Most of the resources are assigned for the data to be evaluated. Low The resources assigned to data evaluation is half as much as the High priority.
Pattern Status	The state of the pattern. These are the pattern states: Active If data must be collected, the pattern must be in the active state. Inactive If the pattern definition is complete, but you do not want to collect data, select "Inactive." Incomplete If pattern creation has started, but you need to save it for completion later, select "Incomplete." Data is not collected for this state. Invalid If there is a problem with the pattern, you can mark the pattern as invalid to signal other operators. No autolearning data analysis is performed for a pattern in this state. Deleted The pattern has been deleted, but system must keep this record to maintain data integrity. No autolearning data analysis is performed for the pattern in this state. It is recommended that you do not use the Deleted status. This status may not be available in future releases.
Transaction Type	The Transaction Definitions that have been configured in this specific Oracle Adaptive Access Manager installation. The type of process such as authentication (login), bill pay, wire transfer, address change, and so on that autolearning is profiling entities for.
Creation Method	The type of bucket the Pattern had been created as. Single Bucket - Single-bucket patterns create and populate one bucket with the exact data points and value ranges specified in the pattern Multi- Bucket – Multi-bucket patterns have buckets for sub-ranges of a parameter range

The Search Results table displays a summary of patterns that match the criteria specified in the Evaluation Priority, Pattern Name, Pattern Status, and Transaction Type fields.

If you want the summary to include the creation method, select Creation Method from the additional fields list under the View drop-down list.

Clicking the Pattern column header sorts all the pattern names in ascending or descending order. Sorting is available for all columns.

A tool tip is available to display the complete description of a pattern if the description is not shown fully in the user interface.

17.7 Navigating to the Patterns Details Page

Follow these steps to navigate to a Pattern Details page.

If you are not on the Patterns Search page, follow the instructions in Section 17.5, "Navigating to the Patterns Search Page."
Search for the pattern of interest, by following the instructions in Section 17.6, "Searching for a Pattern."

There is a link on the pattern name in the Search Results table.
Click the pattern name and the Pattern Details page for the specific pattern appears.

From Pattern Details, you can select the member type and change the pattern name, pattern status, evaluation priority, and description after the pattern is created; add attributes, and view the pattern usage points.

17.8 Viewing Pattern Details

This section provides details on viewing patterns.

17.8.1 Viewing Details of a Specific Pattern

By clicking the pattern name on the Patterns Search page, the Pattern Details page for the specific pattern appears. For instructions, see Section 17.7, "Navigating to the Patterns Details Page."

The Pattern Details page provides such general details about the pattern as the pattern name, status, member type, evaluation priority, and description.

The Pattern Details page provides the following three tabs:

Summary - General details such as pattern name, status, transaction type, and so on
Attributes - Displays attribute details such as definition, status, description and so on.

The number of attributes are displayed in the tab (in parenthesis).

17.9 Creating and Editing Patterns

This section explains how to create and edit patterns. It contains the following topics:

Creating a Pattern
Editing the Pattern
Adding Attributes
Editing Attributes
Deleting Attributes

17.9.1 Creating a Pattern

Best Practices for Autolearning and Pattern Creations

Best practices for autolearning and pattern creations are:

For autolearning configurations: Administrators should keep in mind that any tracking of behavior warrants computational power and storage space and be prudent in configuring the system for the most returns on the efforts.
Best practices for pattern creation: When creating patterns, you must ensure that other patterns in your system are not already collecting the same kind of information. For example, if you create a pattern to collect login time information on user and IP, and then you create another pattern on user and login time, you are creating two patterns that are collecting the same information.
Best practices to keep Oracle Adaptive Access Manager current and relevant given the evolving online security threats: autolearning technology automatically adjust to changing activity and behaviors. For example, autolearning profiles what normal behavior is for each user and all users. In this way security policies are dynamically adjusting in real-time to how users really acts rather than a guess at how they will act. In addition to the automated features it is recommended that security policy be reviewed on a regular basis to make sure they are behaving as expected.
For heavy pattern usage: You might assign different evaluation priorities to various patterns. For example, you can set login patterns to High and other patterns to Low.
For evaluation property: Ensure that you do not set "High" as the evaluation priority for all your patterns, since performance will be impacted by doing so.

Procedure to Create a New Pattern

Follow this procedure to create a new pattern.

All values except transaction type can be modified later in the Pattern Details page.

Transaction type, Creation Method, Member Type, Evaluation Priority, and Description are required fields.

Navigate to the Patterns Search page, as described in Section 17.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, click the New Pattern button or the New icon.

Alternative methods to open the New Pattern page are listed in Section 3.9, "Search, Create, and Import."
In the New Pattern page, enter the pattern name.

A unique pattern name must be entered.
Select the transaction type.

The default transaction type is Authentication.

Other transaction types shown are the transaction definitions that have been set up in your system.

Only active transaction types are available in the list.

Examples of transaction types are authentication, bill pay, money transfer, merchant purchase, credit card, and others. For example, if you select 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, select the method you want to use to create the pattern.
- Single-Bucket
- Multi-Bucket
Select a member type.

The member type is the actor for which data must be captured.

For example, if you select city as the member type, the pattern created collects city data.

Member type list values depend on the transaction type selected.

If the Transaction Type selected is Authentication, member types available are User, City, State, Country, and others.

If, the Transaction Type selected is any transaction from the database, for example, Retail Commerce, Internet, Bill Pay, the member types available are data elements for that transaction. For example, if the Transaction Type is Internet Banking, the member type data elements could be customer and bank name.

One or more member types can be selected for a pattern
Select a evaluation priority

Evaluation priority is the priority in which data is evaluated. There are two evaluation priorities: High and Low.:
- High
  
  There is double the amount of resources made available to process the pattern data in this category as compared to the "Low" priority.
  
  Resources include processing resources and database resources.
- Low
  
  There is half the amount of resources made available to process the pattern data in this category as compared to the "High" high priority.
The chances for finishing the processing of high priority pattern data are doubled the chances for finishing the low priority patterns.
Enter a description.
Click Apply.

Figure 17-7 New Pattern

The Pattern Details page is opened with the Summary and Attributes tabs.

If you try to create a pattern that already exists in the database, an error occurs.

If you try to create a pattern with the same members as another pattern, a message appears: "A pattern with the same member configuration already exists. Are you sure you want to create a new pattern? If you answer "yes," you are allowed to create the pattern.

The pattern is enabled upon creation and the Pattern Details page is displayed. You can edit or review the pattern.

Patterns can be created without any attributes.
Add attributes.

Figure 17-8 Add Attribute

For information, see Section 17.9.2, "Adding Attributes."

For information on attributes, see Section 17.1.3, "Member Types and Attributes."
Activate the pattern.

To activate the pattern, see Section 17.9.3.1, "Activating Patterns."

To use the patterns in rule evaluation, see Section 17.12, "Using Autolearning Data/Profiling Data."

To verify that autolearning is working, see Chapter 31, "FAQ/Troubleshooting."

17.9.2 Adding Attributes

For information on attributes, see Section 17.1.3, "Member Types and Attributes."

Follow these steps to add attributes.

If you are not on the Pattern Details page of the pattern, follow the instructions in Section 17.8.1, "Viewing Details of a Specific Pattern."
In the Attributes tab, click the Add button in the Search Results toolbar.
In the Add Attributes dialog, select an attribute or attributes from the Add list.

Select attributes (data points) you are interested in for the member type. OAAM collects data on the attributes to determine if the member belongs to the profile.

For example, if you select "user" as the member type and the attributes: IP (NNN.N.N.N), City (Redwood City) and Is Registered (False); OAAM records when users match all of these attributes--the user has an IP address of NNN.N.N.N, who lives in Redwood City, and who is not registered. This profiling can then be used to evaluate risk for the "user."

For example, if you want OAAM to track the login times for "user" and "IP" (member type), you would select "time" as an attribute.

After the attributes are added, they are not available in the list for further selection.
Specify the condition information for the attribute.
1. Select the Status.
  
  For example, "Active" if you want OAAM to collect data on the attribute to be used in the pattern membership.
2. Enter the description.
  
  For example, "This pattern creates buckets to track login times for users and IPs."
3. Select a compare operator.
  
  For example, "range" with start value of 0 and end value of 23 if you want to collect data for a range of 24 hours.
  
  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.
  
  For detailed information about compare operators, see Section 17.19, "Pattern Attributes Operators Reference."
4. Enter Increment Step.
  
  The sample size (interval)
  
  For example, 2 for 2 hour intervals.
5. Click Add.
In the Attributes tab, use the arrow controls to reorder the attributes if you want.

Order is not required and is automatically pre-filled.
Click Apply.

A dialog appears, with the message that the attribute was added successfully to pattern.
Click OK to dismiss the dialog.

17.9.3 Activating and Deactivating Patterns

This section explains how to activate and deactivate patterns.

If you select an active pattern, you have the option to deactivate it. Whereas if you select an inactive pattern, you have the option to activate it.

17.9.3.1 Activating Patterns

To activate patterns:

Navigate to the Patterns Search page, as described in Section 17.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, enter the search criteria you want and click Search. For information, see Section 17.6, "Searching for a Pattern."
Select the row for each pattern you want to activate.
Press the Activate button.

17.9.3.2 Deactivating Patterns

You should be extremely careful when disabling patterns. The system does not check to see whether the pattern being disabled is used in any policy.

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).

To deactivate patterns:

To deactivate a pattern, from the Patterns Search page select the row for each pattern you want to deactivate and press the Deactivate button.
To deactivate a pattern from the Pattern Details page, press the Deactivate button.

17.9.4 Editing the Pattern

Care should be taken when editing patterns. Potentially, data that is already collected based on that pattern may no longer be usable after the edit.For example the data would be unusable if you remove one of the attributes and the buckets created in the past for the pattern had taken into account the attribute that is being removed.

To edit the details of a specific pattern:

If you are not on the Pattern Details page of the pattern you want to edit, follow the instructions in Section 17.7, "Navigating to the Patterns Details Page."
To change the pattern name, evaluation priority, and description, edit the appropriate fields in the Summary tab of the Pattern Details page.
To change the status, select from the status you want.

To change the status of the pattern, see Section 17.9.5, "Changing the Status of the Pattern."
Add or change the member types.

For information, see Section 17.9.6, "Adding or Changing Member Types."

For information about member types, see Section 17.1.3, "Member Types and Attributes."
Change the evaluation priority

To change the evaluation priority, see Section 17.9.7, "Changing the Evaluation Priority."
To add attributes, see Section 17.9.2, "Adding Attributes."

For information on attributes, see Section 17.1.3, "Member Types and Attributes."
To edit attributes, see Section 17.9.8, "Editing Attributes."
To delete attributes, see Section 17.9.9, "Deleting Attributes."
Click Apply.

17.9.5 Changing the Status of the Pattern

Active is the default status of the pattern, but you can change the status to one you want.

These are the pattern states:

Active

If data must be collected, the pattern must be in the active state.
Inactive

If the pattern is complete, but you do not want the pattern to collect data, select Inactive.
Incomplete

If the pattern has been created, but you are not ready to decide what attributes to choose yet, select Incomplete. Data is not collected for this state.
Invalid

If you do not want the pattern to be used, select Invalid. Data is not collected for this state.
Deleted

The pattern has been deleted, but the system must keep this record to maintain data integrity. No autolearning data analysis is performed for a pattern in this state.

Note:
It is recommended that you do not use the Deleted status. This status may not be available in future releases.

17.9.6 Adding or Changing Member Types

You can select more than one member type to add or change.

If you try to select the same members as another pattern, a message appears: "A pattern with the same member configuration already exists. Are you sure you want to create a new pattern? If you answer "yes," you are allowed to create the pattern.

For information on member type, see Section 17.1.3, "Member Types and Attributes."

Follow these steps to add or change member types.

If you are not on the Pattern Details page of the pattern, follow the instructions in Section 17.7, "Navigating to the Patterns Details Page."
In the Summary tab, add or change the actor you want to capture data.

For example, user is the member type if you want to collect information about the user.

17.9.7 Changing the Evaluation Priority

Follow these steps to change the evaluation priority.

If you are not on the Pattern Details page of the pattern, follow the instructions in Section 17.7, "Navigating to the Patterns Details Page."
In the Summary tab, change the evaluation priority.

17.9.8 Editing Attributes

Follow these steps to edit attributes.

Click the Attributes tab of the Pattern Details page.

If you are not on the Pattern Details page of the pattern you want to edit, follow the instructions in Section 17.8.1, "Viewing Details of a Specific Pattern."
In the Attributes page, select the attribute you want to edit.
Edit the attribute details and click Save.
Reorder the attributes if you want.
Click Apply.

17.9.9 Deleting Attributes

Care should be taken when deleting attributes. For example the data would be unusable if you remove one of the attributes and the buckets created in the past for the pattern had taken into account the attribute that is being removed.

Follow these steps to delete attributes.

Click the Attributes tab of the Pattern Details page.

If you are not on the Pattern Details page of the pattern you want to edit, follow the instructions in Section 17.8.1, "Viewing Details of a Specific Pattern."
In the Attributes page, click the checkbox next to the Attribute(s) you want to delete from the pattern.
Click Delete.

If you delete an attribute, it is added to the Add list and becomes available the next time you select Attributes.

17.10 Importing and Exporting Patterns

You may want to import and export patterns from other applications. This section explains how to import and export patterns.

17.10.1 Importing Patterns

To import patterns:

Navigate to the Patterns Search page, as described in Section 17.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, click Import Pattern.
In the Pattern Import dialog, click Browse and locate the pattern file you want to import.
Click OK.

You cannot create your own pattern import files. There is an extension ".zip" that is used when patterns are exported and only files in zip formats can be used. Other files, such as .xml files cannot be imported as patterns import files.

17.10.2 Exporting Patterns

To export patterns:

Navigate to the Patterns Search page, as described in Section 17.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, enter the search criteria you want and click Search. For information, see Section 17.6, "Searching for a Pattern."
Select the row for each pattern you want to export.
Select Export Selected from the Actions menu.
In the Export Patterns dialog, click Export.
In the Save dialog, click OK.

17.11 Deleting Patterns

If you have an active pattern and it has collected data, you are not allowed to delete the pattern.

Patterns can be deleted only if there is no association with data and rules. A message appears, saying: "There might be pattern data or associated rules using the data and may become out of sync. Are you sure you want to update?"

When multiple patterns are selected for deletion and if some of the patterns are used or linked to other systems, a warning message appears, stating: "The following instances are linked and cannot be deleted. Do you want to delete the other patterns?" If you answer "yes", the unlinked patterns are deleted.

To delete patterns:

Navigate to the Patterns Search page, as described in Section 17.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, enter the search criteria you want and click Search. For information, see Section 17.6, "Searching for a Pattern."
Select the row for each pattern you want to delete and press the Delete button.

If the patterns selected for deletion are not used or linked to a policy, a warning message is shown asking for confirmation. If you answer "yes", those patterns are deleted.

17.12 Using Autolearning Data/Profiling Data

After you have configured patterns (created buckets with members and attributes), activated them, and started collecting data, you are ready to use autolearning.

Setting up OAAM to process autolearning data is described in the following subsections.

17.12.1 Create a Policy that Uses Autolearning Conditions

Create a policy that uses the autolearning conditions.

For instructions to create a policy, see Section 17.13.1, "Use Case: Challenge Users If Log In Different Time Than Normally."

17.12.2 Associate Autolearning Condition with Policy

For the autolearning condition, associate the pattern you created and modify the condition parameters per your requirements.

There are conditions specific to autolearning that use the collected profiling data to perform certain calculations. These conditions are only applicable to autolearning profiling data and cannot be used for other risk analysis.

For information, see Section 17.13.4, "Use Case: User Logs in During a Certain Time of Day More Than X Times."

The rule evaluates the pattern you selected and autolearning processing is performed.

To learn more about autolearning conditions, see Appendix C, "Conditions Reference."

17.12.3 Check Session Details

Perform logins/transactions and check the session details to make sure that the policy that was created triggers and data is collected for patterns and buckets.

For information on how to find out whether the pattern is working properly, see Section 17.13.2, "Use Case: Test a Pattern."

17.13 Use Cases

This section describes example use cases for autolearning and patterns.

17.13.1 Use Case: Challenge Users If Log In Different Time Than Normally

Jeff is a Security Administrator at Dollar Bank. He wants to challenge users with an OTP if they are logging in at a time of day they do not normally come in. To do this he must configure a security policy and associated groups, rules and patterns.

Jeff starts with the pattern. He performs a search for patterns that have users as members since his use case focuses on the behavior of users.

He sees there are two patterns that have users as members. Neither of them has a time range attribute that works for his use case so Jeff must create a new one.
Jeff creates a multi-bucket login checkpoint pattern with "user" member type and first evaluation priority. He then adds a time range attribute from 0:00 - 23:00 and a step size of 4. This pattern creates and populates 6 time range buckets as users log in.
Jeff searches for the Post-Authentication checkpoint policies already in the system. There are four of them. Since he wants to challenge with an OTP he wants a policy that contains other rules with OTP challenge outcomes.
Next Jeff requires a rule to evaluate the bucket memberships. Jeff searches the rules for one that evaluates if a member has fallen into the current bucket less than a specified percentage in the last specified period. He does not find one so he create one using a user in bucket less than % of time condition.
Jeff adds the rule to the policy and links the pattern.
He then must link action and alert groups. Jeff searches for an action group that contains the challenge OTP action. He finds that there is one already so he links it to the rule.
He searches for an alert group by "time" in the alert message text. He finds one alert group that has an alert with the alert text "device has failed to log in successfully more than 10 times". This alert is not appropriate for his rule so he decides to create a new alert group and alert.
Jeff creates a new alert group for his alert. He then adds a new medium alert to the group with the text "User has fallen into this login time bucket less than 5% of the time in the last 3 months".
Finally Jeff links the alert group to the rule.
He performs log ins to the system to start autolearning.

17.13.2 Use Case: Test a Pattern

Jeff a Security Administrator must make sure the pattern he configured in his use (see Section 17.13.1, "Use Case: Challenge Users If Log In Different Time Than Normally") is working properly.

To test the pattern:

One morning at 9:30 am he creates a new test user and then performs 7 successful logins.
At 3 pm of that day, he performs 3 successful logins.
The next day he logs in at 7 pm and is challenged with an OTP.

This occurs because he has fallen into the 7 pm time bucket less than 5% of the time in the last month.
After the policy and pattern have been in the production system for a month he checks to see if the bucketing in the rule evaluation is accurate. Jeff runs a report to find users that triggered the rule by searching for sessions with the alert, "User has fallen into this login time bucket less than 5% of the time in the last 3 months".
He then selects a few of them and searches for their bucket memberships for this pattern in the last month.

In this way Jeff can see the session where the alert was triggered was at a time that fell into a bucket it had not previously fallen into more than 5% of the time in the last month. From that, Jeff confirms that the policy configuration and pattern are functioning as designed.

17.13.3 Use Case: Track Off-Hour Access

Jeff is a Security Administrator at Dollar Bank. He wants to track off-hour access by employees based on a standard day shift. To do this, he must create a pattern for behavior-based profiling on time.

The pattern profiles the login times of users into three 8-hour buckets.

Figure 17-9 Using Buckets to Track Off-Hour Access

This illustrates the use of buckets to track time

Navigate to the Patterns Search page, as described in Section 17.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, click the New Pattern button.
In the Create Pattern dialog, enter the Pattern name: "User: Work hours."
Select Authentication as the transaction type.
From the Creation Method list, select Multi-Bucket.
Select User as the Member Type.
Select First as the Evaluation Priority.
Enter a description.
Click OK.

A confirmation is displayed.
Click OK.

The Pattern Details page appears.
Click the Attributes tab.

On this tab you can add/edit the attributes of the users behaviors to be tracked. Choose from available attributes shown in the dropdown list.
In the Attributes page, click the Add button.
In the Add Attributes dialog, select Time from the available attributes shown in the drop-down list.
Edit the attribute details.
1. Select Active as the Status.
2. Enter the description.
  
  For example, "This creates three 8-hour buckets."
3. Select a compare operator range with start value of 0 and end value of 23.
4. Enter 8 as the Increment Step.
5. Click Add.
Click Apply.

OAAM creates buckets as needed for the behavior.

17.13.4 Use Case: User Logs in During a Certain Time of Day More Than X Times

Jeff is a Security Administrator at Dollar Bank. He wants to be notified with an alert if a user logs in between 10 am to 5 pm more than 3 times. To do this, he must create a pattern that profiles users and time, and an alert group.

Create a single bucket pattern called, TimeLog10AM-5PM_PS, with the member type, user.
Add the Attribute, Time.
- Compare operator is Range
- Start value is 10 (10 am)
- End value is 17 (5 pm)
Create an Alert Group so that an alert is used to notify you about either anomalies or information in the system when rules are triggered.

For information on Action and Alert groups, see Chapter 12, "Managing Groups."
Create a policy that uses autolearning conditions in the Post-Authentication checkpoint.

Create a rule within the policy that uses conditions to associate the pattern.

Ensure that the rule contains the autolearning condition, "Entity: Entity is member of pattern N times."

Fill in the values for the condition

Label	Name	Default
Pattern Hit Count More than	Pattern Hit Count More than	3
Pattern Name For Membership	Pattern Name for Membership	TimeLog10AM-5PM_PS
is Membership Count more than the Pattern Hit Count for User	isMoreThan	true
Time period type for pattern membership	Time Period Type for Patternmembership	hours
Time Period Type for Pattern Membership	Time Period Type for Pattern Membership	1
Member Type for pattern Membership	MemberType for pattern Membership	user

Add the Alert group as a result of the rule.

Group link to user group.
Verify that the alerts are generated, starting with the fourth login.

17.13.5 Use Case: Patterns Can have Multiple Member Types

Jeff is a Security Administrator at Dollar Bank. He wants to track logins by employees based on days of the week and devices. To do this, he must create a pattern to profile the days of the week, users, and devices login.

If Joe logs in on Monday, his User ID and the Device ID of the computer he is using are added to the Monday bucket once. If Fred uses the same computer to log in on Monday, his User ID and the Device ID of the computer will be added once. At that point, the Monday bucket will have one count for Joe, one count for Fred, and two counts for the device. Rule conditions are then used to evaluate the bucket memberships.

A rule could be created to evaluate one member type of multiple member types.

For example,

Joe logged in on Tuesday less than 5% of the time in the last two months
Joe and this computer logged in on Tuesday less than 5% of the time in the last two months

To set up patterns so that they can have multiple member types with the members independently profiled by the pattern, you perform the following steps.

Create a pattern with User and Device as entities. It will have "Day of the Week" as the attribute and the operator for the attribute will be "for each."

Describe the bucket population correctly.

The condition to use is "Entity member of pattern (fingerprint) less than percentage times (as compared to its own data)."

For information, see Section C.1.2.2, "Entity: Entity is Member of Pattern Less Than Some Percent Time."
Create one rule.
1. Set the percent value to be 5% in the rule.
2. Set the pattern described in Step1 as the pattern in the rule.
3. Set the entity to be user.
4. Set time period to 2.
5. Set time period type to months.
6. Leave the other values to the default.
Create another rule.
1. Set the percent value to be 5% in the rule.
2. Set the pattern described in Step1 as the pattern in the rule.
3. Set entity to be device this time.
4. Set time period to 2.
5. Set time period type to months.
6. Leave the other values to the default.

17.13.6 Use Case: City Usage

Joe's company wants all users to be challenged with an OTP if they are logging in from a city they are not a member of.

Joe logs in from three cities (home, office A and office B). A city pattern records how often he logs in from each.

Bucket	Location
City Bucket #1	home
City Bucket #2	office A
City Bucket #3	office B

Joe's company wants users to be challenged with an OTP two sessions in a row if they are logging in from a city they have not used in the last month. If Joe stops working at office B for 37 days and does not access from anywhere else in that city he will be challenged for an OTP the next time he logs in from that city. To accomplish this use case a rule will be configured to check on the membership count for the current city bucket in the last month. The count threshold will be set to two so the rule will trigger until the user has been a member at least twice in the last rolling month window.

To set up the system so that users are challenged with an OTP if they are logging in from a city they are not a member of, perform the following steps.

Create a pattern with User as the actor, City as the attribute, and For Each as the compare operator.
Use the condition, "Entity is member of bucket less than N times in given time period"
Set the rule parameters for conditions as:
1. Pattern Name as the pattern that you have created.
2. Time period type is month.
3. Time period is 1.
4. Count is 3.
5. Operator if required is less than.

The rule will trigger (and challenge) the user, if the user has not used that city more than 2 times in the last month (in last 30 days).

17.13.7 Use Case: Autolearning Adapts to Behavior of Entities

In addition to profiling, collecting data, and checking it, autolearning adjusts so that the system acts depending on the user's behavior. Conditions and the specified percentage remain unchanged.

If you log into the bank application from California everyday, but then you locate to Seattle without informing your bank. When you log in for the first time from Seattle, you are challenged. The second time, you are challenged again because you are logging in from a city less than 50% of your total logins within 1 month. The system knows Seattle is not the usual place you log in from. You are annoyed, but do not consider it a hindrance yet. Challenging you again will degrade your user experience.

The condition, therefore, has to be configured in such a way that there is a percentage when the system knows that it should no longer challenge you. The system should automatically be smart enough to understand that you are logging in from Seattle every time now going forward and that it should not challenge you.

The system does not challenge you when you log in a third time from Seattle. When you fly to California after three months the system challenges you when you log in. The system wanted to make sure that you are the person logging in to the system.

Example

You want the system to KBA challenge the user if the user logs in from a city less than 50% of the time within a month.

Create a multi- bucket pattern for each city called, UserLoginsCity.
- Member type is user
- Attribute is City; compare operator is "for each"
When a user logs in from different cities a bucket will be created for each city
Create an Action Group to KBA challenge the user for each city less than % membership.
Create policy that will use autolearning conditions in the Post-Authentication checkpoint.

Create a rule within the policy that uses conditions to associate the pattern.

The rule will calculate the percentage membership of a user belonging to a pattern

Ensure that the rule contains the autolearning condition, "Entity: Entity is member of pattern less than some percent times".

For information on this condition, see "Entity: Entity is Member of Pattern Less Than Some Percent Time".

Fill in the values for the condition

Label	Default
Pattern Hit Percent less than	50
Pattern name for membership	UserLoginsCity
Is Membership Count Less than patternHitPercent	True
Time period type for pattern membership	Month
Time period for pattern membership	1
Member type for pattern membership	User

Add the Action group as a result of the rule.

Group link to user group.
If the user logs in from a city < than 50% of the total logins within 1 month, the user is challenged.

17.13.8 Use Case: Single Bucket Pattern

Single-bucket (manually created) patterns create and populate one bucket with the exact data points and value ranges specified in the pattern. You can create a pattern that describes behavior that has been deemed to be high risk based on industry expertise.

You can configure a bucket so that OAAM can look for any traffic that falls in:

8am -10am pattern
New location
New device
New transfer account, not owned by this user is created
Wire transfer to new account

This specific combination has been known to be a very high fraud risk in the past so you want to challenge with an OTP through SMS any time this pattern is seen.

17.13.9 Use Case: Using Pattern

A Security Administrator must configure a policy that challenges a user with a challenge question if the user is logging in from a state that he or she does not log in from very often, specifically one that he or she uses less than twice in a month.

The outcome should include a score and an alert.

Why use patterns for this scenario

This evaluation involves both profiling (patterns) and the rules to evaluate those patterns.

Patterns are used in this scenario for the following reasons:

If rules are to track the frequency of behavior, the period for evaluating the frequency might be relatively long, especially if the evaluation requires months or even years. Using a pattern is recommended in these cases because rules will not have to perform large queries for results. Oracle Adaptive Access Manager checks the bucketing to see if the user is a member of the current state bucket that he is falling into now and the frequency at which he has fallen into that bucket.
Other rules that run can use the pattern, which tracks the state or frequency of state usage, for other types of risk evaluations. By using the same pattern, no overhead is incurred to impact performance.

Steps

Log in to OAAM Admin as an administrator.
In the Navigation tree, double-click Patterns. The Patterns Search page is displayed.
Click the New Pattern button.

Create a pattern where:
- Creation Method: Multi-bucket
- Member Type: User
- Evaluation Priority: High
- Description: Pattern to track the state usage and frequency
Click Create.
Click the Attribute tab.
Click the Add button.
In the Add Attribute dialog, select State as the attribute and click Next.
In the page following, select for Each as the Compare Operator and click Add and then OK.

The compare operator for Each is selected to profile every state that users log in from (a bucket is created for each state and populated with users as they fall into the buckets).
In the Navigator tree, double-click Group.
Click New Group. The Create Group dialog is displayed.
Create a new StateNotUsedOften alert group.
- Group name: State not used often
- Group type: alerts
- Caching policy: Full cache since the group is used in rules and conditions.
Click Create and then OK. The Group Details page is display.
In the Alerts tab of the Group Details page, click Add Member.
In the Add Member page, select Create new element.
Select the Customer Care as the alert type.
Select the Medium as the alert level.
Type in the alert message in the Alert Message box.

For example, user is logging in from a state he or she has used less than 2 times in a month.
Click Add to create and add the new alert to the alert group.
When the confirmation dialog appears, click OK to dismiss the dialog.
In the Navigation tree, double-click Policies. The Policies Search page is displayed.
Search policies for post-authentication policies that are available.

In best practices, KBA challenges occur in the Post-Authentication checkpoint.

Because the rule being created will have the outcome of a KBA challenge, it will have to be in the Post-Authentication checkpoint. It must also be in a policy in which there is a check for KBA registration before this rule runs.
Open the policy to the details page and click the Rules tab.
Click Add.
Plan the rule:

A rule should be created to KBA-challenge the user if it is triggered; therefore the rule must be contained in a policy with other rule challenges.

Because the rule will result in a KBA challenge, the best practice is for the scoring that you set and configure for the rule to have a relationship to the action/outcome of that rule and to the severity of that rule that is being evaluated. The severity of the situation, the action for which the rule would trigger, and the score in which the rule would generate must be proportional to each other.

The rule is checking if the user is logging in from a state that he has logged in from recently, but the situation does not necessarily mean fraud. The situation is one of medium risk--that is why a KBA challenge is used instead of a block. A KBA challenge is appropriate for the scores in the 500 to 700 risk range. For this example, a score of 600 is specified. An OTP challenge would have been appropriate for a score in the 701 to 900 range. For a score of 900 and over, the action triggered should be a "block." The user should be allowed to continue on if the score is under 500.
Enter the summary information and click the Results tab.
Enter 600 as the score.
Enter 100 as the weight.
Select ChallengeQuestionPad as the action.
Select StateNotUsedOften as the alert.
Click the Conditions tab.

Click Add and select Entity: Entity is Member of Pattern N Times.

Enter the following values:

Label	Name	Default
Pattern Hit Count More than	Pattern Hit Count More than	2
Pattern Name For MemberShip	Pattern Name for MemberShip	user:state
is MemberShip Count more than the Pattern Hit Count for User	isMoreThan	false
Time period type for pattern membership	Time Period Type for Patternmembership	month
Time Period Type for Pattern MemberShip	Time Period Type for Pattern MemberShip	1
MemberType for pattern Membership	MemberType for pattern Membership	user

Click Save to save your changes.

A confirmation dialog displays the status of the operation.
Click OK to dismiss the confirmation dialog.

17.13.10 Use Case: Logins from Out of State

Acme is a small business group and all their clients are local to the city and are not expected to travel out of the state very often. The business group wants to track all logins occurring from other states, so they can challenge the users and also trigger a high alert so they can investigate to ensure that it is a valid user logging in from the other state. If they are valid, they will be added to an "Allow User group" so they will not be challenged the next time they log in from another state.

Set autolearning properties to true.
- vcrypt.tracker.autolearning.use.auth.status.for.analysis
- vcrypt.tracker.autolearnin.enabled
Create a single bucket pattern with the following parameters so the pattern tracks all logins not occurring from this state. Essentially the counter will be incremented every time the login occurs from another state.
- Transaction Type: Authentication
- Attribute: State
- Compare Operator: Not in
- Compare Value: State name
- Member Type: User
- Evaluation Priority: First
Use this pattern in a rule condition.
1. Create a rule.
2. Add the condition, ENTITY: Entity is member of pattern N times.
  - Pattern hit count more than: count
  - Pattern Name for membership: Pattern name
  - Is Membership Count More than patternHitCountForUser: True
  - Time period type for pattern membership-- Hours
  - Time period for pattern membership: 1
  - Member type for pattern membership-- User
Save the policy and rule.
Simulate a few logins from different states. The users should be challenged and a high alert should be triggered.
Add a user to the "White User Group".
Add this user group to "excluded user group" in the pre-conditions in the rule.
Save the policy and rule.
Repeat step 5. Users in the White User Group will not be challenged.

17.14 Autolearning Properties

Autolearning properties and their default values out of the box are listed in this section.

Property	Default Value	Property Type	Is Dynamic	Comments
vcrypt.bharosa.autolearning.numPriorities	2	Integer	No	This creates the number of threadpools as the number of priorities. These threadpools are used for post processing the autolearning data. This number should be more than 1.
vcrypt.bharosa.autolearning.threadMultiplier	7	Integer	No	This number is used to create the number of threads for post processing. These threads are part of the threadpool that is used for post processing autolearning data. Keep this number to at least 5.
vcrypt.tracker.autolearnin.enabled	true	Boolean	Yes	This flag is used to control the status for the product level. Setting the value to false disables some of the post processing for autolearning. Rules continue to run but may be using stale data.
vcrypt.tracker.autolearning.use.auth.status.for.analysis	false	Boolean	Yes	This flag is used when the client code does not explicitly call the autolearning API. If you want autolearning (post processing) to occur but do not want to change the client code, setting this flag to true results in autolearning processing for the authentication type of updateAuthStatus requests if the status is SUCCESS for that authentication request. However if the status is not SUCCESS, autolearning does not occur. Running autolearning rules with this flag set to false runs the rules on the data that is stale. If this flag is set to false and autolearning rules are running, and if the log level is set to "debug" for "com.bharosa.vcrypt.tracker.rules.impl.VCryptTrackerAutoLearningImpl" class; then a message is written to the log saying that this property is disabled and rules are still being run.
vcrypt.tracker.autolearning.use.tran.status.for.analysis	false	Boolean	Yes	This flag is used when the client code does not explicitly call the autolearning API. If you want autolearning (post processing) to occur but do not want to change the client code, setting this flag to true results in autolearning processing for updateTransactionStatus requests if the status is SUCCESS for that transaction request. However if the status is not SUCCESS, autolearning does not occur. Running autolearning rules with this flag set to false runs the rules on the data that is stale. If this flag is set to false and you have autolearning rules running, and if the log level is set to "debug" for the "com.bharosa.vcrypt.tracker.rules.impl.VCryptTrackerAutoLearningImpl" class; a message is written to the log saying that this property is disabled and rules are still running.
vcrypt.tracker.autolearning.use.synchronous.execution.for.pattern.analysis	false	Boolean	Yes	This property controls whether the pattern analysis occur in synchronous mode. If set to true, pattern analysis is performed in synchronous fashion. The updateAuthStatus or updateTransactionStatus call may take longer to complete since all the pattern data update occurs as part of the same updateStatus call.
vcrypt.tracker.autolearning.update.entity.profile.for.auth.patterns	true	Boolean	Yes	If this property is set to false, profiles for entities are not updated as part of pattern analysis.
bharosa.menu.queries.entities	false	Boolean	Yes	This flag determines whether the menu item to view historical data should be shown in the OAAM Admin Console.
bharosa.arm.pagetitle.queries.entities.patternworkflow		String	Yes	Default location of the menu for the pattern historical data. Use this historical data page to check if pattern data collection is functioning properly.

17.15 Checking if Autolearning Pattern Analysis Functioning

To quickly find out if Autolearning is functioning, perform the following steps:

Ensure that the base authentication-related entities are installed and that the following properties are set to true.
- vcrypt.tracker.autolearnin.enabled
- vcrypt.tracker.autolearning.use.auth.status.for.analysis
- vcrypt.tracker.autolearning.use.tran.status.for.analysis
Make sure that patterns are defined and active. You should have at least one pattern that has User as a member type and time, city, state, or country as an attribute. For time choose Range as the operator. If you choose the other attributes, choose For Each as the operator. You should choose only one attribute so that you can use this pattern as a test pattern.
Log in to the OAAM Server a few times.
Perform the following database queries on the v_fprints table.

Run

"select * from v_fprints where pattern_id is not null and create_time > sysdate - 1/96"

This will return pattern based fingerprints created in last 15 minutes.

Run

"select * from vt_wf_days where fprint_id in ( select fprint_id from v_fprints where pattern_id is not null and create_time > sysdate - 1/96) "

If this returns records and the record shows a positive integer in "todays day column", autolearning is working. Note: If today is the 15th then look into the Day_15 column in the records returned by this database query.

17.16 Checking if Autolearning Rules are Functioning

To check if the rule were triggered, create a time based pattern that tracks the user.

Create a policy (post authentication) and add the User first time bucket rule to it. Select the time based pattern and leave all other values to default.
Save the policy.
Perform logins from the authenticator using new user names.

If autolearning processing worked then the rule added to the above policy should trigger.
After this perform the same logins again in the same hour.

If autolearning rule is working the rules should not trigger for this second login.

17.17 Autolearning Classes and Logging

Important classes for logging to debug level is summarized below.

Table 17-2 Autolearning Classes and Logging

Class Name/Logger	What does debug logging do
com.bharosa.vcrypt.tracker.autolearning.VCryptAuthPatternAnalysisRequest AND com.bharosa.vcrypt.tracker.autolearning.VCryptTransactionPatternAnalysisRequest	Prints debug log when processing the request. Time required to process the autolearning request is printed as milliseconds. All function entry and exit points are logged along with incoming and outgoing parameters
com.bharosa.vcrypt.tracker.rules.impl.VCryptTrackerAutoLearningImpl	Prints debug log when processing autolearning rules. Request ID is printed along the log statements so you can track the log with the session. All function entry and exit points are logged along with incoming and outgoing parameters
com.bharosa.vcrypt.tracker.autolearning.VCryptAutoLearningRulesUtil	This class implements most of the logic in autolearning rules. Request ID is printed along the log statements so you can track the log with the session. All database queries are also printed. The time required to database query is available from the time in log statements. All function entry and exit points are logged along with incoming and outgoing parameters

17.18 Pattern Attributes Reference

Information about the pattern attributes is presented in this section.

Table 17-3 Pattern Attributes

Name	Description	Type	Operators	Valid Values	Buckets	Comments (Applicable Rules)
dayOfMonth	Day Of the Month (First day = 1, Last Day will vary)	Integer	Equal, not equal, For Each, Less than, Less than Equal to, greater than, greater than equal to, in, not in, range	1 through 31	multi-bucket	User - themselves and all
monthOfTheYear	Month Of the Year (January = 0, December = 11)	Integer	Equal, Not Equal, For Each, Less than, Less than Equal to, greater than, greater than equal to, in, not in, range	0 through 11	multi-bucket	User - themselves and all
Connection Type	Connection Type for the authentication request. The value for this attribute is a positive integer number that indicates the connection type. Examples of connection type are optical connection, wireless connection, dialup connection, T1/T3 type of connection, DSL connection, cable connection, and so on. Refer to location.connection.type.enum for more information on connection type.	Integer	Equal, Not Equal, For Each, Less than, Less than Equal to, greater than, greater than equal to, in, not in, range	lookup location.connection.type.enum	multi-bucket	User - themselves Device - themselves and all Location - themselves
Connection Speed	Connection Speed for the authentication request. The value for this attribute is a positive integer number that indicates the connection speed. Examples of connection speed are High, Medium, Low, and so on. Refer to connection.linespeed.enum for more information.	Integer	Equal, Not Equal, For Each, Less than, Less than Equal to, greater than, greater than equal to, in, not in, range	lookup connection.linespeed.enum	multi-bucket only	User - themselves Device - themselves and all
Routing Type	Connection routing type for the authentication request. The value for this attribute is a positive integer number that indicates the routing type. Examples of routing type are POP, Proxy, AOL, and so on. More information on routing type can be found in location.routing.type.enum.	Integer	Equal, not equal, for each, less than, less than equal to, greater than, greater than equal to, in, not in, range	lookup location.routing.type.enum	multi-bucket only	User - themselves and all Device - themselves and all
Browser	Browser used for the authentication request. Examples of browser are Mozilla, Opera, and so on.	String	For each, in, not in, like, not like	Any string value	multi-bucket only (rarely single)	User - themselves and all Device - themselves and all
Operating System	Operating System used for the authentication request. Examples of Operating System are Unix, Linux, Windows, and others.	String	For each, in, not in, like, not like	Any string value	multi-bucket	User - themselves and all Device - themselves and all
locale	Locale used for the authentication request. Examples of Locale are en_US, fr_CN, en_GB, and so on.	String	For each, in, not in, like, not like	Any string value	multi-bucket only	User - themselves and all Device - themselves and all IP - themselves and all
Device Fingerprint Identifier	Device Fingerprint Identifier available for the authentication request. This number is calculated depending on the device used by the user for this authentication request.	Long	For each, equals, less than, less than equal to, greater than, greater than equal to, in, not in, not equal, range	Any positive number (java.lang.Long)	multi-bucket	User - themselves Device - themselves
Cookie Enabled Status	This boolean variable tracks if the cookie was enabled or disabled on the user's device/browser for this authentication request.	Boolean	For each, not equal, equal	True or False	multi-bucket	User - themselves
Cookie Status	This variable tracks the status of the device/browser cookie. This is a positive integer that corresponds to status of the browser cookie. Examples of the status are Learn mode (0), Enabled (1) and Disabled (2), and so on. More information on cookie state can be found in cookie.state.enum.	Integer	Equal, not equal, for each, less than, less than equal to, greater than, greater than equal to, in, not in, range	lookup cookie.state.enum	multi-bucket	User - themselves
Screen Resolution (based on flash)	This variable tracks the screen resolution used by the user.This attribute is usually available in the form of MxN (M by N) pixels. One of the example is 1600x1200 (pixels).	String	For each, in, not in, like, not like	Any string value. Usually the resolution will appear like MxN. e.g.(1600x1200)	multi-bucket only	Device - themselves
Color screen (based on flash)	This variable tracks whether the user's device has color screen.	Boolean	For each, not equal, equal	True or False	multi-bucket	Device - themselves
Audio encoder (based on flash)	This variable tracks whether the user's device has audio encoder.	Boolean	For each, not equal, equal	True or False	multi-bucket	Device - themselves
Accessibility (based on flash)	This variable tracks whether the user's device has accessibility provisions.	Boolean	For each, not equal, equal	True or False	multi-bucket	User - themselves
Has audio (based on flash)	This variable tracks whether the user's device has audio capabilities.	Boolean	For each, not equal, equal	True or False	multi-bucket	Device - themselves
Country	Country	String	For each, in, not in, like, not like	Any string value	single and multi-bucket	User - themselves and all Device - themselves and all
State	State	String	For each, in, not in, like, not like	Any string value	single and multi-bucket	User - themselves and all Device - themselves and all
City	City	String	For each, in, not in, like, not like	Any string value	single and multi-bucket	User - themselves and all Device - themselves and all
Time	Time when the user is logged in	Integer	Equal, Not Equal, For Each, Less than, Less than Equal to, greater than, greater than equal to, in, not in, range	Integer values (0-23)	multi-bucket	User - themselves and all
Day of Week	Day of the week (Sunday = 1, Saturday = 7)	Integer	Equal, Not Equal, For Each, Less than, Less than Equal to, greater than, greater than equal to, in, not in, range	Integer (1-7)	single and multi-bucket	User - themselves and all
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.	Integer	Equal, Not Equal, For Each, Less than, Less than Equal to, greater than, greater than equal to, in, not in, range	Positive integer value	multi-bucket	User - themselves and all Device - themselves and all Location - themselves and all
User ID	User's Identification Number	String	For each, in, not in, like, not like	String value	multi-bucket	Device - themselves Location - themselves
Group ID	Group Identification Number	String	For each, in, not in, like, not like	any String value	multi-bucket	Device - themselves Location - themselves
Device ID	Device Identification Number	Integer	Equal, Not Equal, For Each, Less than, Less than Equal to, greater than, greater than equal to, in, not in, range	any String value	multi-bucket	User - themselves Location - themselves
Remote 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.	String	For each, in, not in, like, not like	format a.b.c.d	multi-bucket	User - themselves Device - themselves
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.	Boolean	For each, not equal, equal	True or False	multi-bucket	User - themselves
ISP	The ID for an Internet connection service provider.	Long	For each, equals, less than, less than equal to, greater than, greater than equal to, in, not in, not equal, range	Any positive number	multi-bucket	User - themselves and all Device - themselves and all

17.19 Pattern Attributes Operators Reference

Information about the pattern attribute operators is presented in this section.

The Day of Week and City attributes are used in the examples that follow to illustrate how operators work.

Numbers corresponding to the days of the week are:

1 = Sunday
2 = Monday
3 = Tuesday
4 = Wednesday
5 = Thursday
6 = Friday
7 = Saturday

Oracle Adaptive Access Manager will create buckets dynamically as necessary. The first time the criteria specified is fulfilled, Oracle Adaptive Access Manager will create a bucket for the criteria and add the actor as a member with a count of one. The next time the criteria is fulfilled, the actor is added to that same bucket as a member with a count of one. Each subsequent time the criteria is fulfilled, the bucket counter will be incremented.

17.19.1 For Each

If the For each attribute is set, a bucket is created for each distinct value of the attribute.

When the user specifies For Each, and Day of Week as the attribute, a bucket will be created dynamically for each day of the week as required and the counts updated for the buckets as logins occur.

17.19.2 Equals

If the Equals operator is set, the bucket is created and then the count updated only when the attribute value equals the value specified in the Compare Value field.

When the user specifies Day of Week as the attribute and enters 7 (Saturday) in the Compare Value field, a bucket is created for Saturday and the count updated as soon as he logs in on Saturday. The other days do not fulfill the criteria he specified.

17.19.3 Less Than

If the Less Than operator is specified, a bucket is created and the count updated only when the attribute value is less than the value specified in the Compare Value field.

When the user specifies Day of Week as the attribute and enters 4 (Wednesday), a single bucket is created for Sunday (day=1), Monday (day=2), and Tuesday (day=3) and all his logins on Sunday, Monday, and Tuesday will be counted as part of that bucket.

17.19.4 Greater Than

If the Greater Than operator is specified, a bucket is created and the count updated only when the attribute value is greater than the value specified in the Compare Value field.

If the user specifies Day of Week as the attribute and enters 3 (Tuesday), a single bucket is created and the count updated only for Wednesday (day=4), Thursday (day=5), Friday (day=6), and Saturday (day=7). A bucket will not be created nor will the count be updated for the user for Tuesday (day=3).

17.19.5 Less Than Equal To

If the Less Than Equal To operator is specified, a bucket is created and the count updated only if the attribute value is less than or equal to the value specified in the Compare Value field.

When the user specifies Day of Week as the attribute and enters 3 (Tuesday), a bucket will be created and the count updated when the user logs in on Sunday (day=1), Monday (day=2), and Tuesday (day=3). In Less Than Equal To 3, Tuesday (day=3) also qualifies as meeting the bucket population criteria.

17.19.6 Greater Than Equal To

If the Greater Than Equal To operator is specified, a bucket is created and the count updated only if the attribute value is greater than or equal to the value specified in the Compare Value field.

When the user specifies Day of Week as the attribute and entered 3 (Tuesday), a bucket will be created and the count updated when the user logs in on Tuesday (day=3), Wednesday (day=4), Thursday (day=5), Friday (day=6), and Saturday (day=7). In Greater Than Equal To 3, Tuesday also qualifies as meeting the bucket population criteria.

17.19.7 Not Equal

If the Not Equal operator is set, a bucket is created and the count updated when the authentication/transaction attribute has a value not equal to the value specified in the Compare Value field by the user.

In the Day of Week example, if the user specifies a value of 1 (Sunday), a single bucket will be created for all logins other than Sunday (day=1).

17.19.8 In

The In operator works like the Equals operator except all the comma separated values in the Compare Value field are used for an "equals to" comparison. In the Day of Week example, if the user enters 1,2,3,4,5, a single bucket is created for all logins that fall on Sunday (day = 1) through Thursday (day =5).

17.19.9 Not In

The Not In operator works exactly the opposite of In. In the Day of Week example, if the user enters the values 1,2,3,4,5 for the day of the week, a single bucket is created for Friday (day = 6) and Saturday (day =7) only.

17.19.10 Like

The Like operator is applicable and enabled only for string type attributes. If the user's login "city" is used as the attributes and he specifies "San" for the city attribute, his logins from the cities, "San Francisco," "Santa Clara," "San Jose," and "Sangamner" will result in a single bucket and updates to the count.

"Like" compares the string attribute's value with the one specified by the user.

17.19.11 Not Like

The Not like operator is applicable and enabled only for string type attributes. If the user's login "city" is used as the attribute and he specifies "San" for the City attribute, his logins from the cities, "San Francisco," "Santa Clara," "San Jose," and "Sangamner" will not result in the creation of a bucket or updates to the count. His logins from Redwood City, Austin, and other cities that do not have "San" in the name will result in a single bucket and updates for this pattern.

17.19.12 Range

Range is usually used with numerics.

Figure 17-10 Range Compare Operator

17.19.12.1 Fixed Range

When the user enters values for Start Value and End Value and leaves the Increment Step value as 0, he wants to create a bucket for the activity when the attribute value is Greater Than Equal To the Start Value and Less Than Equal To the End Value. Using the Day of Week example, if the user enters 1 (Sunday) as the Start Value and 5 (Thursday) as the End Value, all the logins from Sunday (day=1) through Thursday (day=5) will result in the creation and updates to the count of a single bucket. A fixed range is when the upper and lower limit are fixed and there are no steps "in between" (the increment step is not entered by user).

17.19.12.2 Fixed Range with Steps (or Increment)

When the user enters values for Start Value and End Value and also provides a value for the Increment Step, he wants to create a bucket for the activity when the attribute value is Greater Than or equal to the Start Value and Less Than Equal To the End Value and he wants to create finer level buckets which are separated by the "increment" value of the attribute. Using the Day of Week example, if the user enters 1 (Sunday) as the Start Value and 5 (Thursday) as the End Value and the Increment Step as 1, all the logins from Sunday (day=1) through Thursday (day=5) will result in the creation and updates to the count of multiple buckets. A bucket will be created and updated for the day starting Monday and then for each day (since the increment is one).

17.19.12.3 Upper Unbound Ranges with Steps

Upper unbounded ranges with increment steps are used for items, such as numbers, such as amounts. Basically, multiple-tiered ranges can be configured.

For example you can configure

0 to 100 with Step 10.

101 to 1000 with Step 100.

1001 to 10000 with Step 1000.

10001 to ... with Step 10000.

All the ranges but the last one works the same way as the earlier range example with Start Value and End Value with Increment Step.

The last range works as if the upper limit is infinity. In this scenario, buckets are created for each 10000 (ten thousand) after 10001 (ten thousand one).

If a user has an amount of 200,123 (two hundred thousand 123), a bucket would be created for him for 200,000 through 210,000. His transaction for this amount will fall into this bucket.