From a psychological perspective

Oct 15, 2007 14:44 GMT  ·  By

If you think that the Secure Development Lifecycle over at Microsoft is just a model for building software products designed to offer the highest possible level of user protection by default, then you should know that there is more than meets the eye. The fact of the matter is that there is an entire psychology behind Threat Modeling, as exemplified by Adam Shostack, a Program Manager in Microsoft's Security Engineering group. Shostack revealed that there is a close connection between a mental state of operation documented by psychologist Mihaly Csikszentmihalyi and the Threat Modeling process. Namely the Flow... In this context, Clear goals, Direct and immediate feedback, Balance between ability and challenge as well as Focused attention are critical to performing Threat Modeling.

"Giving people clear goals is important because it helps take them from worrying about what your goals mean to worrying about how to achieve them. Without clear goals, it's very challenging to get into the spirit of anything, whether playing a game or shipping an operating system. As goals go, "think like an attacker" and "brainstorm" aren't up there with "A PC on every desktop." The lack of a clear answer to "how do I know I'm done with my diagrams" or "how many threats should I have," or "what is a good threat model" made it hard for people to do well, and just as importantly, even people who were doing well weren't sure that they were doing well", Shostack stated.

One area where Microsoft has invested resources in is the volume of security documentation made available to code builders as well as an increased number of security experts to provide guidance. But at the same time, training has increasingly focused developers on processes such as self-checking. The times when an entire threat model could be completed without any feedback or corrective action are long gone over at the Redmond company. But at the same time, the overall complexity and challenges of threat modeling have been toned down. In this manner, threat modeling has been tailor fitted on the specific abilities of the code designers working on Microsoft products.

"One final point I'd like to address is that flow is one of many frameworks we could use to address problems in threat modeling. My choice to use it was a driven by its striking absence. Flow isn't the only framework for thinking about these things, and there are some criticisms associated with trying to shoehorn everything into flow. For threat modeling, it just seemed to well?flow", Shostack added.