How to Integrate threat modelling into jira work flows?
How/where to store the threat models so that can be easily be reviewed for future reference?In my experience diagrams/pdfs become obsolete and no one views them in the future?
How to ensure all threats are covered ? How to know that we have threat modelled enough?
How is threat modelling different from a secure design review ?
I am unsure if you are using any threat modeling tool or not, so let me take a swing at this with what I did manually and what I’d do using a platform.
If you’re doing threat modeling manually -
Integrating into Jira workflows - I would have manually entered content directly into our ticketing system after our team collected our initial set of threats and proposed controls or compensating controls. In our ticketing system, I created a specific project and then created unique phases based on priorities or grouped or shared systems/tasks. Other organizations, I have worked with create an epic for each threat model and then log all threats and controls against that epic.
Storing threat models - we were a heavy SharePoint organization so we would have stored them centrally in that document repo with any of the other supporting documentations and notes. You are 100% correct that they were rarely viewed again until we reassessed that infrastructure or application again in the future. Periodically, we would have to return to previously created models to figured out exactly what we meant on some specific threat because data was lost during that transcription into Jira or another ticketing system.
How to ensure all threats are enough - That was always the big question. We usually prioritized and make sure we were using some external system prioritized threats or weaknesses (e.g., this is a public facing financial application so these are most common types of vulnerabilities and threats against that application, followed by a review of what we have personally seen, followed by implementation of our standard control sets, etc). I personally believe that good threat modeling is always an iterative process so no threat model is ever complete (unless the system is kaput )
Integrating into Jira - IriusRisk directly integrates and sends a ticket into Jira that contains all of the information from my countermeasure review. From there I can create the same flow or internal Jira workflow. No translation issues. No non-value added data entry. As someone who was once responsible for that data entry, I am so grateful for this.
Storing Threat models - they are centrally stored and my threat model design or questions about my design informs my threat model. So as my threat model design is updated, it informs and improves my threat model. This coupling of the two is a nice sync. Additionally, all versions of my diagram and full threat model are preserved within my threat model.
How to ensure all threats enough - Hopefully, it you are using an existing threat library (filled with your team’s risk registry or some other set of preconfigured threats and content, you would at least have a good backstop and base to start from). I would still advocate for an iterative process so each threat model should be periodically review at some interval.
Lastly regarding your question about Secure design review - If Threat Modeling is Architectural Risk Analysis which is what I would equate to Secure Design Review then I would say they are semantic differences. However, some organizations also include business process threat modeling or they will threat model infrastructure (which could still be considered a type of design review) as part of their threat modeling practices. To summarize, I would say that Threat Modeling (as a whole) would include more than just Secure Design review.
Hi @hacxys, I’ll give you my point of view to your questions:
How to Integrate threat modelling into jira work flows?
Good question. As @JamesR pointed out, there are different approaches to achieve this depending on the availability of different tooling. You can do this without tools, as James suggested. It’ll require manual entry of tickets and project management techniques on Jira, such as customizing issue types and so on. On the other hand, some automated tools like IriusRisk has been designed to be integrated with Jira and others ticketing platforms. For every countermeasure in the threat model, manually or automatically created, you have the possibility to create a new issue, so the group in charge will receive a ticket to solve it.
How/where to store the threat models so that can be easily be reviewed for future reference?
In my experience diagrams/pdfs become obsolete and no one views them in the future?
Threat modeling is a continuous process. You may have resolved all the threats you have found in a specific moment, but for sure in the future more risk will appear, so if we want to keep our systems secure there isn’t any other way than to review the threat model and challenge the systems often and create several versions with the time.
Adopting an automated tools allow you to export and save or share your projects. You can also use templates or project components so several groups can cooperate or even work on the same project at the same time.
How to ensure all threats are covered? How to know that we have threat modelled enough?
In my opinion we have to understand that threat modeling is not going to make our system invulnerable. By threat modeling we are going to minimize the cost and the complexity of the security issues we are going to find once we make a pentest, but completely eliminating it is not going to be possible, basically because there are always new ways to attack. This is about making the best effort.
About the second question, it depends on the company. In the real world it is not possible to fix all the issues or the countermeasures. Sometimes we have to accept the risk because to solve it it’s not cost effective.
How is threat modelling different from a secure design review?
Threat modeling is a process of identifying potential threats while secure design is a process of reviewing the design. Both are important and both should be used in conjunction to create a security strategy.