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"
(→Description) |
(→Roadmap) |
||
| Line 81: | Line 81: | ||
==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 | |
| − | + | * 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:''' | |
| − | 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 | |
| − | + | * Secure design review and implementation of findings | |
| − | + | * Development of tests (unit and manual) | |
| − | + | * Draft end user documentation | |
| − | + | * "Publicity drive" to sign up alpha/beta users and generate feedback | |
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 | |
| − | + | * (Some) feature enhancements based on feedback from the alpha release | |
| − | + | * Implementation of a rule engine for generation of threats/mitigations | |
| − | + | * 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 | |
| − | + | * Complete end user documentation | |
| − | + | * 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 | |
| − | 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 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. | 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. | ||
| Line 136: | Line 127: | ||
There is nothing on the server side at the moment in the prototype. Areas where this might become necessary are | There is nothing on the server side at the moment in the prototype. Areas where this might become necessary are | ||
| − | + | * If the threat rule engine requires too much power to run feasibly on the client | |
| − | + | * Supporting hooks in to other dev lifecycle tools | |
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. | 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. | ||
| Line 143: | Line 134: | ||
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. | 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. | ||
| − | Challenges | + | '''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 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== | ==Getting Involved== | ||
Revision as of 19:45, 3 June 2015
OWASP Threat Dragon ProjectAn 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. DescriptionThreat 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
However, effective adoption by organisations can be difficult. Reasons for this include:
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:
LicensingThis program is free software: you can redistribute it and/or modify it under the terms of the Apache 2.0 License |
Project ResourcesThe source code for the project can be found here: https://bitbucket.org/theblacklabrador/threatmodellingtool/src And you can click here to see a working prototype. Project LeaderRelated ProjectsClassifications
|
News and Events | ||||
Contributors
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
- Secure design review and implementation of findings
- Development of tests (unit and manual)
- Draft end user documentation
- "Publicity drive" to sign up alpha/beta users and generate feedback
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
- 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 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.
There is nothing on the server side at the moment in the prototype. Areas where this might become necessary are
- If the threat rule engine requires too much power to run feasibly on the client
- Supporting hooks in to other dev lifecycle tools
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.
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.
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 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
Coding
1) Application source code for a threat modeling tool
2) End user documentation for the tool
3) An online hosted version of the tool
