Description of session
The purpose of this session is to introduce the project and create a rough roadmap of deliverables for the project during the summit. The project is currently a documentation project, but it lacks documentation; one of the key objectives of the week will be to produce documentation.
Outcomes/Deliverables
- Set Objectives for the track for the summit
- Spoke on project structure (there are a number of sub-projects that are being set up as separate projects e.g. Threat Model cookbooks) ..* A question was put to the group on whether the separate project was acceptable ..* The group liked the idea of autonomy of such a format but that if they differ in ownership they should be all in ‘one place’ to allow for easy access for consumers.
- Discussed upcoming sessions and how they meet the intent of the project (get stuff documented) and (if relevant) how they link to other OWASP projects.
- Discussed the crossover of other OWASP projects and how some upcoming sessions will cover that crossover and collaboration. e.g. Automated Threat Handbook and Cloud Security Project.
- List of sub-modules we want to see in the OWASP project created.
Synopsis and Takeaways
- Creation of a list of sub-projects with ownership
OWASP TM Project Modules
It may be possible to combine some of the following items under existing / new sub-modules:
- Examples (TM Cookbook)
- Attack/ Mitigation Library
- TM Methodologies
- TM Frameworks
- Education - OWASP Training
- Academia - Research papers
- Practical tips ..* Versioning ..* Inheritance
- Implementation tips/ tricks (agile vs waterflow tips etc)
- Cheat Sheets (existing)
- Meta definition for threat models (DSL workshop Thurs)
- Tools -> Questionnaire (to add tools and tool info - G-questionnaire?) ..* Description ..* What methodology framework do they implement ..* Meta data on tools / tool categorisation (which of the 4 TM questions does the tool answer)
- Case studies (from various experiences on threat modeling in different environments - covering both successes and failures)
- Glossary / taxonomy
Identified Questions
- Who are the customers of the Threat Model projects?
- What is the project structure?
- Should there be separate projects or sub-project modules?
- How is ownership defined for the various threat model projects?
- Is anyone looking at creating a new threat modeling tool?
- Should we perform a call for TM data (Top 10 style?)
- Should we threat model the DevSlop CI/CD pipeline using different frameworks to compare?
- Should we update the Juice Shop threat model (either re-do or call out the version that was threat modelled)?
- Why aren’t more people contributing to the project? How do we make it frictionless?
- Is the project outline on the OWASP website accurate still?
Follow up
- Define owners for each module suggested and ensure the owners are set up with wiki access.
References
- Threat Taxonomy Tash mentioned: https://www.synopsys.com/blogs/software-security/threat-modeling-vocabulary/
- OWASP Devslop project (automated security testing within the CI/CD) https://devslop.co/