Oaam Device Identification_10.1.4.5

Oracle Adaptive Access Managaer

Device Identification Guide

10g Release (10.1.4.5)

November 2008

Oracle Adaptive Access Manager Device Identification Guide, 10g (10.1.4.5.0)

Copyright © 2008, Oracle. All rights reserved.

Oracle Adaptive Access Manager Device Identification Guide 2

The Programs (which include both the software and documentation) contain proprietary information; they are

provided under a license agreement containing restrictions on use and disclosure and are also protected by

copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or

decompilation of the Programs, except to the extent required to obtain interoperability with other independently

created software or as specified by law, is prohibited.

The information contained in this document is subject to change without notice. If you find any problems in the

documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may

be expressly permitted in your license agreement for these Programs, no part of these Programs may be

reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose.

If the Programs are delivered to the United States Government or anyone licensing or using the Programs on

behalf of the United States Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data

delivered to U.S. Government customers are "commercial computer software" or "commercial technical data"

pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such,

use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical

data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the

extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer


Contents

Overview ...................................................................................................................................4

What is Device Fingerprinting...................................................................................................5

When is a device fingerprinted? ...............................................................................................6

Device Fingerprinting Flows at Login....................................................................................7

Device Fingerprinting Attributes ................................................................................................9

Secure Cookie and Browser Characteristics ........................................................................9

Flash Shared Object and Device Characteristics .................................................................9

IP Intelligence .......................................................................................................................9

Models.....................................................................................................................................11

Device Identification Models ...............................................................................................12

Rule Templates ..................................................................................................................13

Use Cases and False Positives ..............................................................................................15

Device Risk Gradient..........................................................................................................17

Device Identification FAQ .......................................................................................................18

Device Identification Models Reference..................................................................................19

201 Cookie enable check ................................................................................................20 202 Flash missing............................................................................................................20 203 Cookie missing .........................................................................................................21 204 Http header mismatch ..............................................................................................22 301 First time browser .....................................................................................................23

Device Identification Rules Reference ....................................................................................24

Cookies Match.................................................................................................................25 Header data match ..........................................................................................................25 Header data match percentage .......................................................................................26 Header data present ........................................................................................................26 Http Header data Browser match ....................................................................................27 Http Header data Browser upgrade.................................................................................27 Http Header data OS match ............................................................................................28 Http Header data OS upgrade.........................................................................................28 Is Cookie Valid.................................................................................................................29 Is Cookie empty...............................................................................................................29 Is Cookie from same device ............................................................................................30 Known header data match percentage............................................................................30


Overview The purpose of this document is to provide an in-depth understanding of Oracle Adaptive Access Manager 's device fingerprinting technology. Oracle Adaptive Access Manager identifies devices based on combinations of the device ID tentacles; secure cookie, flash object, user agent string, browser characteristics, device hardware configuration, network characteristics, geo-location and historical context. The intelligent identification does not rely on any single tentacle so it can function on user devices not following strict specifications. This is especially important in consumer facing deployments.

The device is identified using proprietary logic and a configurable set of nested models. This document lists some of the conditions that are used to identify the device. These conditions evaluate historical user behavior and cases where some tentacles are not available such as cookies, Flash. As well, the specialized models detect high-risk situations such as out-of-sync or manipulated cookies.


What is Device Fingerprinting Oracle Adaptive Access Manager device fingerprinting is a mechanism to recognize the devices a customer uses to login – whether it is a desktop computer, laptop computer or other web enabled device. Oracle Adaptive Access Manager uses dozens of attributes, including proprietary OTS (One Time Secure) cookies, flash objects and advanced “Auto-Learning” device identification logic, to “fingerprint” the device. Oracle Adaptive Access Manager's patent-pending fingerprinting process produces a fingerprint that is not vulnerable to “replay attacks” and does not have any logic on the client side where it’s vulnerable to exploit. The device identification is not merely a static list off attributes but a dynamic capture and evaluation of the specific combinations of attributes.

Fingerprinting Diagram

User InformationGeo-location

Information

Behavior

Information

OAAM Contextual Data

Device Fingerprint

IP information

Auto-Learning

Flash

informationFlash shared

object

Header

information

Single use

cookie


When is a device fingerprinted? A device is fingerprinted as soon as it hits the system, prior to any authentication attempt. This way the device identification information is available for risk evaluation at any runtime. Some common runtimes are pre-authentication, post-authentication and in-session/transaction.

