Welcome again to this series of articles on Threat Modeling vNext.
After the first articles focused on discussing the issue of the Quality for Threat Models, we have moved to the introduction of the Threat Modeling vNext practice, mostly by describing the needs it addresses for various functions. We have noticed how even similar roles like novices and expert Threat Modelers would have different needs, so crucial that different tools may be in order. What if we consider even more exotic requirements?
So, let’s introduce a totally different persona, Elliot, which is a Project Manager for an initiative that includes Threat Modeling as part of its tasks. If you are using an Agile methodology, you may think of Elliot as your average Product Owner. Those two approaches indeed have fundamental differences, but they may be considered pretty similar, at least for our purposes: in fact, both Threats and Mitigations may be mapped to concepts already supported by the chosen methodology. For example, Threats may be associated with Bugs or User Stories and Mitigations with Tasks. Each approach will define a specific process to handle the said entities, but that is ok because we do not want to require the definition of different procedures to handle Threats and Mitigations.
Considering that Agile methodologies are preponderant nowadays, the rest of the article is going to adopt Agile terminology.
It goes without saying that Elliot has some unique needs related to Threat Modeling. In fact, Elliot cares mostly about the Backlog. For instance, he needs to be sure that all the activities that are planned are really required, that they are understandable, and that they are correctly prioritized. To achieve this goal, it is essential for Elliot that the Threats and Mitigations identified by the Threat Model are inserted in the Backlog with the right information and categorization. This allows him to evaluate them and prioritize their implementation. Provisioning of Bugs, User Stories and Tasks from Threats and Mitigations must be automated: in fact, how could anyone hope to create manually tens or even hundreds of those objects, and maintain them aligned with the changes to the Threat Model? Of course, this would not be possible.
Threat Models are to be considered very vital documents: they are intended to be updated, refined, and extended continuously. If you adopt an Agile methodology like Scrum, you will need to revise the Threat Model for your solution regularly, typically at each iteration or Sprint. When you do that, it would be essential to include in your revision the evaluation of the status of the mitigations. For example, if you identified a risk of information disclosure for data in transit due to a lack of channel encryption, it would be essential to recognize the implementation of secure channel encryption in the solution. This would be not only to revise the status of Threats and Mitigations but also to avoid adding new Tasks and User Stories for something which has already been addressed. Doing so would not only be necessary for Threat Modeling practicians like Judith and Lucy, but also for our Product Owner, Elliot. In fact, he needs to be sure to use the limited resources he has to implement required features and fix real issues, not chasing ghosts and addressing inexistent regressions. As a result, the bi-directional flow of information between the chosen Threat Modeling tool and the selected Tracking software is required.
Elliot, as a Product Owner needs to measure improvements: the integration of the Threat Model with the Tracking tool allows introducing a new measure, which would be the Residual Risk. In fact, when a Mitigation is implemented, the Residual Risk would be affected, therefore measuring the Residual Risk would allow understanding and communicating very quickly how security is improved over time.
How to measure Risk? If you have followed the Threat Modeling vNext series, you’ll recall that some basic concepts have been discussed in the article on the Residual Risk. It is possible to start from those ideas and calculate the Residual Risk as a number. The best approach would be to use a Quantitative Risk Analysis approach, such as FAIR, but most of the time, it would not be feasible to do so for Threat Models due to the high number of identified Threats. For this reason, it may be necessary to consider an alternative approach, which would be less rigorous than FAIR, while still helping to understand the relative risk for the various Threats. For example, it may be possible to assign an arbitrary value to what each Severity level means and to the strength of the related Mitigations. In fact, we have already seen that not all Mitigations are born equal, and thus it seems reasonable to assign a different weight based on their characteristics and on the affected Threat. This would allow calculating the Residual Risk as a number, by applying an expression similar to what follows.
In the expression above, Rt represents the Risk calculated for the Threat T. It would be a number associated with each Severity Level defined in the Bug Bar: for example, we may have 100 assigned to Critical Severities, 75 to High Severity and so on. To calculate the Residual Risk, you have then to multiply Rt with the result of subtracting 1 with the division by 100 of the minimum number between 100 and the sum of values derived to the strengths of each implemented mitigation, Si.
For example, let’s imagine having a High Severity Threat, which has two implemented Mitigations, one of Average Strength and the second one Weak. We may assign respectively 50 and 25 to those Strengths. This would mean that the resulting relative Residual Risk for that Threat would be 75 * (1 – Min(100, (50 + 25)) / 100), which equals to 18.75. If we sum the Residual Risks for all the various Threats identified during the Threat Model, we would have our relative Residual Risk for the whole scenario.
It is important to note that this approach is not designed to produce numbers that can be used to compare different projects because it is fundamentally qualitative. Still, it would provide a good representation of how the risk varies within a project or product as a result of the mitigation implementation process.
We may consider other aspects of Threat Models, which may be useful for a Project Manager or Program Owner like Elliot. For example, it could help to provide clarity to a project and to more clearly evaluate the impact of some bug on the overall security of the solution, mainly if the Threat Model tracks essential information like the categorization of the information included in data storages.
Still, the important take away from this conversation is not to identify all the special needs each role would have, but instead about the fact that different people may take different values from the same Threat Model. Thus, it is crucial to recognize the opportunity to give more value to all, by targeting their needs and by providing a view as focused as possible to what each role requires.
Next time we will see an even different situation, with the introduction of a Business Decision Maker, George.
Up until then, stay safe!
Simone On Security 