15 Managing Autolearning

This chapter focuses configuring patterns to profile users, devices, and location to evaluate the risk of the current behavior.

This chapter contains the following sections:

• Autolearning Introduction and Concepts

• Quick Start for Enabling Autolearning for Your System

• Before You Use Autolearning

• User Flows

• Navigating to the Patterns Search Page

• Searching for a Pattern

• Navigating to the Patterns Details Page

• Viewing Pattern Details

• Creating and Editing Patterns

• Importing and Exporting Patterns

• Deleting Patterns

• Using Autolearning Data/Profiling Data

• Using Transaction-Based Patterns

• Checking if Autolearning Pattern Analysis Functioning

• Checking if Autolearning Rules are Functioning

• Debugging Autolearning

• Optimizing the Update of Workflow Tables in Patterns

• Autolearning Properties

• Pattern Attributes

• Pattern Attributes Operators

• Use Cases

15.1 Autolearning Introduction and Concepts

Autolearning is a set of features in Oracle Adaptive Access Manager that is used to dynamically profile behavior in real-time. The behavior of entities such as users, devices, locations, credit cards, addresses, account numbers, and so on, are recorded and used to evaluate the risk of current behavior.

Autolearning patterns optimize the way OAAM captures and evaluates risk in two ways. First the patterns are capturing only the specific entity and data combinations defined which limits data growth by allowing the full session data to be purged while maintaining only the data required for risk analysis. Second, autolearning rules evaluate against the optimized patterns so the underlying queries are less expensive than standard rules from a performance perspective.

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

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

15.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 are defined by configuring the bucket creation method, member types, and attributes to be profiled. As well, rules must be configured to evaluate 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 15-1 shows a bucket creation and population example.

Figure 15-1 Login Times

Description of "Figure 15-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 as 0:00 and end time as 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 15-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 has logged in at this time if he authenticates successfully. This validates that what is recorded is most likely Jeff's real behavior and not a fraudulent attempt. The memberships and associated statistics are saved in each user profile.

15.1.3 Member Types and Attributes

To profile behavior, members and attributes are defined.

Members and attributes act as a guide for Oracle Adaptive Access Manager to analyze data. A member is either an entity involved in an access request or transaction. Some example entities include user, IP address used for logging in, state, credit card used to make a purchase, destination account used in a funds transfer, 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.

15.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 15-2 Single Bucket

  
  Description of "Figure 15-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. Buckets are only created when the data combinations occur.

  For example:

  If you specify a pattern with device as the member type and add a country as the attribute with For each as the compare operator, Oracle Adaptive Access Manager creates a bucket dynamically for each device and country combination as activity occurs. The first time any user logs in from Canada, Oracle Adaptive Access Manager creates a Canada bucket and adds that user's device as a member with a count of one. The next user to log in from Canada has their device added to that same bucket as a member with a count of one. Each subsequent time a user logs in from Canada with the same device the Canada bucket counter is incremented.

  Figure 15-3 Countries Multi-Bucket

  
  Description of "Figure 15-3 Countries Multi-Bucket"
  
  

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

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

Figure 15-4 Bucket Evaluation

Description of "Figure 15-4 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 login time behavior. The multi-bucket pattern was configured to create buckets to cover the entire 24 hours of the day in eight hour samples. Consequently, OAAM ended up creating three time buckets as login activity occurred within each time range.

Buckets	Time Range
Bucket #1	1:00 - 8:59
Bucket #2	9:00 - 16:59
Bucket #3	17:00 - 00:59

Last month all users had 100 successful access requests and John had 25 successful access requests. The buckets were populated with members and counters for each member. The table below shows bucket membership for John in the last month and for all users.

Bucket s	John	All Users
Bucket #1	1	8
Bucket #2	24	90
Bucket #3	0	2

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

15.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, proceed as follows:

1. Make sure entities are imported.

   See Section 15.3.1, "Importing Base Authentication-Related Entities."

2. Create patterns.

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

   See Section 15.9, "Creating and Editing Patterns."

3. Finally, use the patterns in rule evaluation.

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

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

15.3 Before You Use Autolearning

Before using the Autolearning feature, read through Section 15.1, "Autolearning 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.

15.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 25.4, "Importing an OAAM Snapshot."

To import the entities into the server:

1. Open the Entity Definition Search page, as described in Section 19.3.2, "Searching for Entity Definitions."

2. Click Import Entities.

3. In the Import Pattern dialog, click Browse and locate Auth_EntityDefinition.zip.

4. Click OK.

   The OAAM Administration Console shows the entities in that file.

5. Select and import all of them.

15.3.2 Enabling Autolearning Properties

Enable autolearning so that OAAM collects profiling data.

1. 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 the property is not available, you must create the property and set it to true.

2. Set the following properties to true:

   • vcrypt.tracker.autolearning.use.auth.status.for.analysis

     This property must be set to true for the authentication patterns to work. It is set to true by default. 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. It is set to true by default. Transactional patterns profile the entities involved in transactions. For example, capture all the destination accounts and frequency of each that a user transfers funds to in an online banking application.

   • oracle.oaam.transactions.analyzepatterns

     This property is set to true by default, so pattern data can be collected for transactions. If the property does not exist, create it.

15.3.3 Importing Autolearning Policies into the Server

Import the standard autolearning policies, refer to Section 25.4, "Importing an OAAM Snapshot."

15.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 UpdateAuthStatus 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 H, "Pattern Processing."

15.4 User Flows

User flows are presented for:

• Creating a New Pattern

• Editing a Pattern

15.4.1 Creating a New Pattern

These steps describe the Create New Pattern flow:

1. Search for a pattern.

2. If pattern exists, view pattern details.

3. If pattern does not exist, create new pattern.