Generally the login page is embedded with a few lines of static html snippet code. The html snippet also has code to include a flash object and image tags to collect advanced device characteristics. The flash code internally makes a call to the application server thereby uploading the device characteristics. Oracle Adaptive Access Manager generates a unique Secure Cookie for each session and looks for the same cookie the next time any user logs in from the device. The cookie is only valid for that session on that particular device. The cookies are retrieved or set using the following mechanisms:

• Image tags - An image tag might be introduced in the login page, which makes a call to the server to get the image. This request sends the cookies from the browser, which is used for finger printing the device. The image tags could also be used to compute the network bandwidth and the processing speed of the device. These additional data points could also be used by Oracle Adaptive Access Manager to uniquely identify the network/computer device while authenticating the user.

• HTTP Requests - In cases where images are blocked, the cookies might be extracted from the login request itself. Oracle Adaptive Access Manager uses these different modes of collecting the cookies to overcome some technical difficulties imposed by browser or the security settings on the device.

The request from the flash client and image request need to be handled by the application server and passed on to the Oracle Adaptive Access Manager client code. This client code extracts the device characteristics from the request and calls the Oracle Adaptive Access Manager server. The Oracle Adaptive Access Manager client library is given with the source code. The customer can use it directly or customize it to suite their environment.


Device Fingerprinting Flows at Login


Device Fingerprinting Attributes

Secure Cookie and Browser Characteristics

As mentioned above, secure browser cookies are one of the mechanisms used to identify the device. The secure cookies are rotated every time the user logs in. The Secure Cookies are extracted from the HTTP request. Along with the secure cookie, the Oracle Adaptive Access Manager also extracts the Browser characteristics, like user agent, time zone, locale, etc.

For additional characteristics that are used to create a unique fingerprint for the device, refer to the table below.

Operating

System

Operating System Version Patch

Browser Browser Version Patch level JavaScript Support Image Support

Flash Shared Object and Device Characteristics

Similar to Secure Cookie, Oracle Adaptive Access Manager uses Flash Shared Objects to store rotating digital cookie and update it on each login request. The cookie is sent to the server using an HTTP request. Along with the cookie, the Flash movie also sends the device characteristics; such as does the computer have a microphone, audio, etc., thereby adding an additional granularity to the device ID. For additional characteristics, refer to the table below.

Hardware Screen DPI Screen color Screen resolution Has audio card Has printer support Has microphone

Software Has audio encoder Supports Video Has MP3 encoder Can play streaming Audio Can play streaming Video Has Video encoder

IP Intelligence

The locations used by the device are stored in the Oracle Adaptive Access Manager database and used by the rules engine to identify anomalies in device behavior. This is especially useful in cases where cookies and/or Flash are disabled.

Oracle Adaptive Access Manager’s method for device fingerprinting generates a one-time fingerprint for each user session which is unique to the individual’s device and which is replaced upon each subsequent visit with another unique fingerprint. This ensures that a stolen fingerprint cookie cannot be reused for fraud.

Some of the attributes collected to generate the location fingerprint are listed below:


• IP address

• City, State, Country information and confidence factors

• Connection type

• Connection speed

• IP routing type

• ISP flag

• ASN

• Carrier name

• Top-level domain

• Second-level domain

• Registering organization

• A list of anonymizing proxies

• Hostnames and routers


Models Oracle Adaptive Access Manager includes robust risk models (containing pre-packaged rules) for security, business, workflow and 3

rd party data, which are evaluated by the system in real

time. Oracle Adaptive Access Manager’s base models include many rules that use device rule templates.

Policy

Other Model

Rules

Device ID Models

Rules

User Device Location

Rule Templates

Business

SecurityWorkflow

Fraud MonitoringFraud BlockingFraud Challenge

System RegistrationEtc.

DEVICE: Max UsersDEVICE: Secure Cookie MismatchDEVICE: Max false StatusDEVICE: Max Users

Etc.

USER: Account StatusUSER: Action Count

USER: Challenge FailureUSER: Question FailureEtc.

LOCATION: IP Max UsersLOCATION: IP routing type

LOCATION: In IP groupLOCATION: In country groupEtc.

Customizing the rules that come standard with the product and adding new rules require minimal effort on the part of the institution due to the intuitive rule template editor accessible in Oracle Adaptive Access Manager.


Device Identification Models

