I see a lot of confusion over terms when it comes to threat modeling.  The terms matter because they shape focus.  For example if you confuse threats with attacks, you've limited what you're looking for.

There are the terms we used when we created our How To Threat Model Web Applications:

• Asset. An asset is a resource of value. It varies by perspective. To your business, an asset might be the availability of information, or the information itself, such as customer data. It might be intangible, such as your company's reputation. To an attacker, an asset could be the ability to misuse your application for unauthorized access to data or privileged operations.
• Threat. A threat is an undesired event. A potential occurrence, often best described as an effect that might damage or compromise an asset or objective. It may or may not be malicious in nature.
• Vulnerability. A vulnerability is a weakness in some aspect or feature of a system that makes an exploit possible. Vulnerabilities can exist at the network, host, or application levels and include operational practices.
• Attack (or exploit). An attack is an action taken that utilizes one or more vulnerabilities to realize a threat. This could be someone following through on a threat or exploiting a vulnerability.
• Countermeasure. Countermeasures address vulnerabilities to reduce the probability of attacks or the impacts of threats. They do not directly address threats; instead, they address the factors that define the threats. Countermeasures range from improving application design, or improving your code, to improving an operational practice.

Rather than get caught up in the definitions, you can focus on intent:

• Asset.  What do you value?  What do you prioritize?  What do you not value?
• Threat.  What's a potential negative effect or outcome?
• Vulnerability.  Where's the weakness?  How could a threat be realized?
• Attack. How to take advantage of the weakness?
• Countermeasure.  How to plug a hole or reduce the damage?

An example putting this all together would be, my asset is my customer information.  My application faces the threat of injection attacks.   My application's lack of input validation is a vulnerability.  SQL Injection and Cross-site scripting would be attacks.  Countermeasures would be validating input and keeping user input out of the control channel.  

There's a couple of interesting points here:

1. Assets tend to be very much a point of confusion.  It's tough to put boundaries here.  For example, show me which pages or components you don't want to protect.  Do you really have a page or component you don't care about?  Is it an asset or not?  This is why we moved to identifying security objectives in our threat modeling approach.  This was a lot more tangible.  Using security objectives also allowed us to incorporate assets without pinning your threat modeling success to you being able to identify your assets.  However, assets do have their place.  I think they're best use is to identify priorities and values.  Do you care more about your shed or your garage?  Your garage or your house.  OK, let's start w/your house and prioritize there ...
2. Attacks tend to be the domain of subject matter experts.  We don't expect typical practitioners to know the realm of attack possibilities.  That's why we try to provide a picklist where possible.
3. Vulnerabilities are your most valuable fallout of your threat modeling exercise.  While threats help you see what's within the realm of possibility and to prioritize, vulnerabilities are a clear cut action item.  You can use a list of vulnerabilities to drive action.  Given enough relevant info, a developer can analyze and address a vulnerability from their code's perspective.  Testers can scope their work testing that the developer addressed the vulnerability.
4. Countermeasures could also be called mitigations.  You mitigate a risk, not a threat though.  You can counter an attack.  At the end of the day, we went with countermeasures because enough customers liked the idea of being empowered to defend their code against evil doers as well as non-malicous threats.  Put it another way, countermeasures resonated with practitioners.
5. Threats are particularly interesting.  You can slide and dice them many ways.  You can also choose classes of threats.  For example you may view threats strictly as those with business impact.  I think it helps to broaden, yet scope this to negative impact against the confidentiality, integrity, or availability (CIA) of your information system.

What's important in all this is that your security objectives are the ultimate scoping tool and that by understanding the relationships between the terms, you produce more effective results when you threat model.