4. Specify pattern name, member type, evaluation priority, and description.

5. Add attributes.

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

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

1. Search for a pattern.

2. If Pattern exists, view pattern details.

3. Change details.

4. Add attributes.

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

15.5 Navigating to the Patterns Search Page

To open the Patterns Search page:

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane.

   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.5, "Using 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

15.6 Searching for a Pattern

To search for a Pattern:

1. Open the Patterns Search page, as described in Section 15.5, "Navigating to the Patterns Search Page."

   An example Patterns Search page is shown in Figure 15-5.

   Figure 15-5 Patterns Search Page

   
   Description of "Figure 15-5 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.

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

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

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

   Table 15-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 must 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.

   
   

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.

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.

15.7 Navigating to the Patterns Details Page

Follow these steps to navigate to a Pattern Details page.

1. If you are not in the Patterns Search page, follow the instructions in Section 15.5, "Navigating to the Patterns Search Page."

2. Search for the pattern of interest, by following the instructions in Section 15.6, "Searching for a Pattern."

   There is a link on the pattern name in the Search Results table.

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

15.8 Viewing Pattern Details

This section provides details on viewing patterns.

15.8.1 Viewing Details of a Specific Pattern

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

The Pattern Details page provides 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).

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

15.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 Pattern

Follow this procedure to create a 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.

1. Open the Patterns Search page, as described in Section 15.5, "Navigating to the Patterns Search Page."

2. 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.5, "Using Search, Create, and Import."

3. In the New Pattern page, enter the pattern name.

   A unique pattern name must be entered.

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

5. From the Creation Method list, select the method you want to use to create the pattern.

   • Single-Bucket

   • Multi-Bucket

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

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

   The chances for finishing the processing of high priority pattern data are doubled the chances for finishing the low priority patterns.

8. Enter a description.

9. Click Apply.

   Figure 15-6 New Pattern

   
   Description of "Figure 15-6 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.

10. Add attributes.

    Figure 15-7 Add Attribute

    
    Description of "Figure 15-7 Add Attribute"
    
    

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

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

11. Activate the pattern.

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

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

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

15.9.2 Adding Attributes

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

Follow these steps to add attributes.

1. If you are not in the Pattern Details page of the pattern, follow the instructions in Section 15.8.1, "Viewing Details of a Specific Pattern."

2. In the Attributes tab, click Add in the Search Results toolbar.

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

4. 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 15.20, "Pattern Attributes Operators."

   4. Enter Increment Step.

      The sample size (interval)

      For example, 2 for 2 hour intervals.

   5. Click Add.

5. In the Attributes tab, use the arrow controls to reorder the attributes if you want.

   Order is not required and is automatically pre-filled.

6. Click Apply.

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

7. Click OK to dismiss the dialog.

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

15.9.3.1 Activating Patterns

To activate patterns:

1. Open the Patterns Search page, as described in Section 15.5, "Navigating to the Patterns Search Page."

2. In the Patterns Search page, enter the search criteria you want and click Search. For information, see Section 15.6, "Searching for a Pattern."

3. Select the row for each pattern you want to activate.

4. Click Activate.

15.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:

1. To deactivate a pattern, from the Patterns Search page select the row for each pattern you want to deactivate and click Deactivate.

2. To deactivate a pattern from the Pattern Details page, click Deactivate.

15.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:

1. If you are not in the Pattern Details page of the pattern you want to edit, follow the instructions in Section 15.7, "Navigating to the Patterns Details Page."

2. To change the pattern name, evaluation priority, and description, edit the appropriate fields in the Summary tab of the Pattern Details page.

3. To change the status, select from the status you want.

   To change the status of the pattern, see Section 15.9.5, "Changing the Status of the Pattern."

4. Add or change the member types.

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

   For information about member types, see Section 15.1.3, "Member Types and Attributes."

5. Change the evaluation priority

   To change the evaluation priority, see Section 15.9.7, "Changing the Evaluation Priority."

6. To add attributes, see Section 15.9.2, "Adding Attributes."

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

7. To edit attributes, see Section 15.9.8, "Editing Attributes."

8. To delete attributes, see Section 15.9.9, "Deleting Attributes."

9. Click Apply.

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

15.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 15.1.3, "Member Types and Attributes."

Follow these steps to add or change member types.

1. If you are not in the Pattern Details page of the pattern, follow the instructions in Section 15.7, "Navigating to the Patterns Details Page."

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

15.9.7 Changing the Evaluation Priority

Follow these steps to change the evaluation priority.

1. If you are not in the Pattern Details page of the pattern, follow the instructions in Section 15.7, "Navigating to the Patterns Details Page."

2. In the Summary tab, change the evaluation priority.

15.9.8 Editing Attributes

Follow these steps to edit attributes.

1. Click the Attributes tab of the Pattern Details page.

   If you are not in the Pattern Details page of the pattern you want to edit, follow the instructions in Section 15.8.1, "Viewing Details of a Specific Pattern."

2. In the Attributes page, select the attribute you want to edit.

3. Edit the attribute details and click Save.

4. Reorder the attributes if you want.

5. Click Apply.

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

1. Click the Attributes tab of the Pattern Details page.

   If you are not in the Pattern Details page of the pattern you want to edit, follow the instructions in Section 15.8.1, "Viewing Details of a Specific Pattern."

2. In the Attributes page, click the check box next to the Attribute(s) you want to delete from the pattern.

3. Click Delete.

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

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

15.10.1 Importing Patterns

To import patterns:

1. Open the Patterns Search page, as described in Section 15.5, "Navigating to the Patterns Search Page."

2. In the Patterns Search page, click Import Pattern.

3. In the Pattern Import dialog, click Browse and locate the pattern file you want to import.

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

