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
Related Links Top of the: day, week, month.
As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare
Re:What? (Score:5, Informative)
A threat is a possible action taken against you. A vulnerability is a specific avenue by which that threat can be realized. Threats and vulnerabilities exist in different ways. Threats represent things that *might* happen in the future. What you are worrying about is threats *materializing* as attacks. Vulnerabilities don't materialize -- they're there in the system all along.
The practical purpose of this distinction is that the actions you take in response to a vulnerability is different than than the actions you take in response to a threat, and the *results* are *vastly* different.
The response to a vulnerability is to *eliminate it*. Having no lock on a door is a vulnerability you eliminate by putting a lock on the door. Note that eliminating a vulnerability does not eliminate vulnerabilities as a class of concerns; in fact it may introduce a new vulnerability. By installing a lock you've eliminated the vulnerability of somebody simply walking into your house, but you've replaced it with the less serious vulnerability of having the lock picked.
The response to a threat is to *reduce your exposure to it*. Burglary is a threat; you can reduce your exposure to it by eliminating vulnerabilities (the lockless door, the piles of cash under your mattress), and taking steps to reduce the damage (buying insurance), but *eliminating* burglary is not a feasible goal.
It's a useful distinction because it separates concerns that you can eliminate with immediate, concrete actions from those you have to keep an eye on.
Re: (Score:1)
Priorities! (Score:2, Insightful)
Elizabeth Taylor dies and you post this crap? Have some PRIORITIES, man!
Re: (Score:2)
Elizabeth who?
Re:Priorities! (Score:4, Funny)
Elizabeth who?
The woman who was married 8 more times than most /.ers
Re: (Score:2)
I thought she had 7 husbands.
Re: (Score:1)
And 8 marriages. A quick application of the pigeonhole principle will resolve this paradox for you.
Re: (Score:2)
I thought she had 7 husbands.
She did have 7 husbands but she was married 8 times. She married Richard Burton twice.
Re: (Score:2)
Who is that and why should we care? [grin]
It's afternoon here! (Score:3)
It was 14.28 hrs in the afternoon when it was posted, you America-centric insensitive clod!
Re:It's afternoon here! (Score:4, Funny)
I agree. The world should revolve around you and headlines should take your life into account going forward. I'll make a note of this sire and have the staff writing the Internet to make an adjustment.
Re: (Score:1)
Re: (Score:2)
If you don't like the US bias at /., make your own freakin' site like the Japanese did [slashdot.jp]. We're all genius coders here, should be a simple task... right? :)
Pass the coffee! (Score:1)
Re: (Score:2)
Right. Early. (Score:1)
It's way past noon here you timezone-ignoramus. I'm loving it!
Summary (Score:5, Interesting)
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.
Re: (Score:2)
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
Re: (Score:2)
By far #3 is the most dangerous threat.
Re:Summary (Score:4, Funny)
I was maybe 15 years old, and it was the 5th of July. The fireworks from the night before inspired me to embark on a career of pyrotechnics.
My best friend came over and we attempted our first batch of gunpowder. I found the composition of gunpowder in the encyclopedia, got together the ingredients, and set up a table in the backyard. We mashed some old charcoal briquets up, measured out the other ingredients, poured them all in a bucket, and immediately cops started swarming into the backyard.
They came from the back fence over the alley. They came from both neighbors'. They came from the front yard. It was so sudden and so massive there was no chance for us to hide our illegal activity.
But they totally disregarded us, and in fact waved us away. A few minutes later they came out with a long-haired shirtless white guy in handcuffs.
He'd escaped from police custody earlier, and had been hiding in our backyard tree watching us make gunpowder the whole time.
ps- The gunpowder didn't work. Thank God.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:3)
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
The difference (Score:2)
Small comment (Score:3)
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?
Re: (Score:3)
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
TFA says it all... (Score:1)
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.
Re: (Score:2)
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
Semantics (Score:2)
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.
Screw threats (Score:1)
...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
This isn't a hard concept to master (Score:2)
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.
OSSTMM (Score:3)
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.)
Interesting. (Score:2)
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
Re: (Score:2)
Read the whole paper . . . (Score:2)