RSA SecurID Breach Update: (Some) Additional Info Provided to Customers
In my updated initial take on the breach, I noted that:
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.
RSA would like to persuade us that today’s advisory is a step in that direction – while at the same time, being fairly clear that it is not, or is at least not a complete disclosure. RSA claims to have its reasons for withholding more specific information about the attack and the attacker (which we’ll get to below).
Basically, today’s information contains more of the same recommendations as earlier guidance – but with a couple of provocative additions (noted in bold below). From the advisory (RSA customers should consult the advisory itself for additional detail):
- Secure your Authentication Manager database and ensure strong policy and security regarding any exported data
- Review recent Authentication Manager logs for unusually high rates of failed authentications and/or next token
- Educate your help desk and end users on best practices for avoiding social engineering attacks such as targeted phishing
- Establish strong PIN and lockout policies for all users
This reiterates that SecurID is part of a multifactor authentication system that typically includes:
- Server side logic and cryptography
- SecurID algorithm
- Possession of token records
- Association of individual tokens with users
- PIN (typically – but not necessarily always). (A PIN is basically a password used in conjunction with the token – but effectively a password in its own right. RSA strongly recommends against PIN-less deployments, by the way. Today, I think you can clearly see why.)
- Any additional password that may be in use, such as the user’s password for accessing their personal computing environment (e.g. user account password managed in Active Directory)
So, the upside (such as it is): Multiple authentication factors such as a PIN or additional password associated with a specific user mean that customers are not as exposed as they would be if one-time passcodes generated by the SecurID system (server + token) were the only protection resources had in this case – hence why customers are recommended to take the company’s guidance seriously to safeguard these additional factors from exposure or exploit.
Unfortunately, what is not being said also leaves many fearing the worst – that the SecurID system itself is compromised in some meaningful way. Again, I’m going to refrain from much speculation of my own – but until RSA is able to release further information about the attack and the attacker, many organizations are indeed going to respond based on this assumption, mainly because they have little else to go on. Many are already assuming that customer token records have been compromised, in light of guidance to protect the additional factors of SecurID authentication – which begs the question: How much more is there really left to disclose?
If you’re a customer, you are doubtless already drawing your own conclusions – and this is something RSA must address as soon as it can without doing further damage.
Here is RSA’s take on why they would not release more detail generally at this time, from the Q&A published with today’s customer advisory:
Providing additional specific information about the nature of the attack on RSA or about certain elements of RSA SecurID design could enable others to try to compromise our customers’ RSA SecurID implementations.
The company asks us to take on faith, for the time being, that this is the case, while it works through a response that best protects those affected. This will, however, burn through goodwill fairly quickly (it has already) unless and until RSA can demonstrate that its actions were warranted in the best interests of its customers.
In the end, this episode will undoubtedly raise the bar on the security of the systems we rely on to protect our most sensitive information resources, as well as the security of the vendors who provide them – but this will not be particularly straightforward, to say the least. Clearly, adversaries see such assets as high-value targets – and defense against the more sophisticated adversary is, by definition, non-trivial. Fundamental changes may have to be made in the way vendor development environments are architected and secured, beyond how they are protected today. But that hardly means that the security industry should not take a new and different look at how it secures the products that protect our highest value assets.
Inadvertently, the attackers in this case may have done more than just raise the stakes in security gamesmanship. They may have done the industry a tremendous favor by raising the stakes on the protection afforded to security products as well – but at what cost?
And how responsive will the industry ultimately be?