How to Scale Threat Modeling.View the original Working Session content
A document gathering problems identified and solutions proposed.
This session looked at how to scale the threat model process within an organisation. A broad discussion produced a list of problems organised around the Four Key Questions but there was not enough time to produce comprehensive solutions. The discussion will continue on the OWASP TM slack channel and the OWASP TM website.
Organizations face three main causes of bottlenecks when integrating Threat Modeling activities in the SDLC:
- The ratio of developers to security is 100:1.
- Continuous delivery is part of the Agile recipe.
- Growth of microservice architecture popularity means exponentual growth in potential apps that require TM.
- Lack of incentive to allocate resources to do initial risk inventory and thread modeling
- Momentum is lost when Threat Modeling is seen as a continuous process
- Absence of experienced people in the team to do Threat Modeling
- Threat Modeling requires security experience
- One size does not fit all
- Guidance is written for security people but not for developers
- There is already a lot of “stuff” for developers to know
- Lack of accessible case studies of effectiveness
- Maturity, or lack of it, in the team
- Teams do not know the level of granularity of Threat Modeling
- Concerns about subjectivity - no measurable value
- Consistency of methodology and results
- Model security bugs in JIRA and make them visible
- Heuristics to triage if, and where, Threat Modeling is required
- Five- and 30-minute Threat Models (incremental investment)
- SPIKE ™ TimeBox guidance
- Triage system guidance
- Sorry points
- Modular systems with reusable components
- What initiatives are companies using to tackle these challenges?
- How can we scale the amount of Threat Modeling activity in organisations?
- How do we follow up thousands of Threat Models with a reduced team?