In order for Oracle Adaptive Access Manager to perform analysis on transactions, you must determine how to represent the transactions in Oracle Adaptive Access Manager, how to process the data coming in, how to use the data, and how to display the data. For example, in an e-commerce transaction, the data involved are credit card numbers, shipping and billing addresses, names, dollar amounts and so on; for a wire transfer, the data involved are Amount, Name, To account, From account, Routing Number, Bank Address, Bank Phone, and so on.
This chapter contains the following sections:
Determining which items in a transaction are entities and creating the entities saves time, improves performance in the system, decreases the amount of data created, and enables rules using the entity to run faster than if they had used transactional data.
An entity can be used and reused in multiple places, which makes creating transaction definitions much easier. An example of an entity that can be reused is an address. A shipping address and billing address can be created for different transactions from the address entity. If you had defined address as transactional data, you would have to define it twice.
The use case may be to notify the security administrator if a customer is trying to make a purchase and his billing and shipping addresses (street, city, state, and zipcode) are different. A mismatch may indicate that the customer is sending the item to an address different from the address the bill is sent to. A mismatch may mean that a fraudster is using a stolen credit card to buy the item, but there might be valid reasons like the customer might want his purchase sent to his work or he may be purchasing a gift for someone who lives at a different address.
To set up this use case:
Develop the security policy that will accomplish the use case.
Determine what you are trying to accomplish (problem statement).
Break the problem statement into:
Inputs: What data is available to evaluate?
Rules: What types of evaluations do I need to perform on the data?
Outcomes: What should happen based on the analysis?
Translate the wording of the problem statement into a security policy by mapping the data, evaluations, and outcomes to an OAAM configuration.
An outline for determining how to model the transaction is as follows:
After receiving the source data from the customer, identify the mapping between the source data and OAAM entities and transaction. Source data elements are the fields from the customer application.
Table 18-1 Data Fields and Source Keys
| Data Name | Internal ID of Source Fields |
|---|---|
|
Item |
itemId |
|
Price |
itemPrice |
|
Count |
itemCount |
|
First Name |
customer.firstName |
|
Last Name |
customer.lastName |
|
Credit Card |
creditCard.number |
|
CC Expiration Date |
creditCard.expDate |
|
CC Issuing Country |
creditCard.issuingCountry |
|
Is Shipping Address Same? |
shippingAddress.addressSame |
|
Address Line1 |
shippingAddress.addressLine1 |
|
Address Line2 |
shippingAddress.addressLine2 |
|
Address Line3 |
shippingAddress.addressLine3 |
|
City |
shippingAddress.city |
|
State |
shippingAddress.state |
|
Country |
shippingAddress.country |
|
Pin Code |
shippingAddress.pinCode |
|
Address Line1 |
billingAddress.addressLine1 |
|
Address Line2 |
billingAddress.addressLine2 |
|
Address Line1 |
billingAddress.addressLine3 |
|
City |
billingAddress.city |
|
State |
billingAddress.state |
|
Country |
billingAddress.country |
|
Pin Code |
billingAddress.pinCode |
Use the OAAM Administration Console to create and activate the entities and transaction definitions for the transaction based on the model you came up with.
The following steps occur after entities and transaction creation.
Determine the OAAM checkpoint that you can use to trigger the fraud policies that can perform fraud checks on the transaction. If an existing checkpoint can be reused, there is no need to create a checkpoint. Otherwise, create an OAAM checkpoint for the transaction.
Now, look at the requirements for what kind of rules should be included in the fraud policy for this transaction.
Look at the list of transaction rule conditions to see which rule condition is needed. Review the "Example Usage" section of those rule conditions.
Create an OAAM policy and add the rule.
Once the rule condition is configured, specify what should be the Results if the rule condition is satisfied. You can configure Alert and Action groups that indicate that the user has reached his threshold and also a score. The client application can interpret the result and take appropriate action in redirecting the user to the relevant pages that indicate that the user action is not allowed.
Now, you have the setup ready in OAAM so that the transaction can be created in OAAM and fraud policies and rules can be triggered.
Integrate the client application with OAAM using OAAM shared libraries. Refer to "Integrating Native Java Applications" in Developer's Guide for Oracle Adaptive Access Manager for details of the integration. This is required since transactions functionality is available through native integration. As part of this integration, the client application does two things:
Call the OAAM Data Collection API to pass the transaction data. OAAM Data Collection APIs persist the transaction data based on the transaction definition into the OAAM database. This results in the creation of OAAM entities and transaction data. The results of these APIs is a Transaction ID.
Call the OAAM Rules API to trigger the fraud policies/rules associated to the checkpoint. This step results in triggering the rules engine that would execute the policies and rules associated to this checkpoint and creating Alerts if the associated rules trigger. The results of these APIs is a set of actions and risk score as returned by the policies and rules.
Once the integration with client application is done, you can perform a sample transaction and verify the end-to-end flow.
A healthcare organization that cannot provide secure access to its data will suffer significant damage to their institution's reputation, the loss of trust by patients, stakeholders, and the community, and suffer severe penalties. Maintaining secure data is a process that affects all healthcare facility employees, including IT and all partners, insurers, and vendors that work with the provider. OAAM has a set of fraud auditing and detection tools, which can be used to assist organizations. During the discovery phase in a healthcare domain deployment, the business analyst identifies user activities that need to be monitored. User activities could be read-only access of sensitive data such as patient information or actions to add or manage data. Some examples of user activities are:
Sensitive Record Access
VIP Patient Record Access
Coworker Patient Record Access
Unusually High Frequency of Patient Record Access
Unauthorized Access to Patient Record
Unauthorized Access to VIP Patient Record
For these use cases, entity-attribute information must be mapped out and a policy must be developed for "Patient Record Access". During the design phase, Entities, Transactions, Rules, Policies, Alerts and Configurable actions are defined.
Entities and Transactions - User activities and data identified during the discovery phase are mapped to Transactions and Entities definitions in Oracle Adaptive Access Manager. Policies are then configured using these Entities and Transactions.
Policies and Rules - Based on the requirements, Policies and Rules are defined in Oracle Adaptive Access Manager. Appropriate actions are configured for each rule.
Alerts - Alerts can be generated for privacy and fraud incidents. Alerts are defined in Oracle Adaptive Access Manager admin console and associated with rules. Alerts can be classified as High, Medium or Low.
Configurable actions - A configurable action provides a mechanism to add additional tasks to the static actions returned by the rules. A configurable action uses Java classes to implement custom behaviors. Standard configurable actions like automatic case creation and e-mail notification can be configured to create cases or sending e-mail notifications. Other customized actions can be written to meet any specific requirements.
Unusually High Frequency of Access by Employee to Patient Records
Description: Frequency of employee's access to patient records increases to unusually high frequency.
IF employee has accessed patient records during each of the last 12 months
AND Employee has accessed > 500% more patient records in the last six months than in the previous six months
THEN report on potential inappropriate patient record access.
Required data:
Employee demographics:
Person ID
Name
Patient demographics:
Medical Record Number
Name
"Employee [Person ID, Name,] accessed > 500% more patient records in the last six months than in the previous six months."