Deployment Considerations for Risk-Based AuthenticationDeployment 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.
Risk Engine Considerations for Risk-Based AuthenticationRisk Engine Considerations for Risk-Based Authentication
The risk-based authentication (RBA) risk engine creates a profile for each user based on the client device and user behavior. Before you deploy RBA, consider these factors regarding the RBA risk engine:
-
The RBA risk engine requires a learning period during which it acquires the data needed to build profiles on users and their devices, and general user population behavior. During this learning period, users may be challenged more frequently for risk until the profiles are built to establish baseline assurance levels. For user convenience, you can configure the silent collection option to avoid risk-based challenges while the data for baseline assurance levels is acquired. See Silent Collection.
-
The RBA risk engine employs soft matching techniques based on statistical probability. If the risk engine has insufficient data to match a device, it can use forensic tools to assess the match probability and adjust the assurance level accordingly.
-
The RBA risk engine is self-tuning and learns to ignore parameter values that most authentications in your deployment have in common. Self-tuning improves security and reduces overall user challenge rates.
Minimum Minimum Assurance LevelAssurance Level
The minimum assurance level is the confidence threshold that each authentication attempt must meet to avoid a challenge to the user for identity confirmation. The setting is in the risk-based authentication (RBA) policy for each user’s security domain.
Each time a user attempts to authenticate, the risk engine evaluates the device match and user behavior in real-time to produce an assurance level. The risk engine compares the user’s assurance level with the minimum assurance level in the RBA policy. If the user’s level is lower than the minimum, the user is prompted for identity confirmation.
For an authentication attempt to be considered high assurance, most or all device characteristics must match those that were recorded during a previous authentication attempt. Device characteristics include, but are not limited to, the IP address, the browser type and version, and the HTTP and Flash cookies that identify the device.
If the device is not in the user’s device history (and silent collection is expired or is disabled), the authentication attempt is considered low assurance and the user must confirm his or her identity to access the RBA-protected resource. When the user’s assurance level is below the threshold, and the user has not configured an identity confirmation method, the user cannot access the protected resource.
Silent CollectionSilent Collection
Silent collection is an optional feature that facilitates the process of collecting profile and behavioral data for users without the need for user or administrator intervention.
When silent collection is enabled, the risk engine passively monitors user behavior for a defined period without actively challenging users based on risk. During this period, the risk engine automatically registers user devices and observes behavioral patterns. Once the risk engine has gathered enough information to have high assurance about a particular user, that user is prompted to provide any missing information. For example, the user may need to configure security questions or on-demand authentication.
You enable the silent collection period in the risk-based authentication (RBA) policy for all users in a security domain. Using silent collection helps the risk engine build a baseline profile for each user.
Silent collection affects your deployment in the following ways:
-
During silent collection, authentication is based only on the authentication method required by the agent. Users are never challenged for identity confirmation.
-
All devices are registered to the user’s RBA profile. This may include unwanted devices such as internet kiosks.