15.10.2 Exporting Patterns

To export patterns:

1. Open the Patterns Search page, as described in Section 15.5, "Navigating to the Patterns Search Page."

2. In the Patterns Search page, enter the search criteria you want and click Search. For information, see Section 15.6, "Searching for a Pattern."

3. Select the row for each pattern you want to export.

4. Select Export Selected from the Actions menu.

5. In the Export Patterns dialog, click Export.

6. In the Save dialog, click OK.

15.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:

1. Open the Patterns Search page, as described in Section 15.5, "Navigating to the Patterns Search Page."

2. In the Patterns Search page, enter the search criteria you want and click Search. For information, see Section 15.6, "Searching for a Pattern."

3. Select the row for each pattern you want to delete and click Delete.

   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.

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

15.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 15.21.1, "Use Case: Challenge Users If Log In Different Time Than Normally."

15.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 15.21.4, "Use Case: User Logs in During a Certain Time of Day More Than X Times."

Pattern based rules profile the behavior of a user over time. These rules should not be run for users who do not have sufficient history. As well, patterns need enough data in the OAAM database in total to evaluate correctly. There are rules that evaluate if there is enough data in the database for patterns and the number of sessions a user, device, IP, and other factors has in the OAAM database and only run the pattern based rules if the entity has more than the configured threshold.

For information about autolearning rules and conditions, see the autolearning (pattern-based) policies in Chapter 10, "OAAM Policy Concepts and Reference" and the autolearning conditions in Appendix B, "Conditions Reference."

15.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 determine whether the pattern is working properly, see Section 15.21.2, "Use Case: Test a Pattern."

15.13 Using Transaction-Based Patterns

Starting in 11.1.2.0, transactions can be used in autolearning so that entities can be used as pattern members and entity data elements and transaction data can be used as pattern attributes. The benefit is that it brings the power and flexibility of pattern based fraud analysis to transactions.

The transaction-based patterns use the same framework as the authentication-based patterns and processing of the pattern data is performed in an asynchronous matter. Patterns are bound to transactions, so changes to the transaction metadata affects pattern data collection. Pattern data collection in OAAM Offline only works correctly if the data is loaded in chronological order.

You can:

• Create patterns based on a transaction definition. The relationship between a pattern and its transaction definition, once created, cannot be modified. These patterns can incorporate transaction data, entity data, and implicit data such as user, time, location data, and browser/flash fingerprinting.

• Define policies that incorporate these transaction-based patterns.

• View pattern processing details in Session logs

• Use new conditions that allow you to create policies involving transaction-based patterns. When you add attributes to patterns based on entities from a user-defined transaction, the transaction data is available. The following rule conditions are available:

  • Pattern (Transaction): Entity is Member of Pattern N Times

  • Pattern (Transaction): Entity is a Member of the Pattern N Times in a Given Time Period

  • Pattern (Transaction): Entity is a Member of the Pattern Bucket for the First Time in a Certain Time Period

  • Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time

  • Pattern (Transaction): Entity is a Member of the Pattern Bucket Less than Some Percent with All Entities in the Picture

  • Pattern (Transaction): Entity is Member of Pattern X% More Frequently All Entities' Average Over Last N Time Periods

  • Pattern (Transaction): Entity is Member of Pattern X% More Frequently Than Entity's Average Over Last N Time Periods

For more information, refer to Section B.3, "Autolearning Conditions" and Section 15.21, "Use Cases."

15.14 Checking if Autolearning Pattern Analysis Functioning

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

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

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

3. Log in to the OAAM Server a few times.

4. 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 today's 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.

15.15 Checking if Autolearning Rules are Functioning

To check to see whether the rule was triggered, create a time based pattern that tracks the user.

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

2. Save the policy.

3. Perform logins from the authenticator using new user names.

   If autolearning processing worked then the rule added to the policy should trigger.

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

15.16 Debugging Autolearning

Important classes for logging to debug level is summarized below.

Table 15-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

15.17 Optimizing the Update of Workflow Tables in Patterns

When logins are made from oaam_server, all four workflow tables (Hours, Days, Months, and Years) are updated for users/patterns. If you want the feature that enables you to optimize patterns, first take a backup of the system by taking a system snapshot using the OAAM Admin Console. In the OAAM Admin Console under Properties, check if there are any properties that are like pattern.workflow.update.<Hours/Years/Months/Days>.<pattern_global_Id>. If such properties exist, delete these properties. Now, set the following property pattern.workflow.update.<Hours/Years/Months/Days>.<pattern_global_Id > to false for the tables you do not want to be updated. If you decide you want to re-enable certain table updates for patterns, you can do so by setting the properties back to true. The pattern global_id can be found in the V_Pattern table in the OAAM database.

If you do not want to use this feature or are not seeing any performance issue with patterns, no action is required.

15.18 Autolearning Properties

Autolearning properties and their standard default values are listed in this section.

Table 15-3 Autolearning Properties

Property	Default	Property Type	Is Dynamic?	Comments
vcrypt.bharosa.autolearning.numPriorities	2	Integer	No	Creates the number of thread pools as the number of priorities. These thread pools are used for post processing the autolearning data. This number should be more than 1.
vcrypt.bharosa.autolearning.threadMultiplier	7	Integer	No	Number of threads for post processing. These threads are part of the thread pool that is used for post processing autolearning data. Keep this number to at least 5.
vcrypt.tracker.autolearnin.enabled	true	Boolean	Yes	Flag used to control the status for the product level. Setting 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.
oracle.oaam.transactions.analyzepatterns	false	Boolean		Property must be set to true for pattern data to be collected for transactions.
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 to see whether pattern data collection is functioning properly.

