RSA Caught in a Compromised Position

There has been a lot written about the breach of RSA Security and the effect the advanced persistent threat has on SecurID users. The Open Letter to RSA Customers is so vague that it is hard to figure out exactly what the exposure is, and more importantly what to recommend to corporations relying on SecurID for two-factor authentication. I used worked with Security Dynamics, maker of SecurID before changing their name to RSA, as Director of Product Management from 1993-1998, so let me add to the discussion (I no longer have any financial interests in RSA Security).


The big risk is theft of source code that would allow an intruder to design a custom attack against servers installed on customer premises. For instance, all the attacker would need to do is exploit a weakness in the management protocol to be able to insert a backdoor or impersonate a privileged user to steal secrets. This scenario would be very serious as RSA would not be in a position to assure customers of the integrity of their authentication system, and wouldn’t even know how the attack manifests itself until customers are infected.

The lesser risk is theft of serial numbers and seed values. An attacker would still need to associate the exposed seed and serial number with the company that the purchased the token and the user possessing the token. That is really hard for an outsider to do, and if successful all an attacker achieves is one random user to impersonate. Yes, it is a concern but it seems like a manageable one.

If you are a SecurID customer there are a couple of procedural things you should do while RSA conjures up an explanation that may reduce the risk of an infected authentication system:

Audit IPS and firewall policies to ensure that there are no unauthorized communications with SecurID servers. This includes outbound connections that could signal a successful penetration of malware. This communication to the attacker might be the only way to detect a devastating breach of security.

Scale back on remote management of SecurID, including IT service desk procedures. Management operations that originate from outside the server perimeter are particularly dangerous. Consider assigning a member of your security team to perform privileged operations from a physically connected console, and disallow privileged operations over the Internet.

Finally, voice your displeasure at RSA in no uncertain terms and send them the bill for you extra security precautions. If you are a bank using SecurID for high-roller customers, then you are responsible for disclosure and re-imbursement if the system is compromised – RSA owes you more guidance than what I have seen.

It is ironic that enterprises have to disclose security incidents to consumers, but here we have a one of the most trusted security companies on the planet keeping business in the dark. Hopefully, RSA Security soon issues another open letter that is more enlightening on how customers should protect themselves.