Welcome to this new installment of the Threat Modeling vNext series.
Last time we started to describe our new Threat Modeling approach by example, with the introduction of a fictitious character, Judith. She represents a Security-conscious person in some organization, which has been asked to perform a Threat Model. She has no specific training, though; therefore, her most crucial need is to get guidance. Threat Modeling vNext introduces various concepts that are crucial to address this need, as we have seen some of them as part of the previous article.
Now is the time to introduce a new set of features through a new fictitious practician: Lucy. In this case, we are talking about very different needs: in fact, Lucy is a Threat Modeling expert. She can look at the architecture of a system and identify the first weaknesses after only a few minutes of conversation with its authors. There are not many in her Organization as good at Threat Modeling as Lucy is: for this reason, she is in high demand. Lucy tends to work on highly visible projects, characterized by high complexity and subject to substantial regulatory and compliance risks. Most of Lucy’s work is related to new projects, but sometimes she is involved with existing solutions, to assess their risk and help Business Decision Makers to decide how to cope with it.
Lucy does not need to get the guidance required by Judith. On the contrary, that guidance may represent a problem for her, because it would necessarily be based on best practices that would only in part apply to the specific scenarios she deals with. Therefore, using some knowledge in an automated way would be counterproductive for her because it would only dilute the definite recommendation she can provide. Of course, Lucy needs to have some lightweight guidance: even the most experts among us may fail to consider essential details every now and then. And using some source like CAPEC or CWE still provide some structure to the finding and therefore may be regarded by Lucy as a valuable tool. But the primary role of said guidance for Lucy would merely be to provide an unobtrusive hint about required topics that may be overlooked.
For those reasons, Lucy needs more than anything else to get as effective and efficient as she can.
To Lucy, being “effective” means to be able to express the concepts typical to Threat Modeling with the required expressive richness, and at the same time in a way that would simplify communication with her counterparties. This typically involves providing a visual representation of the solution, but it may not be enough. In fact, tables may be more in line with the expectations of those used to work with them. Analogously, Business Decision Makers may require a summary of the situation, possibly expressed in monetary terms, and with graphs and diagrams to better represent the situation and what can be done to address it. That said, even if identifying the security risks represents an integral part of Lucy’s job, recognizing the potential mitigations and giving an idea of their impact would serve an even more important goal for her. This is because Lucy’s counterparties need her guidance to define a roadmap to remediate the risks and get to a situation characterized by an acceptable risk.
As we have anticipated in the article on Threat Modeling vNext Story, one of the most essential characteristics of this practice is related to being flexible. For Lucy, flexibility and extensibility are fundamental characteristics because she can use them to introduce new critical capabilities. For example, she may enable Quantitative Risk Analysis based on FAIR. She could also scan an existing solution to create automatically part of the Threat Model.
You may argue that some of those advanced capabilities would be useful also for our beginner Threat Modeler, Judith, and you would be right. In fact, the exact blend of features you may value the most depends on various factors, including your role and experience. For this reason, the best approach would be something showing precisely what you need and hiding anything else.
Of course, having the possibility to create part of the Threat Model by merely scanning the solution while it is executed represents a convenient and valuable help for all Threat Modelers to achieve better efficiency. Still, Lucy needs something more. For example, she needs to be able to create her reports automatically, with a click of a button. While a beginner may accept to generate simple reports with little or no possibilities of customization, Lucy needs to be able to customize them. In fact, she deals with different groups inside her organization, and many of them have specific templates they require to adopt. Therefore, for Lucy it is essential to have the possibility to create reports conforming with those templates without spending a lot of time to tweak them.
To summarize, Threat Modeling experts require quite a different set of features than the beginners. One may think that Threat Modeling is one single practice and that the difference between experts and non-experts would merely be related to the time spent and the quality of the final result, but it would not be correct. In essence, the needs are different enough to justify the adoption of various tools.
If the difference is so significant for practicians doing mostly the same work, what should we expect for totally different roles? What would a Project Manager require from a Threat Modeling vNext tool? Next week we’ll try to answer this question.
Until then, take care!
Simone On Security 