To view the list of Device Identification models, choose Models from the Admin menu. Then,

from the Models menu, select List Models.

With the Device Identification item selected for the Model Run Time, click Run Query.


Rule Templates

Rule templates form the foundation of all rules. Rule templates are created and edited via the Adaptive Risk Manager user interface.

To view the list of rule templates, choose Rule Templates from the Admin menu. Then, from

the Rule Templates menu, select List Rule Templates.

With the All item selected for the Model Run Time, Policy Type, and Model Status, click

Run Query.

Oracle Adaptive Access Manager offers pre-defined conditions with which to create rule templates that are used by all rules. These rule templates fall into the following categories:

• User

• Device

• Location

• In-session

Sample Rule Template

Some sample rules that use device-related templates include:

Rule Description Conditions Action Alert

Device First Time

Device used by user the first time

None Challenge User

None

Device multiple users

Maximum users using the device for the past "x" seconds

1.Maximum number of users allowed is 3** 2.Seconds elapsed is 600**

Challenge User

Device multiple users


Many failures from device

Many failed login attempts from device within the given time duration

1.Maximum number of unsuccessful attempts allowed is 4** 2.Seconds elapsed is 3600**

Challenge User

Alert Many Device Fails


Use Cases and False Positives Oracle Adaptive Access Manager’s fingerprinting technology does not solely rely on one tentacle. Oracle Adaptive Access Manager uses dozens of attributes to recognize and “fingerprint” the device you typically use to login, providing greater “coverage” for an institution’s customer base. For example, in the case where certain elements are unavailable, the system can still provide robust security utilizing other objects (secure cookie, flash cookie, HTTP header, Real Media, QuickTime, etc.). Oracle Adaptive Access Manager’s secure

device fingerprinting technology allows for a higher non-repudiation1 in associating device with

user and transaction, reducing false positives that other fingerprinting technologies cannot overcome currently.

Oracle Adaptive Access Manager recognizes that institutions need solutions that are non-intrusive for their end users, making device identification increasingly crucial to all rules incorporating device fingerprinting. Consequently, Oracle Adaptive Access Manager’s fingerprinting technology takes into account the following different use cases and exceptions:

Use Cases Description

New Device Use Cases

Both secure and flash cookies are enabled. Both secure and flash cookies are missing. Flash request came through successfully.

Both secure and flash cookies are disabled. User has not used device from this location before

Secure cookies is enabled and flash is disabled

Both secure and flash cookies are missing. Also, the flash request didn’t come through successfully.

Secure cookie is disabled and flash is enabled

Both secure and flash cookies are missing. But flash request came through successfully.

Device Recognized

Both secure and flash cookies are enabled. Both secure and flash cookie came.

Both secure and flash cookies are disabled. Both secure and flash cookies are missing. Also, the flash request didn’t come through successfully.

Secure cookie is enabled and flash is disabled

Only secure cookie came through successfully.

Secure cookie is disabled and flash is enabled

Only flash cookie came through successfully.

Valid Exceptions

Browser upgrade. Browser character mismatched

Device upgrade. Flash data mismatched

Browser and Device upgrade. Both browser and flash data mismatch

Used different browser. Secure cookie is missing.

Secure cookie is missing. Browser characteristics are mismatch. Flash cookie is matching. Flash data is a match (except browser).

User different browser. Both cookie and browser characteristics mismatch.

Secure cookie is mismatch. Browser characteristics are mismatch. Flash cookie is matching. Flash data is a match (except browser).

Secure cookie out of sync and flash is in sync.

Secure cookie is mismatch, but belonged to the same device.

Flash cookie out of sync and secure cookie is sync.

Flash cookie is a mismatch, but belonged to the same device.

Both secure cookie and flash are out of sync.

Both the cookies are mismatch, but they belonged to the same device

1 Non-repudiation = authentication that with high assurance can be asserted to be genuine, and that cannot subsequently be refuted.


Other patterns These use one of the combinations of

regular and exception patterns. User uses multiple browsers and flash enabled.

User uses multiple browsers, with cookie disabled and flash enabled.

Family using same device

Family using same account

Family using same device, same account, different browsers

Family using same device, different account, different browsers

User who travels a lot with their laptop

User who travels a lot, uses kiosk

User who travels, uses laptop or kiosk

User who travels, but using wireless card always

User who travels, but uses public wifi with their laptop

Fraudulent Cases

