15 Managing Autolearning

This chapter focuses configuring patterns to profile users, devices, and location to evaluate the risk of the current behavior. It contains the following sections:

15.1 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

This diagram illustrates pattern usage

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

    This diagram illustrates a 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

    This diagram illustrates multi-buckets

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

This diagram illustrates bucket evaluation

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

Bucket Evaluation Example

In this example a pattern was created to capture user 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 29, "FAQ/Troubleshooting."

15.3 Before You Begin to Use Autolearning

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

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

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 14.4, "Importing a 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 need to create a new 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 out-of-the-box autolearning policies, refer to Section 14.4, "Importing a 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 UpdateAuth Status API, an analyzePatterns value of "true" triggers the pattern processing for the login. If no value is passed, a value of false is assumed. If the authentication status value, resultStatus, is "success" and the analyzePatterns value is "true," OAAM processes the users's data and autolearning/profiling data is collected for the user. For any login, autolearning is performed only once if the authentication status is "success." If the authentication or transaction status is not "success," the buckets are not updated. If the buckets are not updated, the data that autolearning rules use may not be accurate.

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

15.4 User Flows

User flows are presented for:

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. In Fraud Prevention, expand the Navigation tree.

  2. Double-click Patterns.

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

    Alternative methods to open the search page are listed in Section 3.10, "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

    The pattern search page is shown.

    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 need to save it for completion later, select "Incomplete." Data is not collected for this state.

    • Invalid

      If there is a problem with the pattern, you can mark the pattern as invalid to signal other operators. No autolearning data analysis is performed for a pattern in this state.

    • Deleted

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

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

    Transaction Type

    The Transaction Definitions that have been configured in this specific Oracle Adaptive Access Manager installation.

    The type of process such as authentication (login), bill pay, wire transfer, address change, and so on that autolearning is profiling entities for.

    Creation Method

    The type of bucket the Pattern had been created as.

    • Single Bucket - Single-bucket patterns create and populate one bucket with the exact data points and value ranges specified in the pattern

    • Multi- Bucket – Multi-bucket patterns have buckets for sub-ranges of a parameter range


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

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

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

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

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 such general details about the pattern as the pattern name, status, member type, evaluation priority, and description.

The Pattern Details page provides the following three tabs:

  • Summary - General details such as pattern name, status, transaction type, and so on

  • Attributes - Displays attribute details such as definition, status, description and so on.

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

15.9 Creating and Editing Patterns

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

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 New Pattern

Follow this procedure to create a new pattern.

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

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

  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.10, "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" 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

    The pattern summary tab is shown.

    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

    The Add Attributes dialog is shown.

    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 29, "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 the Add button 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 Reference."

    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. Press the Activate button.

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 press the Deactivate button.

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

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 checkbox 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 press the Delete button.

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

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

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

To learn more about autolearning conditions, see Appendix 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.14.2, "Use Case: Test a Pattern."

15.13 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:

For more information, refer to Section B.2.1, "Autolearning Conditions" and Section 15.14, "Use Cases."

15.14 Use Cases

This section describes example use cases for autolearning and patterns.

15.14.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 a new 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.14.2 Use Case: Test a Pattern

