Comments

Afonso Araujo Neto • March 23, 2011 6:56 AM

I think the paper has a small (important) error. When it says “(b) security is a continuum and 100% elimination of a Vulnerability is rarely possible” I think it meant that “100% elimination of a Threat is rarely possible”. I really think it is quite often possible to eliminate single vulnerabilities completely. Otherwise, it really puts things up quite clearly, a good piece to reference 🙂

Kevin • March 23, 2011 7:48 AM

I’m not sure if that is an inaccuracy based on my understanding of threats and vulnerabilities. If you point a gun at me (threat) and I shoot you first then I have completely eliminated a threat (assuming you died). But I am still vulnerable to being shot. So I can completely eliminate a threat, but not a vulnerability. If I put on a bullet proof vest I have reduced (but not eliminated) my vulnerability to bullets. I have not reduced the number of people that want to shoot me (threats).

G.L.D. • March 23, 2011 7:50 AM

His example of a public road nearby being neither a threat nor a vulnerability is a good one, and should help those who might otherwise mistake tools for T’s or V’s.

To further solidify understanding for the reader, the paper needs to continue to explain how Risk (the real reason we do this work) can be defined as the product of:

Threats x Vulnerabilities x Assets

Drive any factor toward zero and you reduce that particular risk.

This paper helps the reader recognize that a roadway is none of the factors above, and to know into which category to place a short fence or a hostile party with a truck.

Clive Robinson • March 23, 2011 7:57 AM

One thing that does not come out with his spectrum of threats and vulnerabilities is the difference between “speciffic” and “class”.

For instance the specific examples of bomb damage, earthquake damage tornado damage fall into the general class of structural damage. Often the a generalised mitigation strategy is better than a specific strategy (an evacuation plan is not likley to differ much for fire or earthquake etc).

The same aproach needs to be applied to both TA’s and VA’s. General classes of threats give basic indicators of many types of specific threat however specific threats do not usually give anything other than specific indicators which means you miss a lot of “unknowns” that you might otherwise have covered.

Also general as oposed to specific gets rid of a lot of Security Theatre.

Thomas Mueller • March 23, 2011 8:12 AM

I wonder how threat and vulnerability assessments are done for (sorry) nuclear facilities. After 9/11 ‘plane crash’ was popular, now I guess (hope) they will do assessments for earthquakes, flooding, corruption related to facility inspections. But I’m not sure about things that didn’t happen yet, such as sabotage by employees, landslides, rocket attacks, volcanoes.

Danny Moules • March 23, 2011 8:21 AM

“now I guess (hope) they will do assessments for earthquakes, flooding, corruption related to facility inspections.”

They already do those things, that’s why the situation is as it is now. Seriously, I’m sick of reading articles talking every day about “the FEAR of nuclear radiation” or “the PANIC about nuclear radiation”.

To quote Dara Ó Briain:

“Zombies are at an all time low level but the fear of zombies could be incredibly high. That doesn’t mean we need to have government policies to deal with the fear of zombies.”

Failsafe after failsafe after failsafe has triggered at that facility. And it still has plenty more failsafes to go before anything people ‘fear’ is going to happen.

Afonso Araujo Neto • March 23, 2011 8:29 AM

@Kevin I think the mapping (as in the paper) would be “You possibly getting shot from someone” as the threat, and “Someone pointing a gun at you” as the vulnerability. But I’m not sure your example is good, because this situation mixes up the attack with the vulnerability. The vulnerability would be more related to “the circumstances that allowed the guy to be able to point this particular gun to you”.

From a computer science point of view, there are more clear examples: The threat of injecting SQL commands to a database through an application, and the vulnerability of a single coding error that can be used to accomplish it. This particular coding error is easily fixable, while eliminating completely the possibility of injecting commands is much harder.

Keith • March 23, 2011 8:30 AM

What he misses is the bridge between a threat and a vulnerability. Consider the malware threat; a bad actor (threat + resources) seeks to exploit a series of vulnerabilities, for some malevolent purpose. Consider all the factors that must facilitate this “attack,” 1) lack of adequate testing of network components, software and employees that could lessen the number and criticality of vulnerabilities; 2) a lack of or ineffective business processes that permit critical, unmitigated vulnerabilities to exist; 3) poor governance that fails to address #1 and 2.

My point is that threat and vulnerabilities don’t exist in isolation, they are enabled by human behavior, behavior that can evaluate and mitigate risk but often do so very poorly as Bruce has pointed out.

Thomas Mueller • March 23, 2011 9:44 AM

@Danny you wrote “failsafe after failsafe has triggered at that facility. And it still has plenty more failsafes to go before anything people ‘fear’ is going to happen.” – I’m not sure about what facility you talk about?

I don’t really fear radiation, but it seems nuclear power plants / the insurance company is only liable for up to 1 billion dollar per accident – that’s clearly too low. By the way, where I live, small airplanes can fly over nuclear power plants without problems. Bombing one would be quite easy. Luckily, my country doesn’t have many enemies.

GreenSquirrel • March 23, 2011 10:09 AM

Interesting document.

I am not sure I fully agree with everything it says, especially with regard to threat assessments.

