By having your security professionals and developers sit down together to analyze the shopping cart application from an attacker's point of view, you will gain a better understanding of how and why a malicious hacker may attack it, and how the vulnerabilities can be removed. If you use a data-flow approach, whereby the threat modeling team maps the point-to-point flow of sensitive information through the application, staff can identify the key processes and threats to those processes.
Countermeasures can then be implemented and tested to ensure the application doesn't leave sensitive or personal information vulnerable to potential attackers.
The best time to perform threat modeling is once the user requirements for the application have been gathered and work has started on its architecture and design. This process not only ensures architecture design issues are resolved early on, but it also creates a set of documents that identify and justify the security requirements of the application. Since the cost of addressing security issues increases as the software design lifecycle proceeds, threat modeling not only helps create a better application, increasing customer confidence, but it also increases its resilience, thus reducing support costs and benefiting the bottom line.
An important rule to follow when developing any application that processes requests from users is to assume all data that the application receives is from an untrusted source. This applies even to users who have logged into their accounts and authenticated themselves. Not trusting user input means validating it for type, length, format and range whenever data passes through a trust boundary, say from a Web form to an application script. If the data isn't deemed valid, your application should reject it. Also, any validation has to be performed on a trusted server, not on the user's machine.
Obviously, you need to lock down the server running your application and ensure it can handle any errors without divulging system information -- users should only get a polite message apologizing that an error has occurred, not a detailed list of the internal workings of the application and the system it runs on. A great resource for improving the security of application software is the Open Web Application Security Project (OWASP), which has loads of examples of how to code securely.
This was first published in July 2009