Security Best Practices for RSA Authentication Manager Self-Service Console

[#1]

Article Number

000035290

Applies To

RSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager

Issue

RSA is aware of a published report on a researcher’s blog that raises concerns about self-service features in RSA Authentication Manager as implemented at a specific client. As pointed out by the researcher, enabling self-service and emergency access over the public Internet presents risks that should be closely scrutinized. This is not to say that Internet-based self-service should never be employed, but that the risk/benefit trade-off must be carefully understood and evaluated and that appropriate compensating controls must be in place. When implemented incorrectly or incompletely, password reset and other “emergency access” scenarios create a weak link that savvy attackers could seek to exploit. This is true for any application or security solution that supports such features.

Resolution

After reviewing the report, it is RSA’s conclusion that an insecure implementation at this researcher’s client led to the vulnerabilities identified and that each of these concerns could be mitigated by following RSA and industry-recommended security best practices including hardened network configuration, proper use of multi-factor authentication, and least privilege. 

1. By default, only limited self-service capabilities are available in RSA Authentication Manager. More sensitive features such as Forgot Password must be explicitly enabled by the administrator. Other features such as Troubleshoot Token can be disabled as required. In general, organizations should enable only those features that are required and for which the benefits outweigh the risks. In highly sensitive deployments, RSA recommends that emergency access is provided through a live help desk call rather than by using self-service.
    
2. Organizations should proceed with caution before making any self-service features available on the public Internet. The researcher concludes his article by highlighting the increased risks when placing self-service outside of a secured boundary. RSA agrees with this assessment. As stated in the RSA Authentication Manager Security Best Practices Guide (originally published in November 2011):

   “Examine your self-service policies and consider hardening self-service access and functionality. Limit access to the self-service console only to users inside your network. RSA strongly recommends that you do not allow users to clear their PIN with the Self-Service Console. Users that must clear their PIN should contact the Help Desk.”

    
   If an organization does choose to make self-service available on the Internet, RSA provides a more secure means to do so through DMZ-based web tier servers. In the researcher’s example, this guidance was ignored. Instead, secured ports were unnecessarily opened on the client’s corporate firewall. The RSA Authentication Manager Planning Guide specifically states:

   “While port 7004 is used by the Security Console, dynamic seed provisioning, and the Self-Service Console, it should not be directly accessible outside the intranet. To allow access to the Self-Service Console or dynamic seed provisioning for external users, set up a web tier to help protect port 7004 and restrict access to the Security Console.”

    
3. Security best practices rely upon a defense-in-depth strategy. RSA SecurID technology is based on the principle of multi-factor authentication, which strengthens security by forcing an attacker to compromise multiple defenses—in this case, something you have (“the token”), and something you know (“the PIN”). When employing emergency access, an equivalent multi-layer approach should be used. In the researcher’s example, this principle was ignored in multiple respects.

First, the researcher’s token was assigned without a PIN.

 

Second, emergency access was deployed as a “single factor” without a second layer of defense (e. g., network security). And while RSA acknowledges the researcher’s finding that Change PIN could be used in an unintended and malicious way, the researcher concedes that this was achieved only through prior knowledge of the user’s Active Directory password. Nevertheless, RSA is currently enhancing the Change PIN feature to address this concern.

 

4. When properly implemented, self-service can be deployed safely and securely. RSA SecurID is one of the most versatile authentication systems on the planet—used by organizations ranging from tens of users to millions of users, and protecting applications of every shape and size. To support this broad range of customers and use cases, RSA SecurID technology is designed to provide an extremely flexible and granular self-service model. In the researcher’s example, several key features of the product were left unexplored.
   1. The RSA Authentication Manager Web Tier allows organizations to decide which RSA SecurID services are available on the public Internet, and enables these services to be deployed securely in the DMZ without opening direct access to the RSA Authentication Manager server.
       
   2. The RSA Self-Service Console includes support for multi-factor authentication. Passwords, for example, can be augmented by requiring a one-time passcode sent to a pre-registered mobile phone or email account.
       
   3. A second factor (e. g., a PIN) should always be used with any one-time passcode solution. RSA SecurID supports additional PIN complexity and lockout features that can be used to help mitigate potential brute force attacks.
       
   4. For emergency access, RSA recommends single-use one-time codes. If an organization chooses to use fixed passcodes, these passcodes should be set to expire in 24 hours or less.
       
   5. When using Security Questions, organizations are encouraged to create custom questions not based on publicly searchable information. Organizations can also configure how many correct answers are required.

Ultimately, customers must decide when and where to use specific self-service features based on their individual needs and risk profile. But the risks can be mitigated by following RSA and industry-recommended security best practices. We encourage RSA customers to stay current with security best practices for deploying and maintaining RSA Authentication Manager by visiting the RSA Link website for the latest documentation updates.  Visit the RSA Authentication Manager 8.2 SP1 page on RSA Link for more information.
 
RSA welcomes independent security reviews as they help create the strongest and safest products for all our customers. Researchers are encouraged to contact RSA directly and to report any suspected product vulnerabilities directly to the Dell EMC Product Security Response Center.
 
Unfortunately, this researcher chose not share his results with RSA prior to publishing so RSA can respond only to the statements as outlined in the article. If new information surfaces, RSA will discuss it right here on the RSA Link website.