The recent RSA Breach ( http://www.rsa.com/node.aspx?id=3872, http://isc.sans.edu/diary.html?storyid=10564 ) has got lots of people asking lots of questions, and as a security consultant, I seem to be getting lots of them directed my way. I thought it was time that someone said "How bad could it possibly be?" and outline just what the worst case might be, along with what the associated risks are (or are not, please read on).

First, let’s review how the RSA Authentication solution works. Your users have a keyfob (or a soft token on a phone or PC), with a token code that changes randomly. They also have a personal PIN code (4-8 alphanumeric digits), which only they know. These combine to make their password, which is normally used for secure access to a VPN, Web Server, Terminal Server or some other resource.

The more astute readers will have already seen the error in the paragraph above. The token code is *not* random (true randomness is a very tough nut to crack). The token code derived mathematically from a seed which is provided by RSA when the server is originally installed, the serial number of that particular token (printed on the back) and the system clock.

In short, RSA’s ACE server is a traditional multifactor authentication system. It combines something you have (the keyfob) with something you know (your PIN code) to authenticate you. Once authenticated, it is up to you to handle Authorization (ie – now that you are in, what do you have access to?).
 

So, back to the RSA event  - what is the worst case breach that might have occurred? Well, for all I know, the information that was stolen was RSA's Christmas Card list, they really aren't forthcoming yet on exactly what the extent of the breach might have been.

The absolute worst case I can think of (and I am NOT implying that this happened), would be if an attacker obtained a complete or partial customer list, complete with seeds and serial numbers. Again this is my own worst case - read on, even this is not as bad as you might think.

First of all, like all good cryptographic algorithms, RSA's token code algorithm is both math heavy and public. If you have the seed, plus the serial number of a token, an attacker can easily calculate the token code at any given time. CAIN for instance is a popular tool that has an interface for this.

This seems pretty bad, but don't forget the rest of it. When a user logs in, they need to supply their userid, their token code, and their pin code. There is no way that an attacker could have obtained the userids (specific to the organization) or pin codes (known only to the user) from RSA.

An attacker could easily obtain a list of users from several sources - your company website might have several senior staff listed, or even a corporate directory. Facebook, Myspace and especially LinkedIn are other likely sources for user names. Combining your first and last name in any of the common formats gets you a list of account names that will work for many environments. (note that some shops will have userids that are not related to your actual name)

This leaves the PIN code and the serial number. The assignment of serial numbers to usernames resides only on the customer’s ACE server - RSA does not have this information. The user’s PIN code is set by that user, and is 4-8 alphanumeric digits, though many organizations still only use 4 numeric digits. Unless people use trivial PINS, such as "1234", or the last 4 digits of their public phone number or extension for a PIN, the PIN is also probably "secret enough", since no-one knows it but the user.

All this being said, RSA's advice <sent in an email to RSA customers, and then re-posted here along with loads of other locations on the web  - http://www.sec.gov/Archives/edgar/data/790070/000119312511070159/dex992.htm > is spot on, and just plain common sense.   Some of the high points I've summarize here (in my own words and order), but RSA’s list of recommendations boil down to “defense in depth” against brute force login attempts (both in protecting against them, and minimizing the impact if successful).

• Implement account lockout on your RSA server - if someone gets their login wrong 3,4 or 5 times, either they are attempting a brute force login, or they are legit, but need a refresher course and shouldn't be logged in tonight. Oddly enough, this one is NOT in RSA’s list, but it’s certainly first on my list !!
• Review your logs regularly. Or even better, use common log monitoring tools like SWATCH, Kiwi Syslog (now owned by SolarWinds), or any other monitor to raise an alert when you see successive failed login attempts. SEIM tools do a bang-up job of this as well.  Have a procedure in place to take action when you see an alert.
• Enforce strong password and PIN policies
• Keep systems patched
• Get your helpdesk on board, both the helpdesk and your users should know what a social engineering attack might sound like and what they should do if they see one.
• Don’t let your workstation get owned. If your workstation is owned, a keystroke logger can snag your PIN, and all is lost. RSA's advice on this includes being careful on social media, don’t open suspicious emails, the usual suspects.
• Use access rights and other authorization methods to implement least privilege access. If you don’t need access to critical information, then you shouldn’t have it.
• Harden your servers

Long story short, no matter how bad RSA's breach might or might not have been, System Administrators have it in their power to implement truly effective mitigations.  In fact, after reviewing the list, all of us should be doing this stuff already – if not, there’s no time like the present to start !

===============
Rob VandenBrink
Metafore