Stolen secure cookie and stolen flash cookie. With stolen browser characteristics and flash data.

Stolen secure cookie and no flash request. With stolen browser characteristics.

Stolen secure cookie and no flash request. Browser characteristic mismatches

Cookie disabled and stolen flash cookie. With stolen browser characteristics and stolen flash data

Cookie disabled and stolen flash cookie. With mismatch browser characteristics and stolen flash data

Cookie disabled and stolen flash cookie. With mismatch browser characteristics and mismatch flash data

Cookie disabled and flash request with no flash cookie. And stolen browser characteristics and stolen flash data.

Secure cookie mismatches and belongs to another device


Device Risk Gradient

These use cases help to define Oracle Adaptive Access Manager’s device risk gradient. The device risk gradient specifies the certainty of the device being identified. This is a standard pre-condition in all device type rules. For example, a device risk gradient of 0 is an exact match whereas a device gradient of 500 is a device with some unexpected by plausible variations from previous sessions, and a score of 1000 a device that has only minimal matching data to make an identification.


Device Identification FAQ 1. What if secure cookies are deleted?

Oracle Adaptive Access Manager’s fingerprinting technology does not solely rely on one tentacle. Oracle Adaptive Access Manager uses dozens of tentacles to recognize and “fingerprint” the device you typically use to login, providing greater “coverage” for an institution’s customer base. If secure cookies are missing or disabled, Oracle Adaptive Access Manager uses other elements such as flash object, HTTP headers, geo-location and user history for device identification. As well history of the device is used to see if the absence of a cookie is expected or an anomaly.

2. What if flash is not enabled?

Oracle Adaptive Access Manager’s fingerprinting technology does not solely rely on one tentacle. Oracle Adaptive Access Manager uses dozens of tentacles to recognize and “fingerprint” the device you typically use to login, providing greater “coverage” for an institution’s customer base. If flash is not enabled, Oracle Adaptive Access Manager uses other elements such as secure cookie, HTTP headers, geo-location and user history for device identification. As well history of the device is used to see if the absence of a flash is expected or an anomaly.

3. How are device risk gradient scores determined?

Device risk gradient scores are determined using Oracle Adaptive Access Manager’s proprietary algorithm and the device ID models. A device score is made up of many elements evaluated historically. Each element can have a range of values. These values are used to determine the device score.

When a customer has the appropriate device scoring models deployed they can see these individual rule scores. The session holds the values that make up this score.

4. Why are there so many device ID models?

Our team has created many device ID models to take into account the various use cases that we’ve learned through experience with our customers. By creating these device ID models, we have created a robust device identification mechanism and reduced false positives as a result.

5. Are device ID models configurable?

Yes, device ID models are configurable.

6. Can we add new device ID models? If so, how?

Yes, new device ID models can be added. We recommend that you work with our Professional Services team to create any new device ID models.


Device Identification Models Reference To view the list of Device Identification models, choose Models from the Admin menu. Then,

from the Models menu, select List Models.


The Device Identification Models provided are:

• 201 Cookie enable check

• 202 Flash missing

• 203 Cookie missing

• 204 Http header mismatch

• 205 Hdr mismatch No Flash

• 206 Hdr mismatch No SC

• 207 Device upgrade

• 208 Brwsr Device upgrade

• 209 SecureCookie mismatch

• 210 Same device DigCookie

• 211 out of sync cookie

• 301 First time browser

• 401 GeoCheck Flash Came

• SystemDeviceID


201 Cookie enable check

202 Flash missing


203 Cookie missing


204 Http header mismatch


301 First time browser


Device Identification Rules Reference To view the list of Device Identification rule templates, choose Rule Templates from the

Admin menu. Then, from the Rule Templates menu, select List Rule Templates.


The Device ID rule templates provided are:

• Cookies Match

• Header data match

• Header data match percentage

• Header data present

• Http Header data Browser match

• Http Header data Browser upgrade

• Http Header data OS match

• Http Header data OS upgrade

• Is Cookie Valid

• Is Cookie empty

• Is Cookie from same device

• Known header data match percentage


Cookies Match

Header data match


Header data match percentage

Header data present


Http Header data Browser match

Http Header data Browser upgrade


Http Header data OS match

Http Header data OS upgrade


Is Cookie Valid

Is Cookie empty


Is Cookie from same device

Known header data match percentage

EXAMPLE FRAUD USE CASES

