In my previous post on threat models, I pointed out situations where TM's are either a complete waste of time, or maybe we've got bigger problems than design issues. To add a little balance and reinforce one of the points I was trying to make, let's look at another situation where the TM was really useful. We've noticed that a very small minority of users have Office crashing frequently, and that if they are, there's likely a hardware problem, probably memory. To help with that problem, we wrote a service that will check your memory for you while the operating system is running. It isn't quite as thorough as doing this from a boot disk, but it works pretty well.
The memory checking service doesn't have any really critical information – just whether you have happy hardware or not – but it does have to run as local system, and it does have to communicate results back to the user. We got into the threat model meeting for the memory checker, and once we came up with a bunch of problems with how to communicate results, we realized that the design we had wasn't working, and quickly moved on to an ad-hoc redesign and TM for the new design. It saved us a bunch of time to figure this out before anyone wrote any code, and might have saved a security bulletin. It was certainly an hour well spent.
The trick here is that if you spend too much time on useless TM's, you start to think all TMs are useless. If you can quickly sort out which are worthwhile from the ones that have a low yield, you can get good results efficiently.
In another life, I was an automotive mechanic, and my favorite tool is the _right_ tool for whatever it is that I'm trying to do. We need to think about security not as purists, but as engineers – we'll never achieve perfection – a great read on this is here - http://yarchive.net/air/perfect_safety.html - and we need to think about what tools and techniques we have that yield the greatest improvement for a given problem. Sometimes, it might be a TM, but it might also be building a great fuzzer or test harness to shake out the implementation bugs.