15.19 Pattern Attributes

Information about the pattern attributes is presented in this section.

Table 15-4 Pattern Attributes

Name	Description	Type	Operators	Valid Values	Buckets	Comments (Applicable Rules)
Day of Month	Day of the month (First day as 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
Month of the Year	Month of the year (January as 0, December as 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	Web 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. For example: (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 as 1, Saturday as 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
Autonomous System Number	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 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
Internet Service Provider	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

15.20 Pattern Attributes Operators

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 as Sunday

• 2 as Monday

• 3 as Tuesday

• 4 as Wednesday

• 5 as Thursday

• 6 as Friday

• 7 as 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.

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

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

15.20.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 as 1), Monday (day as 2), and Tuesday (day as 3) and all his logins on Sunday, Monday, and Tuesday will be counted as part of that bucket.

15.20.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 as 4), Thursday (day as 5), Friday (day as 6), and Saturday (day as 7). A bucket will not be created nor will the count be updated for the user for Tuesday (day as 3).

15.20.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 as 1), Monday (day as 2), and Tuesday (day as 3). In Less Than Equal To 3, Tuesday (day as 3) also qualifies as meeting the bucket population criteria.

15.20.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 as 3), Wednesday (day as 4), Thursday (day as 5), Friday (day as 6), and Saturday (day as 7). In Greater Than Equal To 3, Tuesday also qualifies as meeting the bucket population criteria.

15.20.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 as 1).

15.20.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 as 1) through Thursday (day as 5).

15.20.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 as 6) and Saturday (day as 7) only.

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

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

15.20.12 Range

Range is usually used with numerics.

Figure 15-8 Range Compare Operator

Description of "Figure 15-8 Range Compare Operator"

15.20.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 as 1) through Thursday (day as 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).

15.20.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 as 1) through Thursday (day as 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).

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

15.21 Use Cases

This section describes example use cases for autolearning and patterns.

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

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

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

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

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

5. Jeff adds the rule to the policy and links the pattern.

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

7. 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 an alert group and alert.

8. 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".

9. Finally Jeff links the alert group to the rule.

10. He performs log ins to the system to start autolearning.

15.21.2 Use Case: Test a Pattern

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

To test the pattern:

1. One morning at 9:30 am he creates a new test user and then performs 7 successful logins.

2. At 3 pm of that day, he performs 3 successful logins.

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

4. 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".

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

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

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

Description of "Figure 15-9 Using Buckets to Track Off-Hour Access"

To create a pattern that profiles the login times of users into three 8-hour buckets:

1. Log in to the OAAM Administration Console as an administrator.

2. Create a multi-bucket pattern to capture the count of access over each 8-hour period for a day.

   1. After you have logged in to the OAAM Administration Console, double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

   2. Click New Pattern on the upper right of the console. This displays the New Pattern screen for creating a new pattern.

      Parameter	Values
      Pattern Name	User: Work hours
      Transaction Type	Authentication
      Creation Method	Multi Bucket
      Member Type	User
      Evaluation Priority	High
      Description	Pattern to capture the count of access over each 8-hour period for a 24-hour day

      
      

   3. Click Create. A page with details of your pattern is displayed.

   4. Click the Attribute tab to specify the attributes you will be checking.

   5. Click Add. This will provide a search screen allowing you to search for attributes you want to check. Enter your search criteria and click Search to see a list of attributes you want to use.

      Parameter	Values
      Attribute	Time
      Status	Active
      Compare operator	Range
      Start Value	0
      End value	23
      Increment Step	8
      Description	This creates three 8-hour buckets

      
      

3. Click Add.

OAAM creates buckets as needed for the behavior.

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

1. Create a single bucket pattern called, TimeLog10AM-5PM_PS, with the member type, user.

2. Add the Attribute, Time.

   • Compare operator is Range

   • Start value is 10 (10 am)

   • End value is 17 (5 pm)

3. 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 13, "Managing Groups."

4. Create a policy that uses autolearning conditions in the Post-Authentication checkpoint.

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

   • Ensure that the rule contains the autolearning condition, Pattern (Authentication): 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 Pattern membership	hours
     Time Period Type for Pattern Membership	Time Period Type for Pattern Membership	1
     Member Type for pattern Membership	Member Type for pattern Membership	user

     
     

   • Add the Alert group as a result of the rule.

6. Group link to user group.

7. Verify that the alerts are generated, starting with the fourth login.

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

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

   For information, see Section B.3.2, "Pattern (Authentication): Entity is a Member of the Pattern Less Than Some Percent of Time."

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

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

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

1. Create a pattern with User as the actor, City as the attribute, and For Each as the compare operator.

2. Use the condition, Pattern (Authentication): Entity is a Member of the Pattern N Times in a Given Time Period

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

15.21.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 in to 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, must 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.

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

2. Create an Action Group to KBA challenge the user for each city less than % membership.

3. Create policy that will use autolearning conditions in the Post-Authentication checkpoint.

4. 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, "Pattern (Authentication): Entity is member of pattern less than some percent times".

     For information on this condition, see "Pattern (Authentication): Entity is a Member of the Pattern Less Than Some Percent of 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.

5. Group link to user group.

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

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

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

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

3. Click New Pattern on the upper right of the console. This displays the New Pattern dialog for creating a new pattern.

   Create a pattern where:

   • Creation Method: Multi-bucket

   • Member Type: User

   • Evaluation Priority: High

   • Description: Pattern to track the state usage and frequency

4. Click Create.

5. Click the Attribute tab.

6. Click Add.

7. In the Add Attribute dialog, select State as the attribute and click Next.

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

9. In the Navigator tree, double-click Group.

10. Click New Group. The Create Group dialog is displayed.

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

