Someone Please Explain Threats to Microsoft

It's 2007 and some people still do not know the difference between a threat and a vulnerability. I know these are just the sorts of posts that make me all sorts of new friends, but nothing I say will change their minds anyway. To wit, Threat Modeling Again, Threat Modeling Rules of Thumb:

As you go about filling in the threat model threat list, it’s important to consider the consequences of entering threats and mitigations. While it can be easy to find threats, it is important to realize that all threats have real-world consequences for the development team.

At the end of the day, this process is about ensuring that our customer’s machines aren’t compromised. When we’re deciding which threats need mitigation, we concentrate our efforts on those where the attacker can cause real damage.

When we’re threat modeling, we should ensure that we’ve identified as many of the potential threats as possible (even if you think they’re trivial). At a minimum, the threats we list that we chose to ignore will remain in the document to provide guidance for the future.


Replace every single instance of "threat" in that section with "vulnerability" and the wording will make sense.

Not using the term "threat" properly is a hallmark of Microsoft publications, as mentioned in Preview: The Security Development Lifecycle. I said this in my review of Writing Secure Code, 2nd Ed:

The major problem with WSC2E, often shared by Microsoft titles, is the misuse of terms like "threat" and "risk." Unfortunately, the implied meanings of these terms varies depending on Microsoft's context, which is evidence the authors are using the words improperly. It also makes it difficult for me to provide simple substitution rules. Sometimes Microsoft uses "threat" when they really mean "vulnerability." For example, p 94 says "I always assume that a threat will be taken advantage of." Attackers don't take advantage of threats; they ARE threats. Attackers take advantage of vulnerabilities.

Sometimes Microsoft uses terms properly, like the discussion of denial of service as an "attack" in ch 17. Unfortunately, Microsoft's mislabeled STRIDE model supposedly outlines "threats" like "Denial of service." Argh -- STRIDE is just an inverted CIA AAA model, where STRIDE elements are attacks, not "threats." Microsoft also sometimes says "threat" when they mean "risk." The two are not synonyms. Consider this from p 87: "the only viable software solution is to reduce the overall threat probability or risk to an acceptable level, and that is the ultimate goal of 'threat analysis.'" Here we see confusing threat and risk, and calling what is really risk analysis a "threat analysis." Finally, whenever you read "threat trees," think "attack trees" -- and remember Bruce Schneier worked hard on these but is apparently ignored by Microsoft.


These sentiments reappeared in my review of Security Development Lifecycle: Microsoft continues its pattern of misusing terms like "threat" that started with "Threat Modeling" and WSC2E. SDL demonstrates some movement on the part of the book's authors towards more acceptable usage, however. Material previously discussed in a "Threat Modeling" chapter in WSC2E now appears in a chapter called "Risk Analysis" (ch 9) -- but within the chapter, the terms are mostly still corrupted. Many times Microsoft misuses the term risk too. For example, p 94 says "The Security Risk Assessment is used to determine the system's level of vulnerability to attack." If you're making that decision, it's a vulnerability assessment; when you incorporate threat and asset value calculations with vulnerabilities, that's true risk assessment.

The authors try to deflect what I expect was criticism of their term misuse in previous books. On p 102 they say "The meaning of the word threat is much debated. In this book, a threat is defined as an attacker's objective." The problem with this definition is that it exposes the problems with their terminology. The authors make me cringe when I read phrases like "threats to the system ranked by risk" (p 103) or "spoofing threats risk ranking." On p 104, they are really talking about vulnerabilities when they write "All threats are uncovered through the analysis process." The one time they do use threat properly, it shows their definition is nonsensical: "consider the insider-threat scenario -- should your product protect against attackers who work for your company?" If you recognize that a threat is a party with the capabilities and intentions to exploit a vulnerability in an asset, then Microsoft is describing insiders appropriately -- but not as "an attacker's objective."

Don't get me wrong -- there's a lot to like about SDL. I gave the book four stars, and I think it would be good to read it. I fear, though, that this is another book distributed to Microsoft developers and managers riddled with sometimes confusing or outright wrong ways to think about security. This produces lasting problems that degrade the community's ability to discuss and solve software security problems.


No one is going to take us seriously until we use the right terms. Argh.

Comments

Marcin said…
hmmm, maybe if it's "wrong" in so many places, could it be that you're wrong?? And in fact, those definitions are "right?"

haha, I'm kidding. I agree with you on your definitions and it's important all of us are on the same page with our definitions or we will all end up just confusing ourselves and others.
jbmoore said…
threat (thrĕt) pronunciation
n.