Jeff a Security Administrator must make sure the pattern he configured in his use (see Section 15.14.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.14.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-8 Using Buckets to Track Off-Hour Access

This illustrates the use of buckets to track time

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 the New Pattern button 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 the Add button. 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.14.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 12, "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 Patternmembership

      hours

      Time Period Type for Pattern Membership

      Time Period Type for Pattern Membership

      1

      Member Type for pattern Membership

      MemberType for pattern Membership

      user


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

  6. Group link to user group.

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

15.14.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.2.1.2, "Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent 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.14.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 Member of 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.14.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, has to be configured in such a way that there is a percentage when the system knows that it should no longer challenge you. The system should automatically be smart enough to understand that you are logging in from Seattle every time now going forward and that it should not challenge you.

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

Example

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

  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 Member of Pattern Less Than Some Percent Time".

    • Fill in the values for the condition

      Label Default

      Pattern Hit Percent less than

      50

      Pattern name for membership

      UserLoginsCity

      Is Membership Count Less than patternHitPercent

      True

      Time period type for pattern membership

      Month

      Time period for pattern membership

      1

      Member type for pattern membership

      User


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

  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.14.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.14.9 Use Case: Using Pattern

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

The outcome should include a score and an alert.

Why use patterns for this scenario

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

Patterns are used in this scenario for the following reasons:

  • If rules are to track the frequency of behavior, the period for evaluating the frequency might be relatively long, especially if the evaluation requires months or even years. Using a pattern is recommended in these cases because rules will not have to perform large queries for results. Oracle Adaptive Access Manager checks the bucketing to see if the user is a member of the current state bucket that he is falling into now and the frequency at which he has fallen into that bucket.

  • Other rules that run can use the pattern, which tracks the state or frequency of state usage, for other types of risk evaluations. By using the same pattern, no overhead is incurred to impact performance.

Steps

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

  2. In the Navigation tree, double-click Patterns. The Patterns Search page is displayed.

  3. Click the New Pattern button.

    Create a pattern where:

    • Creation Method: Multi-bucket

    • Member Type: User

    • Evaluation Priority: High

    • Description: Pattern to track the state usage and frequency

    Click Create.

  4. Click the Attribute tab.

  5. Click the Add button.

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

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

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

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

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

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

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

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

  14. Select the Customer Care as the alert type.

  15. Select the Medium as the alert level.

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

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

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

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

  20. Search policies for Post-Authentication policies that are available.

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

    Because the rule being created will have the outcome of a KBA challenge, it will have to be in the Post-Authentication checkpoint. It must also be in a policy in which there is a check for KBA registration before this rule runs.

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

  22. Click Add.

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

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

  25. Enter 600 as the score.

  26. Enter 100 as the weight.

  27. Select ChallengeQuestionPad as the action.

  28. Select StateNotUsedOften as the alert.

  29. Click the Conditions tab.

  30. 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 Patternmembership

    month

    Time Period Type for Pattern MemberShip

    Time Period Type for Pattern MemberShip

    1

    MemberType for pattern Membership

    MemberType for pattern Membership

    user


  31. Click Save to save your changes.

    A confirmation dialog displays the status of the operation.

  32. Click OK to dismiss the confirmation dialog.

15.14.10 Use Case: Logins from Out of State

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

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

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

  3. Save the policy and rule.

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

  5. Add a user to the "Whitelisted User Group".

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

  7. Save the policy and rule.

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

15.14.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 the "Internet Banking" transaction from the OAAM sample application.

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

  2. Create a user multi-bucket pattern to create dollar ranges of $100.

    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 the New Pattern button on the upper right of the console. This displays the New Pattern screen for creating a new pattern.

    3. Enter the Pattern Name. In this example it is User: wire transfer profiling pattern.

    4. Select Internet Banking as the Transaction type since you will be profiling the user's behavior based on internet transactions.

    5. Select Customer as the Member Type.

    6. Select Multi Bucket as the Creation Method since you need to create dollar ranges of $100.

    7. Select High as the Evaluation Priority so that it is processed first.

    8. Enter a description and click Create. A page with details of your pattern is displayed.

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

    10. Click the Add button. 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.

    11. Select Amount from the list and click Next.

    12. Enter a description for this attribute.

    13. Select Range as the Compare Operator.

    14. Enter 0 as the Start Value and leave the End Value blank.

    15. Enter 100 as the Increment Step since the transaction amount is collected in ranges of 100.

    16. Click Add.

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

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

    2. Open the OAAM User vs. Themselves policy.

    3. Click the Rules tab and the Add button.

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

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

      customer


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

    6. Open the Results tab.

    7. Enter a score.

    8. Enter the weight.

    9. Set the rule result Action Group to "OAAM Challenge."

  4. Click Save to save your changes.

    A confirmation dialog displays the status of the operation.

  5. 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.14.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. The Analyst opens the OAAM Administration Console.

  2. The Analyst sees only the appropriate user interface controls afforded his role.

  3. The Analyst selects the action to create a new pattern.

  4. The Analyst creates 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, the Analyst selects 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, the Analyst adds a new attribute, selecting "Time" from the list. For the Attribute Details, the Analyst selects Compare Operator as "Range," Start Value as "0," End Value as "23," and Increment Step as "8."

  5. The Analyst creates 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. The Analyst opens the OAAM User vs. Themselves policy and adds a new rule.

  7. The Analyst adds 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. The Analyst sets the rule result to generate an alert.

Post conditions: Users who perform a number of 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.14.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. The Analyst opens the OAAM Administration Console.

  2. The Analyst sees only the appropriate user interface controls afforded his role.

  3. The Analyst selects the action to create a new pattern.

  4. The Analyst creates 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, the Analyst selects 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, the Analyst adds a new attribute, selecting "Time" from the list. For the Attribute Details, the Analyst selects 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. The Analyst opens the OAAM User vs. All Users policy and adds a new rule.

  6. The Analyst adds 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. The Analyst sets the rule result to generate an alert.

Post conditions: Users who perform a number of 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.14.14 Use Case: Shipping Address Country Pattern

Mike is a security administrator who needs to profile ecommerce 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 ecommerce 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. The Analyst opens the OAAM Administration Console.

  2. The Analyst sees only the appropriate user interface controls afforded his role.

  3. The Analyst selects the action to create a new pattern.

  4. The Analyst creates 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, the Analyst selects 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, the Analyst adds a new attribute, selecting "Country" from the list and selecting "for Each" as the Compare Operator.

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

  5. The Analyst creates 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. The Analyst opens the OAAM User vs. Themselves policy and adds a new rule.

  7. The Analyst adds 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. The Analyst sets 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-2 Shipping Address Country Pattern

Pattern Statement Breakdown Oracle Adaptive Access Manager Security Policy Components

Profile ecommerce 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.14.15 Use Case: Shipping Address Country Pattern and Billing Mismatch

Mike is a security administrator who needs to profile ecommerce 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 ecommerce 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. The Analyst opens the OAAM Administration Console.

  2. The Analyst sees only the appropriate user interface controls afforded his role.

  3. The Analyst selects the action to create a new pattern.

  4. The Analyst creates a new multi-bucket pattern on the ecommerce transaction to create a bucket for each country and count the transactions shipped to each.

    1. In the "New Pattern" Dialog, the Analyst selects 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, the Analyst adds a new attribute, selecting "Country" from the list and selecting "for Each" as the Compare Operator.

  5. The Analyst 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. The Analyst opens the OAAM User vs. All Users policy and adds a new rule.

  7. The Analyst adds 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. The Analyst adds 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. The Analyst sets 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.14.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 ecommerce 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 ecommerce 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. The Analyst opens the OAAM Administration Console.

  2. The Analyst sees only the appropriate user interface controls afforded his role.

  3. The Analyst selects the action to create a new pattern.

  4. The Analyst creates a new single-bucket pattern on the ecommerce 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, the Analyst selects 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, the Analyst adds a new attribute, selecting "Country" for the shipping address from the list, selecting "In" as the Compare Operator, and typing "nigeria" as the Compare Value.

    3. In the Attributes tab, the Analyst adds a new attribute, selecting "Country" for the IP address from the list, selecting "In" as the Compare Operator, and typing "united states" as the Compare Value.

  5. The Analyst 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. The Analyst opens the OAAM User vs. All Users policy and adds a new rule.

  7. The Analyst adds 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. The Analyst adds 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," Specified Condition for Count as "Greater Than Equal," Specified 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. The Analyst sets 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.14.17 Use Case: Browser Locale Pattern

Mike is a security administrator who needs to profile users based on the browser locales they utilize 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. The Analyst opens the OAAM Administration Console.

  2. The Analyst sees only the appropriate user interface controls afforded his role.

  3. The Analyst selects the action to create a new pattern.

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

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

    2. In the Attributes tab, the Analyst adds a new attribute, selecting "Locale" from the list and selects Compare Operator as "for Each".

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

  6. The Analyst opens the OAAM User vs. Themselves policy and adds a new rule.

  7. The Analyst adds 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. The Analyst sets 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.14.18 Use Case: Credit Card by Shipping Address Country Pattern

Mike is a security administrator who needs to profile ecommerce 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 ecommerce transaction. The transaction has entities that represent the credit card and the shipping address.

  1. The Analyst opens the OAAM Administration Console.

  2. The Analyst sees only the appropriate user interface controls afforded his role.

  3. The Analyst selects the action to create a new pattern.

  4. The Analyst creates a new multi-bucket pattern on the ecommerce transaction for each credit card and shipping address country and count the transactions.

    1. In the "New Pattern" Dialog, the Analyst selects 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, the Analyst adds a new attribute, selecting "Country" for the shipping address from the list and selects "for Each" as the Compare Operator.

  5. The Analyst creates 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. The Analyst opens the OAAM User vs. Themselves policy and adds a new rule.

  7. The Analyst adds 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 "Credit Card."

  8. The Analyst adds 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," Specified Condition for Count as "Greater Than," Specified 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. The Analyst sets 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.14.19 Use Case: Credit Card by Dollar Amount Range and Time Pattern

Mike is a security administrator who needs to profile ecommerce 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 ecommerce transaction. The transaction has an entity to represent the credit card and an entity or an attribute that indicates the dollar amount.

  1. The Analyst opens the OAAM Administration Console.

  2. The Analyst sees only the appropriate user interface controls afforded his role.

  3. The Analyst selects the action to create a new pattern.

  4. The Analyst creates a new multi-bucket pattern on the ecommerce transaction to create a bucket for each order amount range of $10 to profile credit cards.

    1. In the "New Pattern" Dialog, the Analyst selects 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, the Analyst adds a new attribute, selecting "Transaction Amount" from the list. For the Attribute Details, the Analyst selects Compare Operator as "Range," Start Value as "0," End Value as blank, and Increment Step as "10."

  5. The Analyst creates a new multi-bucket pattern on the ecommerce profile the frequency ranges of orders by credit card.

    1. In the "New Pattern" Dialog, the Analyst selects 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, the Analyst adds a new attribute, selecting "Day of Month" from the list and selecting Compare Operator as "for Each."

  6. The Analyst creates 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. The Analyst opens the OAAM User vs. Themselves policy and adds a new rule.

  8. The Analyst adds 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: 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. The Analyst adds 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: 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. The Analyst sets 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.

15.15 Autolearning Properties

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

Property Default Value Property Type Is Dynamic Comments

vcrypt.bharosa.autolearning.numPriorities

2

Integer

No

This creates the number of threadpools as the number of priorities. These threadpools are used for post processing the autolearning data. This number should be more than 1.

vcrypt.bharosa.autolearning.threadMultiplier

7

Integer

No

This number is used to create the number of threads for post processing. These threads are part of the threadpool that is used for post processing autolearning data. Keep this number to at least 5.

vcrypt.tracker.autolearnin.enabled

true

Boolean

Yes

This flag is used to control the status for the product level. Setting the value to false disables some of the post processing for autolearning. Rules continue to run but may be using stale data.

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

false

Boolean

Yes

This flag is used when the client code does not explicitly call the autolearning API. If you want autolearning (post processing) to occur but do not want to change the client code, setting this flag to true results in autolearning processing for the authentication type of updateAuthStatus requests if the status is SUCCESS for that authentication request. However if the status is not SUCCESS, autolearning does not occur. Running autolearning rules with this flag set to false runs the rules on the data that is stale. If this flag is set to false and autolearning rules are running, and if the log level is set to "debug" for "com.bharosa.vcrypt.tracker.rules.impl.VCryptTrackerAutoLearningImpl" class; then a message is written to the log saying that this property is disabled and rules are still being run.

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.16 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 "todays day column," autolearning is working. Note: If today is the 15th then look into the Day_15 column in the records returned by this database query.

15.17 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.18 Autolearning Classes and Logging

Important classes for logging to debug level is summarized below.

Table 15-3 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.19 Pattern Attributes Reference

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)

