Deploying the HID Risk Management Solution

The HID® Risk Management Solution (RMS) is a sophisticated fraud and threat detection solution designed with modern fraud schemes and attack types in mind. It is based on device fingerprinting and user identification technology.

HID RMS uses advanced techniques to establish a unique device fingerprint based on the device location, browser, and system hardware details.

Additionally, HID RMS continuously monitors interactions on protected sites in a way that is entirely transparent to the end user (no end-user software installation is required).

Advanced machine learning enables HID RMS to assess user behavior patterns and, combined with other features, such as banking malware or transaction anomaly detection, it can determine the associated risk level for any authentication or transaction.

This technology can help online payment service providers and banks fight against fraudulent transactions, as well as financial malware, social engineering attacks, fraudulent account sign-ups, account takeovers, and phishing attacks.

Coupled with ActivID's strong authentication, the HID Risk Management Solution enables service providers the ability to offer their end users a blend of exceptional user experience and robust security.

How it Works

The HID RMS uses an obfuscated JavaScript embedded within the relying-parties web applications to retrieve information about the end-user’s system, to establish a device fingerprint, study the way users interact with the application, analyze and then, finally, produce a risk score.

This information is given a unique ID so when the relying-party’s application calls the ActivID Appliance, the ActivID Appliance can retrieve a risk score associated with the authentication attempt.

The ActivID Appliance then compares this risk score with the pre-configured threshold values to decide how to process the authentication:

  • Reject and block the channel for the end user (very high risk)

  • Only reject (high risk)

  • Ask for a step-up authentication (medium risk)

  • Authorize the request (low risk)

This feature is activated on the ActivID Appliance by adding and configuring an RMS source for an authentication channel. This ensures that authentications on the designated channel require an HID RMS Risk Score index retrieval.

Infrastructure Components

RMS JavaScript Snippet

The HID RMS JS Snippet is a core component ensuring detection of cyber threats and monitoring of users’ activity in the application. This component is to be placed in HTML code (in header of all pages) of the protected applications. The JavaScript snippet is continuously re-obfuscated to ensure attackers cannot easily reverse engineer the solution.

RMS Mobile SDK Library (Optional)

The HID RMS mobile SDK is counterpart to JavaScript probe this time for mobile applications. This component needs to be integrated into mobile applications using a simple API.

RMS Server

The HID RMS server is the central point of analysis for the data gathered by the respective JavaScript and Mobile SDK probes, as well as providing a graphical web dashboard for fraud analysts to analyze detection cases.

Solution Workflow

The following diagram illustrates the flow of authentications requests and responses when an end user authenticates to relying-party applications such as a banking application leveraging the HID RMS integration.

The green flow illustrates the step-up authentication using the ActivID Push-Based Validation Solution with HID Approve.

Figure 1: HID RMS Solution Authentication Workflow

  1. The end user submits a logon request to the banking application/portal.

  2. The banking web page requests a user data probe using the HID RMS JavaScript.

  3. HID RMS provides the JavaScript and cookies required for the probe on the user’s device.

  4. The HID RMS probe retrieves the user data and returns it to the HID RMS server for analysis.

  5. The banking application retrieves the HID RMS cookie from the user’s browser.

  6. The banking application sends an authentication request, including the HID RMS cookie ID, to the ActivID Appliance.

  7. The ActivID Appliance sends the cookie ID to the HID RMS server to retrieve the risk score.

  8. The HID RMS server returns the risk score.

  9. The ActivID Appliance analyses the risk score based on the configured thresholds:

    • If the score is lower than the thresholds, the ActivID Appliance authorizes the authentication request.

    • If the score is higher than one of the thresholds, the ActivID Appliance either:

      • Rejects the request and blocks the channel for the end user

      • Only rejects the request

      • Ask for a step-up authentication (for example, push-based validation)

  1. The ActivID Appliance sends the response to the banking application.

  2. If the request is authorized, the user authenticates successfully and can access the banking portal.

Important: A common proxy MUST be used to redirect the different exchanges according to the different URL endpoints (see Integrating for a Typical Deployment).

The following diagram illustrates the re-directions described in steps 1 to 5.