12. Click Create and then OK. The Group Details page is display.

13. In the Alerts tab of the Group Details page, click Add Member.

14. In the Add Member page, select Create new element.

15. Select the Customer Care as the alert type.

16. Select the Medium as the alert level.

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

18. Click Add to create and add the new alert to the alert group.

19. When the confirmation dialog appears, click OK to dismiss the dialog.

20. In the Navigation tree, double-click Policies. The Policies Search page is displayed.

21. 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 must 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.

22. Open the policy to the details page and click the Rules tab.

23. Click Add.

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

25. Enter the summary information and click the Results tab.

26. Enter 600 as the score.

27. Enter 100 as the weight.

28. Select ChallengeQuestionPad as the action.

29. Select StateNotUsedOften as the alert.

30. Click the Conditions tab.

31. Click Add and select Pattern (Authentication): 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 Pattern membership	month
    Time Period Type for Pattern MemberShip	Time Period Type for Pattern MemberShip	1
    Member Type for pattern Membership	Member Type for pattern Membership	user

    
    

32. Click Save to save your changes.

    A confirmation dialog displays the status of the operation.

33. Click OK to dismiss the confirmation dialog.

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

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

3. Click New Pattern on the upper right of the console. This displays the New Pattern dialog for creating a new pattern.

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

5. Use this pattern in a rule condition.

   1. Create a rule.

   2. Add the condition, Pattern (Authentication): 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

6. Save the policy and rule.

7. Simulate a few logins from different states. The users should be challenged and a high alert should be triggered.

8. Add a user to the White User Group.

9. Add this user group to excluded user group in the pre-conditions in the rule.

10. Save the policy and rule.

11. Repeat step 5. Users in the White User Group will not be challenged.

15.21.11 Use Case: Wire Transfer Dollar Amount Pattern

Mike is a security administrator who needs to profile user behavior based on the online banking wire transfers they complete. Mike wants to track the ranges of dollar amounts each user normally transfers. He creates a user multi-bucket pattern to create dollar ranges of $100. Mike then implements a rule to challenge the user if the current dollar range bucket transfer has fallen into one the user has had less than 10% of the time in the last three months.

Prerequisites: Default snapshot is loaded. System has a defined transaction that represents a banking wire transfer, such as an Internet Banking transaction.

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

3. Click New Pattern on the upper right of the console. This displays the New Pattern dialog for creating a new pattern. You want to create a user multi-bucket pattern to create dollar ranges of $100.

4. Specify initial details about the new pattern and click Create. All values except transaction type and creation method can be modified later in the Pattern Details page.

   Parameters	Value
   Pattern Name	User: Internet Banking Amount
   Transaction Type	Internet Banking since you will be profiling the user's behavior based on internet transactions
   Creation Method	Multi bucket since you must create dollar ranges of $100
   Member Types	User
   Evaluation Priority	High so that it is processed first.
   Description	Tracks the transaction amounts for each users' Internet Banking transactions.

   
   

   After clicking Create, a page with details about the pattern is displayed.

5. Click the Attribute tab and then the Add Attribute icon in the toolbar.

6. When the Add Attribute dialog appears, enter Amount in the Attribute Name field and click Search.

7. Select Amount from the list and click Next.

8. Provide the following information and click Add.

   Parameters	Value
   Description	Enter a description for the attribute.
   Compare Operator	Range
   Start Value	0
   End Value	Leave blank.
   Increment Step	100 since the transaction amount is collected in ranges of 100.

   
   

9. Double-click Policies in the Navigation pane. This will provide the Policies Search page allowing you to search for OAAM Users vs. Themselves policy. Enter the search criteria and click Search.

10. Open the OAAM User vs. Themselves policy.

11. Click the Rules tab and Add. You want to create a rule to challenge if the current dollar range bucket transfer has fallen into is one the user has been a member of less than 10% of the time in the last three months.

12. Enter details about the Rule in the Summary tab such as the Rule Name and Description. Do not change the Rule Status. Leave it as Active.

13. Click the Conditions tab and add the "Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time" condition.

    Enter the following values:

    Parameter	Value
    Pattern hit count less than	10
    Pattern name for membership	User: wire transfer
    is membership count less than the pattern hit percent	True
    Time period type for pattern membership	months
    Time period for pattern membership	3
    Member type for pattern membership	user

    
    

14. Open the Results tab.

15. Enter a score.

16. Enter the weight.

17. Set the rule result Action Group to OAAM Challenge.

18. Click Save to save your changes. A confirmation dialog displays the status of the operation.

19. Click OK to dismiss the confirmation dialog.

Post conditions: Users who perform a wire transfer for an amount in a dollar range that is different from 90% of their wire transfers over the previous three months are challenged.

The pattern rule triggers when the wire transfer transaction amount is less than 10% of all the other transactions.

15.21.12 Use Case: HR Employee Record Access Pattern per User

Mike is a security administrator who needs to profile and evaluate users behavior based on the frequency and volume of access requests they make to an HR application for employee records. Mike wants to track the number of records per 8-hour time period normally accessed by each HR representative. He creates a multi-bucket pattern to capture the count of requests over each 8-hour period for a day. Mike then implements a rule to generate an alert if the current access falls into an 8 hour range that exceeds the user's average over the last month by 40%.

Prerequisites: Default snapshot is loaded. System has a defined transaction that represents employee record access.

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

3. Click New Pattern on the upper right of the console. This displays the New Pattern dialog for creating a new pattern.

4. Create a new multi-bucket pattern on the employee record access transaction to capture the count of requests over each 8-hour period for a day.

   1. In the New Pattern dialog, select Transaction Type as HR Record Access, Creation Method as Multi-Bucket, Member Types as HR Rep, and Evaluation Priority as High.

   2. In the Attributes tab, add a new attribute, selecting Time from the list. For the Attribute Details, select Compare Operator as Range, Start Value as 0, End Value as 23, and Increment Step as 8.

