Introducing Oracle Adaptive Risk Management

2 Introducing Oracle Adaptive Risk Management

Oracle Adaptive Risk Management (OARM) is a comprehensive system that provides a way to monitor and control any user activity in your IT infrastructure (Single sign-on, Business Transactions).

Topics

2.1 About Oracle Adaptive Risk Management (OARM)

Oracle Adaptive Risk Management (OARM) is an integrated system that aggregates risk data associated with users and user activities, analyzes and evaluates business risks posed by users and their activities and provides advice to be acted on to mitigate them.

The system works best when integrated with Oracle Advanced Authentication (OAA), which executes risk mitigation actions to Block, Challenge, or Allow user activities based on the risk assessment associated with it.

The system can also work in a stand-alone mode where it can be consulted for remedial actions by consuming applications. OARM system is highly extensible owing to its micro-services based architecture, allowing additional capabilities to be added without having to indulge in a costly upgrade process.

2.2 Features of Oracle Adaptive Risk Management (OARM)

Oracle Adaptive Risk Management (OARM) system revolves around user activities, which are secured using business friendly rules.

OARM is shipped with an out-of-the-box User Authentication activity, which is baked in with a rich set of rules that can readily be used to secure the business. The system also provides the capability to augment the User Authentication activity with additional rules, remove rules not applicable to business, or add net new user activities to be monitored. OARM supports seeding data feeds from certified external sources that would also be used in risk analytics. This, combined with OARM's profiling capability provides the right mix of seed data for running analytics.

Configuration of Rules, managing and monitoring User Activities can be achieved with an intuitively designed Administration Console. The Administration Console allows Administrators to implement rules applicable to their Organization without being concerned with the nuances of the underlying system.

OARM in conjunction with OAA provides a large set of modern, multi-factor challenge methods allowing Administrators to choose challenge mechanisms that fit their business requirements. OAA also makes integration of OARM with existing Identity Management systems like Oracle Access Management Suite (OAM), very easy to achieve.

2.3 Understanding Terminologies in OARM

The following terminologies are used in OARM:

User Activity

User activity is any operation performed by the user that requires monitoring. For example, logging in, resetting passwords, and so on.

Out-of-the-box, OARM provides a user activity called User Authentication, which is built with a rich set of prepacked rules. User Authentication evaluates user activities to detect commonly found threats and take remedial actions or raise alerts.

Custom Activities

You can create your own custom activity in addition to the out-of-the-box User Authentication activity and create rules using the information collected from this custom activity. The rules are customized to the needs of the business. These rules could be transactional in nature, monitoring various aspects of the user activity in which the business is interested. Some examples of custom activities are internet banking or bill payment in a banking application. You can add rules that use information such as the amount of the payment, user information, and so on to identify a fraudulent money transfer.

Condition

Conditions are configurable evaluation statements that specifies one or more criteria to be satisfied by the access request in the OARM rule evaluation process and flow. They use datapoints from historical and runtime data to evaluate risk or business logic.

Each authentication rule contains one or more conditions that define whether a user is permitted or denied access to a protected resource by the rule. Conditions are pre-packaged in the system and cannot be created by a user. Conditions may take user inputs when adding them to a rule.

Rules

Rules are the main building blocks of decision making in OARM. Rules sum together the outcomes of various conditions that constitute them. Rules can then be used to make decisions to trigger actions or generate alerts.

You can implement new rules or edit existing rules based on new fraud data to fit business needs.

Action

An action is triggered based on the outcome of the evaluation of the configured rules. For example, actions can be forcing a user to register a security profile, blocking access, asking for a PIN or password based on a rule checking for Risky IPs. OARM provides several standard actions. The most prominent actions are ALLOW, CHALLENGE, and BLOCK.

Alert

Alerts are messages that indicate situations requiring attention based on the outcome of the evaluation of the configured rules. For example an alert is generated when a user logs in from a new country. Once the alert is issued, the Administrator can view the logged instance on the User Sessions page.

Groups

Groups are collections of similar items to simplify configuration workload. Groups can be used in places such as Rule conditions, Actions, and Alerts. You can choose from the following type of groups: User ID, User Name, Location, Device, Action, and Alert.

For example, to create a rule "Risky IP," you must add a condition to find out if the user IP used for login is in the list of risky IPs configured. The risky IPs are grouped together as Risky IP of type IP and the rule condition uses this group.

Profiles

Profiles 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.

Session

A session captures user's attributes and lifecycle, from the time of authentication until the resulting outcomes of the configured OARM risk management rules. An OARM session created is bound to both a user and the client with which they have authenticated.

OARM maintains a history of a user's sessions. Each session entry includes the Username, Device ID, IP address, and Session ID. You can view the session information using the User Sessions page.

The User Sessions page displays an overview of the events that transpired during a particular session for fraud analysis. It displays a summary of all the related information regarding the session, such as the session information, device information, location information from where the user logged in, user activities associated with the session, and rules, actions, and alerts triggered for the session.

OARM provides the capability to gather detailed information about the session and to allow you to drill down further into the details involved in the session. For example, you are a member of the security team at Acme Corp. You work with OARM on a regular basis, following up on escalated customer issues and security alerts. You perform a session search every couple hours throughout the day to identify any issues needing your attention.

2.4 OOTB User Authentication Rules Supported

OARM provides out-of-the-box (OOTB) authentication rules that alert you to potential attacker so that you can take corrective action.

The following table lists the OOTB user authentication rules supported by OARM.