As I see it, the “threat” is a way of describing (i.e. a scenario) how a threat actor can exploit a vulnerability.

Without a threat actor or without a vulnerability, there is no threat. Likewise if you can prevent a threat actor accessing a vulnerability, there is no threat.

(having read the comments, I realise this is very similar to what Keith wrote – sorry).

Brad • March 23, 2011 10:16 AM

I think this is a fascinating argument, but it is really we are not defining the threat at its lowest level in the example. If we do that then the definitions basically hold up.
Example: the ‘threat’ isn’t if someone can shoot you, the ‘threat’ is that humans are susceptible to being penetrated by fast flying dense objects which cause damage. So if we take this threat, then we can define a vulnerability, some different scenarios on how it is most likely to occur, and mitigations to the risk.

Johnny B Good • March 23, 2011 10:32 AM

@ Brad
I like that you focussed on the fast flying objects penetrating people and I was going to do the same. But, with respect, you then used the wrong word ‘threat’. The key indicator is the word susceptible that you used. Susceptible and vulnerable are basically synonymous . Our vulnerability (or susceptibility) is that we are easily maimed or killed by flying objects especially those with high kinetic energy or mass. The threat (threat agent) is the person or thing that might hurl said object at us.

aaron • March 23, 2011 11:00 AM

Infosec folks with a military background like to cling to these old definitions.. they need to accept defeat — these terms have been redefined. GET OVER IT and MOVE ON! I gave up on insisting the definition of a threat is not a vulnerability years ago and it has made my life much easier.

mc • March 23, 2011 12:07 PM

“I wonder how threat and vulnerability assessments are done for (sorry) nuclear facilities.”

Design Basis Threat Analysis & DEPO is used for Physical Security Systems in the United States.

Disasters and Attacks are treated differently, under safety systems and security systems respectively. A third set of regulatory systems dealing with reporting and monitoring of material is called safeguards. All three systems work together in theory, but there is tension (e.g., easy pathways out of a building in case of fire = not optimal for security).

As far as security (attacks w/ an adversary that adapts purposely to subvert your systems as opposed to a “dumb” event) broadly its threat analysis (ID attackers/capabilities/motivations/etc), followed by a pathway analysis (looking for the most vulnerable pathway), and then mitigation (adding either detection/delay). Scenario analysis happens after pathway analysis to help ID vulnerabilities that may not be apparent with historical threat based analysis.

This is then used to manage risk by looking at probability of events, consequences, and costs of changes.

jml • March 23, 2011 12:21 PM

The paper may be helpful, as I’ve been trying to explain to some in my world that unpatched OS/app vulnerabilities are still vulnerabilities, even if they’re screened from the Internet by a firewall.

The threat is mitigated by the screening, but the vulnerability is still present.

-jml

Clive Robinson • March 23, 2011 12:30 PM

@ Johnny B Good,

“susceptible and vulnerable are basically synonymous”

Err not in all fields of endevor relating to security.

You as a person may be suseptable to many things, however not all of them will cause a harmfull effect in you. That is you may be suseptable but it may not have an effect on you or the effect may change with intensity etc (think thermal energy for instance).

It is why we usually say “a person is susceptable to XXX if YYY….” Thus the type of effect is stated (XXX) qualified by a conditional (YYY) as well.

For instance humans are susceptable to most types of EM radiation. The effects are many and varied and the two conditionals generaly being the frequency and the field density of the EM radiation.

However the normal usage of vulnerable has an implicit “effect of harm” from the stated “cause” but usually it is not qualified via a conditional. That is you would say “a person is vulnerable to disease”.

That is “vulnarable” unlike “susceptible” is a binary statment (it is / it is not). The qualifier on susceptable is often qualitive in nature as well.

Mikhail • March 23, 2011 1:05 PM

IMHO:

Vulnerability –

Some weakness in a system or process.

Threat –

A vulnerability that is readily exploitable, with a risk probability beyond what the system owner is willing to accept.

Way easier and far more robust than the ridiculous caveats this paper has placed on the definitions.

A vulnerability is objective, a threat is a subjective evaluation of the risk that vulnerability entails.

B-Con • March 23, 2011 1:51 PM

Interesting taxonomy. That means when something that goes wrong, it is best viewed as a pairing of a threat and vulnerability, ie:

SomethingThatGoesWrong_x = (Threat_y,Vulnerability_z)

Unless I missed something, “something that goes wrong” wasn’t given a specific name in the paper.

Peter E Retep • March 23, 2011 2:40 PM

Recent history demonstrates the fallacy of modernist defense thinking:

“You must be able to deter your enemy from the most likely way they may attack you” – MacNamara Doctrine

vs
Von Clausewitz’:
“You must be able to defeat your enemies in the most dangerous [asymmewtric] way they can attack you.”

The U.S. is painfully and expensively re-learning a lesson its citizens began learning in 1774, 1812, 1861,
[by 1898 the US learned it], but forgot for: 1916, 1941, 1952, 1963, 1992, and forward.

The distinction between vulnerability and threat is at the heart of the matter.
To forget the distinction is to invite attack.

