Welcome to this new installment of the Threat Modeling vNext series. It started about two months ago to discuss the problems we are currently facing with Threat Modeling and how we could improve it to address them.
The previous article of the series introduced Threat Modeling vNext by telling the story of how it has born and evolved. Of course, that story is far from being concluded, because a process whose goal is to be flexible, integrated and customizable, must evolve with the needs.
That said, I know that the various articles written so far do a poor job in really telling what Threat Modeling vNext is. So, this article is here to fill this gap. And what would be better than explaining it by examples?
So, let’s introduce Judith to you. She is an Architect with some knowledge about Security. Her Organization has asked her to perform a Threat Model on the solution she is designing, as part of the standard project deliverables. She doesn’t really know how to start, because her knowledge of the security aspects of the adopted technologies is limited. Moreover, the overall Threat Modeling process is relatively new to her, given that this has been only recently introduced as a requirement.
What Judith needs is guidance: that would be something to provide information about common risks for the specific blend of technologies she is adopting and recommendations for the mitigations to implement. Judith also needs to have tools that would guide through the Threat Modeling process, simplifying it and showing recommendations to improve the quality of her assessments.
Let’s imagine how Judith would perform the Threat Model: she would open a tool to draw a sketch of the solution. If you are familiar with the Microsoft Threat Modeling Tool, that would be something in the line of the DFD diagram, which represents the bulk of the experience. Judith may fill the diagram with metadata that would help to better clarify the situation. Then she may import various knowledge bases, specifically designed to cover the technologies she has used for her solution. Let’s assume that it is based on Azure PaaS, Kubernetes and Machine Learning: she will have a knowledge base to be imported for each one of them. This will create a unique blend, specially designed for her scenario. Then she will use it to automatically generate Threats and associate common Mitigations to her solution.
At this point, Judith will be able to check the generated items. First of all, she may identify in the Threat Model the mitigations that have already been considered. Moreover, Judith will need to adjust the Severities of the Threats to take into account the existing Mitigations. In other words, she needs to complete the Threat Model.
Then Judith will get a look at a Dashboard that would provide her an assessment of the quality of her Threat Model: is it acceptable or not? What shall she do to improve it?
Finally, she will generate the Report the Security Team within her Organization requires, using the official template they have provided to her, and then the work will be over.
You may have noticed some fundamental ideas: for instance, you do not have a single Knowledge Base, but many. This is required because current projects are built upon multiple technologies, and maintaining all of them may be prohibitive. Much better to adopt a divide-and-rule approach based on the creation of separated knowledge bases. Then, you would need to proceed with a bottom-up method, which would mean to compose the unique blend that makes sense for your specific scenario by cherry-picking some knowledge bases out of the available set. Traditional approaches involve having a single knowledgebase covering all the possible topics. Threat Modeling vNext makes knowledgebases maintenance much more straightforward, as it simplifies them so that they can be more easily understood.
Another essential idea is about the Dashboard to assess the Quality of the Threat Model. The intent is to provide a simple way to identify mistakes and address them. If you have a development background, you may think of the equivalent to a Static Analysis Security Testing (SAST) tool for Threat Modeling. One of the tenets of Threat Modeling vNext is flexibility and customization, which does also apply to this case: for example, let’s imagine that Judith’s organization defines a field that must be filled up, to indicate the sensitivity of the data stored in a database or other mediums. Of course, the Organization would want to enforce this requirement. This could be done in a prescriptive way, but also by extending the Dashboard with a customized rule. Such a rule would allow Judith to identify all those situations where she has violated the rule and address them to get the best Threat Model she can get.
This week, we have only seen a first example of how one could benefit from the ideas part of Threat Modeling vNext. Next week, we’ll see another example, by introducing Lucy, the Threat Modeling expert. Then we’ll continue by expanding to less technical roles, represented by Elliot, the Project Manager, and finally by George, which is a Business Decision Maker who is involved in the Exception Management process as the official approver for Exception requests.
Simone On Security 