Security is Hard: Weak Measures

The real problem isn’t the fragile piece of glass, though; it’s the guy throwing the brick. – Richard Bejtlich

Everyone in the industry measures security vulnerabilities by some context of risk.  Some prefer the DREAD model, some measure through Critical – Informational, some measure through CVSS, some even go a step further and add threat agents into the mix.   But, what those approaches were essentially flawed?

Our modern security risk systems appear to be based on the idea that a successful attack is like a natural disaster.  If you have a poor ceiling and a hurricane comes through town, there is a high probability you’re going to lose your roof.  The recommendation would be to fix your roof, with your risk level being dependent on how often hurricanes come through town.  But, though this is true and (to a degree) useful, that whole line of thinking isn’t really how breaches go down.  Hackers associated to breaches aren’t like a hurricane at all.  They are nothing short of robbers who attack an armored car, or the petty thief who robs a home while no one is in it.  They have motive, they are premeditated, and they are doing it because there is a payoff at the end.  If the ROI is worth it, the details of how it goes down (what you’ve done to protect yourself or not) are somewhat immaterial.

Before you comment and say things like, “SQL injections are still super common and crazy critical to fix!”– I already know that.  In fact, I think that SQL injection proves my point. Criminals target what makes the most sense for what they are willing to invest.  Attacks that are: easy to test for, common to find, and can lead to deep access into the system– that’s the sorta stuff dreams are made of!  Why be creative and ‘leet’ when shit that worked 3 years ago still works today?  This is exactly the same reason why most muggers aren’t highly trained ex-military seals– they don’t need to be.  They are predators who attack on the weak– it’s basically that simple.

For most people, the better return on investment is going to be investing in basic protection mechanisms and strategies that help keep their noses out of trouble.  The fact that SQL injections and cracking WEP wireless is still so very common just reinforces that we are measuring and prioritizing things wrong.  Instead of being concerned about what CAN happen, perhaps we should first be dealing with what IS happening.  If we actually had information available to let us understand the indicators and predictors around how and why companies are targeted for breaches– that would be a significantly more relevant way to determine what risks a company actually should concern itself with.  Funny how criminology has taken that approach for years…

If a risk matrix doesn’t treat attackers like intelligent, capable human beings who may or may not intend to do you harm— it simply cannot help you prioritize where you place your efforts.  Instead of being worried about the likelihood of a hurricane coming through town and magically transporting your wallet into an attackers hands, perhaps we should focus on not leaving your wallet hanging out of your pants.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Andre Gironda  On October 16, 2010 at 3:51 pm

    There’s no reason why manufacturers sell devices (or push firmware to their support websites) that can enable WEP. All modern Access-Points should include secure update functionality, and like Firefox and Chrome, have a very high fully-patched rate. Then we should just wipe-out WEP as if it never even existed. If the former setting was WEP, the current setting now becomes WPA Personal and the user is forced to change the password just like on a Windows domain.

    There’s no reason why apps can’t be tested for SQLi on the server-side using technology like O2’s unhandled exceptions module, the ImmunitySec SQL Hooker plug-in, or the HP Fortify PTA product. In other words — install one or all of these on your staging/integration servers before they go live in production.

    Protecting data and databases is also penultimate to this. Please provide a privacy wall and honeytokens — your RDBMS definitely supports it if written in the past 40 years and you don’t need to patch anything.

    • pinvoke  On October 22, 2010 at 5:16 pm

      Andre,

      I appreciate your perspective and have some additional thoughts about what you’re saying. I don’t think that your observations are incongruent with my post at all. I will follow up later on this point.

      -A

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: