Threat Modeling Again, STRIDE
STRIDE stands for "Spoofing", "Tampering", "Repudiation", "Information disclosure", "Denial of service", and "Elevation of privilege".
Essentially the idea is that you can classify all your threats according to one of the 6 STRIDE categories. Since each category has a specific set of potential mitigations, once you've analyzed the threats and categorized them, you should know how to mitigate them.
A caveat: as David points out in his "Dreadful" post, STRIDE is not a rigorous classification mechanism - there's a ton of overlap between the various categories (a successful Elevation of Privilege attack could result in Tampering of data, for instance). But it doesn't change the fact that it's an extremely useful mechanism for analyzing threats to a system.
So what are each of the STRIDE categories?
A spoofing attack occurs when an attacker pretends to be someone they're not. So an attacker using DNS hijacking and pretending to be www.microsoft.com would be an example of a "spoofing" attack. Spoofing attacks can happen locally. For instance, as I mentioned in "Reapplying the decal" one mechanism that the Decal plugin framework injects itself into the Asheron's Call process is to spoof one of the COM objects that Asheron's Call uses.
Tampering attacks occur when the attacker modifies data in transit. An attacker that modified a TCP stream by predicting the sequence numbers would be tampering with that data flows. Obviously data stores can be tampered with - that's what happens when the attacker writes specially crafted data into a file to exploit a vulnerability.
Repudiation occurs when someone performs an action and then claims that they didn't actually do it. Primarily this shows up on operations like credit card transactions - a user purchases something and then claims that they didn't do it. Another way that this shows up is in email - if I receive an email from you, you can claim that you never sent it.
Information Disclosure threats are usually quite straightforward - can the attacker view data that they're not supposed to view? So if you're transferring data from one computer to another, if the attacker can sniff the data on the wire, then your component is subject to an information disclosure threat. Data Stores are also subject to information disclosure threats - if an unauthorized person can read the contents of the file, it's an information disclosure.
Denial of service
Denial of service threats occur when an attacker can degrade or deny service to users. So if an attacker can crash your component or redirect packets into a black hole, or consume all the CPU on the box, you have a Denial of service situation.
Elevation of privilege
Finally, there's Elevation of privilege. An elevation of privilege threat occurs when an attacker has the ability to gain privileges that they'd not normally have. One of the reasons that classic buffer overflows are so important is that they often allow an attacker to raise their privilege level - for instance, a buffer overflow in any internet facing component allows an attacker to elevate their privilege level from anonymous to the local user (or whatever account is hosting the vulnerable component).
Please note, these are only rough classifications of threats (not vulnerabilities). And many of them aren't relevant in every circumstance. For instance, if your component is like PlaySound, you don't need to worry about information disclosure threats to the data flows between the Application and PlaySound. On the other hand, if you're writing an email server, you absolutely DO care about information disclosure threats.
UPDATE: Adam Shostak over on the SDL team has posted an enhanced definition of the STRIDE categories on the Microsoft SDL blog. You can read that list here: http://blogs.msdn.com/sdl/archive/2007/09/11/stride-chart.aspx
Next: STRIDE mitigations
Edit: Larry can't count to 6.