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:
