Risk-Based Authentication

Risk-based authentication (RBA) identifies potentially risky or fraudulent authentication attempts by silently analyzing user behavior and the device of origin. RBA strengthens SecurID authentication and traditional password-based authentication. If the assessed risk is unacceptable, the user is challenged to further confirm his or her identity by using one of the following methods:

  • On-demand authentication (ODA). The user must correctly enter a PIN and a one-time tokencode that is sent to a preconfigured mobile phone number or e-mail account.

  • Security questions. The user must correctly answer one or more security questions. Correct answers to questions can be configured on the Self-Service Console or during authentication when silent collection is enabled.

RSA Authentication Manager contains a risk engine that intelligently accumulates and assesses knowledge about each user’s device and behavior over time. When the user attempts to authenticate, the risk engine refers to the collected data to evaluate the risk. The risk engine then assigns an assurance level such as high, medium, or low to the user's authentication attempt. RBA compares this to the minimum acceptable level of assurance that you have configured. If the risk level is higher than the minimum assurance level, the user is prompted to confirm his or her identity by answering security questions or using ODA.

Note: Risk-based authentication (RBA) only works with web-based authentication agents that use the UDP protocol.

Risk-Based Authentication Data Flow

The following figure shows a web-based application before it is configured for risk-based authentication (RBA). In this example, the network resource is protected by an SSL-VPN, and the SSL-VPN is configured to validate user logon credentials using an LDAP directory.

securid_rba_integration_before_98x29.jpg

Data flow occurs in the following sequence:

  1. The user browses to the SSL-VPN logon page over an HTTPS connection.

  2. The user provides a user name and password.

  3. The SSL-VPN validates the user’s identity using an LDAP directory, the identity source, over an LDAPS connection.

  4. The SSL-VPN grants the user access to the protected resource.

When RBA is enabled, the logon page for the web-based application redirects the user to the Authentication Manager logon page. The user enters logon credentials, and Authentication Manager validates the user’s credentials using an LDAP directory as an identity source.

You can deploy RBA so that the workflow is transparent to the user. The redirect is immediate. Also, you can customize the Authentication Manager logon page.

The following figure shows RBA integrated with the SSL-VPN.

securid_rba_integration_after-am_400x469.jpg

Data flow occurs in the following sequence:

  1. The user browses to the SSL-VPN logon page over an HTTPS connection.

  2. The SSL-VPN redirects the user’s browser to an Authentication Manager logon page.

  3. The user provides a user name and password.

  4. Authentication Manager validates the user’s identity using an LDAP directory, the identity source, over an LDAPS connection.

    Also, Authentication Manager assesses the assurance level (the confidence level that determines when the user is challenged for identity confirmation) of the authentication attempt. One of the following occurs:

    • If the assurance level meets the level that is required by the RBA policy, the workflow continues at step 5.

    • If the assurance level does not meet the level that is required by the RBA policy, the user is prompted to confirm his or her identity. One of the following happens:

      • If the user provides identity confirmation, the workflow continues at step 5.

      • If the user does not provide identity confirmation, Authentication Manager returns a message to the user’s browser that access is denied, and the workflow ends.

  5. Authentication Manager redirects the user’s browser to the SSL-VPN with an authentication artifact to confirm that the user’s credentials are valid.

  6. The SSL-VPN validates the authentication artifact over the SecurID protocol, which is the native authentication protocol for Authentication Manager.

  7. The SSL-VPN grants the user access to the protected resource.

Risk-Based Authentication Prevents Data Loss from Stolen Passwords

RBA allows users who are accustomed to authenticating with passwords to continue doing so with little or no impact on their daily tasks. At the same time, RBA protects your company if passwords are stolen.

For example, consider John, a sales representative who regularly accesses the corporate SSL-VPN from his home office. John typically authenticates with just a user name and password using the same laptop every day. Suppose an unauthorized person steals John’s password and attempts to log on to the SSL-VPN from a different machine and location. RBA detects that the attacker is using an unrecognized device and challenges the attacker to confirm his identity by answering security questions. When the attacker fails the challenge, he is denied access.

Users who are accustomed to using passwords for authentication can continue to do so while RBA works in the background to protect sensitive company resources. The authentication experience is interrupted only if a user’s behavior is considered unusual.

In most cases, the typical user simply enters a password, as shown in the following steps:

  1. The user opens a browser window and accesses the company web portal.

  2. The user enters a password.

  3. The user gains access to the protected resource.

