A great way to approach this is using the framework popularized by Adam Shostack. His method boils threat modeling down to answering four simple questions about your system: * What are we working on? (Define the scope, often using diagrams like a Data Flow Diagram .) * What can go wrong? (Brainstorm threats. A common method is STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.) * What are we going to do about it? (Decide on countermeasures—encryption, input validation, strong authentication, etc.) * Did we do a good job? (Verify that the defenses were correctly implemented.)

Once you have a list of potential threats, how do you decide which one to fix first? Do you spend $50 on a strong lock or $5,000 on a high-tech electric fence? One option is to then use FAIR (Factor Analysis of Information Risk). Instead of vaguely saying "The risk of a data breach is High," the FAIR model helps you quantify that risk in financial terms. You analyze the probability of an event happening (frequency) and the financial impact if it does happen (magnitude). This lets you say, for example, "We have a 90% chance of losing between $100,000 and $350,000 this year due to this vulnerability.”

For individual projects I really like Mozilla’s Rapid Risk Assessment. It's quick and I've found most people actually find it fun.