posted by Scott Crawford   | April 4, 2011 | 0 Comments

Catching up after a long weekend spent (mostly) offline, and digesting RSA’s Friday disclosure regarding its recent breach. In the plus column for RSA:

  • At least they made an effort to communicate some detail, albeit late, and at no small risk to their reputation no matter how their statement would be received.
  • They were reasonably forthcoming about the nature of the attack itself, and appear to have immediately informed and worked with thousands of customers in dealing with the impact, for which they deserve credit – though given the issues they have to contend with around disclosure, we must essentially take their word at this point for how they helped, without knowing exactly what they disclosed to those customers.

On the other side of the balance sheet, regarding both RSA and coverage of their disclosure:

  • Outside of whatever they may have shared with the customers they contacted, RSA still has yet to disclose exactly what was compromised, and the extent of the impact. Again, as I noted last week, RSA may have a few issues to contend with in disclosure.
  • I’m not big on Monday morning quarterbacking. For every failure of defense that can be called out in any case, there are likely many, many more that could have been exploited – and may be yet. But this obscures a very important fact relevant to this case: no matter how skilled an adversary may be, we far too seldom make it particularly difficult for even simple attacks to succeed.

This gets into some of the detail of the RSA breach that bothers me about invoking the so-called Advanced Persistent Threat in any incident. RSA has used this handle liberally in describing the attack – while at the same time being fairly clear on Friday that the foothold gained by the attacker was good old fashioned phishing (even if the attempt may have been reasonably well targeted).

This is not to say there are no such things as adversaries with the motivation, resources and expertise to carry out more strategic attacks. Nor should we rule out such an adversary in the RSA breach – particularly considering how SecurID could be seen as a strategic objective for such an adversary, since it often stands between them and more sensitive assets across a large number of high-value targets. But the fact that initial entry was gained through such a common technique nevertheless begs the question: just how sophisticated did the attacker really have to be to get in the door?

Nick Selby and I wrote about this paradox over a year ago, and it’s just as true today as it was then: A more adept adversary may use tactics that range from those requiring detailed technical knowledge of a unique target – to basic techniques that continue to prove their effectiveness over and over again, for one simple reason: Because they work.

This is why such vague terms as “advanced” and “persistent” are a problem: they make it possible for us to absolve ourselves for any attacker’s not-so-sophisticated successes, no matter how skilled the adversary. And this, in turn, can distract us from realizing something even more serious:

To the extent this notion of APT is (ab)used to rationalize a breach helps us avoid recognizing just how low a bar we’re setting for attackers, and how poor a job we’re doing in reducing exposure when we could do better, even with imperfect techniques. In Verizon’s 2010 Data Breach Investigations Report, 85 percent of attacks in the caseload were not considered highly difficult, while 96 percent of the breaches examined (that’s nearly every single one, folks) were avoidable through simple or intermediate controls – a figure that is actually up 9 percent from the prior report.

This is one of the reasons we have such a need for more data-driven approaches to security, rather than describing threats with generalities such as “advanced” and “persistent” that really tell us nothing of any value about specific incidents. Given numbers like these, does an attacker really need to be advanced in order to succeed?

If we’re so exposed, a good deal of the reason is that the fault, dear Brutus, is not in the APT, but in ourselves. Security vendors in particular should take note of this fact – particularly if their own offerings could help them do better. Hardly anyone would be in a better position to demonstrate how an approach to security that recognizes this reality could reduce exposure, than those who are responsible for assets whose compromise could affect far more than just the victim organization alone.

Enhanced by Zemanta


Posted in Uncategorized



Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>