Rule	Description
Block based on Risky IP	This rule will be triggered if an IP has previously been marked as a risky IP by the security team.
Block based on active anonymizer	This rule determines whether the IP address being used has been confirmed as an anonymizer within the last six months by the IP Location data provider.
Challenge based on Suspect Anonymizer	This rule determines whether the IP address being used has been confirmed as an anonymizer in the last two years but not in the last six months by the IP Location data provider.
Challenge based on Risky Device	This rule will be triggered if a device has previously marked as risky by the security team.
Challenge based on Country	This rule will be triggered if a user has logged in less than 20% of the time from this country in the last three months.
Challenge based on Less frequently used Autonomous System Number (ASN)	This rule will be triggered if a user activity occurs from a less frequently used Autonomous System Number (ASN).
Challenge based on Connection type	This rule will be triggered if a user has logged in with this connection type less than 6% of the time in the last month.
Challenge based on Routing type that is not utilized very often	This rule will be triggered if the user activity occurs via a less commonly used Routing type.
Challenge based on Least frequently used ISP	This rule will be triggered if user activity occurs from sparingly used ISPs.
Challenge based on Device	This rule will be triggered if a user has used this device to log in less than 10% of the time over the past month.
Challenge based on State from which least access happens	This rule will be triggered if user activity occurs from states with the least amount of activity.
Challenge based on Indicate Less Visited Time of day	This rule will be triggered if the user activity occurs at a rarely used time, such as 1 AM local time, when most users are dormant. This is a pattern-based authentication method in which an entity is a member of the pattern bucket less than a certain percentage of the time with all entities in the picture.
Challenge based on Browser locale from which least access happens	This rule is triggered if the user activity occurs in a browser locale with the least access. This is a pattern-based authentication method in which an entity is a member of the pattern bucket less than a certain percentage of the time with all entities in the picture.
Challenge based on Connection type that is not utilized very often	This rule will be triggered if the user activity occurs via a less commonly used connection type. This is a pattern-based authentication method in which an entity is a member of the pattern bucket less than a certain percentage of the time with all entities in the picture.
Challenge based on Country from which least access happens	This rule will be triggered if the user activity occurs from states with the least amount of activity.
Challenge based on Day of week with the lowest number of visitors	This rule will be triggered if the user activity if the user activity occurs on the days of the week with the fewest visitors. This is a pattern-based authentication method in which an entity is a member of the pattern bucket less than a certain percentage of the time with all entities in the picture.
Challenge based on Risky countries	This rule will be triggered if a country has previously been marked as a risky country by the security team.
Challenge based on Unknown Anonymizer	There are currently no positive test results available. The initial anonymizer assignment is based on other sources and has yet to be confirmed by the IP Location data provider. This address is removed from the list if no positive test results are obtained.
Challenge based on Dormant Device	This rule will be triggered if a device has not been used in thirty days and more than two users login from it within twenty-four hours.
Challenge based on Device with many failures	This rule will be triggered if a device makes more than four unsuccessful login attempts within eight hours.
Challenge based on Maximum devices per user	This rule will be triggered if a user logs in using more than two devices within eight hours.
Challenge based on device maximum velocity	This rule will be triggered if a device appears to have traveled faster than jet speed in the last 20 hours since its last login.
Challenge based on risky connection type	This rule will be triggered if a connection type has previously been marked as a risky connection type by the security team.
Challenge based on limit activity from dormant IPs	This rule will be triggered if a dormant IP address is used excessively in a user activity.
Challenge based on based on limit user activity surge from an IP	This rule will be triggered if there is an increase in user activity from a specific IP address.
Challenge based on based on private anonymizer	This IP address allegedly contains anonymous proxies that are not publicly accessible. As a result, automated tools cannot be used to test them on a regular basis. These addresses are typically associated with commercial ventures that provide anonymity services to the general public. Addresses with this designation are derived from ownership data or obtained from reliable sources.
Challenge based on user blocked recently	This rule will be triggered if a user has been blocked more than twice in the last eight hours.
Challenge based on maximum users per device	This rule will be triggered if more than four users log in using the same device within thirty days.
Challenge based on day of the week	This rule will be triggered if the user activity occurs on days of the week with the fewest visitors.
Challenge based on Time of day	This rule will be triggered if a user has accessed within the current time range less than 3% of the time in the last month.
Does user have a profile	This rule determines whether the pattern auto learning feature is enabled and whether the user has a historical behavior profile.
Is there enough pattern data available?	This rule determines whether there is enough pattern data available for auto-learning rules to use.
Predict if current session is fraudulent	This rule checks to see if the current session is predicted to be fraudulent using the Oracle Data Miner fraud classification model.
Predict if current session is anomalous	This rule predicts whether the current session is anomalous based on the anomaly ODM model.

2.5 Understanding the Sequence of User Activity Runtime API Calls

This section demonstrates how OARM processes user activities and provides values for API operations from the client application.

The following is a general sequence of API calls.

Create an OARM session using createSession (session-POST API). It creates a requestId, which is required for Create Custom User Activity API.
Client application then provides information about Custom User Activity by invoking Create Custom User Activity API (which uses the request ID created in Step 1).
Review to make sure the status of the Create Custom User Activity is successful before obtaining the transaction ID from the response.
Client can then call the processRules API to trigger the fraud policies/rules associated to the Transaction 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 output of this API is a set of actions and risk score as returned by the policies and rules.
Based on the outcome of the processRules API call, the client application can choose to call the Update Custom User Activity API to set the transaction status or to update data in the existing transaction.

Note:
Ensure that the Custom User Activity status is updated. This is due to the fact that some rules may use the status of previous transaction (user activity) as a data point.
In some cases, client applications can choose to execute a processRules API with a Pre Transaction checkpoint first and then Post Transaction kind of checkpoint that has policies/rules that have to be executed after a transaction is created. This can help application to figure out if transaction is good to execute, and then after execution any additional rules that may be required.