We're a small company and we do not have resources that we can dedicate to heavyweight threat modeling. However, if we could find a threat modeling framework that was pretty lightweight I think there is value in documenting the data flows and vulnerabilities that surface from the exercise.

I have looked most closely at STRIDE but when it comes to the data flow diagrams (DFDs) I get stuck - perhaps because the application(s) are already built and I seem to include minutiae that probably doesn't belong.

I also found Threat Modeling Express but it won't be easy to get development's time to assist in the exercise.

Ideally it is something that can be worked on piecemeal by one person. Although I understand the value in having different viewpoints it just probably isn't realistic at this point in time as everyone is busy.

Since the application is built is there still value in threat modeling? Should I just point w3af or nikto at my apps periodically and remediate any vulnerabilities?

In short, what is the best bang for the buck for a small company in terms of discovering threats? What model or framework will yield actionable results with a modest investment of resources?


  • I'm not sure I fully understand why STRIDE isn't working for you. Can you say more? When you say you get stuck, what exactly do you get stuck on? Do you mean, you don't know how the data flows in your apps? Do you mean, you know but it is too complex to diagram comprehensively? Something else? Have you tried building a high-level DFD that summarizes the key data flows, and then applied STRIDE based upon that?
    – D.W.
    Commented Jun 9, 2011 at 7:33
  • 2
    By the way, did you say you want a methodology that works without cooperation of developers? That worries me. I wonder if it would be better to start by getting buy-in that this is part of developers' responsibility and goals. I feel like security needs to be part of their job; if security is important, the mindset needs to be that their job isn't done until the system is secure, and they need to be evaluated on that. There's no magic pixie dust you can sprinkle on an already-built system, after it's built, to make it secure.
    – D.W.
    Commented Jun 9, 2011 at 7:36
  • @D.W. re: STRIDE I already have a high-level logical diagram that summarizes the key data flows but it is a complex application with a backend and multiple frontends / service interfaces. One such interface is FTPS. I thought I'd do a DFD for each service interface but even this "easy" one seems to be complicated by the fact that NFS is used for central storage (i.e. the FTP upload is stored centrally on an NFS server). We also use virtual users for FTP authentication. Is authentication something I'd include in a DFD? That sort of thing.
    – Jason
    Commented Jun 9, 2011 at 15:54
  • @ D.W. re: developer cooperation. Our developers are professionals and adhere to best practices but we want to become more proactive and incorporate security elements into our SDLC. I understand what you're saying and eventually they will need to accept that it is part of their job. I was hoping to make some headway on other aspects of a proactive security posture but perhaps it is quixotic to separate the operations from the development.
    – Jason
    Commented Jun 9, 2011 at 16:01
  • I guess my main advice would be: "don't let the perfect be the enemy of the good". You can still get some benefits by doing threat modelling with a coarse-and-incomplete model of the data flows in the application. So, go ahead and start with the coarse diagram and analyze the threats. Later you can elaborate the details if you want. P.S. NFS: I would treat NFS as another element, with some data communications between the NFS client and the NFS server. Depending upon your threat model, that might pose a threat, or might be negligible.
    – D.W.
    Commented Jun 10, 2011 at 4:04

3 Answers 3


Threat Modeling is really a skill, based on experience, after learning what works and what doesn't.
I don't think a choice of framework will make things much easier for you, you will still have the same issues and difficulties that you have now.

On the contrary, I would recommend STRIDE-per-element as the better place to start, and later add in additional techniques as appropriate.

It's probably more likely that you just need some pointers on how to do threat modeling efficiently, simply changing the methodology would not be your silver bullet.

My recommendations:

  • Go through an entire threat modeling exercise first with someone experienced, who knows how to do it - that is really the best way to learn, by doing. Even if this means getting an external consultant for a few hours.
  • One of the reasons that DFDs are recommended, is because these often already exist. Try and find out if anyone has these, or even something similar.
  • Another reason for DFDs, is because they can be relatively simple. If you say that you get stuck on minutiae, then zoom out, and keep the DFD at layer 0 or layer 1, only occasionally digging down into layer 2 as needed - but no more than that.
  • Remember, you want to focus on the high-level overview, flows between modules and across trust boundaries. You should never have to drill into the implementation (though involving developers/architects that understand how it works, can you help you discover interesting points that do require additional mapping.) Don't get carried away in the details!
  • Microsoft has two different tools to help with Threat Modeling, TAM and SDL TM. These are based on different outlooks and sub-methodologies, one of them works as a "wizard"-ish-like app. I much prefer SDL TM.
  • Consider focusing a TM on one module/section of the application at a time, instead of trying to grab all of it at once.
  • Remember that during TM, you're not looking for solutions. That can quickly sidetrack any TM effort.
  • Ideally, you'd have the viewpoints and input from all the stakeholders (architecture/product management/development/QA/operations....), but realistically, in many orgs that's not possible - instead, try to focus small bites of time with representatives from each, and pose specific questions that will help flesh out your model. If there was no DFD or other diagram, and you built it yourself - get their feedback on it, often they will be thanking you just for providing them with that.

Some additional thoughts on TM, as per your extra questions at the end:
Simply pointing a proper web app scanner at your servers will definitely be easier. However, I believe TM would be much more effective, and in the long term would be more efficient too (for numerous reasons, different topic though).
Even though the app already exists, it's still worthwhile to go back and analyze it - some things will be easier (less guesswork), some things may not pan out, but you can discover what types of flaws are interesting. That is what can help you go back and fix specific issues, not just the technicalities which do not apply to your business. And worst case - all it will do is help you focus your testing efforts in areas that are more "interesting", instead of mass-testing the entire system.

Some links I have found helpful in the past when teaching others how to do TM:


Verison have an open framework which they have developed along with industry. I find it extremely lightweight, and it might be useful for you to use for threat modelling. You can find the community documentation at: https://verisframework.wiki.zoho.com/ .


Microsoft had the Threat Analysis and Modeling tool which seemed to incorporate a lot of their STRIDE / DREAD information as well as countermeasures to threats from their Threats & Countermeasures best practices.

Some of the methodologies and tools out there:

Microsoft Threat Modeling - Seems very tech / engineering centric with seasoned security analysts needed to build detailed threat models. In an AGILE environment, scaling might be an issue.

PASTA (Process for Attack Simulation and Threat Analysis) - Found this here. This methodology seems like it would involve all stakeholders in the SDLC including your developers.

Trike - Threat Modeling by taking risks into perspective.


  • Microsoft TAM
  • MyAppSecurity ThreatModeler
  • Trike Octotrike
  • Practical Threat Analysis

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .