It seems obvious, but I have seen this missed enough times that it bears mentioning. Usually threat modeling begins after some initial software design work is done. The software design model is fed into the threat model process which looks at the attack surface (data, methods, and channel) and defines the spoofing, tampering, dispute, information disclosure, denial of service and elevation of privilege threats.
Then one or more countermeasures is built to address the threats and these are built into the system as part of the normal dev cycle. But here is the thing - threat modeling should not be fire and forget. The countermeasures themselves may contain vulnerabilities and add to the attack surface. In fact you can bet on it. The best recent example is Brad Hill's work on the various issues found in XML Security. The designers of WS-Security wanted a checkbox for security which is a great design goal, but not a good implementation mindset for those of us in the trenches. Instead we want to find the right countermeasures, then iterate our threat model again.
The threat model plays a central role in building security into the system, it is a useful level of abstraction and leads to pragmatic, concrete security requirements (which can be elusive); but it is not a mission of flying into the carrier and giving the thumbs up. A better way to think about it is as a design spec that is iterated throughout the dev process - so it is a dynamic. it is not "hey we got the lights on in Baghdad", it is how long do they stay on, what attacks do they see, how do they respond...
Comments