Microsoft, Explain Threats to Microsoft
The Microsoft Malware Protection Center recently published their third Security Intelligence Report. The front page of the report saysAn in-depth perspective on software vulnerabilities and exploits, malicious code threats, and potentially unwanted software, focusing on the first half of 2007
Inside it continues:
This report provides an in-depth perspective on software vulnerabilities (both in Microsoft software and third-party software), software exploits (for which there is a related MSRC bulletin), malicious software, and potentially unwanted software. The lists below summarize the key points from each section of the report...
The number of disclosures of new software vulnerabilities across the industry continues to be in the thousands...
Contrast that proper use of the word vulnerabilities in those excerpts with the incorrect use of the word threat in the quotes I noted in Someone Please Explain Threats to Microsoft:
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...
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.
In that excerpt, all uses of the word threat should be replaced with the word vulnerability, with possible exception of the term "threat modeling." In reality it should be "attack modeling," but in all other cases Microsoft is clearly talking about discovering holes/flaws/problems in their software, i.e., vulnerabilities.
So, it seems that the people who have the big security picture -- those who write the Microsoft Security Intelligence Reports -- know the difference between a threat and a vulnerability. The developers who focus on Microsoft's software -- those exercising the Microsoft Security Development Lifecycle -- are using "threat" when they should be saying "vulnerability."
It would be good for the SIR people to talk to the SDLC people. Without that coordination Microsoft's developers will continue to view the security problem incorrectly, and by extension, so will the customers who look to Microsoft for intellectual guidance.
On a related note, I was happy to see the latest SIR available as a .pdf.
Comments
:^)
This is his attempt to sort of acknowledge incorrect use in earlier books but not really change his terminology. I address that direct quote in my review of SDLC.
Pull your head out of the software development sand. You'll see there is a bigger security world out there. The digital scene thinks it can sweep away decades or more of security terminology in favor of their warped usage. Kudos to Gary and crew for adopting and explaining these terms correctly.
It’s hard to imagine why someone would want to redefine standard terms. On the face of it, it seems like great gall--very arrogant and foolish of MS to even attempt co-opting our language. However, I suspect they have some other motive. When intelligent people inexplicably insist on doing nonsensical things, it can be useful to look for hidden motives.
Richard has another blog post about SDL terminology, and there, an anonymous commenter notes that MS may be avoiding the “V” word (vulnerability) for PR reasons. Also, might MS’s corporate lawyers have banned MS’s use of the “V” word, as it could be used against them in law suits? Imagine a shake-down law-suit in which MS is compelled to admit they ship code with known security “vulnerabilities”, and the jury is clueless about computer security. Would it help MS’s legal-defense if they only have to admit to shipping code with known “threats”.
BTW: on page 102 of SDL, they say that their definition of “threat” is also used in Common Criteria (CC). However, there’s been lots of criticism published about CC--even by MS in the SDL book itself (page 22f)!
Jim