RSA SecurID Breach Summary

Brandy Peterson, Chief Technology Officer, FishNet Security

Overview
RSA released information on Thursday, March 17 that they had been the victim of an electronic breach and that information had been stolen from their internal systems. This breach and theft appears to be restricted to the SecurID product line. RSA has provided a few advisories and guides providing limited details about the breach and actions customers should take in response, but specifics are lacking and the recommendations are broad.

FishNet Security wants to provide our customers with their own analysis of the information, which will allow them to take more focused action to mitigate any new threats.

Breach Announcements and Resources

SecureCare Online notification (updated 3/21/2011):
https://knowledge.rsasecurity.com/scolcms/set.aspx?id=8890

Letter from Arthur Coviello Jr., Executive Chairman, RSA:
http://www.rsa.com/node.aspx?id=3872

RSA Call-in for customers with further questions:
For customers in the US, please call
+1-800-782-4362; Option #5 [RSA]; Option #6 [Security Bulletin]

For customers in Canada, please call
+1-800-543-4782; Option #5 [RSA]; Option #6[Security Bulletin]

For International customers, please call
+1-508-497-7901; Option #5 [RSA]; Option #6 [Security Bulletin]

FishNet Security Analysis
It is important for FishNet Security and our customers to take thoughtful, prudent action based on the facts available in order to mitigate any risks that may arise from this third-party compromise. While it is always important to follow security best practices, most of our customers already have a general information security approach that implements those best practices and they only need to know how to tweak that approach to respond to this increased risk. FishNet Security's following analysis includes an overview of the breach and actionable information, based on available information and some assumptions where that information is lacking.

Breach Overview - What was Stolen?
Since RSA is not providing specific details on the information stolen, it is prudent to evaluate the worst-case scenario of any and all RSA information being stolen and possibly offered up for sale.
In the act of manufacturing and delivering the SecurID product, RSA must have the following:

1. Token serial number (or some kind of unique identifier that is tied to serial number) - all other information must be tied back to this serial number
2. The algorithm used to generate the tokencode for the specific type of token (IE Software/Hardware)
3. Token lifetime
4. Time-based token interval (IE 30/60/120 seconds)
5. Tokencode length
6. Token form-factor (size/type, SW/HW)
7. Name (possibly license number) of the client receiving a specific batch of tokens

Bottom line - in the worst-case scenario, the attackers would have information that allows them to generate tokencodes for the specific tokens a given customer has purchased. Note that most or all of this information is only required to manufacture and distribute the tokens, and is not necessarily maintained after the tokens are delivered. Since this is a multi-factor authentication solution, it is important to understand what the attackers could not have stolen directly from RSA. This is not to say that they do not or will not have this information in their possession, just that they did not get it from RSA. This information includes:

1. Usernames
2. PINs
3. Token serial number tied to PINs
4. Token time offset
5. Customer-specific configuration items such as PIN length & complexity, username conventions, token lockout timers, deployment, and helpdesk methodologies, etc.
6. Applications (internal and external) deployed to authenticate via SecurID

Attack Vectors - What do I need to Monitor and Mitigate?
In the worst-case scenario the attackers have weakened the SecurID infrastructure by narrowing down the universe of possible targets, identifying the customers to target and providing specific information about their target (serial number and form-factor). Breaking down all the angles in a detailed threat model is beyond the scope of this document and must be tailored to each specific customer scenario. However, FishNet Security presents a few considerations in this regard.

The attacker still needs the following information to authenticate to the victim's infrastructure;

1.  Username tied to token serial number
2. The user's PIN
3. Application/infrastructure to authenticate against

Therefore, an organization using RSA SecurID needs to be worried about attacks that target the above information. These attacks can be categorized as social engineering ("SE"), theft, surveillance, secondary compromise (e.g., use of a botnet already in place within the target company), and fraud (user takes active part in providing information).

The most likely attack scenarios include the following:

•  Prioritize targets based on whatever is most important to the attacker - visibility, reputation, money, etc.
• Purchase required information gathered via crimeware or rent a botnet already resident in target customer to gather information
• Profile a target for high-value individuals (like the list of executive leadership on their website)
• Make assumptions about their username based on first/last name information
• Attempt to social engineer either the individual or helpdesk to get targeted information
• Use external information gathering techniques such as social networking
• Targeting specific individuals for token theft - or simply stealing the token long enough to lift the serial number
• Brute force for any unknown information

Each end-user's environment is different and subsequently, the attack vectors may vary based on that environment. It is important for each customer to perform a threat analysis based on their unique situation.

Monitoring and Mitigation - How do I Watch for and Mitigate the Attacks?
The advantage here is that there are a number of items the attacker does not have in order to complete a successful attack, and that getting some of those items may be more difficult than penetrating a softer target in a different way.

First and foremost, be cognizant of your status as a target within the black hat community. Are you a high-value target? Is your company visibly on the wrong side (from a hacktivist viewpoint) of certain social issues? Would you be a "feather in the cap" of a hacker group? Everyone should be vigilant and careful, but certain organizations need to take more stringent precautions.

Second, make prudent assumptions and work backwards to logical monitoring and mitigation techniques. For example, assume your seed records are in the wild and your usernames are easily guessed, but the relationship between the two is not established. So, you need to be watching for and preventing attacks aimed at gaining that seed record-to-username relationship and the PIN.

Specific recommendations include:

• Engage your trusted Information Security provider for help with strategy and tactics, operational support, and general advice.
• Implement measures on your helpdesk to prevent sharing of the token serial number (this should only ever be assigned by one person during the provisioning process and subsequently does not need to be known by anyone) and never ask for a person's token serial number.
• Obfuscate the serial number on the back of the token - you only need it to provision. An asset tag would work well for this. Remediation for deployed tokens is difficult, but could be done in the field by the user.
• Protect your Authentication Manager backups and follow the best practice/hardening guides, including storing physical media in safes, etc.
• Educate users on the dangers of social engineering attacks. This is an ongoing, coordinated effort, not a one-time email. More comprehensive end-user education is also within scope here.
• Harden your helpdesk against social engineering using a combination of education and process updates.
• Monitor your Authentication Manager logs for brute-force attacks and out-of-profile levels of authentication failures. If you start to see a larger than normal number of PIN Guessing Attacks, that could be an indicator that someone has gained that username-to-seed record relationship.
• Look at your PIN standards (length, complexity, rotation) and update if found lacking.
• Make sure you are using multiple methods of detection for malware in your environment. Endpoint antivirus is not enough and will not give you an accurate picture of the botnet activity within your infrastructure.
• Above all, do not do anything rash - think through each action and act deliberately. An operationally sound environment is a critical piece of good information security.

The above recommendations are incomplete and general. They may not apply to your environment, and they may not be severe enough for your purposes. As your trusted information security advisor, FishNet Security can put resources at your disposal to help you make the right decisions and complete any necessary mitigation steps. Do not hesitate to reach out to us for assistance in this matter.