5. Create a rule to generate an alert if the current access falls into an 8 hour range that exceeds the user's average over the last month by 40%.

6. Open the OAAM User vs. Themselves policy and add a new rule.

7. Add the "Pattern (Transaction): Entity is Member of Pattern X% More Frequently Than Entity's Average Over Last N Time Periods" condition to the rule, with Pattern Hit Percent greater than as 40, Pattern name for membership: the name of the pattern created in step 4, Time period type for pattern membership as Days, Time period for pattern membership as 30, and Member type for pattern membership as HR rep.

8. Set the rule result to generate an alert.

Post conditions: Users who perform many access requests in an 8-hour period that is 40% higher than their average number of the access requests over the previous month cause an alert.

15.21.13 Use Case: HR Employee Record Access Pattern for All Users

Mike is a security administrator who needs to profile and evaluate users behavior based on the frequency and volume of access requests they make to an HR application for employee records compared to the access requests of others. Mike wants to track the number of records per 8-hour time period normally accessed by any HR representative. He creates a multi-bucket pattern to capture the count of requests over each 8-hour period for a day. Mike then implements a rule to generate an alert if the current access falls into an 8-hour range that exceeds the average for all users over the last month by 30%.

Prerequisites: Default snapshot is loaded. System has a defined transaction that represents employee record access.

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

3. Click New Pattern on the upper right of the console. This displays the New Pattern dialog for creating a new pattern.

4. Create a new multi-bucket pattern on the employee record access transaction to capture the count of requests over each 8-hour period for a day.

   1. In the New Pattern dialog, select Transaction Type as HR Record Access, Creation Method as Multi-Bucket, Member Types as HR Rep, and Evaluation Priority as High.

   2. In the Attributes tab, add a new attribute, selecting Time from the list. For the Attribute Details, select Compare Operator as Range, Start Value as 0, End Value as 23, and Increment Step as 8 to generate an alert if the current access falls into an 8 hour range that exceeds the average for all users over the last month by 30%.

5. Open the OAAM User vs. All Users policy and add a new rule.

6. Add the "Pattern (Transaction): Entity is Member of Pattern X% More Frequently All Entities' Average Over Last N Time Periods" condition to the rule, with Pattern Hit Percent greater than as 30, Pattern name for membership: pattern created in step 4, Time period type for pattern membership as Days, Time period for pattern membership as 30, and Member type for pattern membership as HR Rep.

7. Set the rule result to generate an alert.

Post conditions: Users who perform many access requests in an 8-hour period that is 40% higher than the average number of the access requests for all users over the previous month cause an alert.

15.21.14 Use Case: Shipping Address Country Pattern

Mike is a security administrator who needs to profile e-commerce transactions based on the country the goods are shipping to. He creates a pattern to create a bucket for each country and count the transactions shipped to each. He then implements a rule to generate an alert if a transaction is one where the goods are shipping to a country that less than 5% of all other orders have shipped to in the last 3 months.

Prerequisites: Default snapshot is loaded. System has a defined transaction that represents the e-commerce transaction, such as the Retail Ecommerce transaction from the OAAM sample application. The transaction has an entity or an attribute that indicates the country in the shipping address.

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

3. Click New Pattern on the upper right of the console. This displays the New Pattern dialog for creating a new pattern.

4. Create a new multi-bucket pattern on the Retail Ecommerce transaction to create a bucket for each country in the shipping address.

   1. In the New Pattern dialog, select Transaction Type as Retail Ecommerce, Creation Method as Multi-Bucket, Member Type as Shipping Address, and Evaluation Priority as High.

   2. In the Attributes tab, add a new attribute, selecting Country from the list and select for Each as the Compare Operator.

   A pattern is created for the Retail Ecommerce Transaction type. It collects country information for every transaction.

5. Create a rule to generate an alert if goods in a transaction is shipping to a country that less than 5% of all other orders have shipped to in the last 3 months.

6. Open the OAAM User vs. Themselves policy and add a new rule.

7. Add the "Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time" condition to the rule, with Pattern Hit Percent less than as 5, Pattern name for membership: pattern created in step 4, Is Membership Count Less than patternHitPercent as "True," Time period type for pattern membership as Months, Time period for pattern membership as 3, and Member type for pattern membership as Shipping Address.

8. Set the rule result Action Group to OAAM Challenge.

Post conditions: Users who ship to a country that has been used in transactions less than 5% of the time over the past three months generate an alert.

Table 15-5 Shipping Address Country Pattern

Pattern Statement Breakdown	Oracle Adaptive Access Manager Security Policy Components
Profile e-commerce transactions	Transaction type is Retail Ecommerce
User is shipping goods to countries	Entity is user
Country the goods are shipping to	Attribute is Shipping.Address.Country
Create a bucket for each country	Creation method is multi-bucket; compare operator For each
Count the transactions shipped to each [country]	Pattern to collect country information for transactions Pattern tracks each user's shipping address country for Retail Ecommerce transactions
Rule	An alert triggers when the user ships to a country that is less than 5% of all the other countries shipped to
Condition	Pattern (Transaction): Entity is member of pattern less than some percent times condition
Policy to evaluate their current behavior against their own historical behavior.	OAAM User vs. Themselves
Percentage basis specified in rule	5%
Time period specified in rule	last 3 months
Checkpoint	Rule created in a policy that runs in the Transaction Update checkpoint
Rule result Action Group to OAAM Challenge	OAAM Challenge

15.21.15 Use Case: Shipping Address Country Pattern and Billing Mismatch

