This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Threat Dragon"

From OWASP
Jump to: navigation, search
(→‎Description)
(update roadmap progress)
 
(18 intermediate revisions by the same user not shown)
Line 4: Line 4:
  
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
−
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
+
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
  
 
==OWASP Threat Dragon Project==
 
==OWASP Threat Dragon Project==
Line 33: Line 33:
  
 
This program is free software: you can redistribute it and/or modify it under the terms of the [http://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 License]  
 
This program is free software: you can redistribute it and/or modify it under the terms of the [http://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 License]  
−
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
+
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
  
 
== Project Resources ==
 
== Project Resources ==
Line 39: Line 39:
 
The source code for the project can be found here:
 
The source code for the project can be found here:
  
−
https://bitbucket.org/theblacklabrador/threatmodellingtool/src
+
https://github.com/mike-goodwin/owasp-threat-dragon
  
−
And you can click here to see [https://babydragon.azurewebsites.net/ a working prototype].
+
You can click here to see a working prototype:
 +
 
 +
https://threatdragon.org
 +
 
 +
And (draft) end-user documentation can be found here:
 +
 
 +
http://docs.threatdragon.org
  
 
== Project Leader ==
 
== Project Leader ==
Line 53: Line 59:
 
   {| width="200" cellpadding="2"
 
   {| width="200" cellpadding="2"
 
   |-
 
   |-
−
   | colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
+
   | colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
 
   |-
 
   |-
−
   | align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
+
   | rowspan="2" align="center" valign="top" width="50%" | [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
−
   | align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]   
+
   | align="center" valign="top" width="50%" | [[File:Owasp-builders-small.png|link=Builders]]   
  
 
   |}
 
   |}
  
−
| valign="top" style="padding-left:25px;width:200px;" |  
+
| valign="top" style="padding-left:25px;width:200px;" |  
  
 
== News and Events ==
 
== News and Events ==
Line 68: Line 74:
 
=FAQs=
 
=FAQs=
  
−
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
+
'''Q1:''' Hold on...isn't this the same as [https://github.com/mozilla/seasponge Mozilla's SeaSponge]?
−
<span style="color:#ff0000">
+
 
−
+
'''A1:''' As I was working on prototyping this, mostly as a way of getting myself properly up to speed with javascript, I found out about SeaSponge via the OWASP leaders mailing list. SeaSponge has a lot in common with this project and I based my implementation of the threat model file download feature on theirs. Maybe they could be merged in the future? Who knows?
 +
 
 
= Acknowledgements =
 
= Acknowledgements =
 
==Contributors==
 
==Contributors==
Line 81: Line 88:
  
 
==Roadmap==
 
==Roadmap==
−
Vision for the project:
+
'''Vision for the project:'''
−
================
 
  
 
The overall vision for the project is to implement a tool that removes as many barriers as possible for organisations wanting to embed threat modelling into their development lifecycle. Barriers I have seen are:
 
The overall vision for the project is to implement a tool that removes as many barriers as possible for organisations wanting to embed threat modelling into their development lifecycle. Barriers I have seen are:
  
−
- Lack of cross platform tooling: Tool needs to be x-platform
+
* Lack of cross platform tooling: Tool needs to be x-platform
−
- Poor UX in existing tools, productivity is poor: Great UX is a must
+
* Poor UX in existing tools, productivity is poor: Great UX is a must
−
- Steep learning curve for adopting teams: Tool to build in expert knowledge to help the team get started
+
* Steep learning curve for adopting teams: Tool to build in expert knowledge to help the team get started
−
- Models are ignored: Integration with other lifecycle tools is key
+
* Models are ignored: Integration with other lifecycle tools is key
  
−
 
+
'''Initial high level plan:'''
−
Initial high level plan:
 
−
================
 
  
 
Milestone 1: Alpha release - Basic threat modelling experience
 
Milestone 1: Alpha release - Basic threat modelling experience
−
----------------------------------------------------------------------------
 
  
−
- Architecture review of the existing prototype with refinement/change where required
+
* Architecture review of the existing prototype with refinement/change where required - '''complete: Confirmed JointJs works fine, Storage model changed and addition of Electon based desktop variant. Nools rule engine (no longer supported) replaced by [https://github.com/cachecontrol/json-rules-engine json-rules-engine]. Shifted from Grunt/Bower to NPM/Browserify'''
−
- Secure design review and implementation of findings
+
* Secure design review and implementation of findings
−
- Development of tests (unit and manual)
+
* Development of tests (unit and manual) - '''complete: [https://codecov.io/github/mike-goodwin/owasp-threat-dragon?branch=master Codecov report]'''
−
- Draft end user documentation
+
* Draft end user documentation - '''complete: [http://mike-goodwin.github.io/owasp-threat-dragon/ GitHub pages]'''
−
- "Publicity drive" to sign up alpha/beta users and generate feedback
+
* "Publicity drive" to sign up alpha/beta users and generate feedback - '''Some progress on this. The desktop app has had 13k downloads - unclear how many people are actually using it. The GH repo for the desktop version has 79 stars. The web version gets about 94 unique visitors per day on average and the GH repo has 229 stars.'''
  
 
Milestone 2: Beta release - Threat/mitigation rule engine
 
Milestone 2: Beta release - Threat/mitigation rule engine
−
--------------------------------------------------------------------
 
  
−
- Refinement of UX based on feedback from the alpha release
+
* Refinement of UX based on feedback from the alpha release
−
- (Some) feature enhancements based on feedback from the alpha release
+
* (Some) feature enhancements based on feedback from the alpha release - '''Implemented some feature requests (e.g. snap-to-grid) and fixed issues reports (e.g. save bugs) by users'''
−
- Implementation of a rule engine for generation of threats/mitigations
+
* Implementation of a rule engine for generation of threats/mitigations
−
- Updated tests and end-user documentation
+
* Updated tests and end-user documentation
  
 
Milestone 3: Release 1
 
Milestone 3: Release 1
−
---------------------------
 
  
−
- Key refinements, bug fixes and new features based on feedback from the beta release
+
* Key refinements, bug fixes and new features based on feedback from the beta release
−
- Complete end user documentation
+
* Complete end user documentation
−
- Penetration test
+
* Penetration test
  
 
Milestone 4 - Dev lifecycle integration
 
Milestone 4 - Dev lifecycle integration
−
-----------------------------------------------
 
  
−
  - Detailed scope to be defined, but in general the vision is to support hooks into issue tracking and requirements management tool so that threats/mitigations can be tracked through to implementation and test
+
* Detailed scope to be defined, but in general the vision is to support hooks into issue tracking and requirements management tool so that threats/mitigations can be tracked through to implementation and test
  
−
Timeframes
+
'''Timeframes'''
−
---------------
 
  
 
This is hard to estimate as it could change a lot if there were other developers involved. Based on my current velocity with just me, I would say release 1 could be complete in 1 year (optimistically).
 
This is hard to estimate as it could change a lot if there were other developers involved. Based on my current velocity with just me, I would say release 1 could be complete in 1 year (optimistically).
  
−
Technology
+
'''Technology'''
−
=========
+
 
 +
The technical architecture is javascript from top to bottom. In the client the key libraries are Angular for the MVC architecture and JointJS for the diagramming. JointJS has a log of great features, but is not a perfect fit for Angular. This needs a review. In the prototype, all storage is done on the client using browser local storage.
 +
 
 +
Following an architecture review the following key changes were made:
  
−
The technical architecture is javascript from top to bottom. In the client the key libraries are Angular for the MVC architecture and JointJS for the diagraming. JointJS has a log of great features, but is not a perfect fit for Angular. This needs a review. In the prototype, all storage is done on the client using browser local storage.
+
* A new Electron based, installable desktop variant was introduced using the local file system for model storage
 +
* The web variant was changed to use GitHub for model storage - other source control systems will follow (e.g. BitBucket)
 +
* Seperation of common code into a new NPM package, shared between the web and desktop variants
 +
* The Nools rule engine will be replaced since it is no longer maintained
  
−
There is nothing on the server side at the moment in the prototype. Areas where this might become necessary are
+
'''Challenges'''
  
−
- If the threat rule engine requires too much power to run feasibly on the client
+
* Getting enough usage of the alpha and beta to get the UX and rule engine right
−
- Supporting hooks in to other dev lifecycle tools
+
* Finding a sustainable way to host it, especially to support deeper GitHub/BitBucket/Etc. integration
  
−
If needed I plan to use node.js on the server so that the rule engine can be flexible enough to run either client or server side.
+
==Getting Involved==
  
−
Server-side storage has not been needed yet. If it becomes necessary, then a review of options will be needed to find a way to do this that is sustainable and consistent with the open source approach for the project.
+
===Alpha testers===
  
−
Challenges
+
Great user experience is one of the key goals for the project and to get that right it needs some users! If you would like to try the tool out, that would be great. A working prototype can be found at:
−
========
 
  
−
- Getting enough usage of the alpha and beta to get the UX and rule engine right
+
https://threatdragon.org/
−
- Finding a sustainable way to host it, especially if it needs any kind of server side storage or processing - the prototype today just serves static content and all the logic is on the client side
 
  
−
==Getting Involved==
+
The desktop variant (for Windows and OSX) can be downloaded from:
 +
 
 +
https://github.com/mike-goodwin/owasp-threat-dragon-desktop/releases
 +
 
 +
To help you get started, take a look at the (draft) docs:
 +
 
 +
[http://mike-goodwin.github.io/owasp-threat-dragon/ http://docs.threatdragon.org/]
 +
 
 +
If you are still having problems, let me know and I will be pleased to help ([email protected]). All feedback is ''very'' welcome. Either email me or put an issue on GitHub
  
 +
https://github.com/mike-goodwin/owasp-threat-dragon/issues
  
 
===Coding===
 
===Coding===
  
 +
Coding help of any kind is always welcome. The project builds easily (let me know if you have any problems) so getting up and running should be simple.
 +
 +
===Threat rule engine===
 +
 +
If you are not into javascript, you can still help! We need to build a powerful threat generation rule engine to replace the stubbed one that is in place for the prototype. If you can contribute in this area by defining rule, that would be great.
  
 
=Minimum Viable Product=
 
=Minimum Viable Product=
Line 162: Line 179:
  
 
3) An online hosted version of the tool
 
3) An online hosted version of the tool
 +
 +
4) An installable, cross-platform desktop version of the tool
  
  
  
