RSA issued an updated note to help customers assess their risk and prioritize remediation steps following a cyber attack that extracted some information related to RSA SecurID authentication products. The note provides a customer FAQ, updated best practices guides, and recommends securing authentication databases and logs, educating users on social engineering, and strengthening PIN policies. RSA SecurID remains effective if customers take steps to protect the additional information needed for attacks.

1. RSA SECURCARE ONLINE NOTE
Dear RSA SecurCare® Online Customer,
Summary:
As previously reported, a recent attack on RSA’s systems resulted in certain information being extracted
related to RSA SecurID® authentication products. This note is being provided in order to help customers
further assess their risk and prioritize their remediation steps as necessary in relation to this event.
RSA SecurID technology continues to be a very effective authentication solution. 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.
Based on feedback from customers, we are issuing this follow-up RSA SecurCare note to help customers
assess their risk and prioritize their remediation steps. We strongly urge you to initiate these steps
immediately, if they are not already part of your environment. These remediation steps are those we
have implemented across RSA's and EMC's business, with respect to our RSA SecurID authentication
system.
Description:
Updated content is being provided to help customers further assess their risk and prioritize their
remediation steps in relation to this event. All content is available on the RSA SecurCare website, and
links to that content are provided in this note. Updated information includes:
 A Customer FAQ providing answers to help customers further assess their risk and prioritize
their remediation steps, if they are not already part of your environment. The FAQ is part of this
document.
 Updates to our best practices guides based on customer feedback, including more detailed Log
Monitoring Guidelines related to RSA®Authentication Manager 6.x and 7.x implementations.
Affected Products:
The only affected products are RSA SecurID authentication products.
1

2. Overall Recommendations:
RSA strongly urges customers to review all documents referenced in this note. Based on customer
requests for prioritization of remediation, below are the most important remediation steps being
recommended to customers:
 Secure your Authentication Manager database and ensure strong policy and security
regarding any exported data (see Best Practices Guides for specific instructions)
 Review recent Authentication Manager logs for unusually high rates of failed
authentications and/or next token code events, both of which could indicate suspicious
activity (see Authentication Manager 6.x and 7.x Log Guidelines and Best Practices
Guides for specific instructions)
 Educate your help desk and end users on best practices for avoiding social engineering
attacks such as targeted phishing (see Best Practices Guides for specific instructions)
 Establish strong PIN and lockout policies for all users (see Best Practices Guides for
specific instructions)
Please follow the links below to the Security Best Practices Guides.
For the latest and most current information on RSA’s recommendations, please join one of RSA’s
ongoing series of customer conference calls. Click here for more information. Even if you have been on
a previous call, we encourage you to join future calls for updated information.
If you are unable to access the files via RSA SecurCare Online, please contact support at:
U.S.: 1-800-782-4362, Option #5 for RSA, Option #1 for RSA SecurCare note
Canada: 1-800-543-4782, Option #5 for RSA, Option #1 for RSA SecurCare note
International: +1-508-497-7901, Option #5 for RSA, Option #1 for RSA SecurCare note
For additional global contact numbers please reference: http://www.emc.com/collateral/contact-
us/h4165-csc-phonelist-ho.pdf
2

3. 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
3

4. 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 prioritize 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.
4

5. 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:
a. Do not store any copies of data extracted from Authentication Manager online. You should
keep an encrypted secure copy offline.
b. Remote access to Authentication Manager hosts should be reviewed and limited.
c. Physically control access to your Authentication Manager servers within your datacenter
environment.
d. 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
5

6. 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.
6

7. 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
7