Figure 2: HID RMS Proxy Workflow

Integrating for a Typical Deployment

A typical HID RMS deployment consists of the following steps:

Step Description

  1. Add a New RMS Source

An HID RMS Source is required to allow communications between the ActivID Appliance and the RMS information Provider, using secured account settings.

IP and port information should be provided at this step. RMS Source access ports should also be defined (for example, 8043 for probe requests, and 8053 for risk retrieval).

Note: RMS providers must also allow inbound connections from:

  • Relaying party application’s proxy to allow the PROBE request from the end user’s browser.

  • The ActivID Appliance to retrieve the Risk score during the authentication workflows.

  1. Bind the RMS Source to a Channel

Binding an RMS Source for a channel implies that all authentication requests for this channel must provide valid Risk Management information.

If this information is missing, or if it reveals a potential threat, the authentication process will be impacted.

Once an RMS source is bound to a channel, the appropriate Risk Thresholds can then be defined.

In addition, using the Enable RMS fail-open… setting, you can define if all the authentications on this channel will be allowed or rejected if the HID RMS server is down (or cannot be reached).

Note: Threshold values might be adjusted in early deployment steps. Contact HID Global Professional Services for guidance.
Important: It is recommended that you do not bind the direct channel (CH_DIRECT) to an RMS Source.

  1. Integrating the HID RMS Calls in the Relying Party Application

The relying party application must integrate the RMS client configuration into its portal.

For example:

  • Include the HID RMS JavaScript snippet in the header of all pages of the protected web application/portal.

  • Make sure HID RMS cookies are retrieved and included in the authentication requests sent to the ActivID Appliance.

See also the HID RMS Demo Sample provided in delivery.

  1. Configure the Proxy

The HID RMS tag in the end user's browser only uses the relying party application host defined in the authentication page URL.

Therefore, a common proxy MUST be used to redirect the different exchanges according to the different URL endpoints.

See also the example in Using the HID RMS Demo Sample.

  1. Configure a Push-Based RMS Step-up Solution

HID RMS allows defining a Step-up authentication method to mitigate potential threats.

In a typical deployment, it could be the use of a One-Time –Password provided on a device.

The deployment demonstrates step-up using the ActivID Push-Based Validation solution with the HID Approve mobile application.

This solution requires configuring Push Based Authentication policies, and the use of an HTTP Callback method (to relay the authentication result to the relying party application once the end user has approved the push logon request on their device).

For further information, see Deploying the Push-Based Validation Solution.

For detailed configuration instructions, see Configuring the ActivID Appliance for HID RMS.

Risk Scoring and Step-Up Authentication Thresholds

Defining the appropriate threshold values for your deployment is typically an iterative process that first requires a pilot phase in a production environment for observation and analysis to determine ‘normal’ usage patterns.

The individual thresholds are then adjusted after a pilot phase and can be based on a number of variables such as risk appetite relative to overall user experience design, known risk factors in a given region, or threats that may be specific to the service.

As a basic example, defined thresholds could be:

  • 0-400 – Authorize

  • 401-600 – Ask for a step-up authentication

  • 601-900 – Reject

  • 901-1000 – Reject and Block

If the associated risk score for the end user’s authentication request falls between 0-400, then their authentication request will be authorized with no further action required by the user.

If the risk score falls between 401 and 600, then the user will be required to perform a step-up authentication.

A score between 601-900, and the specific authentication request will be rejected outright.

A score over 900 would block the authentication channel for the end user, thus requiring administrator intervention or a defined period of time before the user could successfully authenticate on the channel again.

Thresholds comparisons are exclusive: for example, setting the reject threshold to 600 indicates that all scores exclusively superior to 600 will be rejected.

You can define threshold at high level (“aggregate score”) but also define a specific value for each HID RMS section (User, Device, Session, and Action). By default, the following examples use the “aggregate score".

The ActivID Appliance also enables you to evaluate the associated risk score for the second authentication in a step-up authentication. The reject and block scores can be configured as the same for the step-up authentication, or they can be different.

For examples of threshold configurations, see the HID RMS Scenarios.