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.