updated best practices for securid implementations

Tuesday, 22 March 2011

If you are unable to access the files via RSA SecurCare Online, please contact support at: 
+1-508-497-7901, Option #5 for RSA, Option #1 for RSA SecurCare note.


Customer FAQ
INCIDENT OVERVIEW

1. What happened?
Recently, our security systems identified an extremely sophisticated cyber attack in progress, targeting our RSA business unit. We took a variety of aggressive measures against the threat to protect our customers and our business including further hardening our IT infrastructure and working closely with appropriate authorities.

2. What information was lost?
Our investigation to date has revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is related to RSA SecurID authentication products.

3. Why can’t you provide more details about the information that was extracted related to RSA SecurID technology?
Our customers’ security is our number one priority. We continue to provide our customers with all the information they need to assess their risk and ensure they are protected. Providing additional specific information about the nature of the attack on RSA or about certain elements of RSA SecurID design could enable others to try to compromise our customers’ RSA SecurID implementations.

4. Does this event weaken my RSA SecurID solution against attacks?
RSA SecurID technology continues to be an effective authentication solution. To the best of our knowledge, whoever attacked RSA has certain information related to the RSA SecurID solution, but not enough to complete a successful attack without obtaining additional information that is only held by our customers. We have provided best practices so customers can strengthen the protection of the RSA SecurID information they hold. RSA SecurID technology is as effective as it was before against other attacks.

5. What constitutes a direct attack on an RSA SecurID customer?
To compromise any RSA SecurID deployment, an attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information.

6. What constitutes a broader attack on an RSA SecurID customer?
To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information.

The broader attack we referenced most likely would be an indirect attack on a customer that uses a combination of technical and social engineering techniques to attempt to compromise all pieces of information about the token, the customer, the individual users and their PINs. Social engineering attacks typically target customers’ end users and help desks. Technical attacks typically target customers’ back end servers, networks and end user machines. Our prioritized remediation steps in the RSA SecurID Best Practices Guides are focused on strengthening your security against these potential broader attacks.

7. Have my SecurID token records been taken?
For the security of our customers, we are not releasing any additional information about what was taken. It is more important to understand all the critical components of the RSA SecurID solution.

To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful attack, someone would need to have possession of all this information.

8. Has RSA stopped manufacturing and/or distributing RSA SecurID tokens or other products?
As part of our standard operating procedures, while we further harden our environment some operations are interrupted. We expect to resume distribution soon and will share information on this when available.

9. Are any other RSA or EMC products affected?
We have no evidence that customer security related to other RSA products has been similarly impacted by this attack. We also are confident that no other EMC products were impacted by this attack. It is important to note that we do not believe that either customer or employee personally identifiable information has been compromised.

10. What new information are you disclosing in this note, and why are you issuing it now?
We are not disclosing new information related to the incident. Customers have asked us to provide more specific best practices and also help them prioritis the remediation steps. They also asked us to clarify some of the terms we used in the original communication. We are responding to these requests.

IMMEDIATE GUIDANCE FOR RSA SECURID CUSTOMERS

11. What are the top four steps I should take to protect my system?
RSA strongly recommends that each customer review the RSA SecurID Security Best Practices available on SecurCare Online and take immediate action to address non-conforming areas in your deployment. Specific areas of focus include the following:

• Secure your Authentication Manager database and ensure strong policy and security regarding any exported data (For more information see the Protecting Sensitive Data and Protecting the Authentication Manager Environment section in the RSA Authentication Manager Security Best Practices Guide)
• Review recent Authentication Manager logs for unusually high rates of failed authentications and/or next token (For more information see the Authentication Manager Log Monitoring Guidelines)
• Educate your help desk and end users on best practices for avoiding social engineering attacks such as targeted phishing. (For more information see the Preventing Social Engineering Attacks section in the RSA Authentication Manager Security Best Practices Guide)

• Establish strong PIN and lockout policies for all users (For more information, see the PIN Management section in the RSA Authentication Manager Security Best Practices Guide)
We have also included three other security best practice guides for customers who are interested in taking additional measures to further secure their RSA SecurID implementations.

12. How do I secure my RSA Authentication Manager Database and exported data?
To protect the data stored in your Authentication Manager database:

• Do not store any copies of data extracted from Authentication Manager online. You should keep an encrypted secure copy offline.
• Remote access to Authentication Manager hosts should be reviewed and limited.
• Physically control access to your Authentication Manager servers within your datacenter environment.
• Use firewalls to isolate your Authentication Manager network.
For more information see the Protecting Sensitive Data and Protecting the Authentication Manager Environment section in the RSA Authentication Manager Security Best Practices Guide.

13. How can I monitor my deployment for unusual authentication activity?
To detect unusual authentication activity, the Authentication Manager logs should be monitored for abnormally high rates of failed authentications and/or “Next Tokencode Required” events. If these types of activities are detected, your organization should be prepared to identify the access point being used and shut them down.

The Authentication Manager Log Monitoring Guidelines has detailed descriptions of several additional events that your organization should consider monitoring.

14. How do I protect users and help desks against Social Engineering attacks such as targeted phishing?
Educate your users on a regular basis about how to avoid phishing attacks. Be sure to follow best practices and guidelines from sources such as the Anti-Phishing Working Group (APWG) at http://education.apwg.org/r/en/index.htm.

In addition, make sure your end users know the following:
• They will never be asked for and should never provide their token serial numbers, tokencodes, PINs, passwords, etc.
• Do not enter tokencodes into links that you clicked in an email. Instead, type in the URL of the reputable site to which you want to authenticate.
It is also critical that your Help Desk Administrators verify the end user’s identity before performing any Help Desk operations on their behalf. Recommended actions include:

• Call the end user back on a phone owned by the organization and on a number that is already stored in the system.
• Send the user an email to a company email address. If possible, use encrypted mail.
• Work with the employee’s manager to verify the user’s identity
• Verify the identity in person
• Use multiple open-ended questions from employee records (e.g., “Name one person in your group” or, “What is your badge number?”). Avoid yes/no questions
Important: Be wary of using mobile phones for identity confirmation, even if they are owned by the company, as mobile phone numbers are often stored in locations that are vulnerable to tampering or social engineering.

For more information see the Preventing Social Engineering Attacks section in the RSA Authentication Manager Security Best Practices Guide.

15. How do I strengthen my PIN and Lockout Policy?
The most effective method to strengthen RSA SecurID authentication is to establish strong PIN policies and to reinforce the importance of secure PIN management with your end users.
________________________________________
Note: It is important to strike the right balance between security best practices and user convenience. If system generated alpha numeric 8 digit pins are too complex, find the strongest pin policy that best suits your user community.
________________________________________

RSA recommends the following baseline for PIN management:

• Configure Authentication Manager to require the use of 8 digit PINs.
• Do not use 4-character numeric pins. If you must use a short PIN (e.g. 4 characters), require alphanumeric characters (a-z, A-Z, 0-9) when the token type supports them.
• Configure Authentication Manager to randomly generate PINs. Do not allow your users to choose their PINs.
• Instruct all users to guard their PINs and to never tell anyone their PINs. Administrators should never ask for or know the user’s PIN.
• Configure Authentication Manager to lockout a user after three failed authentication attempts. Require manual intervention to unlock users who repeatedly fail authentication.

For more information, see the PIN Management section in the RSA Authentication Manager Security Best Practices Guide.