Mike is a security administrator who needs to profile e-commerce transactions based on the country the goods are shipping to and if the billing and shipping addresses are from different countries. He creates a pattern to create a bucket for each country and count the transactions shipped to each. He then implements a rule to generate an alert if a transaction is shipping to a country that less than 5% of all other orders have shipped to in the last 3 months and if the shipping address country and billing address country are not the same.

Prerequisites: Default snapshot is loaded. System has a defined transaction that represents the e-commerce transaction, such as the Retail Ecommerce transaction from oaam_sample. The transaction has entities or attributes that indicates the country in the shipping address and the country in the billing address.

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

3. Click New Pattern on the upper right of the console. This displays the New Pattern dialog for creating a new pattern.

4. Create a new multi-bucket pattern on the e-commerce transaction to create a bucket for each country and count the transactions shipped to each.

   1. In the New Pattern dialog, select Transaction Type as Retail Ecommerce, Creation Method as Multi-Bucket, Member Types as Shipping Address, and Evaluation Priority as High.

   2. In the Attributes tab, add a new attribute, selecting Country from the list and select for Each as the Compare Operator.

5. Creates a rule to generate an alert if a transaction is shipping to a country that less than 5% of all other orders have shipped to in the last 3 months and if the shipping address country and billing address country are not the same.

6. Open the OAAM User vs. All Users policy and add a new rule.

7. Add the "Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time" condition to the rule, with Pattern Hit Percent less than as 5, Pattern name for membership: pattern created in step 4, Is Membership Count Less than patternHitPercent as True, Time period type for pattern membership as Months, Time period for pattern membership as 3, and Member type for pattern membership as Shipping Address.

8. Add the "Session: Compare two parameter values" condition to the rule, with Parameter key 1 as Transaction.billingAddress.country, Operation as Not Equal To, Parameter key 2 as Transaction.shippingAddress.country, Ignore case as True, and if no data, return as False.

9. Set the rule result to generate an alert.

Post conditions: If a user ships to a country different from his billing address, and the shipping country is one that is used less than 5% of the time, then an alert is generated.

15.21.16 Use Case: Shipping Address Country IP Pattern

Mike is a security administrator who needs to profile if it is normal for any credit cards to be used in an e-commerce transaction to be made from an IP in the USA and ship to Nigeria. He creates a pattern to create a bucket for transactions made from an IP mapped to anywhere in the USA and shipped to anywhere in Nigeria and maintain counts for every credit card used. He then implements a rule to generate an alert if a card has at least 5 orders in the last year and has had a combination captured in this pattern and it has occurred in less than 25% all other orders from this card in the last 4 months.

Prerequisites: Default snapshot is loaded. System has a defined transaction that represents the e-commerce transaction. The transaction has an entity to represent the credit card and entities or attributes that indicate shipping country and user's country as resolved from their IP address.

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

3. Click New Pattern on the upper right of the console. This displays the New Pattern dialog for creating a new pattern.

4. Create a new single-bucket pattern on the e-commerce transaction to for transactions made from an IP mapped to anywhere in the USA and shipped to anywhere in Nigeria and maintain counts for every credit card used.

   1. In the New Pattern dialog, select Transaction Type as Retail Ecommerce, Creation Method as Single-Bucket, Member Types as Credit Card, and Evaluation Priority as High.

   2. In the Attributes tab, add a new attribute, selecting Country for the shipping address from the list, select In as the Compare Operator, and type nigeria as the Compare Value.

   3. In the Attributes tab, add a new attribute, selecting Country for the IP address from the list, select In as the Compare Operator, and type united states as the Compare Value.

5. Creates a rule to generate an alert if a card has at least five orders in the last year and has had a combination captured in this pattern and it has occurred in less than 25% all other orders from this card in the last 4 months.

6. Open the OAAM User vs. All Users policy and add a new rule.

7. Add the "Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time" condition to the rule, with Pattern Hit Percent less than as 5, Pattern name for membership: pattern created in step 4, Is Membership Count Less than patternHitPercent as True, Time period type for pattern membership as Months, Time period for pattern membership as 4, and Member type for pattern membership as Credit Card.

8. Add the "Transaction: Check Count of any entity or element of a Transaction using filter conditions" condition to the rule, with Select Transaction to check as Retail Ecommerce, select Entity or Element to count as Credit Card, specify Condition for Count as Greater Than Equal, specify Check value for Count as 5, Duration as 1 Rolling years, Ignore Current Transaction in count? as True, for the same user? as False, and apply the filter checks on Current Transaction as False.

9. Set the rule result to generate an alert.

Post conditions: If a user logged in from the US places an order with a shipping address in Nigeria, and does so with a card that has not been used in this manner 25% or more of the time over the last 4 months, an alert will be generated.

15.21.17 Use Case: Browser Locale Pattern

Mike is a security administrator who needs to profile users based on the browser locales they use when accessing. He creates a multi-bucket pattern for users by locale. This creates a bucket for each locale. He then develops a rule to challenge if the locale being used is one this user has never used previously.

Prerequisites: Default snapshot is loaded.

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

3. Click New Pattern on the upper right of the console. This displays the New Pattern dialog for creating a new pattern.

4. Create a new multi-bucket pattern on the authentication transaction to track each browser locale.

   1. In the New Pattern dialog, select Transaction Type as Internet Banking, Creation Method as Multi-Bucket, Member Types as Customer, and Evaluation Priority as High.

   2. In the Attributes tab, add a new attribute, selecting Locale from the list and select Compare Operator as for Each.

5. Create a rule to challenge if the locale being used is one this user has never used previously.

6. Open the OAAM User vs. Themselves policy and add a new rule.

