none
Differences between Threat Model Tool v.2.1 and v.3 beta and related approaches

    Question

  • Hello,
    I'm using the Threat Modeling tools (version 2.1 and 3 beta) and I have some questions:

    1. The two versions appear quite different. The version 3 beta uses DFD to model system components and interactions at high level. The version 2.1 not contains DFD and it models system at low level. The DFD is the new approach that you will adopt for the future?
    2. The version 2.1 contains a wide threats library but it is not appear in version 3 beta. Are you planning to add it in the next version?
    3. To generate a complete threats report for the application, I try this approach:
     a. I use the version 3 beta to model system at high level (components, interactions, functions) with DFD
     b. I use the STRIDE model to identify the threats categories
     c. I use the previous information into version 2.1 to refine the threats categories and to obtain specific threats for my application
     d. I use the version 2.1 to generate specific threats report
     e. I merge information provided by tools (v.3 and v.2.1) to generate the final report
       Do you agree with my approach? Is it correct?

    Thank you,
    Marco Vallini

    • Moved by Hengzhe Li Tuesday, June 21, 2011 12:15 PM Forum Consolidate (From:Microsoft Security Development Lifecycle (SDL) - Threat Modeling)
    Wednesday, March 25, 2009 9:02 AM

Answers

  • Marco, I suspect you're comparing two similarly-named but separate and distinct products:
    These two tools were developed quite independently of one another (despite both being products of Microsoft), and from my interactions with the responsible groups, it doesn't seem like either group has had any mandate or specific motivation to interoperate or co-develop with the other.  This isn't that uncommon for a company of the size of Microsoft, and in fact in my experience it's quite a feat of expertise and brute force for groups that have so (relatively) little in common to achieve a single, integrated engineering project.

    There may be another release of the ACE TAM tool at some point, but I wouldn't anticipate it having any specific integration with the SDL TM tool.

    On that assumption, I'd say your approach in (3) is probably as good as it'll get.  I'm sure with some really well-designed XSLT and/or XML-manipulating code, you could make (3e) happen, but I don't know how you'd do that otherwise (other than manually).
    ParanoidMike (Intel)
    Sunday, March 29, 2009 5:43 AM
  • Mike is right on. You are referring to two different products. The ACE TAM tool is built for SDL-IT, where SDLTM is for SDLC. SDLTM is focused around the principles of STRIDE... and used by Microsoft in the creation of their commercialized software that follows the Microsoft Software Development Lifecycle. Back in early 2008 when I was begging Adam and his team to release the SDLTM tool publicly, I wrote a blog post which included a graphic on the difference of SDL-IT and SDLC. You can check it out at http://silverstr.ufies.org/blog/archives/001039.html. The picture looks like this:



    If you wish to use the STRIDE approach, then the SDLTM tool is much more suited for your needs.

    Hope that helps.
    Monday, March 30, 2009 9:18 PM