dayOfMonth

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

monthOfTheYear

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

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

ASN

A unique identifier of an autonomous system on the Internet. Along with other comparators, "for each" is available because if you come from another ASN, you could track that as another bucket. For this attribute, the "equal to" comparator is not available because users will not know the ASN since it is not exposed.

Integer

Equal, Not Equal, For Each, Less than, Less than Equal to, greater than, greater than equal to, in, not in, range

Positive integer value

multi-bucket

  • User - themselves and all

  • Device - themselves and all

  • Location - themselves and all

User ID

User's Identification Number

String

For each, in, not in, like, not like

String value

multi-bucket

  • Device - themselves

  • Location - themselves

Group ID

Group Identification Number

String

For each, in, not in, like, not like

any String value

multi-bucket

  • Device - themselves

  • Location - themselves

Device ID

Device Identification Number

Integer

Equal, Not Equal, For Each, Less than, Less than Equal to, greater than, greater than equal to, in, not in, range

any String value

multi-bucket

  • User - themselves

  • Location - themselves

Remote IP

This is the IP address where the authentication is from. It could be the real IP of the user, anonymizer, proxy, or gateway, and so on, to which the end user is connected to.

String

For each, in, not in, like, not like

format a.b.c.d

multi-bucket

  • User - themselves

  • Device - themselves

Is Registered

This attribute tracks if the user needs to be tracked on the "isRegistered" criterion. So if the user is a registered user (completed registration), he is treated in the pattern one way, and if he is not a registered user (has not completed registration), he is treated another way.

Boolean

For each, not equal, equal

True or False

multi-bucket

User - themselves

ISP

The ID for an Internet connection service provider.

Long

For each, equals, less than, less than equal to, greater than, greater than equal to, in, not in, not equal, range

Any positive number

multi-bucket

  • User - themselves and all

  • Device - themselves and all


15.20 Pattern Attributes Operators Reference

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

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

Numbers corresponding to the days of the week are:

  • 1 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-9 Range Compare Operator

The range attribute dialog is shown.

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.