"This column proposes a
way to think about secure design from a more holistic perspective by
using threat models to drive your security engineering process,
primarily helping you prioritize code review, fuzz testing, and attack
surface analysis tasks.
post, which can be found on the Security Development Lifecycle (SDL)
blog. You will notice that the concepts in this column map very well
onto Jeremy’s ideas and will allow you to add more structure and
precision to your security efforts as you learn to crawl, then walk,
and finally run with the SDL.
I am proposing is using the threat model to help drive other SDL
security requirements, primarily code review priority, fuzz testing
priority, and attack surface reduction. That’s all there is to it. Of
course, I need to explain myself, so let’s look at each in a little
detail. Let me start with threat modeling."
"In my opinion, when
people think of security vulnerabilities, most think of implementation
bugs. One could argue that the SDL is focused a little too much on
implementation bugs, and historically it was because most of the
vulnerabilities Microsoft has fixed resulted from implementation bugs.
But over the last couple of years we have moved more resources to focus
on secure design, in part because the implementation bugs are now more
scarce thanks to the SDL.
modeling is a cornerstone of the SDL because it allows a development
team to think about secure design in a structured way. The threat
modeling process can be effectively simplified into the following tasks:
- Draw a picture of your software’s data flows.
- Use the "STRIDE per element" approach to find threats that apply to the design.
- Address each threat.
- Verify that you’ve modeled enough of the software, considered each threat, and addressed all the threats you discovered."
Read more: http://msdn.microsoft.com/en-us/magazine/dd148644.aspx