All replies

  • Marco, I suspect you're comparing two similarly-named but separate and distinct products:
    These two tools were developed quite independently of one another (despite both being products of Microsoft), and from my interactions with the responsible groups, it doesn't seem like either group has had any mandate or specific motivation to interoperate or co-develop with the other.  This isn't that uncommon for a company of the size of Microsoft, and in fact in my experience it's quite a feat of expertise and brute force for groups that have so (relatively) little in common to achieve a single, integrated engineering project.

    There may be another release of the ACE TAM tool at some point, but I wouldn't anticipate it having any specific integration with the SDL TM tool.

    On that assumption, I'd say your approach in (3) is probably as good as it'll get.  I'm sure with some really well-designed XSLT and/or XML-manipulating code, you could make (3e) happen, but I don't know how you'd do that otherwise (other than manually).
    ParanoidMike (Intel)
    Sunday, March 29, 2009 5:43 AM
  • Mike is right on. You are referring to two different products. The ACE TAM tool is built for SDL-IT, where SDLTM is for SDLC. SDLTM is focused around the principles of STRIDE... and used by Microsoft in the creation of their commercialized software that follows the Microsoft Software Development Lifecycle. Back in early 2008 when I was begging Adam and his team to release the SDLTM tool publicly, I wrote a blog post which included a graphic on the difference of SDL-IT and SDLC. You can check it out at http://silverstr.ufies.org/blog/archives/001039.html. The picture looks like this:



    If you wish to use the STRIDE approach, then the SDLTM tool is much more suited for your needs.

    Hope that helps.
    Monday, March 30, 2009 9:18 PM
  • Dana, what do you mean when you say "the STRIDE approach"?  I hear many people mean different things when they refer to STRIDE, and given how long you've studied this space, I'd like to understand your seasoned opinion.

    Thanks, Mike
    ParanoidMike (Intel)
    Tuesday, March 31, 2009 4:30 AM
  • Hey Mike,

    When I speak of the STRIDE approach, I am talking about software-centric threat modeling where we break down components in an architecture to its basic elements, and then look at the threats to which the components are suceptible, categorizing them against the STRIDE acronym. If you consider most vulnerabilities, they can be classified into one of those categories.

    Compared to other threat modeling techniques, what makes the STRIDE approach interesting to me is that instead of trying to look at it from an attacker's point of view and trace down the entry points first, we instead draw data flow diagrams (DFD) to display graphically how the components communicate with one another, what data is passed, when they pass trust boundaries, and how that occurs. Argueably, this makes it it easier to pinpoint where the most vitial components are which are at higher risk, allowing you to make design decisions that impacts on security earlier, faster and cheaper in the development cycle. Sometimes, it might mean we can only focus on the highest risk elements first, allowing us to balance the investment in secure coding to the most logical parts that will give us the higher return on investment. If we can't fix everything, lets at the very least approach it to reduce the risk to an acceptable level for that particular code cycle. (Some MS people may disagree with this approach, but I work in an agile development environment where we do short sprints that are always refactoring code.... we may not be able to get to everything in every iteration as the threat landscape changes and we learn new mitigation techniques to resolve new or outstanding issues we didn't previously know about)

    As the SDLC has evolved based on the experiences Microsoft has seen in its own process, we have learned that many components to which STRIDE is applied have the same types of threats, and the same mitigations. As such, it becomes much easier to iterate through all elements and make informed decisions on what needs to be done. It simplifies this process to a point where developers don't need to be security experts to look more defensively at their designs and code, which in the long run SHOULD give us safer, more stable code that the entire dev and test teams can be part of... making higher quality software they can be proud of.

    I have to admit, my experience is quite different than most dev teams. I work on very small teams, sometimes as small and just 2 or 3 people in a particular sprint. We don't have the luxury of teams that have a number of experts on staff who can review the threat models or the corresponding code, which means we have to balance the time and value of threat modeling against the practical returns in doing so. I can't be everywhere to do everything, so knowledge transfer has to be where it makes the most sense. With the use of the SDL TM, we can see immediate and practical returns. Each sprint cycle we dedicate half a day to draw or update the DFDs for the product backlog items using the SDL TM tool. Then we update or create the threat model and do a TM review at the end of the day. It has become part of our typical 30 day dev cycle, and everyone has taken to doing it as the tool makes it extremely easy and efficient.

    Not sure if that negates the value of my opinion or not. I think every team will have their own approach. The SDLTM is a tool that is easily adaptable to whatever dev process your team uses. And the best thing is... anyone on the team can use it. You don't have to be an expert to do so. And that is a direct outcome from how Microsoft has applied the STRIDE approach with the DFD and the outputted Analyze Model in the SDLTM tool.

    Hope that helps and provides a glimpse to what I believe it means.
    Tuesday, March 31, 2009 6:36 AM
  • Mike, Dana,

    I try to refer to this as "STRIDE per element threat modeling"   The core is the little chart ...I don't see how to include an image here, so see this blog post http://blogs.msdn.com/sdl/archive/2007/10/29/the-stride-per-element-chart.aspx

    The essence is to be both prescriptive (so people can do it) and broad (to give them a mental framework for remembering stuff.)   I think STRIDE works well for Microsoft because it's a memonic and we've been using it for a decade.  Other organizations with different approaches might want to adopt it for what works for them.  I'd love to hear about any success you have.
    Tuesday, March 31, 2009 4:50 PM
  • Adam,

    Yep. Thats what I was referring to when I mentioned that you guys have evolved it to understand that you can apply STRIDE categorization per element. Frank's original Threat Modeling book was more asset and entry point centric, where you guys have grown to this element focused approach... which I really love. It makes it extremely efficient for me, as I am slowly building a library of mitigation tactics for particular STRIDE elements... which allows us to reuse code that continues to mature for each threat. It is starting to be common that for each element, we have reusable class libraries that resolves particular threats... allowing us to snap in solutions quickly. And the beauty is those components have higher level of unit testing and fuzz testing behind it to give us higher levels of confidence that mitigated threats have appropriate safeguards.

    That chart you refer to is key to this:


    Some day in the future, I hope to be able to take much of these components and drive it through our internal SharePoint WIKI... so as we analyze the model, we can simply refer to standard URLs for mitigation tactics... so junior developers can increase their domain of knowledge while applying company driven best practice solutions for common threats. Which is where the linkable URLS in the TM will be useful.

    All in good time. Keep up the great work!
    Tuesday, March 31, 2009 5:04 PM
  • Hi,

    I am going to start threat modeling of a system described below, but couldn't understand whether i should use TAM v.2.1 or SDL Threat modeling tool v3. Hence i am using this thread to ask my query.

    Mine is web application which has to be hosted in SaaS environment and going to serve 37 customers with different needs with the common baseline of requirement.
    This application which has to be hosted on a central server hosting site and has to interact with different external systems of different vendors(outside our network at different locations across the country) to collect and store data.
    These external systems are using different types of LDAP system to authenticate and authorise users using eDirectory, ADFS, Tivoli directory server, eTrust etc.

    Please let me know as which of the two tools should be used to do threat modeling of this application including its interaction with external applications and data stores.

    Cheers
    TicArch

    Wednesday, May 27, 2009 1:13 PM
  • Hey TicArch,

    I would think the SDL TM would be appropriate here as you want to do a STRIDE per element approach to see where the threats exist between components in your system. It all starts with the DFD. I would recommend you layout your design in the SDL TM tool and see just where you are when you are done. If you find that the SDL methodology doesn't meet your needs, you can easily transfer that knowledge to the TAM tool, so little work is lost. However, the benefits of the SDL TM tool come into play immediately as you begin to see the tool identify threats to your design which you will need to account for, as part of the analyze model step.

    If you refer back to the SDLC vs SDL-IT chart I included earlier in the thread, the tools approach it significantly differently. However, the first stages both include understanding how data traverses your system. Start with the SDL TM tool, as its much better suited to do that. (I am however biased ;-) )

    Hope that helps.
    Wednesday, May 27, 2009 4:00 PM
  • Tried to go to the blog URL in this reply but it keeps saying this is still being migrated and suggests to try http://blogs.msdn.com/ or http://blogs.technet.com/ neither of which are having that content. Any chances this blog can be accessed now?

    Asp.Net, SQL, T-SQL, JavaScript, C# Developer

    Wednesday, December 5, 2018 12:48 AM