threats, assets, vulnerabilities

Bejtlich posted, “What Do You Investigate First?” He brings up the question of three different approaches:

  • focus on the threats
  • focus on the assets
  • focus on the vulnerabilties

These are great bullet points for a blog post (or hell, probably a small book) on how these approaches can be tackled, including perspectives from prevention, detection, response. And how these may compare to the “reality” many orgs face in responding to only the things that people will raise fire alarms about if they’re not available or what you might get in the most trouble for not responding to…

I was going to flesh this out as a full future post, but decided already that I don’t have the time, yet didn’t want to lose the beginning of my thoughts…

evilgrade discussion reflects our challenges

Wanted to link really quickly to a recent example of the problems we face in security, even amongst ourselves. EvilGrade 2.0 was recently released, and the full-disclosure announcement sparked some…discussion. As background, EvilGrade is software that assists an attacker in hijacking the upgrade process of a piece of software and sending its own executable in place of a real upgrade executable, thus having it automatically executed by the software.
The subsequent discussion brings up the points of (I’m just informally summarizing here):

  • Hijacking upgrade mechanisms is a vulnerability (or weakness).
  • This vuln is not necessarily easy to leverage by an attacker. Has limited (but useful!) applicability. (local network access; targeted; etc)
  • There is an opportunity cost to addressing this issue. (Time spent fixing small issue = time not spent elsewhere.
  • The issue may be easily fixed with certificate signing. (Everything is always ‘easy’ to someone…)
  • Certificate-signing also has its own weaknesses.
  • Cert-signing also means added code which means added complexity and possibly more exposure to other attacks.
  • Ultimately the question: is this issue worth fixing in product ABC? Is this huge enough that we stop corporate updates until a fixed is proven, audited, and required by regulations? (Ok, I added that last part myself…)

This is a classic example of the belief that every vulnerability must be fixed, no matter the cost vs doing what you can with the resources and costs/risks available to you (which can be very subjective in measure). This sort of argument is pretty much religious. In fact, I’ve called it such in the past with posts about security religions. There are usually no universally correct answers, and there is usually pretty detrimental and venomous discussion once you start down these threads.

But it illustrates the challenges we face even amongst our own in the security circles. It gets worse when you have one person on each side of this discussion whispering into opposite ears of the non-technical business-owner who makes the ultimate decisions. (Although, cost-savers probably always have an inside track in that argument…and ‘doin nothing’ is the easier example to explain…)

Full disclosure: I have sympathies on both sides of that discussion.