−
__NOTOC__ <headertabs />  
+
__NOTOC__ <headertabs></headertabs>  
  
−
[[Category:OWASP Project]]  [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]]  [[Category:OWASP_Tool]]
+
[[Category:OWASP Project]]   
 +
[[Category:OWASP_Builders]]  
 +
[[Category:OWASP_Defenders]]   
 +
[[Category:OWASP_Tool]]

Latest revision as of 12:19, 30 June 2019

OWASP Project Header.jpg

OWASP Threat Dragon Project

An online threat modelling web application including system diagramming and a rule engine to auto-generate threats/mitigations. The focus will be on great UX a powerful rule engine and alignment with other development lifecycle tools.

Description

Threat modelling is widely regarded as a powerful way to build security into the design of applications early in the development lifecycle. At its best, it is especially good for

  • Ensuring defence-in-depth
  • Establishing consistent security design patterns across an application
  • Flushing out security requirements and user stories

However, effective adoption by organisations can be difficult. Reasons for this include:

  • There are no cross-platform, free tools (that I am aware of)
  • The usability of existing tools is not great - productivity for the team is therefore poor, especially in the early stages of adoption
  • The learning curve for teams is steep - threat modelling often ends up being left to a small "expert" subset of a team and ignores the valuable perspectives from the wider team
  • Integration with other development lifecycle tools (e.g. issue tracking tools) is poor - leading to models being ignored