grumpy • March 24, 2011 4:17 AM

I like the way that threats and vulnerabilities are described as two very distinct things. What helps you figure out threats (eg intel) may be no help when trying to figure out vulnerabilities (eg technical skills). They are really very different fields demanding very different qualifications which makes the integration between them a hard problem to solve.

Peter • March 24, 2011 10:36 AM

Excellent and insightful paper. It seems as though Vulnerability Analysis is a must-do function and a prerequisite for Threat Analysis, which you can maybe do if you have the time and resources. Sounds about right.

I disagree only on one point. The author seems to believe that Threat Analysis is not really worth the effort, because it is hard to do right and easy to get wrong, while focusing on vulnerabilities is so easy.
This might hold true with physical security, but in Infosec circles, we know that there are always vulnerabilities you don’t yet know exist, and that threats always have the initiative. So studying likely and dangerous courses of action a threat might take is definitely useful, especially if you then form a plan around those scenarios.

I am curious–what is the distinction between “Red Teaming” and “Adversarial
Vulnerability Assessments?” How would an “AVA” not involve some effort to understand the threat, their motivations, etc.? If TA is so difficult, why is AVA listed as such a potent tool?

Clive Robinson • March 24, 2011 1:22 PM

@ Peter,

“I disagree only on one point. The author seems to believe that Threat Analysis is not really worth the effort, because it is hard to do right and easy to get wrong, while focusing on vulnerabilities is so easy.”

I can give you a good reason for this in that we tend to think in “classes” for threats that do not map to “classes” in vulnerabilities. The oposit tends to be true as well in that we think of “individual” vulnerabilities not “classes” and we try to map them individualy to classes of threat.

You can see how this goes wrong if you think “terrorist threat” you immediatly think of bombs bullets and hostages, most of which are actualy in different classes of vulnerability. That is bomb threats tend to be in the “evacuate” and “structural damage” vulnerability classes etc…

TheRidge • March 24, 2011 11:10 PM

What if the vulnerability is not readability repairable ? I think of buffer overflow OS vulnerabilities waiting for the patch. Hence there is a threat to get root/admin on an OS. Well want if we reduce the threat by using an intrusion detection/intrusion prevention system with sigs for that attack and we already have a hardened kernel with a chrooted like environment. Now we have reduced the threat without fixing the vuln. Right ?

If I am right, then I question the real world application of his assessment.

TheRidge • March 24, 2011 11:37 PM

When I think of chasing vulnerabilities, I think about the words of Marcus Ranum.

http://www.ranum.com/security/computer_security/editorials/master-tzu/index.html

Valuing vulnerabilities as a top priority is chasing of the wind. Understanding the whole threat and finding a way to manage or eliminate it despite vulnerabilities seems to be the path to enlightenment. While Marcus seems to have the skills to write his own secured software, many admins do not. So the next best thing is to expect that something may be vulnerable and to apply solutions that can prevent or contain it anyway. That’s the idea behind chrooting and/or solutions like SELinux and grsecurity. I wish Windows had embraced concepts like Chroot and/or SELinux and grsecurity.

Again, am I missing something here ?

Dirk Praet • March 25, 2011 5:02 AM

@ Danny Moules

“”Zombies are at an all time low level ”

Surely you are not following Belgian politics.

Zian • March 26, 2011 5:58 PM

The formatting of the paper gives it an instant credibility boost in my eyes and I would like to see it improved a little more and handed out to everyone in the software engineering world.

By breaking things down and starting from the basics, he has managed to make meaningful and insightful comments about the entire security industry.

Johann van der Merwe • March 28, 2011 2:38 PM

I would like to make some general comments related to the paper. Maybe somebody will find them useful.

If you consider available literature, the comments above and comments on similar blog posts, you may note that the information security industry is not in full agreement on the meaning of the term “threat”. Although I agree with the definition in the paper to a large extend, I would define the attributes of the “Who” (threat agent) more clearly. I particulary like the way the “Intel threat agent library” define threat agents (search for it in Google). I have enhanced it for use in risk assessments and combine it with intelligence data and information on past security incidents (as suggested in the paper) to derive threats for a specific information asset.

In addition, I think this “confusion” on the meaning of the term “threat” is a source of problems for us in the industry. In particular, if you consider the risk equation R= T X V X I, threat (T) is also where most of the uncertainty lies when considering risk. Without understanding the treats you are dealing with you have little (or no) chance of protecting information assets again, for example, Advanced Persistent Threats (APTs). For this reason I think the Threat Assessments is not only important but critical.

In light of the above I don’t agree with the statement in the paper “If you understand and take some reasonable effort to mitigate your security Vulnerabilities, you are probably in fairly good shape regardless of the Threats (which you are likely to get wrong anyway).” Your understanding of potential threats (and the attributes of threats) is fundamental to identifying vulnerabilities and treating risks. “Who” you up against is also related to the value of your information assets. You will therefore also scale your Threat and Vulnerability Assessment efforts in relation to the value of the information assets or more specifically the possible consequences for the business should CIA be impacted.

As a final comment I would like to congratulate the author on the good piece of work.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.