After the password is entered, Authentication Manager analyzes the user’s risk level to determine if the user’s behavior and device are found to deviate from past attempts. Users who are considered suspicious or high risk are prompted to confirm their identity by performing these steps:

  1. If the user is configured for more than one identity confirmation method, the user is prompted to choose either on-demand authentication (ODA) or security questions.

  2. If the user selects ODA, the user enters a PIN. Authentication Manager Express sends a tokencode to the user by e-mail or SMS. The user enters the tokencode and is authenticated.

    If the user selects security questions, the user is prompted to answer predefined questions. If successful, the user is authenticated.

How Risk-Based Authentication Works

Risk-based authentication (RBA) intelligently assesses authentication risk for each user and accumulates knowledge about each user’s device and behavior over time to determine if an authentication attempt is legitimate. RBA has the following features:

  • Data Collection. RBA requires a learning period during which it builds up a profile of user devices and user behavior. After the initial learning period has expired, RBA continues to learn from the behavior of the user population and regularly customizes its risk model to adjust its definitions of “normal” and “abnormal” for your deployment.

  • Device Registration. The first time a user successfully authenticates from a device, RBA records characteristics about the device in the user’s device history and thus registers the device to the user. A registered device is one that Authentication Manager recognizes and that the user has previously used for authentication.

  • Device Matching. During authentication, RBA examines the characteristics of the user’s laptop or desktop computer and compares them with a list of previously used devices, in an attempt to find a close match.

  • Assurance Level. RBA uses the device characteristics and user behavior to calculate an assurance level, which is the likelihood that the access attempt is being made by a legitimate user. When the user attempts to authenticate, RBA refers to its collected data to evaluate the risk and then assigns an assurance level such as high, medium, or low to the user's authentication attempt.

Methods for Enabling Users for Risk-Based Authentication

A user must be enabled for risk-based authentication (RBA) to access an RBA-protected resource. Use one of the following methods:

Automatic. When a user accesses an RBA-protected resource, the user becomes enabled for RBA automatically after the first successful authentication. For instructions, see Enable Users Automatically for Risk-Based Authentication.

Manual. Only specified users can access RBA-protected resources. An administrator must manually enable these users for RBA. For instructions, see Enable Users Manually for Risk-Based Authentication.

Note: Users you enable for RBA are counted against the RBA limit in your license.

Deployment Considerations for Risk-Based Authentication

Before you deploy risk-based authentication (RBA), consider these aspects when you plan your RBA deployment strategy and establish RBA policies:

  • Do you want to use RBA for all users in a security domain? If yes, you can configure Authentication Manager to enable all users automatically. If no, the administrator enables users individually.

  • Do you have a web tier? RSA recommends a web tier for RBA. You can have multiple web tiers handling RBA traffic.

  • Which server do you want to select as the preferred server for RBA? RBA requires a preferred server. You must select a unique preferred server for each web tier handling RBA traffic.

  • Do you want to integrate RBA with your web-based authentication agents? RSA supports specific web-based agents for integration with RBA. You may integrate other web-based agents that support either the SecurID protocol or the RADIUS protocol.

  • Do you want to use silent collection, which allows the system to establish a baseline authentication history for each user and register authentication devices automatically to users during the data accumulation period?

  • How often do users access protected resources from public computers or devices? Consider this when you are choosing a minimum assurance level, deciding whether you want to enable silent collection, and configuring device settings. You may want to select a higher assurance level if users frequently use public computers or devices.

  • Do users typically access protected resources using multiple devices or from changing locations? How sensitive should Authentication Manager be to changes in the user’s location, device, and behavior? Consider this when you choose a minimum assurance level and configure device settings.

  • Which identity confirmation methods should be available to users? For example, if users carry mobile phones that your organization authorizes for business use, you might choose on-demand authentication. For laptop or desktop users, you might choose security questions.

  • How many devices should be associated with each user? How long should each device remain registered to the user? Consider these when you are configuring device settings.

  • Do you want your organization’s logo on the RBA logon pages? For more information, see Customize Self-Service Console Web Pages.

  • Do your users use SecurID authenticators? When RBA is enabled, the following authenticator-related events can cause the system to raise the risk level.

    • User exceeds your threshold for unsuccessful logon attempts

    • User uses a temporary tokencode or fixed passcode

    • Administrator clears a user’s PIN

    • Administrator changes a user’s PIN

    • Administrator marks a token as lost and a user attempts to logon with it

You may want to educate the SecurID users about these additional risk contributors to help them understand why the system challenges them for identity confirmation.

Recommendations for Determining the Minimum Assurance Level

