| Oracle® Adaptive Access Manager Concepts Release 10g (10.1.4.5) Part Number E12049-03 |
|
|
View PDF |
| Oracle® Adaptive Access Manager Concepts Release 10g (10.1.4.5) Part Number E12049-03 |
|
|
View PDF |
Auto-learning is a profiling process in which an administrator defines behavior patterns. 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 in general) over time so that the profiles created can be 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 in order to profile behavior in a granular way.
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.
This chapter contains the following sections:
Patterns are either created in single-buckets or multi-buckets where buckets are groupings of behaviors in a broad sense.
Single-bucket created patterns have the exact data points, value ranges and/or patterns defined by an administrator. Auto-learning (a set of features that performs adaptive evaluations of risk) can be influenced by creating specific patterns that an administrator wants Adaptive Risk Manager to watch for. Usually these patterns represent behavior considered to be high risk based on industry expertise. An administrator can configure the behavior pattern through Adaptive Risk Manager.
Example
A fraud specialist may configure a pattern so that Adaptive Risk Manager can look for any traffic that falls in the pattern.
A pattern could have the following combination:
8am -10am pattern
and
New device
and
New location
and
New transfer account, not owned by this user is created
and
Wire transfer to new account
Multi-bucket patterns have more data points than single-bucket created patterns. An administrator selects the data points and samples he wants to base the pattern on, and then during post-processing Adaptive Risk Manager queries the historical data to create the bucket combinations that have occurred in the system. Each bucket will automatically keep from overlapping with each other based on the other buckets already in the system.
Example
An administrator specifies the following data points and sample size for auto-creation.
Transaction = Bill Pay
Member Types = user, device, location
Data Point = Time
Sample size = 2 hours
Start Time= 00:00
Retroactive = Yes
Adaptive Risk Manager would then use post-processing cycles to run queries on all the data in the database to build a maximum of 12 patterns for 2-hour time slots in which bill pay transactions have occurred. After creation, the patterns will be populated with user, device and locations that have fallen within each 2-hour pattern. The memberships and associated statistics will be saved in each user, device, and location profile.
If a web application has three possible transactions that need to be monitored (A, B and C). There are a finite number of patterns that can be created to capture the sequence patterns of these transactions. If transaction data parameter ranges are also being captured, the number of possible patterns increases.
Example
Pattern creation parameters are defined to only capture transaction type. There are three transaction types (A, B and C) in the application so patterns will be created based on these.
Risk level is calculated based on the combinations of pattern memberships for the user/device/location being used. The more elements are outside of their normal membership, the higher the risk.
Example 1
Login time will be profiled as part of the pattern risk assessment. For this example, login time patterns will be manually defined. The time patterns are organized around normal business hours in a single time zone. This pattern might be utilized for internal enterprise use for regional offices in that time zone and/or if the local time of the user is known.
| Patterns | Time Range |
|---|---|
| Pattern #1 | 0:00 to 4:59 |
| Pattern #2 | 5:00 to 8:59 |
| Pattern #3 | 9:00 to 16:59 |
| Pattern #4 | 17:00 to 23:59 |
After a month of recording, the system finds the following three independent pattern 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 | = high risk [device in #4] |
| If User A logs in at 8:27 using Device X from IP Y | = medium risk [device & IP in #2] |
| If User A logs in at 11:15 using Device X from IP Y | = very low risk [all in #3] |
The first scenario is shown in more granular detail below.
If User A logs in at 3:37 and they have previously only logged in between 9:00 and 16:59 that elevates the risk. If Device X is used and it has previously only been used between 5:00 to 23:59 that elevates the risk. 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 all three of the major components involved in the risk evaluation are not in pattern #1 the overall risk level is very high. It's important to emphasis that each of these elements is evaluated for membership in the time profiles independently in this example.
Example 2
The next example presents a view of the evaluation of pattern membership and the amount of variance by using the same patterns as the previous example but with different memberships and scenarios.
| Pattern | Time Range |
|---|---|
| Pattern #1 | 0:00 to 4:59 |
| Pattern #2 | 5:00 to 8:59 |
| Pattern #3 | 9:00 to 16:59 |
| Pattern #4 | 17:00 to 23:59 |
After a month of recording, the system finds these three independent pattern memberships.
| Entity | Membership |
|---|---|
| User A | [ #3 ] |
| Device X | [ #1, #2, #3, #4 ] |
| IP Y | [ #1, #2, #3 ] |
Evaluation of the memberships and taking variance into account produce 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 | = upper medium risk [user is not in #1 or its immediate neighbor #2] |
| If User A logs in at 8:27 using Device X from IP Y | = lower medium risk [user is not in #2 but they are in its immediate neighbor #3] |
Patterns are populated and maintained based on the number of successful outcomes. The membership of patterns is constantly reevaluated. The threshold values that govern membership evaluation is independently configurable for each pattern. If he wants, an administrator can apply a configuration to a selection of multiple patterns with a single operation.
Example
Joe regularly logs in from three cities (home, office A and office B). All cities in the Tri-State area including these three had a pattern created for each of them when the system was configured. Joe belongs to the following three city patterns currently.
| Pattern | Location |
|---|---|
| City Pattern #1 | [home] |
| City Pattern #2 | [office A] |
| City Pattern #3 | [office B] |
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. To become a member of a pattern, an employee must successfully answer the challenge the first two sessions he access the system from that city. To continue membership in pattern #3, Joe must successfully utilize an IP from that city at least once a month. If he stops working at office B for 37 days and does not access from anywhere else in that city, he will be removed from group #3 automatically by Adaptive Risk Manager. If he goes back to office B after his absence he will be challenged for an OTP since he is no longer a member of pattern #3.
Statistical and aggregate queries/templates are provided by Adaptive Risk Manager so that administrators can view pattern membership totals, percentages, and so on. Pattern reports, which are available through BI, provide data based on the pattern information.
BucketsByPatternAndMember: lists all buckets based on pattern and member type for the time range specified.
MemberEntitiesByPattern: lists all metadata for the member entity based on the pattern selected.
MembersByPattern: lists all members based on the pattern selected.
PatternsByMember: lists all patterns available based on the Member Type.
PatternsByMemberEntities: lists all patterns that have the specific metadata as its member entity.
|
 Copyright © 2008, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
