(Updated: Commentary on RSA’s disclosure and SecurCare advisory of March 17)

Yesterday, RSA Security disclosed that it had been the victim of a security breach that, according to Executive Chairman Art Coviello’s open letter to customers, resulted in the exposure of information “specifically related to RSA’s SecurID two-factor authentication products.” Coviello’s letter goes on to state that

“[w]hile at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.”

With the investigation ongoing, little detail has been disclosed by RSA as of this writing, except for the company to note that the attack was, to quote Coviello’s letter, “in the category of an Advanced Persistent Threat (APT)” – which really tells us very little. The term APT can be deceptive since, as Nick Selby and I described over a year ago, an “advanced” attack may use sadly well-proven techniques such as social engineering to gain an advantage, even if more sophisticated tactics include purpose-built malware requiring highly specific knowledge of the target.

That combination is suggested in the SecurCare online note RSA published yesterday in concert with an 8-K RSA filed following its disclosure, in which the company provided initial guidance to customers in response to the incident – which raises a few points worth noting about this attack:

  • The target was SecurID, a two-factor authentication product used to provide a higher level of authentication for controlling more sensitive access to information systems, such as administrative access to IT resources in the data center – which helps to explain why SecurID was the target. As with virtually any technology, it’s not as if two-factor or one-time password authentication techniques don’t already have their weaknesses – but gaining access to more detailed information about SecurID functionality could at a minimum “lower the bar” for exploits against the technique. How much lower, if at all, cannot be said at this point, unless and until more information about the specifics of what was exposed in the attack become available.
  • So much of RSA’s SecurCare advisory sounds less like guidance to customers and more like allusions to how RSA itself may have been breached (“We recommend customers harden, closely monitor, and limit remote and physical access to infrastructure that is hosting critical security software”). What guidance is provided for customers is fairly general (avoid typical avenues for phishing or social engineering, enforce strong password and PIN policies, monitor access controls and changes in user privileges), suggesting that access to resources protected by SecurID may be at higher risk if SecurID itself has been compromised. But let’s be clear: Any speculation regarding the impact of this attack – mine or anyone else’s – on either RSA or its customers is, so far, nothing but conjecture. To date, RSA has disclosed no detail about exactly what was compromised or how, leaving customers with no actionable information regarding their true risk, and spawning reactionary speculation industry-wide. RSA must address this.
  • I have already been asked, “Shouldn’t a security company be expected to do a better job of securing such assets?” This question misses a point that too many organizations still overlook: any organization responsible for assets of sufficient value to warrant a more dedicated attack may in fact already be penetrated and simply not aware of it, or not aware of the specific nature of the threat.
  • It does, however, raise the question of the level of risk involved with a specific environment. Many organizations are already concerned about protecting high-value intellectual property. But SecurID is a tool that itself protects higher-sensitivity access among a wide variety of organizations worldwide, which raises its value considerably as a target.
  • These factors seem likely to make those responsible for such assets and environments to consider more carefully how they may be able to contain threats and isolate access from interactions with less sensitive IT and information resources; how they may be able to contain threats from having a wider impact; and how they may not only increase their visibility into activity in these environments, but to do so in a way that supports effective action. (I summarized such an approach in another post a few months back.)

What can RSA SecurID customers and users do for now? Until further information about this incident is made available, customers should follow RSA’s SecurCare advisory and be watching for further information and guidance from RSA about this attack. Those that provide SecurID to their own customers should keep those customers informed as to any steps they should take once further information becomes available. It’s much too early to consider alternatives to two-factor or one-time password authentication techniques already in place, but RSA may provide guidance on how to better secure deployments affected by this incident. Modifying user behavior – well, I’ll defer much comment on that difficult topic for now, but organizations can always take steps to raise awareness of the risks of social engineering and social media.

RSA should be expected to release further detail on the extent to which SecurID – or other products, if any – may have been affected by this incident. It is also hoped that they will disclose as much detail about the nature of the attack as possible to enable others to be aware of the techniques used and ways to defend against them more effectively. This will likely be an episode that resonates throughout the security community for some time, affecting not only RSA and SecurID customers and users, but vendors of security and high-sensitivity technologies themselves to greater or lesser degrees.

Related articles: