Open tmart234 opened 4 years ago
Hello @tmart234 - this is a very good sugestion. Threat Dragon does not scale well, at least not at the moment, so it would be good to think of how to introduce templates, hierarchy, etc
Can you expand on your ideas and provide some thoughts on how it would be implemented?
Cheers, Jon
What about making the threat library/rules that is already there available for editing and maybe adding the possibility of making more than one of each. I'm picturing a tree structure with a generic threat with multiple children beneath that can be applied in each instance. Maybe this could be a stepping stone in the right direction that could hopefully come before 2.x?
Hello @gobrtg - just checking my understanding, this is a hierarchy of threats applied to elements within one diagram? Not a tree of diagrams?
There is a lot of work we need to do on the threat generation rule engine, and this might be related to that
Transferred to threat dragon repo
To make threat modeling highly repeatable, you’d create a model from an existing template. Tree structure would apply to any “generic” components (threats and elements). A template contains set of non-generic elements, the non-generic threat list, all the threat properties, and threat logic. Logic should be configurable and simple (ex: flow is, element is, source is, target is, flow property is). If using something like STRIDE per element, you’d check the logic condition for every element in the model. If condition satisfied, then it’s a generated threat. Hypothetical example: you can have a AWS template. That template would have a non-generic datastore element called S3 bucket. That S3 bucket element has a unique element property called “is public”. Then threat logic is “S3bucket.is_public is ‘yes’”. So when the modeler has the aws template applied, use S3 element with public prop, they will generate the non-generic information disclosure threat.
Most people describe threat modeling process as: 1. Identify Assets 2. Create an Architecture Overview 3. Decompose the Application 4. Identify the Threats 5. Document the Threats 6. Rate the Threats By using consistent architecture and templates that contain that architecture, part of the Create Architecture Overview step has been abstracted away. The Architecture is now all the non-generic elements available in the template. Also by building a template with generated non-generic threats, the “Identifying Threats” phase from the modeling process has also been abstracted away. The MS tool is plagued by the problem that no one shares templates (even though templates should be abstracted of intellectual property). That is probably the biggest challenge here. Industry and domain experts should be the ones creating and sharing these templates. But who should model? Everyone! And templates/repeatability would definitely lower the bar for that.
In the new version 1.5 (due out this week) we have created a ThreatDragonModels
directory where there are two threat models : a new (empty) model and the demo threat model. Maybe this could be the start of some templates?
@tmart234 and @gobrtg did you want to see what you think?
There is also the OWASP threat model cookbook site at https://github.com/OWASP/threat-model-cookbook/pulse, but that may not be specific enough to Threat Dragon ... there is a model in there from TD to show what could be done
Referencing the threat modeling manifesto, Templates really help to assist with: “what are we working on?” .. Not in terms of a specific application, but in terms of describing consistent system components, Architecture, and environmental aspects (boundaries, flows, & external actors). And also addresses “what could go wrong?” in terms of the threat list, threat logic, and threat generation.
Therefore, I’m not sure ThreatDragonModels is appropriate because templates wouldn’t contain any diagram level information. (Size, position, vertices, in-scope, open threats). Attached is a rough example of what I think a template json format could look like for my previous mentioned aws threat. This info would probably be combined into the model file w diagrams later.
{ "summary": { "title": "empty template", "owner": "SME Tim" }, "detail": { "templates": [ { "title": "my_AWS_template", "templateJson": { "cells": [ { "type": "tm.Store", "id": "a25bbb4e-093f-4238-a620-31efdee452dc", "z": 1, "attrs": { "text": { "text": "S3 Bucket" }, "is_public": [ "yes", "no" ] } } ], "threats": [ { "severity": "High", "mitigation": "bucket level policies and IAM level policies.", "description": "Attacker gets access to confidential data stored in S3 bucket", "title": "Public bucket is exposed", "type": "Information Disclosure", "logic": "[S3_bucket].is_public is 'yes'" } ] } } ] } }
Again, I don’t think threat dragon should ever be responsible for providing the templates themselves to the modelers. this should only be provided by 3rd party domain experts as The tool simply couldn’t cover every domain. Other modeling tooling tries to do this (provide a non-generic threat list) and fails bc the tooling could never extensively cover domains like mobile, embedded systems, OT, automotive, medical, etc.
Here are some examples of threat model templates. Not sure what other tools, besides MS tool, have the concept. https://github.com/matthiasrohr/OTMT/blob/master/secodis%20web%20plain.tb7 https://github.com/rhurlbut/CodeMash2020/blob/master/CodeMash2020-Default.tb7 https://github.com/microsoft/threat-modeling-templates https://github.com/nccgroup/The_Automotive_Threat_Modeling_Template
This is something we should strive for in version 2.x. We're currently working hard to get version 2.0 ready for release, as it will address some security related issues as well as a bunch of other open github issues.
The only concern I have with this idea would be that it could wind up adding a bit of complexity to the threat modeling process. I think it'd work so long as we maintain the traditional threat-modeling flow, but add some sort of connector for an optional templating engine.
So unfortunately, we won't be working on it immediately, but hope to get to it in the relatively near future!
Your comment is completely correct in increasing complexity of the tool and overall process… but if the threat model practitioner was to use an existing template supporting automatic Threat generation, then the traditional processes is actually simplified because now modeler does not manually manage Threat generation and adopts properties of non-generic element. Of course, as you mentioned, maintain the current flow of the tool, the generic elements, manual Threat entries, etc.
I believe now is an opportune moment to consider implementing this idea, especially since the release of the 2.0.x version. I propose that, similar to how you have limited data store objects to certain STRIDE terms, we apply the same approach to templates. For instance, we can have a data store object where all threats are automatically assigned based on the properties filled in by the modeler. The modeler can then review and determine whether specific threats should remain open or be closed. This way, we can save time by not having to manually add threats for each service and application, and instead focus on quickly auditing them.
Initially, this step should be less challenging and complex compared to adding an engine functionality for customizable threats.
Hello @iman4000 , I agree - the problem we have is the lack of contributors, so if you can help out that would be great Also the threat model cookbook may become read only and archived, so not much help from that direction sadly
studying to get my certification here, but I am on vacation. I will try to help in the 1st week of July :-)
I'm enthusiastic about contributing and lending a hand to this project. However, I want to make it clear that my expertise lies in Python rather than JavaScript. If there's a way I can assist in achieving this goal using Python or any other relevant technology, please let me know. I'll be more than happy to contribute in the best way I can.
This issue is stale because it has been open for 6 months with no activity.
The list of threat models contained in the 'Explore a sample threat model' is the natural place for the threat model templates / starting point Promoting this issue to the threat engine milestone becaus eit is closely related
Add feature to import a threat template or a list of pre defined threats. Seems ... chaotic to have to re-add threats for every model that you design. especially if designing a lot of threat models. When reusing components/elements, you will encounter the same threats... this tool should scale to reuse predefined components/elements and threats. Process of generating threat list is way too manual.