Use Case #1 – Insider Fraud: holistic risk evaluation

Dr. John Smith works at First Care hospital in San Francisco CA. He works day shift at the hospital

most of the time and in the evenings he often catches up on paperwork from his home office.

Unfortunately Dr. Smith is very forgetful and a little careless. He can never seem to remember his

username and password to access the medial records and billing system so he has written them down

on a post-it along with the URL of the application. At the end of his shift one night he accidentally

leaves the post-it on one of the PCs in his office at the hospital.

It’s now 1:27 Am, the night shift. Jeff is a temp worker recently hired by the janitorial company

responsible for the hospital. He is stuck working graveyard. He really hates his new job and he has an


issue with doctors in general. Just this evening a doctor bumped into him and spilled coffee all over.

Jeff is mopping the office that Dr. Smith shares with a group of other doctors. Tonight it’s quiet so

nobody is using the office. Jeff is stewing about doctors and spilt coffee when he spots the post-it on

the PC. He gets an idea; he could really mess with that doctor if he logged in and changed their

password without them knowing it. Maybe it’s even the password of the doctor that spilt his coffee.

First Care hospital has 137 PCs that are used for accessing the online records and billing system.

These PCs are built and maintained with a single Windows XP image. IE is the only browser installed

and it has cookies disabled. The Flash player is also not installed.

Jeff enters Dr. Smith’s username and password. OAAM determines that this situation is anomalous

for Dr. Smith so a KBA challenge question is presented. Jeff answers the question three times

incorrectly and locks out Dr. Smith’s account. Jeff gets bored and goes looking for doughnuts in the

break room.

Jeff was prevented from accessing Dr. Smith’s account because his behavior fell outside of what is

“ordinary” for Dr. Smith. Specifically, the time at which the login attempt was occurring was suspect.

Dr. Smith works the day shift unless he has to fill in for somebody. Even though he works at home

in the evenings sometimes it’s rarely late at night.

In addition to preventing the fraudulent login in real-time OAAM also captured the attempt in great

detail for forensic investigation of the situation if required. This form of audit record is far more

information than any application log could ever furnish. A compliance office could easily see not only

that there was a failed login attempt but also why Jeff failed, where Jeff was, what device he was using

and many other useful data points. As well, situations related to this one could easily be located in the

investigation tool.

Variations: possible device risk gradient permutations of use case #1 hospital PC. The use case

above is written to match row #1 below (both disabled). If everything in the use case were the same

except for the cookies and Flash the results would be rows 2 – 4. OAAM learns what the “normal”

composition of a device is over time. As long as the composition is consistent the risk is kept low.

Cookies Enabled Flash Enabled Device Risk Gradient Score

First 3 Logins 4th Login Plus

1 800 (new device each time) 550 (first device ID used)

2 X 300 (first device ID used) 0

3 X 200 (first device ID used) 0

4 X X 0 0


Device Profile

User ID: jsmith

Device ID: 84762678497

OS: Win XP

Browser: IE 6.2

Language: en-US

Cookie: no

Flash: no

IP: 123.54.78.32

City: San Francisco

State: CA

Country: USA

Connection: T1

Routing Type: Proxy

Time: 1:27 am

User: jsmith

Device ID: 84762678497

Usage: 26 last 30 days

OS: Win XP

Browser: IE 6.2

Language: en-US

Cookie: no

Flash: no

Device ID: 65674534522


OS: Vista Home

Browser: IE 7

Language: en-US

Cookie: yes**

Flash: yes**

Location Profile

User: jsmith

IP: 123.54.78.32


IP: 45.67.23.54


IP: 76.111.43.1


Time Profile

User: jsmith

Time Bucket: 5:00 – 12:59


Time Bucket: 13:00 – 20:59


Time Bucket: 21:00 – 4:59


Has jsmith used Device ID:

84762678497 less than

20% of the time in the last

30 days?

Has jsmith used IP:

123.54.78.32 less than 5%

of the time in the last 30

days?

Has jsmith used Time

Bucket: 21:00 – 4:59 less

than 33% of the time in the

last 30 days?

Current Situational

Context KBA

Challenge

IF YES

Historical Context

Historical Context

Historical Context

NO NO

IF YES

KBA

Challenge

YES

KBA

Challenge

Oaam Device Identification_10.1.4.5

Documents

Transcript of Oaam Device Identification_10.1.4.5