The specific example I have in mind here is the breach of RSA in March 2011 where attackers got away with critical information which could be the seed information which is used to generate the pseudo-random numbers for RSA tokens.
RSA have kept very quiet about the actual details, so if I was in charge of security at an organisation what could I do to secure against a worst case scenario? How would I even know what the worst case could be?
I think the fact that your security vendor is being far from transparent, is already a pretty bad case scenario.
When the vendor is being secretive wrt security details - be it specifics of an incident, or the security internals of the product itself (or at least proof of security, e.g. crypto algos) - this is an inherent risk, to the entire security posture of your own organization.
Now, while in certain circumstances it is legitimate to accept a risk, such a risk as this (having your whole security architecture rely on a third party, which may or may not be trusted)should not be accepted lightly.
When a vendor starts to tip in the direction of withholding critical information, instead of supporting customers in making smart choices, I would say that the risk acceptance decision starts being a bit murky.
As a result, if I was in that position (and ignoring constraints such as budget, time, and politics), I would re-evaluate my relationship with ALL vendors supplying a critical piece of my infrastructure. Note that this is irrelevant of the actual impact - high impact flaws can happen to (almost) anyone - the important part is how you choose to deal with it.
In my opinion, in this case the way they dealt with it (or didn't) shows that they don't understand the trust relationship that needs to be in place, for the above risk acceptance to be valid. At the very least, I might consider changing vendor relationships to one of risk transferrance instead of acceptance, via strict SLAs with penalty clauses.
And in this specific case?
Well, assuming that switching out the entire authentication mechanism until this deal gets sorted, is not really possible - not much else to do, except activate more logging on logins, pay extra attention to anomalous logins, watch what your users do, and generally try to minimize access for users...
If a vendor suffers a compromise on a system which you use, and refuses to give you satisfactorily details on the impact of the compromise on your systems, then what you should look for is... a new vendor.
Worst case scenario is complete breakdown of whatever the security system was used for. E.g. in an authentication system, attackers know enough to authenticate themselves under whichever fake identity they wish, and may also prevent valid users from authenticating, or disrupts their authentication process such that the server authenticates them transparently with the wrong ID.
This question really goes back into risk management, and I'm not even talking about risk management derived from information security management.
I'm talking about project management risk management. A lot of companies have a PMO (project management office) but fewer have project risk experts in them.
When scoping out a project, such as outsourcing identity management to a vendor's product, such as RSA SecurID -- project risk managers would say, "how much should we put into this single vendor solution?" -- not from a security perspective, but merely from a "run the business" perspective.
In my mind, when a large company goes to purchase a product and roll it out (this applies to outsourcing and cloud computing, including SaaS, as well) there is the notion not to put all your eggs in one basket. If your primary vendor goes away -- how easy it is to move to a secondary or tertiary vendor?
When planning -- it is easy to just look at cutting up providers/vendors into percentages and overfill. If you have a solution that is 100 percent in house, considering adding one external solution that will fill a 20 percent gap. Then, add another provider for another 20 percent -- a 40 percent outside solution. Determine which provider is most worthwhile of the two after some performance accounting (and probably financial accounting) analysis, as well as your own internal audit performance and business metrics around said product.
If one solution sticks out -- tap on another 20 percent, and if they behave well over another time period (a cycle, or iteration, of six sigma), add a final 20 percent. Then you have two providers -- one at 20 percent, one at 60 percent (and 20 percent still in-house). As a final move, add a third provider/vendor solution at 20 percent (for a fully outsourced solution). However, retain your ability to fall back to your 20 percent solution if need be for a certain time period. See how they perform. Using your second and third providers -- see if either of them can take on another 20 percent (like your first provider did) during trial runs. If they pass, perform failure scenarios where you drop your primary provider down to 40 percent and let the secondary or tertiary provider take on that additional 20 percent for a period of time. Analyze using your metrics and six sigma tools how the secondary and tertiary providers perform -- and shift around the numbers if your primary provider is failing you.
In the long run -- you'll be able to quickly move from one solution point to another -- and potentially even back to an in-house solution. This isn't just information security management, risk management, or disaster recovery / business process operations. It's good project management practice!
Somebody else will have a better answer I'm sure, but I think at worst case, it requires immediate revocation of all tokens, and an audit of all the systems that the tokens were used to secure.
I think worst case scenario should be defined by the business, per business.