It is now four days since Art Coviello's open letter and the substantive analysis of what was actually taken from RSA is still essentially unavailable. The letter is a careful piece of writing, in the way that crisis communications letters from public companies are careful — it confirms that an attack happened, calls it an Advanced Persistent Threat, says that "specific RSA information" was extracted, says that the information "could potentially" be used to reduce the effectiveness of SecurID, and stops well short of saying what kind of information. The phrasing has been chosen to permit several different interpretations, and that is the point.
If you read the letter alongside Adobe's APSA11-01 advisory from the previous week, and the patch they shipped on the fifteenth, the picture sharpens. CVE-2011-0609 is a Flash bug being actively exploited through SWF objects embedded in Excel documents distributed by mail. Adobe's wording in the advisory was guarded but specific — XLS file delivered via email, embedded Flash player, exploit in the wild — and the date alignment with the RSA disclosure is uncomfortably tight. Nobody has tied the two together publicly yet that I am aware of, but every CISO I have spoken to in the last forty-eight hours has been thinking it. If Coviello's letter and Adobe's advisory are describing the same incident chain, then an emailed XLS into RSA, dropping something on a workstation, getting laterally to wherever the SecurID seed records or the equivalent live, is the picture. That fits "APT" in the way the term has been used since Aurora — careful spear-phishing, weaponised office document, custom backdoor, patient lateral movement.
The operational question that has consumed my Monday is what to do about the SecurID deployments at the clients. Towry and Northcott both use SecurID for parts of their stack; News International do not, but several of their suppliers do. The RSA letter is essentially a polite request to do compensating-control work without being told what specifically the compensation needs to compensate for. The honest answer to that is "treat the second factor as if it had become a shared secret known to a sophisticated attacker, and add additional controls that do not depend on the SecurID seed". The dishonest answer is to wait for RSA to give you a clearer steer, and on present information they are not in a position to.
What that means in practice for the next two weeks: tighter rules on where SecurID-protected administrative access is allowed to come from, source-IP allow-listing, a return to per-IP geofencing for authentication that I would normally consider unnecessarily inconvenient, and — in the stack where it is feasible — a second factor that does not depend on SecurID. The CRYPTOCard infrastructure at one of the clients turns out to be already in place for legacy reasons, which has saved an awkward conversation. At the other end, I have been on calls with two boards explaining why "we use a market-leading two-factor product" is no longer the answer to the inevitable post-breach board question, and may not have been an answer for some time before this incident. There is going to be a year of these conversations.
The wider point is the one that has been forming since Stuxnet and Aurora and is now becoming hard to evade. The defensive security industry — the people who make the products, the people who write the standards, the people who issue the certifications — sits inside the threat model. RSA is not a peripheral vendor. SecurID has been the gold standard for two-factor authentication for fifteen years. If RSA's own information systems are sufficiently compromisable that the seed records (or whatever was actually taken) walk out the door under cover of an Excel attachment, then the implicit trust calibration that runs through every PCI scope decision, every ISO 27001 controls statement, every sensitive-systems risk register that says "two-factor for administrators" is wrong by an order of magnitude that we have not previously had to think about. I do not yet know how to recalibrate it, beyond the immediate compensating controls, but the question is now operationally pressing.
For Hedgehog's pen-testing work, this also reframes part of what I am writing about for the methodology piece. The question "is your two-factor authentication actually a defence" is not the trivial one of whether it is deployed and configured; it is the deeper one of whether the trust assumption that underpins the second factor has been compromised at the supplier level, and whether your incident-response procedures have any way of knowing that. Most clients are nowhere near the second of those questions. I am going to have to introduce it carefully.
Coviello's letter ends with the line that "remediations to RSA's infrastructure" are continuing — which is at least an admission that remediation is needed, which Microsoft and similar vendors have historically been reluctant to make in equivalent moments. It does not yet tell us what remediation looks like, what the customer-side equivalent of remediation looks like, or what the longer-term shape of SecurID-as-a-product is in the aftermath. I will be reading Bruce Schneier and Mikko Hypponen closely over the next fortnight to see if anything firms up.
The next post will probably be the SQL-injection methodology piece I have been promising the engagements team for two months, unless something else breaks in the SecurID chain. Or unless Slim Amamou resigns in protest from the Tunisian government, which my correspondents in Tunis are now expecting any day.