Respond
March 22, 2011

RSA Breach: Mitigations for Your SecurID Implementation

The blogosphere has lit up in the last several days with details of an attack that involves the company that makes one of the most widely-used 2-factor authentication solutions. RSA, a subsidiary of EMC, the maker of the SecurID 2-factor authentication system was hacked by what they are calling an advanced persistent threat (APT). RSA released an open letter with very few details about the actual attack and then sent out a letter to current customers with general suggestions for increasing the security of their systems in the wake of the attacks. The information given in the open letter was thin and indicates that due to an on-going government investigation they cannot release more details. The company simply states that the attack was "extremely sophisticated" and that the data exfiltrated by the attackers does not enable "direct attacks" on the SecurID system but does "reduce the effectiveness" of the system.

At this point we could begin speculating on what data was lost or what vector was used in the attack or what group is responsible for the attack. There is plenty of this going on around the web and there are some good write ups out there already. See some of the below articles for more information.

Ars Technica
NY Times
Engadget
Network World

After this attack was made public RSA provided some advice for mitigating the effects of the currently undisclosed compromise. I've picked out some of the better advice here.

1. Enforce strong passwords and PINs.
2. Review help desk procedures with an eye toward blocking social engineering attacks.
3. Tell users to avoid suspicious e-mails and not to give out user names and other credentials when they are solicited by    e-mail or phone call. They should report such attempts.

The above are some pretty general suggestions and I think they would fit into best practices for security in general. Strong passwords and user education, two of the most important things we can do to protect our systems. RSA also had some rather comical advice:
"Implement two-factor authentication to directories and use SIEM products to keep an eye on directory activity."

What are some other ways to mitigate the effects of a SecurID system compromise? Throwing the system out wholesale is not the answer even though I'm sure this was the initial knee-jerk reaction of some IT shops. Locking the system down beyond use was probably another common reaction, but remember we do not want to become "Mordac the Preventer of Information Services." As security practitioners we are here to protect users and company assets while also enabling users and the company to function. Luckily for most of the users of the RSA SecurID system there are some simple solutions and some slightly more complicated solutions.

1. Enforce strong PINs!
The"PIN" in SecurID terms is the users password, this is the "something you know". I think it is unfortunately named "PIN" because this causes most people to associate it with bankcard "PINs" i.e. short 4 digit codes that never need to be changed. In reality you should have your RSA system set to enforce, at a minimum, an 8-12 character "PIN". Be sure to enable the use of alphanumeric characters. Recent versions of RSA Authentication Manager allow the use of the following set of characters [a-z A-Z 0-9]. While not perfect it does allow for 62^8 (~ 2.18E14) combinations. Much better than a 4 (10,000), 6 (1,000,000), or even 8 (100,000,000) digit "PIN" using only numbers.

2. Enforce strong PINs! No really!
Yes I repeated myself to make a point here. Also to point out something of note in the RSA Authentication Manager settings. You can set the PIN to be 8-12 characters, and you can enable the [a-z A-Z 0-9] character set but users will still be able to make a poor 8 digit only PIN! In addition to giving users the option to use characters you should make sure to set the complexity requirements. These are pretty simple, you just set the minimum number of letters and numbers that must be in a PIN.

3. Set a PIN expiration time.
The system allows the PIN to be set to never expire. Yes you have an ever changing 2nd factor in the token itself but now with it potentially being compromised forcing PIN changes on a regular (30, 60 or 90) day basis is an even better idea. (Hint: you should have been doing this already). I've seen guidance anywhere from 30 to 90 days, I think 30 days is a bit short and there are other changes you can make that are more effective and don't impact the user as much.

4. Lock users out
Set a lockout threshold for failures and either set the system to automatically unlock after a sufficiently long period of time (30 min or more) or require an administrator to unlock the account. If the tokens have been compromised an attacker is most likely going to still have to perform some brute force or PIN/tokencode guessing as part of the attack. Setting a lockout will slow them down or require them to call an administrator who will hopefully be on the look out for suspicious behavior.

5. Audit users
I've seen systems where every user is issued an RSA token. Make sure to audit your users on a regular basis to identify those that are not utilizing the system. A good idea here is to define a process where user logins are audited and if a user has not logged into the system for x period of time then they are disabled. If they go for another x period of time then collect their tokens and remove them from the system completely. A user who isn't using the system is a risk you don't need to accept. Also a user who isn't using the system most likely isn't keeping track of that pesky token.

6. Use another layer of authentication
User or machine certificates are a good way to increase the security of a system. For instance if your organization is one of many using RSA tokens with a VPN solution then consider adding user or machine certificates into the authentication mechanism for the VPN. For most VPN systems the ability to use certificates to augment user/password authentication systems is already available.

7. Monitor your logs
Monitor the RSA authentication logs for suspicious behavior. Again, if the tokens have been compromised an attacker is most likely going to still have to perform some brute force or PIN/tokencode guessing. Monitoring the logs for repetitive failures in a short amount of time can alert your staff to attacks. Also, having a SIEM that can automate the task of monitoring the logs, and alerting when the activity is seen is an even better solution.

I hope some of this advice is helpful in dealing with the effects of the breach, and if you have any other helpful advice please leave it in the comments.

Continue reading

cybersecurity newsletter
The MPG newsletter

Get great curated articles into your inbox.

Our semi-regular newletter is a great source of information.
No spam!