Before you deploy risk-based authentication (RBA), consider these factors regarding the minimum assurance level:

  • Many factors are involved in calculating the risk level. Results may vary based on your network, users, and specific situations.

  • The best minimum assurance level for your deployment depends on:

    • The sensitivity of the resources being protected

    • The acceptable user challenge rate

  • If strength-of-authentication is your primary objective, start with a higher assurance level, and adjust it to a lower level if users are being challenged too often.

  • If ease-of-use is your primary objective, start with a lower assurance level, and adjust it to a higher level if you want more security.

  • RSA recommends starting with a Medium-High assurance level.

Because assurance increases when the device is known and the user behavior is predictable, some user populations are better suited to higher assurance levels than others. For example, employees authenticating regularly from the same device and location usually have much higher assurance than employees who travel frequently. Adjust the minimum assurance level to match the majority of your user population.

The Impact of User Behavior on Risk-Based Authentication

A user’s behavior affects how often the user is challenged to confirm identity. The system calculates and assigns users a Behavioral Risk Assurance Level that indicates the degree of confidence that the user is known to the deployment. The Behavioral Risk Assurance Level is based on the user’s typical behavior. Abnormal user behavior, such as attempting to authenticate several times in a row using the wrong password, lowers the Behavioral Risk Assurance Level and increases the assessed risk of the authentication attempt.

The system also calculates and assigns a client device a Device Assurance Level that indicates the degree of confidence that the device is known to the deployment. The Device Assurance Level is based on a specified device matching technique.

Low-risk behaviors include common activities that are perfectly valid under most circumstances but could be associated with fraud. For example:

  • The user’s account was recently modified.

  • The user is authenticating from a previously unknown IP address.

Medium-risk behaviors may include multiple activities that are combined in a suspicious way. For example:

  • The user authenticates from an unknown IP address soon after a failed identity confirmation challenge.

  • The user authenticates from an unknown IP address after changing his profile through the Self-Service Console.

Any clearly identified fraudulent activity constitutes high-risk behavior. For example, authentication attempted from a machine with an invalid or compromised cookie is a high-risk behavior.

The effect of user behavior on the device and behavioral risk assurance level is shown in the following table.

Device Matching Technique

Device Assurance Level

Behavioral Risk Assurance Level

Low

Medium

Medium-
High

High

Based on two or more unique attributes and statistical data

High

High

High

Medium-
High

Very Low

Based on one unique attribute plus statistical data

Medium-
High

Medium-
High

Medium

Low

Very Low

Based on one unique attribute

Medium

Medium

Medium

Low

Very Low

Based on statistical data

Low

Very Low

Very Low

Very Low

Very Low

Unregistered device

Very Low

Very Low

Very Low

Very Low

Very Low

Testing Your Risk-Based Authentication Integration

Test your risk-based authentication (RBA) integration to verify that Authentication Manager can authenticate users for the agent. If the test is unsuccessful, troubleshoot the setup, and repeat the test until it succeeds.

The Authentication Activity Monitor logging detail can be used for troubleshooting if the test is unsuccessful.

Procedure

  1. Create a test user in the Security Console by adding a new user to the internal database and the default security domain (SystemDomain).

    For instructions, see Add a User to the Internal Database.

  2. Verify that the RBA policy associated with the default security domain (SystemDomain) has the following configuration and edit the policy if necessary:

    • Automatic enablement is allowed.

    • Silent collection is allowed.

    For instructions on editing an RBA policy, see Edit a Risk-Based Authentication Policy.

  3. Start the Authentication Activity Monitor in the Security Console.

    Click Start Monitor to view real-time authentication activity.

  4. Do one of the following:

    • Go to another computer on the same network, start the browser, and go to the logon page for your web-based application.

    • Start a different browser application on the same machine if you have more than one installed. For example, if you used Firefox to access the Security Console, you may use Internet Explorer to access the logon page for your web-based application.

    The logon page for your web-based application automatically redirects you to the Authentication Manager logon page. If you are not redirected to this page, troubleshoot the test. For more information, see Troubleshooting the Authentication Test.

  5. Enter the logon credentials for the test user.

  6. Verify that your browser loads the correct landing page for the network resource that you are trying to access.

  7. Review authentication logging in the Authentication Activity Monitor. If the test succeeded, familiarize yourself with entries that are logged for successful authentication. If the test is unsuccessful, review the entries and review Troubleshooting the Authentication Test.

Planning for Domain Name System Updates

To allow users to locate your web tier and optional load balancer, you must buy publicly resolvable names for these systems. Do the following:

  • Define a domain name, for example, mydomain.com

  • Define host names, for example, myhost.mydomain.com

  • Contact a Domain Name registrar, and register the domain name and associated host names.

Clients using Self-Service and risk-based authentication (RBA) must be able to resolve to the virtual host name using Domain Name System (DNS).

  • If your deployment has a load balancer, the virtual hostname must resolve to the public IP address of the load balancer.

  • If your deployment does not have a load balancer, the virtual hostname must resolve to the public IP addresses of each web tier.

