Trust is earned every day, and in information security, your customers' trust is easy to lose and hard to earn back. RSA had a breach with unknown ramifications. RSA Chairman Art Coviello's cryptic notice, and RSA's relative silence since then, is not helping customers feel confident in SecurID as a product or RSA as a company. Just look at what's happening on Twitter for gems like this: "Dear #RSA, open your pants and show us the problem, or we will never trust you again."
I don't think any reasonable information security or IT professional would expect any vendor to be 100 percent secure, and RSA is no exception. You do your level best (and RSA has some very good people working for it), but you can't stop every attack. Your customers understand. When a problem or breach occurs, however, you retain your customers' trust by being forthright about the problem and stating what you are doing about it. That is what Microsoft and VeriSign did when VeriSign erroneously issued two code signing certificates in 2001. The two companies owned up, came clean and moved on. Fact is, RSA has to come clean publicly about what was taken and when it was taken, and then issue a forthright assessment of the damage to customers. RSA is hiding, and its customers do not like it.
But let's assume the worst, like Steve Gibson does, and think about what would happen if the master seed database was stolen. The damage from the loss of that database entails knowing what it contains. Does it just map token serial numbers to seed values used to initialize the tokens, or does it also map which tokens were sent to customers? Is the random number part of the seed values truly randomly generated, or are they somehow tied to the token in some way? Are the random numbers that are part of the seed random, or can the next one be derived? Why are the serial-to-seed mappings retained, anyway? You and I could probably come up with dozens more questions about the impact of losing the seed database, and it is natural for us to tend toward the worst case.
Maybe the seed data base wasn't breached? Steve Bellovin is "worried about the source code to any of the myriad back-end administrative products necessary to use SecurID. ... An attacker who could penetrate these administrative systems doesn't have to worry about key generation or cryptanalysis; they could simply steal existing keys or insert new ones of their own." Getting the source code to the SecurID software would give attackers a clear advantage in targeting software vulnerabilities that could be exploited. Remember, every SecurID installation has a database that maps user names, tokens, seeds and pins together. Given that data set, now an attacker can impersonate specific users, and that is a significant threat. Exploiting servers and communications channels is an effective attack strategy.
The truth is, RSA customers don't know what was lost--RSA isn't saying--and they are getting an earful of wild speculation and hyperbole from news outlets, blog posts and other outlets. (I do not include Gibson or Bellovin in this group.) Customers are getting angry because not only have they made an investment in SecurID, they have made investments of time and money in all the other systems that are integrated and rely on SecurID. Add it up and the costs are enormous. And now there is a breach, and without any other information, these same customers have no idea about the risks to their SecurID systems. That's OK, though, because RSA sent a new support note to its customers yesterday that included a FAQ.