OWASP Threat Dragon will address this by providing a free, open-source, threat modelling web application for teams implementing the STRIDE approach. The key areas of focus for the tool will be:

  • Great UX - using Threat Dragon should be simple, engaging and fun
  • A powerful threat/mitigation rule engine - this will lower the barrier to entry for teams and allow non-specialists to contribute
  • Integration points with other development lifecycle tools - this will ensure that models slot easily into the development lifecycle and remain relevant as the project evolves

Licensing

This program is free software: you can redistribute it and/or modify it under the terms of the Apache 2.0 License

Project Resources

The source code for the project can be found here:

https://github.com/mike-goodwin/owasp-threat-dragon

You can click here to see a working prototype:

https://threatdragon.org

And (draft) end-user documentation can be found here:

http://docs.threatdragon.org

Project Leader

Mike Goodwin

Related Projects

Classifications

Project Type Files TOOL.jpg
Incubator Project Owasp-builders-small.png

News and Events

Q1: Hold on...isn't this the same as Mozilla's SeaSponge?

A1: As I was working on prototyping this, mostly as a way of getting myself properly up to speed with javascript, I found out about SeaSponge via the OWASP leaders mailing list. SeaSponge has a lot in common with this project and I based my implementation of the threat model file download feature on theirs. Maybe they could be merged in the future? Who knows?

