Possible collaboration with the Threats Manager Platform project

[simonec73]

Hi and thank you, @jgadsden, for having invited me.

I'm the author of Threats Manager Platform, a fully open-source Threat Modeling engine. It is based on .NET Core 3.1, therefore it is already multi-platform. You can find it at https://github.com/simonec73/threatsmanager.

The idea I am proposing is to work together to integrate it within Threat Dragon. You'll get multiple benefits, including a mature object model and ontology (https://downloads.threatsmanager.com/latest/Threats%20Manager%20Platform%20Ontology.pdf). It also already provides logic to generate automatically Threats, Mitigations, and Questions over a diagram. It allows importing threat models and templates produced with Microsoft Threat Modeling Tool and much more. In the near future, it will support the concept of Weaknesses and Vulnerabilities and will be able to consume MITRE databases. I'm also working on the integration of Quantitative Risk Analysis tools based on FAIR. You can get an idea about the possibilities by looking at my Threats Manager Studio, a free Windows Desktop tool that can be downloaded from https://threatsmanager.com/downloads.

I will be more than happy to collaborate with you to explore the possibility to make this part of Threat Dragon. My knowledge of the technologies you are using for your tool is limited, but I can work with you to answer your needs. For instance, I am thinking to migrate to .NET 5 or even .NET standard. I expect other gaps, but I am willing to work with you to address them.

What do you think about that?

[lreading]

Hi @simonec73, glad to have you!

I'm working on Threat Dragon v2, which is a complete rewrite of the front-end, and a redesign of the back-end code. This includes the schema that's used for our current threat models. I think this conversation has come up at a fantastic time, as I will soon be starting work on the actual modeling functionality. I'm hyper-focused on v2 currently, as the original version was written in AngularJS and will be EOL soon.

Unfortunately, I haven't taken a closer look at Threats Manager yet, but plan to this week/end. I think the first thing I need to understand is how the integration would work best between the two tools. From there, I can make better informed design decisions and help get things kicked off. Do you have any thoughts on a good starting point? eg: using Threat Dragon as a UI for editing or creating Threats Manager models? Vice versa? Implementing a specific feature?

Threat Dragon is using a node/express backend and version 2.0 will have a front-end written in Vue.js. The desktop versions are electron wrappers around the web application. The stack runs in docker as well, and I suspect that will be the preferred enterprise deployment model moving forward, but that is purely speculation on my behalf. With that said, I see one of the biggest integration hurdles being the different tech stacks. I'm competent with C#/.NET, however, I don't know what the appetite from our users would be for having dependencies on both NodeJs and .NET (core/standard) would be. One of our goals for V2 is including a REST API. That work includes making the back-end stateless and completely decoupling the UI. This work opens Threat Dragon up better to integrating with other services, especially via REST. Is that something that lends itself well to Threats Manager, or is it currently a desktop-only experience? If I completely missing the idea here, please do let me know! 😅

I'm looking forward to working with you and learning more about Threats Manager! And thank you again for reaching out, I know there's a discussion over on the Threats Manager repo as well. It's exciting to get this conversation started!

[simonec73]

All great points.

Threats Manager Studio is a desktop-only experience, but this is not what I am proposing you.
Threats Manager Studio is based on Threats Manager Platform, which is a re-hostable engine totally independent from WinForms or specific platforms. The Platform is what I am proposing to you.
The idea would be to make Threat Dragon "THE web interface for Threat Modeling", by leveraging the Platform to implement its back-end. This would allow to automatically inherit most present and future Threats Manager Studio's functionalities. For our users, the most immediate benefit would be to allow moving from one experience to the other seamlessly.

Personally, I am not sure if a stateless back-end is the way to go: in fact, I would suggest otherwise. I'm oriented to prefer an Actors-based solution, where a stateful Actor would be spawned centrally. That would allow multiple users to access the Threat Model at the same time. This is the most important differentiator which a Web interface like Threat Dragon would provide, compared with Threats Manager Studio. I was starting to think about implementing this approach within Threats Manager Studio, but given my current workload and roadmap I was not planning to devote time to it before early 2022.

Bottom line, I would suggest to plan a call between us, to discuss possibilities and ideas.

[jgadsden]

Hello @simonec73 and great to have you join us

I agree that there are two linked activities to our threat modelling - drawing the diagram and also determining the threats. @lreading is working on updating the diagramming function of Threat Dragon and equally well we would like to work on the threat engine of Threat Dragon.

At present TD can suggest threats according to the STRIDE threats per element:

          S | T | R | I | D | E
ACTOR   | X |   | X |   |   |
STORE   |   | X | X | X | X |
PROCESS | X | X | X | X | X | X
FLOW    |   | X |   | X | X |

[simonec73]

STRIDE per Element does not work well because it does not allow to generate specific threats. I really need to show you Threats Manager Studio's automatic threat generation and mitigations association capabilities.

[lreading]

I do have a couple of concerns related to licenses:

• Should we start maintaining any part of the Threats Manager Platform, PostSharp would require any contributor to get a license. While they have a community version, I'm not a big fan of using a tool that requires a per-developer license in an open source project.
• The icons in use are licensed by a third party specifically to Threats Manager, and are not to be used outside of it. That may also some confusion for Threats Manager users when they see icons that they are not used to in the Threat Dragon UI.

We also cannot forget about current Threat Dragon users. V2 must be backward compatible with v1, as people have invested a lot of time creating their models. I'm getting the impression that Threats Manager is very opinionated; one of Threat Dragon's selling points is ease of use and accessibility. It currently supports STRIDE, LINNDUN and CIA models. and we will need to continue to support those moving forward. Even if Threat Dragon becomes the UI for Threats Manager, it needs to support its existing functionality and user base.

Just for some clarification, I was referring to application state - eg sessions, using cookie auth. Resource state still exists, and models are persisted and will be accessible by multiple users. Part of the 2.0 work is adding more ways of authenticating and persistence methods.

[simonec73]

All great points, thank you.
A couple of answers about licenses:

• PostSharp free license is required for creating or updating new extensions, or if you maintain the Core libraries. There is no need for PostSharp if you simply consume the Platform as it is.
• the Incors icon library is used by the core libraries only for a function which returns the images for the various objects. That is still an allowed scenario. If you are not comfortable with it, I'm sure we can think something to address this problem.

[simonec73]

I totally agree about being an open platform covering things like LINDDUN. This is where templates and property schemes come to the rescue. In fact, I'm planning to add a template to cover LINDDUN.
Matter of fact, the approach is so open that it provides just a batter minimum of properties, to allow the definition of custom properties to cover all needs.
But again, I really recommend to organize a call to see it in action. It's hard to give all the answers you need via message. I know a collaboration may be revolutionary for both Threat Dragon and the Platform.

[simonec73]

A word about compatibility with the current format: I'm positive that I can create an importer, like the one for TMT. Do you have some documentation I can use?

[jgadsden]

I have created an issue #187 that can be used to prototype various ideas if we want. The three of us are assignees

Up to now I thought of Threats Manager and Threat Dragon as being two separate products, but now there is a possibility that Threats Manager can supply the engine for suggesting threats. For this to happen it would have to fit in with the way Threat Dragon is structured, in that it is a node.js project, but still well worth looking at it to see if it can work

I am not sure how this can be achieved - I must admit to having never been involved with C# and rarely have to use any Microsoft product or operating system (my apologies to @simonec73 ) - but I can help with my experience of what Threat Dragon does already