Skip navigation
All Places > Products > RSA SecurID Access > Blog > 2019 > May
2019

Every customer who has adopted RSA SecurID Access’s risk engine capability to attain Identity Confidence, love and fully trust the capability.  Based on several discussions with you during the RSA conference and 1-1 sessions we realized that customers were looking for more visibility into the workings of risk engine to better understand how the risk engine can add value to your security policies. Specifically, you wanted to know why a user/group was challenged or what factors contributed to a user’s/group’s higher level of risk and hence lower identity confidence.

 

What did we do?

In May release, we have introduced a simple yet powerful capability through user event monitor to help solve visibility challenges. Below is a screenshot of the user event monitor for a user that sums up the entire feature. 

  • Confidence score  - Overall user identity confidence score. You can look at the aggregate confidence score across the entire user population (confidence Threshold) and benchmark a user’s confidence score against the aggregate score.
  • Category scores define what contributed to the overall confidence score. You can see if the low or high confidence score was driven more by the user’s device or by the location or by the user’s overall behavior or some combination thereof.  Category score consists of Device confidence, Behavior confidence, and Location confidence. 

The category scores (location, device & user behavior scores) are aggregated through a mathematical model to get the overall user level confidence score. 

 

 

 

For example, in the above screenshot user's confidence score is lesser than the aggregate score (confidence threshold) of the entire user population. In other words, the current user access request is riskier than the rest of the population and hence appropriate policy controls have to be in place to challenge the user with additional assurance. The reason for the user's lower confidence is more influenced by the lack of trust in the location from which the access request is coming from than the device from which the user request originates or the user's behavior. 

 

The lower the category (location, behavior or device) score is the lower the confidence is on that category. The system gains more trust by the continuous learning process on each of those categories over multiple access requests. This will eventually lead to higher confidence in each of those categories and hence the overall user confidence. 

 

How can these category scores add more value?

In addition to providing visibility into what contributed to the user's confidence level, these category scores can be used to determine the effectiveness of your security policies fully driven by identity context. For example, if admins see the device confidence is lower across a user set (ex: users within OU=Salesforce) leading to lower assurance across that user set (salesforce) the admin can try improving the device confidence and hence overall user confidence. One way to improve device confidence is to enable users with a managed device (through EMM/UEM).

 

Another great example could be how you can map your user or group level confidence (or risk) with better granularity to an IT application (as an RSA Archer IT asset) and make informed identity context driven risk management decisions. Possibilities are infinite with this enhanced visibility into RSA SID Access Risk Engine!

 

Hope the examples above help you in mapping some of the user level or group level identity risk factors to your organizational policies. As we learn more we plan to add more visibility and better way to control the risk engine so that you can take some meaningful actions impacting your identity risk posture.

The powerful policy engine in RSA SecurID Access can be used to control access to “My Page,” just like you can control access to other protected resources/applications.  This allows you to configure additional protections beyond simple password-based authentication.  You might consider incorporating some or all of the following elements into your policy:

  • If you have an Active Directory group for users with existing RSA SecurID Tokens (hardware, software, or ODA), you could configure a ruleset to require those users to perform additional authentication  to access My Page, by specifying an assurance level that includes RSA SecurID Tokens.
  • You could add a contextual rule to your ruleset that uses IP Address and/or (with Premium license) Trusted Networks, Trusted Locations, and so on.  For example, you might allow users who are logging in from your corporate network or  company office locations to access My Page with just a password, while users logging in from any other locations would need to perform additional authentication to meet a specified level of assurance.
  • If you have your users’ phone numbers in Active Directory, you might want to consider adding the SMS or Voice tokencode authentication methods (licensed separately) to an Assurance Level, so users who don’t have a SecurID Token could receive an SMS or Voice tokencode and use it to access My Page and/or other resources, as appropriate.

For example, here is how you might use some of these suggestions protect access to My Page:

 

First, configure your assurance levels. Note that “SecurID Token” is part of the medium assurance level. That will be important in the next step when you configure your policy.

Now create your “My Page” policy. In this case you will create a ruleset for the subset of users that belong to an Active Directory group named “SecurIDUsers”.

Then select the settings shown below. These settings will allow these users to use their SecurID tokens to securely access My Page, where they may then enroll the RSA SecurID Authenticate application.

New users that do not have a SecurID token also need secure access to My Page. You could allow access to My Page with just a password for new users who are in a trusted location such as your corporate office, or who are logged into a trusted network, such as on your corporate network. You could also allow new users who are not in a trusted location and not in a trusted network to authenticate with SMS or Voice tokencode since they do not have a SecurID token.

 

To accomplish this, create an additional rule set that includes a conditional rule that allows password access to users in a trusted location or using a trusted network and that requires additional authentication for those users who do not meet one of those conditions. In this case you’ll assign a low assurance level to the rule to allow these users to authenticate with SMS or Voice tokencode.

 

When you’ve finished creating your new policy, go to Platform > My Page, select the policy you created, click Save, and then Publish changes before testing to ensure your configuration achieves your goals.

Improved visibility into identity confidence scores, thresholds and categories

To help improve understanding of the identity confidence attribute scoring and behavior we have added new events (25001, 25002) to User Event Monitor Messages for the Cloud Authentication Service  that show the authentication event score, thresholds for high or low confidence and the relative scores for device, location and behavior categories.  Additional details can be found under “Reporting a User’s Identity Confidence Score,” here - Condition Attributes for Access Policies .

 

Find out what is coming with monthly product webinars

If you haven’t already done so – check out RSA SecurID Access:  All Access Granted  to register for monthly product webinars.   You can also find recordings of the April and May webinars for demos of features in our May and upcoming June releases.

 

Important: Upcoming Cloud Authentication Service IP Address Changes

To align with Microsoft Azure Resource Manager deployment model changes, the Cloud Authentication Service and Cloud Administration Console IP addresses will be changing in August 2019. Your deployment must be able to connect to both new and old IP addresses in August 2019.

 

RSA recommends that you start planning with your organization now to make the necessary changes to connect to these new IP addresses. If you do not update your firewall rules with the new IP addresses, your identity routers will not be able to contact the Cloud Authentication Service and services will be disrupted. For details, see Schedule for Planned Changes to Cloud Authentication Service IP Addresses (March 2020) 

 

Release Notes

For further details on all the new and updated capabilities of the May release, please refer to the Release Notes here:  RSA SecurID® Access Release Notes: Cloud Authentication Service and RSA SecurID Authenticate App  

 

This enhancement makes RSA SecurID® Access and even more convenient, pervasive and intelligent solution for your authentication needs.

Do you want access to RSA SecurID Access Experts? Do you like access to new information before it becomes mainstream? Who doesn’t love fun, exciting and informative presentations? Well, you are in luck the RSA SecurID Access All Access Granted community is the place you want to be. I will provide you with five reasons why you should follow the community!


1. Access to RSA SecurID Access Experts
2. Exclusive access to RSA SecurID vision and product evolution
3. Each Presentation is full of energy and informative information
4. Meet and Great other SecurID Access Enthusiast
5. Participation is encouraged, and we look forward to hearing your voice

 

*** Make sure to sign up and attend the SecurID Access Product Roadmap session: Click here 


So what are you waiting for? Follow the RSA SecurID Access All Access Granted community today. https://community.rsa.com/community/products/securid/all-access-granted 

Filter Blog