9 Auto-learning

Auto-learning is the application of a number of Oracle Adaptive Access Manager features to dynamically profile behavior of user, device, locations, and transaction entities. Patterns are defined by an administrator to automatically capture behavior. These patterns are in turn used by Adaptive Risk Manager to dynamically create and populate buckets based on the pattern parameters. Adaptive Risk Manager automatically records/maintains the bucket memberships of the users/devices/locations/entities over time so that the overall profile can be used to evaluate risk. As well, dynamic actions are used to populate groups based on rule outcomes to further profile behavior. The memberships of these automatically managed groups are also used to evaluate risk.

The Auto-learning feature profiles transactions and authentications being performed by different actors (entities). This process establishes what is normal or average behavior for an individual or a population. In turn this allows evaluations to be made that can determine if a situation is an anomaly and therefore potentially fraudulent. The task is accomplished by

capturing the transaction and authentication data and passing it through various patterns thereby creating/populating various buckets to profile behavior in a granular way.

An example scenario is when we want to find out what the typical log in times (time of the day) are for users. To find out the login times, we would set up an Auto-learning pattern that has the user as a member and time as a parameter. We would choose to have a multi-bucket pattern and set start time=00 and endtime=23 (these are hours of the day).

When users log in, we will have profiles for each user on log in time. When we gather this data for a few days or months, we can use this data to challenge the user if he logs in at a time at which he does not usually log in.
capturing the behavioral and transaction data, based on the actors (entities), and then creating the statistics for the entities based on their memberships to various patterns and hour/day/month/year time samples.

An example: we will have several patterns in the system.
- one capturing the login name (user) and the time of log in
- another capturing the login device and the city of the log in
When the data is analyzed and tabulated, we will have created records to tell us
- user "U1" exhibited the behavior of Pattern A. The user "U1" is a member of Pattern A
- if the user, or IP, or device exhibited a behavior that matched the configured pattern, then that user (entity) is a member of the pattern.

This document provides information on pattern data processing and the APIs for triggering pattern data processing.

9.1 Pattern Data Processing (On-Line and Scheduled)

If the system load is light and if the pattern is configured, the data will be processed as soon as the clients calls the API that is used for triggering the data processing. The system load is the number of authentication, transaction, rule processing (and other) reports and requests served by the Oracle Adaptive Access Manager server.

The logic for processing the data is as follows.

For each (successful) transaction record, the following process occurs:

Get all the attributes of the transaction from the database.
Determine the transaction type and if any of the patterns have the same transaction type as the one we have at hand.
If there are no patterns having the same transaction type as the one at hand, the process is stopped at this point and returns to the caller with nothing.
If there are patterns that have the same transaction type as the one at hand, then the following process is performed for each pattern.
1. Get the parameters for that pattern and determine if the parameter values for the transaction at hand satisfy the requirements (like range for example). If not, move to next pattern.
2. If the parameters satisfy the requirements, then go to the fingerprint table.
3. If the fingerprint exists for such a combination, then go ahead and update the counters in workflow tables (hour, day, month, year).
4. If the fingerprint does not exist, then create a fingerprint and create entries in the workflow table for that fingerprint and put the count there.
5. After this determine if the pattern is configured to capture the one-time or lifetime values for the parameters, if set to do so. Then go and update the correct profile table. While doing this, if the profile table does not have an entry for this entity, create the entry. Data1 thru Data10 fields from entity profile tables will be used to capture the pattern membership and the values.
6. Repeat steps a through e for rest of the patterns.
Repeat steps 1 through 4 for each transaction.

9.2 APIs for Triggering Pattern Data Processing

The APIs for triggering patterning data processing are

updateTransactionStatus
updateAuthStatus
processPatternAnalysis

9.2.1 updateTransactionStatus

API to update the given transaction status and trigger the pattern data analysis if appropriate. A nonzero value of analyzePatterns will result in triggering the pattern analysis if not already done for this transaction.

public VCryptResponse updateTransactionStatus(java.lang.String requestId, long transactionId, int status, boolean analyzePatterns)
public VCryptResponse updateTransactionStatus(java.lang.String requestId, java.util.Date requestTime, long transactionId, int status, java.util.Map[] contextMap, boolean analyzePatterns)

Table 9-1 updateTransactionStatus Parameters

Parameter	Description
requestId	Request Identifier
requestTime	The time when this request was made.
transactionId	Transaction Id to be updated.
status	New Status
contextMap	array of contextMap
analyzePatterns	Boolean to indicate if the pattern analysis should be done. When passed in as true the pattern analysis is done for this transaction.

9.2.2 updateAuthStatus

API to update the user node log auth status and trigger the pattern data analysis if appropriate. A nonzero value of analyzePatterns will result in triggering the pattern analysis if not already done for this transaction.

public VCryptResponse updateAuthStatus(java.lang.String requestId, int resultStatus, int clientType, java.lang.String clientVersion, boolean analyzePatterns)
public VCryptResponse updateAuthStatus(java.lang.String requestId, java.util.Date requestTime, int resultStatus, int clientType, java.lang.String clientVersion, boolean analyzePatterns)

Table 9-2 updateAuthStatus Parameters

Parameter	Description
requestId	request Id
requestTime	Time of update
resultStatus	The authentication result. This is the enumeration value of the authentication result.
clientType	This is an enum value defined to identify the client type used for authentication.
clientVersion	Optional parameter to specify the version of the client used
analyzePatterns	Boolean to indicate if the pattern analysis should be done. When passed in as true the pattern analysis is done for this transaction.

9.2.3 processPatternAnalysis

API to trigger the processing of data for pattern matching. This call will only trigger the processing of data for pattern matching. The last parameter transactionType can be used by authentication type user interactions, since auth (or login) are not first-class transactions.

public VCryptResponse processPatternAnalysis(java.lang.String requestId, long transactionId, int status, java.lang.String transactionType)

Table 9-3 processPatternAnalysis

Parameter	Description
requestId	request Id
transactionId	Transaction Id to be updated.
status	New Status
transactionType	String that indicates the type of transaction. Has to be "auth" for authentication type. For other types it can be "bill_pay, ....",; basically the type name of the transaction.