7. Add the Pattern (Transaction): Entity is a Member of the Pattern Bucket for the First Time in a Certain Time Period condition to the rule, with Is condition True as True, Time period type for bucket membership as Years, Time period for bucket membership as 999, Member type for pattern-bucket membership as Customer, and First Time count as 1.

8. Set the rule result Action Group to OAAM Challenge.

Post conditions: A user who is using a locale that she has never used before is challenged.

15.21.18 Use Case: Credit Card by Shipping Address Country Pattern

Mike is a security administrator who needs to profile e-commerce transactions based on the credit card and country the goods are shipping to. He creates a pattern to create a bucket for each credit card and shipping address country and count the transactions. He then implements a rule to alert if a transaction uses a credit card that has been used more than five items and has shipped to the current country less than 5% of the time in the last 3 months.

Prerequisites: Default snapshot is loaded. System has a defined transaction that represents the e-commerce transaction. The transaction has entities that represent the credit card and the shipping address.

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

3. Click New Pattern on the upper right of the console. This displays the New Pattern dialog for creating a new pattern.

4. Create a new multi-bucket pattern on the e-commerce transaction for each credit card and shipping address country and count the transactions.

   1. In the New Pattern dialog, select Transaction Type as Retail Ecommerce, Creation Method as Multi-Bucket, Member Types as Credit Card, and Evaluation Priority as High.

   2. In the Attributes tab, add a new attribute, selecting Country for the shipping address from the list and select for Each as the Compare Operator.

5. Create a rule to alert if a transaction uses a credit card that has been used more than five items and has shipped to the current country less than 5% of the time in the last 3 months.

6. Open the OAAM User vs. Themselves policy and add a new rule.

7. Add the Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time condition to the rule, with Pattern Hit Percent less than as 5, Pattern name for membership as the pattern created in Step 4, Is Membership Count Less than patternHitPercent as True, Time period type for pattern membership as Months, Time period for pattern membership as 3, and Member type for pattern membership as Credit Card.

8. Add the Transaction: Check Count of Any Entity or Element of a Transaction Using Filter Conditions condition to the rule, with Select Transaction to check as Retail Ecommerce, select Entity or Element to count as Credit Card, specify Condition for Count as Greater Than, specify Check value for Count as 5, Duration as 3 Rolling months, Ignore Current Transaction in count? as True, for the same user? as False, and apply the filter checks on Current Transaction as False.

9. Set the rule result to generate an alert.

Post conditions: If a user ships to a country that has not been associated with his credit card at least 5% of the time in the last 3 months, and the card has been used more than 5 times in the last 3 months, the transaction triggers an alert.

15.21.19 Use Case: Credit Card by Dollar Amount Range and Time Pattern

Mike is a security administrator who needs to profile e-commerce orders based on the credit card, the frequency of orders and dollar amount ranges. He creates a pattern to create a bucket for each order amount range of $10 to profile credit cards. He then creates a pattern to profile the frequency ranges of orders by credit card. He then implements a rule to generate an alert if a transaction uses a credit card a number of times in the last 24 hours that is 40% higher than the average over the last three months and the credit card has had more than four orders falling into the same dollar amount range bucket in the last 24 hours.

Prerequisites: Default snapshot is loaded. System has a defined transaction that represents the e-commerce transaction. The transaction has an entity to represent the credit card and an entity or an attribute that indicates the dollar amount.

1. Log in to the OAAM Administration Console as an administrator.

2. Double-click Patterns in the Navigation pane. The Patterns Search page is displayed.

3. Click New Pattern on the upper right of the console. This displays the New Pattern dialog for creating a new pattern.

4. Create a new multi-bucket pattern on the e-commerce transaction to create a bucket for each order amount range of $10 to profile credit cards.

   1. In the New Pattern dialog, select Transaction Type as Retail Ecommerce, Creation Method as Multi-Bucket, Member Types as Credit Card, and Evaluation Priority as High.

   2. In the Attributes tab, add a new attribute, select Transaction Amount from the list. For the Attribute Details, select Compare Operator as Range, Start Value as 0, End Value as blank, and Increment Step as 10.

5. Create a new multi-bucket pattern on the e-commerce profile the frequency ranges of orders by credit card.

   1. In the New Pattern dialog, select Transaction Type as Retail Ecommerce, Creation Method as Multi-Bucket, Member Types as Credit Card, and Evaluation Priority as High.

   2. In the Attributes tab, add a new attribute, select Day of Month from the list and select Compare Operator as for Each.

6. Create a rule to generate an alert if a transaction uses a credit card that has fallen into frequency range bucket in the first 24 hours that it has not in the first three months and the credit card has had more than four orders falling into the same dollar amount range bucket in the last 24 hours.

7. Open the OAAM User vs. Themselves policy and add a new rule.

8. Add the Pattern (Transaction): Entity is a Member of the Pattern N Times in a Given Time Period condition to the rule, with Pattern name for membership as the pattern created in step 4, Time period for pattern membership as 24, Time period type for pattern membership as Hours, Member type for pattern membership as Credit Card, Bucket hit count as 4, Compare operator for the count as Greater than, Return value for condition is true as True, and Return value if condition encounters an error as False.

9. Add the Pattern (Transaction): Entity is Member of Pattern X% More Frequently Than Entity's Average Over Last N Time Periods condition to the rule, with Pattern Hit Percent greater than as 40, Pattern name for membership as the pattern created in step 4, Time period type for pattern membership as Months, Time period for pattern membership as 3, and Member type for pattern membership as Credit Card.

10. Set the rule result to generate an alert.

Post conditions: If a credit card falls into a 24-hour period frequency bucket that it has not been in the last three months, and has four transactions in the same dollar range in the past 24 hours, an alert will be generated.