Contributors

Mike Goodwin

Roadmap

Vision for the project:

The overall vision for the project is to implement a tool that removes as many barriers as possible for organisations wanting to embed threat modelling into their development lifecycle. Barriers I have seen are:

  • Lack of cross platform tooling: Tool needs to be x-platform
  • Poor UX in existing tools, productivity is poor: Great UX is a must
  • Steep learning curve for adopting teams: Tool to build in expert knowledge to help the team get started
  • Models are ignored: Integration with other lifecycle tools is key

Initial high level plan:

Milestone 1: Alpha release - Basic threat modelling experience

  • Architecture review of the existing prototype with refinement/change where required - complete: Confirmed JointJs works fine, Storage model changed and addition of Electon based desktop variant. Nools rule engine (no longer supported) replaced by json-rules-engine. Shifted from Grunt/Bower to NPM/Browserify
  • Secure design review and implementation of findings
  • Development of tests (unit and manual) - complete: Codecov report
  • Draft end user documentation - complete: GitHub pages
  • "Publicity drive" to sign up alpha/beta users and generate feedback - Some progress on this. The desktop app has had 13k downloads - unclear how many people are actually using it. The GH repo for the desktop version has 79 stars. The web version gets about 94 unique visitors per day on average and the GH repo has 229 stars.

Milestone 2: Beta release - Threat/mitigation rule engine

  • Refinement of UX based on feedback from the alpha release
  • (Some) feature enhancements based on feedback from the alpha release - Implemented some feature requests (e.g. snap-to-grid) and fixed issues reports (e.g. save bugs) by users
  • Implementation of a rule engine for generation of threats/mitigations
  • Updated tests and end-user documentation

Milestone 3: Release 1

  • Key refinements, bug fixes and new features based on feedback from the beta release
  • Complete end user documentation
  • Penetration test

Milestone 4 - Dev lifecycle integration

  • Detailed scope to be defined, but in general the vision is to support hooks into issue tracking and requirements management tool so that threats/mitigations can be tracked through to implementation and test

Timeframes

This is hard to estimate as it could change a lot if there were other developers involved. Based on my current velocity with just me, I would say release 1 could be complete in 1 year (optimistically).

Technology

The technical architecture is javascript from top to bottom. In the client the key libraries are Angular for the MVC architecture and JointJS for the diagramming. JointJS has a log of great features, but is not a perfect fit for Angular. This needs a review. In the prototype, all storage is done on the client using browser local storage.

Following an architecture review the following key changes were made:

  • A new Electron based, installable desktop variant was introduced using the local file system for model storage
  • The web variant was changed to use GitHub for model storage - other source control systems will follow (e.g. BitBucket)
  • Seperation of common code into a new NPM package, shared between the web and desktop variants
  • The Nools rule engine will be replaced since it is no longer maintained

Challenges

  • Getting enough usage of the alpha and beta to get the UX and rule engine right
  • Finding a sustainable way to host it, especially to support deeper GitHub/BitBucket/Etc. integration

Getting Involved

Alpha testers

Great user experience is one of the key goals for the project and to get that right it needs some users! If you would like to try the tool out, that would be great. A working prototype can be found at:

https://threatdragon.org/

The desktop variant (for Windows and OSX) can be downloaded from:

https://github.com/mike-goodwin/owasp-threat-dragon-desktop/releases

To help you get started, take a look at the (draft) docs:

http://docs.threatdragon.org/

If you are still having problems, let me know and I will be pleased to help ([email protected]). All feedback is very welcome. Either email me or put an issue on GitHub

https://github.com/mike-goodwin/owasp-threat-dragon/issues

Coding

Coding help of any kind is always welcome. The project builds easily (let me know if you have any problems) so getting up and running should be simple.

Threat rule engine

If you are not into javascript, you can still help! We need to build a powerful threat generation rule engine to replace the stubbed one that is in place for the prototype. If you can contribute in this area by defining rule, that would be great.

1) Application source code for a threat modeling tool

2) End user documentation for the tool

3) An online hosted version of the tool

4) An installable, cross-platform desktop version of the tool


Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_Threat_Dragon&oldid=252719"