View Risk-Based Authentication Settings for a User

You can view the risk-based authentication (RBA) settings for a user to do any of the following:

  • View whether the user is currently enabled for RBA.

  • View the number of devices in the user's device history.

  • Delete the user's device history.

  • View the identity confirmation methods that are allowed by the RBA policy, and determine whether the user has configured each method.

  • View silent collection details for the user, including whether silent collection is allowed by the RBA policy, whether the silent period has started, and how many days are remaining in the silent collection period.

Procedure

  1. In the Security Console, click Identity > Users > Manage Existing.

  2. Use the search field to find the user. Some fields are case sensitive.

  3. Click the user that you want to view, and select Risk-Based Authentication.

Disable a User for Risk-Based Authentication

Disabling a user for risk-based authentication (RBA) prevents the user from accessing RBA-protected resources. The system retains the user's RBA-related data, including the user's authentication history and device history. (Devices remain in the user device history according to the device administration settings in the RBA policy.)

Note: If the RBA policy allows users to become automatically enabled for RBA, then the user can become re-enabled for RBA. For more information, see Methods for Enabling Users for Risk-Based Authentication.

Procedure

  1. In the Security Console, click Authentication > Risk-Based Authentication > Manage Enabled Users.

  2. Use the search fields to find the user that you want to disable for RBA.

  3. Click the user that you want to disable for RBA, and select Risk-Based Authentication.

  4. Under RBA Settings, deselect Enable user for RBA.

  5. Click Save.

Delete the Device History for a User

When you delete the device history, the user's devices become unregistered, and the user is required to provide identity confirmation the next time the user tries to access an RBA-protected resource.

RSA recommends that you delete a user's device history if the user reports a device as lost or stolen. You might also want to delete a user's device history if it contains devices that are no longer in use, or if the user mistakenly chooses to register a device that is public or shared.

Procedure

  1. In the Security Console, click Authentication > Risk-Based Authentication > Manage Enabled Users.

  2. Use the search fields to find the user whose device history that you want to delete.

  3. Click the user, and click Delete Device History.

  4. Click OK to confirm the deletion.

Search Users Based on Risk-Based Authentication Settings

You can search for users based on whether they are enabled for risk-based authentication (RBA). Some fields are case sensitive.

Procedure

Do one of the following:

  • Search for users who are not enabled for RBA.

    1. In the Security Console, click Authentication > Risk-Based Authentication > Enable Users.

    2. Use the search fields to find the users that are not enabled for RBA.

  • Search for users who are enabled for RBA.

    1. Click Authentication > Risk-Based Authentication > Manage Enabled Users.

    2. Use the search fields to find the users that are enabled for RBA.

Configure Web-Based Application Logon Pages for Risk-Based Authentication

To log on to an application that is protected by risk-based authentication (RBA), the users must provide their credentials to the application logon page that is modified using the RBA integration script. The RBA integration script redirects users to RSA Authentication Manager.

Procedure

  1. In the Security Console, select Access > Authentication Agents > Manage Existing.

  2. Click the appropriate web-based application agent, and select View.

  3. Under Risk-Based Authentication (RBA) Settings, click Go to Download Page.

  4. If you are using a web tier, confirm that the values for the following are correct:

    • Virtual Hostname

    • Virtual Host Port

    • Authentication Agent

  5. In the Agent Type drop-down list, select your web-based application.

  6. Click Download File.

  7. To add the script to the logon page for your web-based application, follow the instructions provided in the RSA implementation guide for your web-based application.

After you finish

Enable users for RBA. For instructions, see Enable Users Automatically for Risk-Based Authentication.

Custom Solutions for Web-Based Applications for Risk-Based Authentication

For web-based applications that have been certified as SecurID Ready but not supported by RSA Authentication Manager for risk-based authentication (RBA), you can create your own custom solution. To create a custom solution, you must create your own RBA integration script using the XML template that RSA provides. For a complete list of RSA Ready products, go to https://community.securid.com/t5/securid-integrations/tkb-p/securid-access-integrations.

For instructions on creating an RBA integration script for an SecurID Ready application, see the RSA Authentication Manager Risk-Based Authentication (RBA) Custom Integration Guide.

Related Concepts

Risk-Based Authentication Data Flow

Deployment Considerations for Risk-Based Authentication

Risk Engine Considerations for Risk-Based Authentication

Device History for Risk-Based Authentication

Silent Collection

Custom Solutions for Web-Based Applications for Risk-Based Authentication

Methods for Enabling Users for Risk-Based Authentication