Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security

Threats vs. Vulnerabilities 51

Schneier's blog links to a short paper on the difference between threats and vulnerabilities. It's a little heavy for this early in the morning, but it might be worth your time.
This discussion has been archived. No new comments can be posted.

Threats vs. Vulnerabilities

Comments Filter:
  • Priorities! (Score:2, Insightful)

    by Anonymous Coward

    Elizabeth Taylor dies and you post this crap? Have some PRIORITIES, man!

  • by captainpanic ( 1173915 ) on Wednesday March 23, 2011 @08:39AM (#35585462)

    It was 14.28 hrs in the afternoon when it was posted, you America-centric insensitive clod!

  • Eish, too early indeed. I kick-started my day with this, and now I have to buy another coffee to reset. That's TWO coffees in 25 mins... I am beginning to suspect I have a vulnerability. No wait, it's a threat, but only if I someone spikes it, then the vulnerability lies with me, but the threat is external. OMG!
  • It's way past noon here you timezone-ignoramus. I'm loving it!

  • Summary (Score:5, Interesting)

    by cpu6502 ( 1960974 ) on Wednesday March 23, 2011 @08:50AM (#35585608)

    Difference between "threats" and "vunlerabilities"

    THREAT: A Criminal might break into my house
    Vulnerability: My house has no lock.

    He then goes on to talk about how using Threat Analysis tools is Not sufficient to identify vulnerabilities, because they are not the same thing, and Vulnerabilities are much more difficult to identify.

    • That's a pretty funny summary. He really does defeat his own point by coupling them so tightly.

      What he should have done to make his point better was to first do his vulnerability assessment:

      1) Windows are not bullet-proof
      2) Doors can be easily kicked in.
      3) Back gate has no lock
      4) Locks to the front doors haven't been changed since last residents moved out.
      5) Comings and goings of residents are obvious and predictable

      Threat Assessment:

      1) Junk mail
      2) Neighbor's dog crap
      3) Random prison escapee hiding in back

      • By far #3 is the most dangerous threat.

      • by hey! ( 33014 )

        No, no, no! The strength of a window is a *feature* (or perhaps we should say a "property"); a bullet being fired through that window is the *vulnerability", which may or may not exist in all non-bullet proof windows. For example, a window put in an interior swinging door to prevent people from braining each other with the door may have the feature or characteristic of being not strong enough to deflect a bullet, but shots being fired through that window do not present a realistic vulnerability.

        Arguably t

    • It's more like:

      Threat: it's been seen in the wild, hammering something.

      Vulnerability: a conceivable possibility exists if someone is dogged enough to do the wild coding needed, and some happless situation is setup, to cause a problem which may or may not result in something to worry about.

      Threats are alive and transitive, vulnerabilities are conceptual and passive.

    • Your summary is spot-on, my issue is with TFA's analysis.

      Vulnerabilities are FAR easier to recognize than threats, insofar as you are aware of capabilities. Threats involve understanding motivations and goals of people with inimical goals, or 'unknown unknowns'.

      It's far easier to recognize that your house has no lock, than to conceptualize that there are thieves out there who want to break in, if that's not a part of your intellectual framework in the first place. To be topically relevant, I'd guess it's e

  • I like my girls with an ait of vulnerability. My brother likes them with a threatening air. (seriously, at times he has bruises all over him because of his "play acting" with girls)
  • by ifoxtrot ( 529292 ) on Wednesday March 23, 2011 @09:08AM (#35585770)
    FTA " Another sort of related problem commonly found in infrastructure security assessments is confusing features with vulnerabilities. Thus, a public road that travels close to the facility is often considered a Vulnerability. It is not, however; it is only an attribute. Only when coupled with an attack scenario (truck bomb, the road makes visual and electronic surveillance easier for espionage, assets can be thrown over the fence by insiders to the bad guy's parked truck, etc.) does a feature become a Vulnerability".

    I'm not quite sure about the point the author is trying to make here: what's the purpose of differentiating between features/attributes and vulnerabilities? Is it only a vulnerability when it can be exploited? This is actually undermining the definitions the author uses for explaining the difference between threat and vulnerability: if a vulnerability can be "exploited by multiple adversaries having a range of motivations and interest in a lot of different assets", requiring attack scenarios to be specified before allowing an "attribute" to be called a vulnerability feels a bit unnecessary, and could even focus the attention too much onto one kind of attack. Incidentally, neither attribute nor attack scenario is defined anywhere in the paper, which makes the distinction being drawn here weird.

    In my view, a vulnerability is a property of the system that allows an attack; there is a natural overlap between a vulnerability and an attack, but they do exist independently: it is sometimes interesting to think of vulnerabilities that have no known or feasible attack (e.g. crypto ciphers that are seen as weak do not necessarily have feasible attack scenarios). Requiring an attack scenario in order to classify a feature (or attribute) as a vulnerability seems unnecessary: why would you have described the attribute as a vulnerability if you didn't have an attack in mind already?

    • I think what he's getting at is that "Features" are not, by themselves, vulnerabilities. For a feature to become a vulnerability requires context. To a certain degree, you have to frame the conversation a bit. If you frame the conversation "I want to be protected", you can spend days/weeks/lifetimes spinning around in circles. "I want to protect myself against terrorists" is a lot different than "I want to protect myself from dishonest employees", which is a lot different from "I want to protect myself from

    • I'm not quite sure about the point the author is trying to make here: what's the purpose of differentiating between features/attributes and vulnerabilities? Is it only a vulnerability when it can be exploited? This is actually undermining the definitions the author uses for explaining the difference between threat and vulnerability: if a vulnerability can be "exploited by multiple adversaries having a range of motivations and interest in a lot of different assets", requiring attack scenarios to be specified before allowing an "attribute" to be called a vulnerability feels a bit unnecessary, and could even focus the attention too much onto one kind of attack. Incidentally, neither attribute nor attack scenario is defined anywhere in the paper, which makes the distinction being drawn here weird.

      *Editor’s Note: This paper was not peer-reviewed. This work was performed under the auspices of the
      United States Department of Energy (DOE) under contract DE-AC02-06CH11357. The views expressed
      here are those of the author and should not necessarily be ascribed to Argonne National Laboratory or
      DOE. Jon Warner provided useful suggestions.

    • by ediron2 ( 246908 ) *

      You're close to agreement, but the road isn't the vulnerability. Traits of the road can cause (and eliminate) vulnerability, and they'll each come back to the mechanism that'd be exploited, not the road itself.

      A security patrol, barriers, countersurveillance, removing the ability to loiter and eavesdrop and monitoring systems can mitigate or remove vulnerabilities. The road can remain, you just have to mitigate the vulnerabilities it creates.

      Maybe what's snagging you up is that sometimes the best mitigati

  • This distinction isn't hard to understand --unless you're a project manager. I made the mistake a few years ago of telling a PM about a vulnerability in one of our web apps. She started sending e-mails CCing everyone from the CEO to the janitor telling them about this "security breach." When I tried to gently correct this misunderstanding, all I got was a lot of diva attitude and "I'll call it whatever I want." I was really happy when I quit that job.

     

  • ...some have yet to get past the concept of vulnerabilities vs. exploits.

    Vulnerability: The lock on my door can easily be picked using a stick of butter
    Exploit: Someone exploited the butter vulnerability in my lock to gain access to my house

  • Threat: A guy who doesn't like you
    Vulnerability: Getting kicked in the nuts really hurts.

    When a Threat finds a Vulnerability, and exploits it, that's when you have a problem.

  • by Ken_g6 ( 775014 ) on Wednesday March 23, 2011 @11:00AM (#35587610)

    For much more detail and depth about these kinds of topics, see the free OSSTMM [isecom.org]. (Scroll down to the bottom of the page.)

  • I was hoping the paper would also go into vulnerabilities-without-threats. I've been having a debate with some people regarding car vulnerabilities - Some universities have done studies and determined that someone could use the tire pressure monitoring systems as a way to hack into the car's computer and screw with some readings. The car guys are generally up in arms about this - "Why wouldn't they secure the systems," while I take the stand that even though the car is technically vulnerable to such an atta

    • To a certain extent I would believe it would really depend on the value of the target. Anyone can steal dog poop from a yard, so they are obviously vulnerable, but I doubt many people are particularly worried about losing said dog poop.
  • . . . and I still don't know what the definition of "security" is.

There is no opinion so absurd that some philosopher will not express it. -- Marcus Tullius Cicero, "Ad familiares"

Working...