1. An expression of an intention to inflict pain, injury, evil, or punishment.
2. An indication of impending danger or harm.
3. One that is regarded as a possible danger; a menace.

vulnerability
n 1: the state of being vulnerable or exposed; "exposure to
ridicule" or "vulnerability to litigation" [syn: exposure]
2: susceptibility to injury or attack [ant: invulnerability]

Yes, technically it should be vulnerability assessment and modeling. The perspective is whether you are thinking defensively or offensively. If you are the defender, you are trying to minimize your vulnerabilities. If you are the attacker, you are creating threats to the defender or the defender's systems. If you can't create an exploit to take advantage of a vulnerability, then you are not a threat. It sounds like threat modeling and vulnerability assessment are two sides of the same coin, like an IDS team and a penetration team during a network security exercise.
Weber Ress said…
This comment has been removed by the author.
Weber Ress said…
In my opinion, this discussion isn't about security, threat modeling or SDL. It's about English Language, synonyms and grammar. It's necessary check the context. The sentence "a threat is defined as an attacker's objective" is correct if you check inside a secure software development (for example) in a security context. If you analysis this sentence alone, you get "strange" results.
@ Weber Ress
"this discussion isn't about security, threat modeling or SDL. It's about English Language, synonyms and grammar."

This is not only about Semantics. Any knowledge area must have a basic terminology like military terminology. That's why ISO creates specific standards to define vocabulary like ISO Guide 73 and the ISO 27000 (the last one will be release soon).
Anonymous said…
Agree that we could do better in the terminology area.

On Schneier's attack trees, the big problem I have is trying to record and visualise the data.

Microsoft have the "Threat Modelling GUI", which has the terminology wrong but at least starts to cover the requirement.

Are you aware of any other tools? Creating attack trees collaboratively would be a neat way to capture security knowledge.
Anonymous said…
It's nice to see more people saying the same thing. I think part of the problem at MS comes from their insistence that they're trying to model the attacker, instead of modeling the system—when you think defensively and are trying to find all the ways that a system can be broken, not just a few, you need to understand the system's requirements and what security means in the system. This emphasis on requirements requires you to have a high level concept like threats, separate from implementation-level vulnerabilities.

It's a long way from being ready for prime time, and even the methodology talked about there is pretty out of date, but we have a tool (under development) and some other information online at http://octotrike.com. With luck, there will be some updates coming soon.
Eleanor, do you mean www.octotrike.org? I hadn't heard of your project before -- neat.
Anonymous said…
I very much suspect that this misuse of terms comes from Microsoft marketing. They might have decided that there is no such thing as "vulnerability" to be mentioned in their books, hence they named it "threat".
While it isn't technically correct, it sounds like "oh look at us poor guys. we have to face a plethora of threads every day" instead of "look at us erring humans. we cannot guarantee that every line of code is free from unintended blunders"

Another example for marketing intentionally corrupting language.
jbmoore said…
This comment has been removed by the author.
jbmoore said…
Exploited vulnerabilities are a threat to Microsoft's public image they've fostered that they build secure software when the evidence is to the contrary. But they are not alone. I received an email from ISC(2) today about threat modeling. Richard is right that one has to get the terminology within context right or else people fail to communicate effectively.
Anonymous said…
This comment has been removed by a blog administrator.
Jim Yuill said…
I’m evaluating SDL for use in a new software system. I really liked SDL until I got to Chapter 9 on Risk Analysis. In this chapter, I’m having serious problems understanding the SDL terminology. After many re-reads of the chapter, I’m suspecting the problem is not my lack of intelligence, but instead, that the terminology has significant flaws. Further, these flaws lead me to wonder what other aspects of SDL might have problems.

Richard’s blog articles provide excellent insights on these terminology problems—thanks!

Some additional thoughts:

* Richard identified that, in SDL, “threat” often means “vulnerability”. I’d add that, also, “threat” often seems to mean “potential vulnerability”, e.g., as in “Identify Threats to the System” on page 116 of the SDL book.

* In general, SDL might be clearer if the authors explicitly stated whether “threats” refer to *potential* or *actual* vulnerabilities, e.g., is the threat modeling process used to identify potential or actual vulnerabilities?

* At times, the term "threat” seems to make most sense as being “ways software can potentially be attacked”, or “ways hackers could attempt to attack software”, e.g., the STRIDE threat types as described on pg 114

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics