It must have hurt: RSA, one of the world’s biggest names in IT Security, recently was forced to admit that there had been a successful attack against the “seeds” that are a part of their hallmark RSA SecurID Token system. These seeds store secret information that enables the system to assemble one-time passwords. Nobody really knows how serious the breach of security has been, and RSA isn’t talking, but there nevertheless are lessons to be learned for the entire industry.
One of the things RSA has refused to discuss is the amount of information lost through the seed theft. Another is the thief’s identity. And finally, no one knows for sure (except RSA, presumably) whether and how attacks have been made or could be made against installed systems. All of this creates a deep sense of insecurity among customers and users of the technology, since one factor of their multi-factor security system has been compromised.
All of this has nothing at all to do with the devices is use, nor with the logon data such as user names, passwords and PINs. However, a really determined attacker could probably use phishing or social engineering attack methods to collect this information from at least some users, thus giving them access to RSA SecurID protected systems.
No matter what the ultimate reason or where responsibility lies, the case proves that in the end, the secret sauce that everyone using RSA SecurID placed their trust in just wasn’t secret enough.
And while it is true that nothing is ever completely safe, the question remains how users and companies can achieve an adequate degree of protection.
What RSA customers can do
One thing is clear: Relying on a single security mechanism is risky. Anyone using RSA SecurID tokens must think about how to react. This means assessing their risk levels and choosing from a range of remedies.
One logical way to react is by sharply auditing the systems in question in order to discover attacks at the earliest possible stage. Switching to an entirely different system is probably not an option for most customers, given the degree with which RSA SecurID is interwoven into the structure of their IT environments. Completely redesigning these systems would call for huge expenditures of both time and money.
This, again, is nothing unique to RSA SecurID. Any security mechanism will contain some kind of residual risk, and being prepared is one of the ground rules of the game.
The only possible answer is something called „versatile authentication“. Basically, this means being able to combine a number of different security mechanisms in any desired way. For instance, the system might require additional authentication through another mechanism if highly sensitive data is being requested, or if management decides to re-assess the risk attached to any individual mechanism, such as is now the case for SecurID.
There are a number of very good multiple-factor authentication schemes in the market today, each involving its own mix of soft tokens, out-of-band authentication, hardware token and other mechanisms. Therefore it is entirely possible to introduce new mechanisms retroactively by implementing an additional factor or requiring additional information upon authentication, even without resorting to the fuss and bother of hardware tokens.
This added flexibility lets organizations react faster to new risk scenarios like the one described here. It also allows more nuanced methods of authentication, for instance by implementing an addition authentication layer for extremely valuable information or by tailoring different security mechanisms to different groups of users. Hardware tokens may be easier and cheaper to implement for company employees than for external customers or partners, for instance.
Making decisions case by case
This approach means that it becomes less important to talk about just how secure any individual factor may nor may not be. As in the case of RSA SecurID, the real question becomes: How much risk remains, and how much am I willing to accept?
Versatile authentication allows organizations to be more flexible in deciding which mechanisms to deploy and what mix of mechanisms is right for individual groups of users, as well as what information they should be allowed to access. This gives organizations more ways to react if something goes wrong.
Cast-iron authentication is neither practicable nor affordable, and even if an organization should ante up, there still will remain some degree of residual risk. Strategically speaking, versatile authentication is the only way to go if you want to be able to react correctly the next time a security vendor is successfully attacked. And depend upon it, you competitors who are having a field day ridiculing your unfortunate colleagues at RSA. Your may be in the headlines one day, too, and sooner than you think.