Closed MatKallada closed 9 years ago
+1! I drew up the diagram in their tutorial. I'll upload the sample file ASAP and we can start breaking it apart soon.
Man, that would be fantastic! I'm pumped to dissect this bad boy.
This is a screenshot of what it looks like:
Working on uploading the .tm4
file now.
We could learn a lot about how Microsoft architected their application by looking at this resulting serialized form. :smiley:
I am currently working on this issue and examining the structure of the .tm4 format.
One thing that came to mind: imagine that companies with competing products get jealous that we are stealing their users, so the obfuscate their file format(s), rendering our work for parsing it, useless. Thoughts on whether this situation is realistic? If so, should we re-consider attempting to do this?
Definitely a possibility, I wonder how the Microsoft one compares between versions too On Sep 24, 2014 10:26 PM, "Mat" notifications@github.com wrote:
I am currently working on this issue and examining the structure of the .tm4 format.
One thing that came to mind: imagine that companies creating competing products get jealous that we are stealing their users, so the obfuscate their file format(s), rendering our work for parsing it, useless. Thoughts on whether this situation is realistic?
— Reply to this email directly or view it on GitHub https://github.com/mozilla/seasponge/issues/4#issuecomment-56762640.
What are your thoughts @curtisko ? Do you think we should make a serious effort to import .tm4 files?
If we properly architect our own file format and in-memory representation of these threat model drawings, we should be able to import and export .tm4
files without too much issue.
It may be low priority, however I like the idea of being able to migrate all existing Microsoft Threat Modelling Tool users to SeaSponge overnight :wink:.
This will require a little more research into how the .tm4
file is structured. We may learn a thing or two by looking into how Microsoft did things, which is why I really like to have this feature: it forces us to learn from those who have already made mistakes, learned, and iterated to their current version of their product.
Let's stand on their shoulders and skip past those third-party mistakes and push our own level of innovation and make mistakes of our own where it matters.
Looking into the developer's mindset for the .tm4
structure could be useful, though this feature will ask for a lot of time - time which could be used for more important issues.
I am borderline on this issue. Being released quite recently, I doubt that there are many people using the threat modelling toolkit from Microsoft. Furthermore, it really shouldn't be that difficult for someone to sketch up a model that they've build previously on our platform.
Let's stand on their shoulders and skip past those third-party mistakes and push our own level of innovation and make mistakes of our own where it matters.
Making our own file structure should be a trivial process, and I doubt we'd make a serious number of mistakes along the way. I feel that we'd make more mistakes trying to understand the .tm4
format anyway.
As cool as this feature would be, I can foresee some hassles along the way; hassles that I don't think would be worth it. We should focus on the core functionalities of the application itself and if we have time, we'll check back on this one.
Being released quite recently,
I was under the impression that Microsoft's Threat modelling tool had been around for a while and with many iterations of improvements.
Furthermore, it really shouldn't be that difficult for someone to sketch up a model that they've build previously on our platform.
I have yet to see a big example of someone using this tool so I would agree that a small threat model could be quickly recreated in SeaSponge.
Making our own file structure should be a trivial process, and I doubt we'd make a serious number of mistakes along the way. I feel that we'd make more mistakes trying to understand the .tm4 format anyway. As cool as this feature would be, I can foresee some hassles along the way; hassles that I don't think would be worth it. We should focus on the core functionalities of the application itself and if we have time, we'll check back on this one.
I thought Microsoft's tool was the go-to application for threat modelling and had been around for years. Given this is not the case then I whole-hearted agree with everything you said above :smile:. Thanks for clearing things up!
I feel like this feature while cool, as Mat said will likely prove to be more effort than worth. If SeaSponge does become the goto application and is simple to use, anyone currently using the microsoft threat modeling tool will likely spend the time to migrate over. While it may prove a one time inconvenience for the user I think the ability to contribute and improve the software because it is open source will outweigh the time spent.
I was under the impression that Microsoft's Threat modelling tool had been around for a while and with > many iterations of improvements.
The MS tool is actually quite old, (at least 8 years), the current version that does not require visio is quite new, so there are likely lots of users.
Do you think we should make a serious effort to import .tm4 files?
Yes, my intuition is that this kind of feature is important. It allows current files to be imported and worked on and allows for the possibility for SeaSponge files to be exported and continue to be used in the MS tool by those that have process that still depend on it.
The MS tool is actually quite old, (at least 8 years), the current version that does not require visio is quite new, so there are likely lots of users.
Thanks for confirming, @curtisko. Good to know.
In that case, my initial sentiment stands and I agree with @curtisko, we should implement this feature.
Thanks @curtisko; With 8 years of service, it only makes sense to make an attempt to understand the SDL file structure and sway their users.
I'm going to try and find an older version to see if the save files are the same format.
I plan to make a simple one element model in both versions and then compare the files
That link is to the SDL process documents. SDL being different than the threat modeling tool (which is encompassed within the SDL, confusing I know).
During the meeting today we discussed that version 3.1.8 may be worthwhile to support. But if it is too different than 2014 just focus on the latest.
Cool :+1: I will have a look at both structures.
https://drive.google.com/folderview?id=0B4Rxc9EJ2xxNT2I5T0xWaXNBUFU&usp=sharing has the uploaded files and screenshots. I couldn't download 3.1.8 at home because I don't have visio. I will get the corresponding files next time at school
Awesome, thanks a lot; am analyzing these
The "Threat Model Information", for @Frozenfire92
http://stackoverflow.com/a/17604312 should be useful in parsing the file
The Element's Properties
UI is now complete:
So XSLT is pretty cool.
Here's a way to convert XML to JSON: http://www.bramstein.com/projects/xsltjson/
We have changed our schema so much from our original plan that it is not feasible to import a Microsoft threat model. We found that the Microsoft threat modeling tool is actually very different from the Seasponge tool.
I would about developing a partial converter? While there are significant differences, SeaSponge can be very flexible and would likely work for the most part to import basic stencil elements and create their flows.
The current most popular tool for threat modeling is the the Microsoft Threat Modelling Tool. This tool uses an XML based format for storing threat models. A user can import threat models that have been created using the Microsoft tool.