Oracle® Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager Release 11g (11.1.1) E14568-02 |
|
![]() Previous |
![]() Next |
Autolearning is a set of features in Oracle Adaptive Access Manager that dynamically profile behavior in real-time. The behavior of users, devices and locations are recorded and used to evaluate the risk of current behavior.
This chapter focuses on managing and using the Autolearning features in the following sections:
This section introduces you to the concepts of autolearning and how they are used.
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.
Patterns record the behavior of the users, device and locations accessing the system by creating a digest of the access data. The digest or profile information is then stored in a historical data table and used for calculating the current risk using rules.
Patterns require that bucketing, member types, and attributes to be defined. As well, rules must be configured to harness the profiling conducted by the patterns.
Patterns are used by Oracle Adaptive Access Manager to either define one bucket or dynamically create buckets. Oracle Adaptive Access Manager collects data and populates these buckets with members based on pattern parameters, and rules perform risk evaluations on dynamically changing membership and distributions of the buckets. Pattern evaluation and population occurs only when the result of the transaction is successful.
Bucket Creation and Population
Figure 14-1 shows a bucket creation and population example.
If you want to track employee login times, you would:
Set up a pattern where the member type is User and the attribute is Time.
Choose multi-bucket as the creation method for the pattern. A multi-bucket pattern creates as many buckets as required to capture behaviors as opposed to a single-bucket pattern which only creates one to capture a specific behavior.
Set start time=0:00 and end time=23:59, which are the hours of the day, and a increment step size of 8 hours.
During the processing of the transaction/login data, Oracle Adaptive Access Manager creates the buckets as required and populates them with counts for each member. Each bucket will automatically keep from overlapping with each other based on the other buckets already in the system. As shown in Figure 14-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 will be incremented by one. If no user has ever logged into this system between 7:00 and 14:59 then Oracle Adaptive Access Manager will also create that bucket as part of the processing. This 7:00 and 14:59 bucket then would be used to record login time behavior for all users going forward.
After creation, the buckets will be populated with the logins of users that have fallen within each 8-hour time range.
Oracle Adaptive Access Manager will only record that Jeff used this computer if he logs in successfully. This validates that what is recorded is most likely Jeff's real behavior and not a fraudulent attempt to log in using Jeff's credentials. The memberships and associated statistics will be saved in each user profile.
To profile behavior, members and attributes are required.
Members and attributes act as a guide for Oracle Adaptive Access Manager to analyze data. Member is the actor in the system. Examples of actors are user, IP address used for logging in, and so on.
Attributes are the particular pieces of information associated with the activity being tracked. An example is the time of day for a login. Patterns collect data about members. If the member type is User, the pattern will collect 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 will be 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 will be more flexible and manageable in the long run.
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 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.
Multi-bucket patterns usually create more buckets than single-bucket patterns. They create buckets as required based on the parameter configurations.
You configure the data types and samples you want Oracle Adaptive Access Manager to generate buckets from, and then during pattern processing Oracle Adaptive Access Manager creates buckets as needed to capture behaviors.
For example:
If you specify "For each" as the compare operator and country as the attribute, Oracle Adaptive Access Manager will create a bucket dynamically for each country as activity occurs from the country. The first time any user logs in from Canada, Oracle Adaptive Access Manager will create a Canada bucket and add that user as a member with a count of one. The next user to log in from Canada will be added to that same bucket as a member with a count of one. Each subsequent time a user logs in from Canada his Canada bucket counter will be incremented.
Buckets are not created until they are needed. If you choose user logins for a 24-hour range with an increment step size of 8 then up to 3 buckets will be created, one for each 8-hour time slot in which logins occur.
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 look at either the individual's current behavior versus his past behavior or the individual's current behavior versus the past behavior of all individuals.
The Autolearning feature tracks transactions and authentications being performed by different actors (entities) based on patterns you create. This process establishes what is normal or average behavior for an individual or a population.
In this example John's login behavior is being evaluated against his own profile and the profile of all users.
Bucket Evaluation Example
In this example a pattern was created to capture user, device and IP login time behavior. The multi-bucket pattern was configured to create buckets to cover the entire 24 hours of the day in four hour samples. Consequently, OAAM ended up creating four time buckets as login activity occurred within each time range.
Buckets | Time Range |
---|---|
Bucket #1 | 0:00 to 4:59 |
Bucket #2 | 5:00 to 8:59 |
Bucket #3 | 9:00 to 16:59 |
Bucket #4 | 17:00 to 23:59 |
After a month of recording, the system has created four time buckets and populated them with members and counters for each member. The three entities now have the following bucket memberships.
Entity | Membership |
---|---|
User A | #3 |
Device X | #2, #3, #4 |
IP Y | #2, #3 |
Evaluation of the memberships produces the following conclusions:
Note: These scenarios are not a sequence; each is a distinct scenario. |
Scenarios | Risk |
---|---|
If User A logs in at 3:37 using Device X from IP Y | very high risk (none are in #1) |
If User A logs in at 18:07 using Device X from IP Y | medium - high risk (device in #4) |
If User A logs in at 8:27 using Device X from IP Y | medium risk (device and IP in #2) |
If User A logs in at 11:15 using Device X from IP Y | very low risk (all in #3) |
The following paragraph describes the first scenario in more granular detail.
If User A logs in at 3:37 and he has previously only logged in between 9:00 and 16:59 that elevates the risk because he is not a member of the Bucket #1. If Device X is used and it has previously only been used between 5:00 to 23:59 that elevates the risk because User A and Device X are not members of Bucket #1. And, if IP Y is used and it has previously only been used between 5:00 to 16:59 that elevates the risk as well since User A, Device X, and IP Y are all not members of Bucket #1. Since all three of the major components involved in the risk evaluation are not in bucket #1 the overall risk level is very high. It's important to emphasize that each of these elements is evaluated for membership in the time profiles independently in this example.
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 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.
The chapter has been organized into sections by topic. If you have used autolearning before, use this chapter effectively in any order that is convenient for you.
If you want profiling and autolearning enabled in your system, follow this procedure:
Make sure entities are imported.
See Section 14.3.1, "Importing Basic Authentication-Related Entities."
Enable autolearning properties.
Create patterns.
Define patterns, add attributes, and activate /enable the patterns so that the system can start collecting pattern data.
Finally, use the patterns in rule evaluation.
For information on using autolearning, see Section 14.12, "Using Autolearning Data/Profiling Data."
To verify that autolearning is turned on and working, see Chapter 25, "Troubleshooting."
Before using the Autolearning feature, read through Section 14.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.
The actors that are tracked during authentication are called authentication entities and include user, city, device, and so on. These basic entities are required to enable conditions that are used for patterns. Before you begin using the Autolearning feature, you must import these basic entities into your system. Basic required entities are shipped along with Oracle Adaptive Access Manager in the Auth_EntityDefinition.zip file, which is located in the oaam_init directory.
To import the entities:
Navigate to the Entities Search page, as described in Section 16.2, "Navigating to the Entities Search Page."
Click Import Entities.
In the Import Pattern screen, click Browse and locate Auth_EntityDefinition.zip.
Click OK.
OAAM Admin shows the entities in that file.
Select and import all of them.
Enable autolearning so that OAAM collects profiling data.
Ensure that vcrypt.tracker.autolearning.enabled is set to true.
The default value is true. It is like a "master (on/off) switch" for autolearning.
If this property is absent, this default value is used. If the property is present, the assigned value is used.
Set the following properties to true:
If the properties do not exist, create them.
vcrypt.tracker.autolearning.use.auth.status.for.analysis
This property must be set to true for the authentication patterns to work. Authentication patterns are the patterns that are used in processing the data relevant to authentication (login) related information only.
vcrypt.tracker.autolearning.use.tran.status.for.analysis
This property must be set to true for the transaction-related patterns to work. Transaction related patterns are the one that process the transaction related data for autolearning. An example is a pattern that profiles users who are performing wire transfer operations.
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" will trigger 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 A, "Pattern Processing."
User flows are presented for:
These steps describe the Create New Pattern flow:
Search for a pattern.
If pattern exists, view pattern details.
If pattern does not exist, create new pattern.
Specify pattern name, member type, evaluation priority, and description.
Add attributes.
If there are no validation errors, the new Pattern will be created successfully.
The following steps describe the Edit Pattern flow.
Note: If you edit a Pattern the data that is already collected based on that pattern could potentially become unusable. For example, if a user edits a Pattern and removes one of the attributes, the data that was collected previously may not be usable since the buckets created in the past for this Pattern would have taken into account the attribute that is now being removed. |
Search for a pattern.
If Pattern exists, view pattern details.
Change details.
Add attributes.
If there are no validation errors, the pattern will be edited successfully.
To navigate to the Patterns Search page:
In Fraud Prevention, expand the Navigation tree.
Double-click Patterns.
The Patterns Search page is displayed with results based on the default search criteria.
Alternative methods to open the search page are listed in Section 3.9, "Access to 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
To search for a Pattern:
Navigate to the Patterns Search page, as described in Section 14.5, "Navigating to the Patterns Search Page."
An example Patterns Search page is shown in Figure 14-6.
The Pattern Search page displays a Search section and a Results table that shows a summary of the patterns that match your search criteria.
Specify criteria in the Search Filter to locate the pattern and click Search.
The search filter criteria are described in Table 14-1.
If you want to reset the search parameters to the default setting, use the Reset button.
Table 14-1 Search Filter Criteria
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.
Follow these steps to navigate to a Pattern Details page.
If you are not on the Patterns Search page, follow the instructions in Section 14.5, "Navigating to the Patterns Search Page."
Search for the pattern of interest, by following the instructions in Section 14.6, "Searching for a Pattern."
There is a link on the pattern name in the Search Results table.
Click the pattern name and the Pattern Details page for the specific pattern appears.
From Pattern Details, you can select the member type and change the pattern name, pattern status, evaluation priority, and description after the pattern is created; add attributes, and view the pattern usage points.
This section provides details on viewing patterns.
By clicking the pattern name on the Patterns Search page, the Pattern Details page for the specific pattern appears. For instructions, see Section 14.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).
This section explains how to create and edit patterns. It contains the following topics:
Best Practices for Autolearning and Pattern Creations
Best practices for autolearning and pattern creations are:
For autolearning configurations: Administrators should keep in mind that any tracking of behavior warrants computational power and storage space and be prudent in configuring the system for the most returns on the efforts.
Best practices for pattern creation: When creating patterns, you must ensure that other patterns in your system are not already collecting the same kind of information. For example, if you create a pattern to collect login time information on user and IP, and then you create another pattern on user and login time, you are creating two patterns that are collecting the same information.
Best practices to keep Oracle Adaptive Access Manager current and relevant given the evolving online security threats: autolearning technology automatically adjust to changing activity and behaviors. For example, autolearning profiles what normal behavior is for each user and all users. In this way security policies are dynamically adjusting in real-time to how users really acts rather than a guess at how they will act. In addition to the automated features it is recommended that security policy be reviewed on a regular basis to make sure they are behaving as expected.
For heavy pattern usage: You might assign different evaluation priorities to various patterns. For example, you can set login patterns to High and other patterns to Low.
For evaluation property: Ensure that you do not set "High" as the evaluation priority for all your patterns, since performance will be impacted by doing so.
Procedure to Create a New Pattern
Follow this procedure to create a new pattern.
All values except transaction type can be modified later in the Pattern Details page.
Transaction type, Creation Method, Member Type, Evaluation Priority, and Description are required fields.
Navigate to the Patterns Search page, as described in Section 14.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, click the New Pattern button or the New icon.
Alternative methods to open the New Pattern page are listed in Section 3.9, "Access to Search, Create, and Import."
In the New Pattern page, enter the pattern name.
A unique pattern name must be entered.
Select the transaction type.
The default transaction type is Authentication.
Other transaction types shown are the transaction definitions that have been set up in your system.
Only active transaction types are available in the list.
Examples of transaction types are authentication, bill pay, money transfer, merchant purchase, credit card, and others. For example, if you select merchant purchase as the transaction type, you want to gather data on the activity of all the members during merchant purchases.
From the Creation Method list, select the method you want to use to create the pattern.
Select a member type.
The member type is the actor for which data must be captured.
For example, if you select city as the member type, the pattern created collects city data.
Member type list values depend on the transaction type selected.
If the Transaction Type selected is Authentication, member types available are User, City, State, Country, and others.
If, the Transaction Type selected is any transaction from the database, for example, Retail Commerce, Internet, Bill Pay, the member types available are data elements for that transaction. For example, if the Transaction Type is Internet Banking, the member type data elements could be customer and bank name.
One or more member types can be selected for a pattern
Select a evaluation priority
Evaluation priority is the priority in which data is evaluated. There are two evaluation priorities: High and Low.:
High
There is double the amount of resources made available to process the pattern data in this category as compared to the "Low" priority.
Resources include processing resources and database resources.
Low
There is half the amount of resources made available to process the pattern data in this category as compared to the "High" high priority.
The chances for finishing the processing of high priority pattern data are doubled the chances for finishing the low priority patterns.
Enter a description.
Click Apply.
The Pattern Details page is opened with the Summary and Attributes tabs.
If you try to create a pattern that already exists in the database, an error occurs.
If you try to create a pattern with the same members as another pattern, a message appears: "A pattern with the same member configuration already exists. Are you sure you want to create a new pattern? If you answer "yes," you are allowed to create the pattern.
The pattern is enabled upon creation and the Pattern Details page is displayed. You can edit or review the pattern.
Patterns can be created without any attributes.
Add attributes.
For information, see Section 14.9.2, "Adding Attributes."
For information on attributes, see Section 14.1.3, "Member Types and Attributes."
Activate the pattern.
To activate the pattern, see Section 14.9.3.1, "Activating Patterns."
To use the patterns in rule evaluation, see Section 14.12, "Using Autolearning Data/Profiling Data."
To verify that autolearning is working, see Chapter 25, "Troubleshooting."
For information on attributes, see Section 14.1.3, "Member Types and Attributes."
Follow these steps to add attributes.
If you are not on the Pattern Details page of the pattern, follow the instructions in Section 14.8.1, "Viewing Details of a Specific Pattern."
In the Attributes tab, click the Add button in the Search Results toolbar.
In the Add Attributes screen, select an attribute or attributes from the Add list.
Select attributes (data points) you are interested in for the member type. OAAM collects data on the attributes to determine if the member belongs to the profile.
For example, if you select "user" as the member type and the attributes: IP (NNN.N.N.N), City (Redwood City) and Is Registered (False); OAAM records when users match all of these attributes--the user has an IP address of NNN.N.N.N, who lives in Redwood City, and who is not registered. This profiling can then be used to evaluate risk for the "user."
For example, if you want OAAM to track the login times for "user" and "IP" (member type), you would select "time" as an attribute.
After the attributes are added, they are not available in the list for further selection.
Specify the condition information for the attribute.
Select the Status.
For example, "Active" if you want OAAM to collect data on the attribute to be used in the pattern membership.
Enter the description.
For example, "This pattern creates buckets to track login times for users and IPs."
Select a compare operator.
For example, "range" with start value of 0 and end value of 23 if we 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 14.14, "Pattern Attributes Operators Reference."
Enter Increment Step.
The sample size (interval)
For example, 2 for 2 hour intervals.
Click Add.
In the Attributes tab, use the arrow controls to reorder the attributes if you want.
Order is not required and is automatically pre-filled.
Click Apply.
A dialog appears, with the message that the attribute was added successfully to pattern.
Click OK to dismiss the dialog.
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.
Navigate to the Patterns Search page, as described in Section 14.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, enter the search criteria you want and click Search. For information, see Section 14.6, "Searching for a Pattern."
Select the row for each pattern you want to activate.
Press the Activate button.
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 a pattern, from the Patterns Search page select the row for each pattern you want to deactivate and press the Deactivate button.
To deactivate a pattern from the Pattern Details page, press the Deactivate button.
Care should be taken when editing patterns. Potentially, data that is already collected based on that pattern may no longer be usable after the edit.For example the data would be unusable if you remove one of the attributes and the buckets created in the past for the pattern had taken into account the attribute that is being removed.
To edit the details of a specific pattern:
If you are not on the Pattern Details page of the pattern you want to edit, follow the instructions in Section 14.7, "Navigating to the Patterns Details Page."
To change the pattern name, evaluation priority, and description, edit the appropriate fields in the Summary tab of the Pattern Details page.
To change the status, select from the status you want.
To change the status of the pattern, see Section 14.9.5, "Changing the Status of the Pattern."
Add or change the member types.
For information, see Section 14.9.6, "Adding or Changing Member Types."
For information about member types, see Section 14.1.3, "Member Types and Attributes."
Change the evaluation priority
To change the evaluation priority, see Section 14.9.7, "Changing the Evaluation Priority."
To add attributes, see Section 14.9.2, "Adding Attributes."
For information on attributes, see Section 14.1.3, "Member Types and Attributes."
To edit attributes, see Section 14.9.8, "Editing Attributes."
To delete attributes, see Section 14.9.9, "Deleting Attributes."
Click Apply.
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 will be performed for 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. |
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 14.1.3, "Member Types and Attributes."
Follow these steps to add or change member types.
If you are not on the Pattern Details page of the pattern, follow the instructions in Section 14.7, "Navigating to the Patterns Details Page."
In the Summary tab, add or change the actor you want to capture data.
For example, user is the member type if you want to collect information about the user.
Follow these steps to change the evaluation priority.
If you are not on the Pattern Details page of the pattern, follow the instructions in Section 14.7, "Navigating to the Patterns Details Page."
In the Summary tab, change the evaluation priority.
Follow these steps to edit attributes.
Click the Attributes tab of the Pattern Details page.
If you are not on the Pattern Details page of the pattern you want to edit, follow the instructions in Section 14.8.1, "Viewing Details of a Specific Pattern."
In the Attributes page, select the attribute you want to edit.
Edit the attribute details and click Save.
Reorder the attributes if you want.
Click Apply.
Care should be taken when deleting attributes. For example the data would be unusable if you remove one of the attributes and the buckets created in the past for the pattern had taken into account the attribute that is being removed.
Follow these steps to delete attributes.
Click the Attributes tab of the Pattern Details page.
If you are not on the Pattern Details page of the pattern you want to edit, follow the instructions in Section 14.8.1, "Viewing Details of a Specific Pattern."
In the Attributes page, click the checkbox next to the Attribute(s) you want to delete from the pattern.
Click Delete.
If you delete an attribute, it is added to the Add list and becomes available the next time you select Attributes.
You may want to import and export patterns from other applications. This section explains how to import and export patterns.
Navigate to the Patterns Search page, as described in Section 14.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, click Import Pattern.
In the Pattern Import screen, click Browse and locate the pattern file you want to import.
Click OK.
Navigate to the Patterns Search page, as described in Section 14.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, enter the search criteria you want and click Search. For information, see Section 14.6, "Searching for a Pattern."
Select the row for each pattern you want to export.
Select Export Selected from the Actions menu.
In the Export Patterns screen, click Export.
In the Save screen, click OK.
If you have an active pattern and it has collected data, you are not allowed to delete the pattern.
Patterns can be deleted only if there is no association with data and rules. A message appears, saying: "There might be pattern data or associated rules using the data and may become out of sync. Are you sure you want to update?"
When multiple patterns are selected for deletion and if some of the patterns are used or linked to other systems, a warning message appears, stating: "The following instances are linked and cannot be deleted. Do you want to delete the other patterns?" If you answer "yes", the unlinked patterns are deleted.
To delete patterns:
Navigate to the Patterns Search page, as described in Section 14.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, enter the search criteria you want and click Search. For information, see Section 14.6, "Searching for a Pattern."
Select the row for each pattern you want to delete and press the Delete button.
If the patterns selected for deletion are not used or linked to a policy, a warning message is shown asking for confirmation. If you answer "yes", those patterns are deleted.
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.
Create a policy that will use the autolearning conditions.
For instructions to create a policy, see Section 14.13.1, "Use Case: Challenge Users If Log In Different Time Than Normally."
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 14.13.4, "Use Case: User Logs in During a Certain Time of Day More Than X Times."
The rule will evaluate the pattern you selected and autolearning processing will be performed.
To learn more about autolearning conditions, see Appendix B, "Conditions Reference."
Perform logins/transactions and check the session details to make sure that the policy that was created triggers and data is collected for patterns and buckets.
For information on how to find out whether the pattern is working properly, see Section 14.13.2, "Use Case: Test a Pattern."
This section describes example use cases for autolearning and patterns.
Jeff is a Security Administrator at Dollar Bank. He wants to challenge users with an OTP if they are logging in at a time of day they do not normally come in. To do this he must configure a security policy and associated groups, rules and patterns.
Jeff starts with the pattern. He performs a search for patterns that have users as members since his use case focuses on the behavior of users.
He sees there are two patterns that have users as members. Neither of them has a time range attribute that works for his use case so Jeff must create a new one.
Jeff creates a multi-bucket login checkpoint pattern with "user" member type and first evaluation priority. He then adds a time range attribute from 0:00 - 23:00 and a step size of 4. This pattern creates and populates 6 time range buckets as users log in.
Jeff searches for the Post-Authentication checkpoint policies already in the system. There are four of them. Since he wants to challenge with an OTP he wants a policy that contains other rules with OTP challenge outcomes.
Next Jeff requires a rule to evaluate the bucket memberships. Jeff searches the rules for one that evaluates if a member has fallen into the current bucket less than a specified percentage in the last specified period. He does not find one so he create one using a user in bucket less than % of time condition.
Jeff adds the rule to the policy and links the pattern.
He then must link action and alert groups. Jeff searches for an action group that contains the challenge OTP action. He finds that there is one already so he links it to the rule.
He searches for an alert group by "time" in the alert message text. He finds one alert group that has an alert with the alert text "device has failed to log in successfully more than 10 times". This alert is not appropriate for his rule so he decides to create a new alert group and alert.
Jeff creates a new alert group for his alert. He then adds a new medium alert to the group with the text "User has fallen into this login time bucket less than 5% of the time in the last 3 months".
Finally Jeff links the alert group to the rule.
He performs log ins to the system to start autolearning.
Jeff a Security Administrator must make sure the pattern he configured in his use (see Section 14.13.1, "Use Case: Challenge Users If Log In Different Time Than Normally") is working properly.
To test the pattern:
One morning at 9:30 am he creates a new test user and then performs 7 successful logins.
At 3 pm of that day, he performs 3 successful logins.
The next day he logs in at 7 pm and is challenged with an OTP.
This occurs because he has fallen into the 7 pm time bucket less than 5% of the time in the last month.
After the policy and pattern have been in the production system for a month he checks to see if the bucketing in the rule evaluation is accurate. Jeff runs a report to find users that triggered the rule by searching for sessions with the alert, "User has fallen into this login time bucket less than 5% of the time in the last 3 months".
He then selects a few of them and searches for their bucket memberships for this pattern in the last month.
In this way Jeff can see the session where the alert was triggered was at a time that fell into a bucket it had not previously fallen into more than 5% of the time in the last month. From that, Jeff confirms that the policy configuration and pattern are functioning as designed.
Jeff is a Security Administrator at Dollar Bank. He wants to track off-hour access by employees based on a standard day shift. To do this, he must create a pattern for behavior-based profiling on time.
The pattern profiles the login times of users into three 8-hour buckets.
Navigate to the Patterns Search page, as described in Section 14.5, "Navigating to the Patterns Search Page."
In the Patterns Search page, click the New Pattern button.
In the Create Pattern screen, enter the Pattern name: "User: Work hours."
Select Authentication as the transaction type.
From the Creation Method list, select Multi-Bucket.
Select User as the Member Type.
Select First as the Evaluation Priority.
Enter a description.
Click OK.
A confirmation is displayed.
Click OK.
The Pattern Details page appears.
Click the Attributes tab.
On this tab you can add/edit the attributes of the users behaviors to be tracked.
In the Attributes page, click the Add button.
In the Add Attributes screen, select Time from the available attributes shown in the drop-down list.
Edit the attribute details.
Select Active as the Status.
Enter the description.
For example, "This creates three 8-hour buckets."
Select a compare operator range with start value of 0 and end value of 23.
Enter 8 as the Increment Step.
Click Add.
Click Apply.
OAAM creates buckets as needed for the behavior.
Jeff is a Security Administrator at Dollar Bank. He wants to be notified with an alert if a user logs in between 10 am to 5 pm more than 3 times. To do this, he must create a pattern that profiles users and time, and an alert group.
Create a single bucket pattern called, TimeLog10AM-5PM_PS, with the member type, user.
Add the Attribute, Time.
Compare operator is Range
Start value is 10 (10 am)
End value is 17 (5 pm)
Create an Alert Group so that an alert is used to notify you about either anomalies or information in the system when rules are triggered.
For information on Action and Alert groups, see Chapter 10, "Managing Groups."
Create a policy that will use autolearning conditions in the Post-Authentication checkpoint.
Create a rule within the policy that uses conditions to associate the pattern.
Ensure that the rule contains the autolearning condition, "Entity: Entity is member of pattern N times."
Fill in the values for the condition
Label | Name | Default |
---|---|---|
Pattern Hit Count More than | Pattern Hit Count More than | 3 |
Pattern Name For Membership | Pattern Name for Membership | TimeLog10AM-5PM_PS |
is Membership Count more than the Pattern Hit Count for User | isMoreThan | true |
Time period type for pattern membership | Time Period Type for Patternmembership | hours |
Time Period Type for Pattern Membership | Time Period Type for Pattern Membership | 1 |
Member Type for pattern Membership | MemberType for pattern Membership | user |
Add the Alert group as a result of the rule.
Group link to user group.
Verify that the alerts are generated, starting with the fourth login.
Jeff is a Security Administrator at Dollar Bank. He wants to track logins by employees based on days of the week and devices. To do this, he must create a pattern to profile the days of the week, users, and devices login.
If Joe logs in on Monday, his user ID and the device ID of the computer he is using are added to the Monday bucket once. If Fred uses the same computer to log in on Monday, his user ID and the device ID of the computer will be added once. At that point, the Monday bucket will have one count for Joe, one count for Fred, and two counts for the device. Rule conditions are then used to evaluate the bucket memberships.
A rule could be created to evaluate one member type of multiple member types.
For example,
Joe logged in on Tuesday less than 5% of the time in the last two months
Joe and this computer logged in on Tuesday less than 5% of the time in the last two months
To set up patterns so that they can have multiple member types with the members independently profiled by the pattern, you perform the following steps.
Create a pattern with User and Device as entities. It will have "Day of the Week" as the attribute and the operator for the attribute will be "for each."
Describe the bucket population correctly.
The condition to use is "Entity member of pattern (fingerprint) less than percentage times (as compared to its own data)."
For information, see Section B.1.2.2, "Entity: Entity is member of pattern less than some percent times."
Create one rule.
Set the percent value to be 5% in the rule.
Set the pattern described in Step1 as the pattern in the rule.
Set the entity to be user.
Set time period to 2.
Set time period type to months.
Leave the other values to the default.
Create another rule.
Set the percent value to be 5% in the rule.
Set the pattern described in Step1 as the pattern in the rule.
Set entity to be device this time.
Set time period to 2.
Set time period type to months.
Leave the other values to the default.
Joe's company wants all users to be challenged with an OTP if they are logging in from a city they are not a member of.
Joe logs in from three cities (home, office A and office B). A city pattern records how often he logs in from each.
Bucket | Location |
---|---|
City Bucket #1 | home |
City Bucket #2 | office A |
City Bucket #3 | office B |
Joe's company wants users to be challenged with an OTP two sessions in a row if they are logging in from a city they have not used in the last month. If Joe stops working at office B for 37 days and does not access from anywhere else in that city he will be challenged for an OTP the next time he logs in from that city. To accomplish this use case a rule will be configured to check on the membership count for the current city bucket in the last month. The count threshold will be set to two so the rule will trigger until the user has been a member at least twice in the last rolling month window.
To set up the system so that users are challenged with an OTP if they are logging in from a city they are not a member of, perform the following steps.
Create a pattern with User as the actor, City as the attribute, and For Each as the compare operator.
Use the condition, "Entity is member of bucket less than N times in given time period"
Set the rule parameters for conditions as:
Pattern Name as the pattern that we have created.
Time period type is month.
Time period is 1.
Count is 3.
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).
In addition to profiling, collecting data, and checking it, autolearning adjusts so that the system acts depending on the user's behavior. Conditions and the specified percentage remain unchanged.
If you log into the bank application from California everyday, but then you locate to Seattle without informing your bank. When you log in for the first time from Seattle, you are challenged. The second time, you are challenged again because you are logging in from a city less than 50% of your total logins within 1 month. The system knows Seattle is not the usual place you log in from. You are annoyed, but do not consider it a hindrance yet. Challenging you again will degrade your user experience.
The condition, therefore, has to be configured in such a way that there is a percentage when the system knows that it should no longer challenge you. The system should automatically be smart enough to understand that you are logging in from Seattle every time now going forward and that it should not challenge you.
The system does not challenge you when you log in a third time from Seattle. When you fly to California after three months the system challenges you when you log in. The system wanted to make sure that you are the person logging in to the system.
Example
You want the system to KBA challenge the user if the user logs in from a city less than 50% of the time within a month.
Create a multi- bucket pattern for each city called, UserLoginsCity.
Member type is user
Attribute is City; compare operator is "for each"
When a user logs in from different cities a bucket will be created for each city
Create an Action Group to KBA challenge the user for each city less than % membership.
Create policy that will use autolearning conditions in the Post-Authentication checkpoint.
Create a rule within the policy that uses conditions to associate the pattern.
The rule will calculate the percentage membership of a user belonging to a pattern
Ensure that the rule contains the autolearning condition, "Entity: Entity is member of pattern less than some percent times".
For information on this condition, see "Entity: Entity is member of pattern less than some percent times".
Fill in the values for the condition
Label | Default |
---|---|
Pattern Hit Percent less than | 50 |
Pattern name for membership | UserLoginsCity |
Is Membership Count Less than patternHitPercent | True |
Time period type for pattern membership | Month |
Time period for pattern membership | 1 |
Member type for pattern membership | User |
Add the Action group as a result of the rule.
Group link to user group.
If the user logs in from a city < than 50% of the total logins within 1 month, the user is challenged.
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.
A Security Administrator must configure a policy that challenges a user with a challenge question if the user is logging in from a state that he or she does not log in from very often, specifically one that he or she uses less than twice in a month.
The outcome should include a score and an alert.
Why use patterns for this scenario
This evaluation involves both profiling (patterns) and the rules to evaluate those patterns.
Patterns are used in this scenario for the following reasons:
If rules are to track the frequency of behavior, the period for evaluating the frequency might be relatively long, especially if the evaluation requires months or even years. Using a pattern is recommended in these cases because rules will not have to perform large queries for results. Oracle Adaptive Access Manager checks the bucketing to see if the user is a member of the current state bucket that he is falling into now and the frequency at which he has fallen into that bucket.
Other rules that run can use the pattern, which tracks the state or frequency of state usage, for other types of risk evaluations. By using the same pattern, no overhead is incurred to impact performance.
Steps
Log in to OAAM Admin as an administrator.
In the Navigation tree, double-click Patterns. The Patterns Search page is displayed.
Click the New Pattern button.
Create a pattern where:
Creation Method: Multi-bucket
Member Type: User
Evaluation Priority: High
Description: Pattern to track the state usage and frequency
Click Create.
Click the Attribute tab.
Click the Add button.
In the Add Attribute dialog, select State as the attribute and click Next.
In the page following, select for Each as the Compare Operator and click Add and then OK.
The compare operator for Each is selected to profile every state that users log in from (a bucket is created for each state and populated with users as they fall into the buckets).
In the Navigator tree, double-click Group.
Click New Group. The Create Group dialog is displayed.
Create a new StateNotUsedOften
alert group.
Group name: State not used often
Group type: alerts
Caching policy: Full cache since the group is used in rules and conditions.
Click Create and then OK. The Group Details page is display.
In the Alerts tab of the Group Details page, click Add Member.
In the Add Member page, select Create new element.
Select the Customer Care as the alert type.
Select the Medium as the alert level.
Type in the alert message in the Alert Message box.
For example, user is logging in from a state he or she has used less than 2 times in a month.
Click Add to create and add the new alert to the alert group.
When the confirmation dialog appears, click OK to dismiss the dialog.
In the Navigation tree, double-click Policies. The Policies Search page is displayed.
Search policies for post-authentication policies that are available.
In best practices, KBA challenges occur in the Post-Authentication checkpoint.
Because the rule being created will have the outcome of a KBA challenge, it will have to be in the Post-Authentication checkpoint. It must also be in a policy in which there is a check for KBA registration before this rule runs.
Open the policy to the details page and click the Rules tab.
Click Add.
Plan the rule:
A rule should be created to KBA-challenge the user if it is triggered; therefore the rule must be contained in a policy with other rule challenges.
Because the rule will result in a KBA challenge, the best practice is for the scoring that you set and configure for the rule to have a relationship to the action/outcome of that rule and to the severity of that rule that is being evaluated. The severity of the situation, the action for which the rule would trigger, and the score in which the rule would generate must be proportional to each other.
The rule is checking if the user is logging in from a state that he has logged in from recently, but the situation does not necessarily mean fraud. The situation is one of medium risk--that is why a KBA challenge is used instead of a block. A KBA challenge is appropriate for the scores in the 500 to 700 risk range. For this example, a score of 600 is specified. An OTP challenge would have been appropriate for a score in the 701 to 900 range. For a score of 900 and over, the action triggered should be a "block." The user should be allowed to continue on if the score is under 500.
Enter the summary information and click the Results tab.
Enter 600
as the score.
Enter 100
as the weight.
Select ChallengeQuestionPad as the action.
Select StateNotUsedOften as the alert.
Click the Conditions tab.
Click Add and select Entity: Entity is member of pattern N times.
Enter the following values:
Label | Name | Default |
---|---|---|
Pattern Hit Count More than | Pattern Hit Count More than | 2 |
Pattern Name For MemberShip | Pattern Name for MemberShip | user:state |
is MemberShip Count more than the Pattern Hit Count for User | isMoreThan | false |
Time period type for pattern membership | Time Period Type for Patternmembership | month |
Time Period Type for Pattern MemberShip | Time Period Type for Pattern MemberShip | 1 |
MemberType for pattern Membership | MemberType for pattern Membership | user |
Click Save to save your changes.
A confirmation dialog displays the status of the operation.
Click OK to dismiss the confirmation dialog.
Information about the pattern attribute operators is presented in this section.
The Day of Week and City attributes are used in the examples that follow to illustrate how operators work.
Numbers corresponding to the days of the week are:
1 = Sunday
2 = Monday
3 = Tuesday
4 = Wednesday
5 = Thursday
6 = Friday
7 = Saturday
Oracle Adaptive Access Manager will create buckets dynamically as necessary. The first time the criteria specified is fulfilled, Oracle Adaptive Access Manager will create a bucket for the criteria and add the actor as a member with a count of one. The next time the criteria is fulfilled, the actor is added to that same bucket as a member with a count of one. Each subsequent time the criteria is fulfilled, the bucket counter will be incremented.
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.
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.
If the Less Than operator is specified, a bucket is created and the count updated only when the attribute value is less than the value specified in the Compare Value field.
When the user specifies Day of Week as the attribute and enters 4 (Wednesday), a single bucket is created for Sunday (day=1), Monday (day=2), and Tuesday (day=3) and all his logins on Sunday, Monday, and Tuesday will be counted as part of that bucket.
If the Greater Than operator is specified, a bucket is created and the count updated only when the attribute value is greater than the value specified in the Compare Value field.
If the user specifies Day of Week as the attribute and enters 3 (Tuesday), a single bucket is created and the count updated only for Wednesday (day=4), Thursday (day=5), Friday (day=6), and Saturday (day=7). A bucket will not be created nor will the count be updated for the user for Tuesday (day=3).
If the Less Than Equal To operator is specified, a bucket is created and the count updated only if the attribute value is less than or equal to the value specified in the Compare Value field.
When the user specifies Day of Week as the attribute and enters 3 (Tuesday), a bucket will be created and the count updated when the user logs in on Sunday (day=1), Monday (day=2), and Tuesday (day=3). In Less Than Equal To 3, Tuesday (day=3) also qualifies as meeting the bucket population criteria.
If the Greater Than Equal To operator is specified, a bucket is created and the count updated only if the attribute value is greater than or equal to the value specified in the Compare Value field.
When the user specifies Day of Week as the attribute and entered 3 (Tuesday), a bucket will be created and the count updated when the user logs in on Tuesday (day=3), Wednesday (day=4), Thursday (day=5), Friday (day=6), and Saturday (day=7). In Greater Than Equal To 3, Tuesday also qualifies as meeting the bucket population criteria.
If the Not Equal operator is set, a bucket is created and the count updated when the authentication/transaction attribute has a value not equal to the value specified in the Compare Value field by the user.
In the Day of Week example, if the user specifies a value of 1 (Sunday), a single bucket will be created for all logins other than Sunday (day=1).
The In operator works like the Equals operator except all the comma separated values in the Compare Value field are used for an "equals to" comparison. In the Day of Week example, if the user enters 1,2,3,4,5, a single bucket is created for all logins that fall on Sunday (day = 1) through Thursday (day =5).
The Not In operator works exactly the opposite of In. In the Day of Week example, if the user enters the values 1,2,3,4,5 for the day of the week, a single bucket is created for Friday (day = 6) and Saturday (day =7) only.
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.
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.
Range is usually used with numerics.
When the user enters values for Start Value and End Value and leaves the Increment Step value as 0, he wants to create a bucket for the activity when the attribute value is Greater Than Equal To the Start Value and Less Than Equal To the End Value. Using the Day of Week example, if the user enters 1
(Sunday) as the Start Value and 5
(Thursday) as the End Value, all the logins from Sunday (day=1) through Thursday (day=5) will result in the creation and updates to the count of a single bucket. A fixed range is when the upper and lower limit are fixed and there are no steps "in between" (the increment step is not entered by user).
When the user enters values for Start Value and End Value and also provides a value for the Increment Step, he wants to create a bucket for the activity when the attribute value is Greater Than or equal to the Start Value and Less Than Equal To the End Value and he wants to create finer level buckets which are separated by the "increment" value of the attribute. Using the Day of Week example, if the user enters 1
(Sunday) as the Start Value and 5
(Thursday) as the End Value and the Increment Step as 1
, all the logins from Sunday (day=1) through Thursday (day=5) will result in the creation and updates to the count of multiple buckets. A bucket will be created and updated for the day starting Monday and then for each day (since the increment is one).
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.