Threat Modeling with TMS: the Interviews

Threats Manager Studio (TMS) is a Threat Modeling tool that provides superior efficiency and effectiveness. But how can you practically use it to create your own Threat Models? This article is the fifth in a series to answer this question, by showing a complete process since the diagramming phase. The previous article is available from here.

With the previous four articles, we prepared a first diagram of our sample system and we have shown how to use Templates to automatically create Threats and assign Mitigations. We have seen the activities you are supposed to do, to update the severity of the Threat Events and the status of the Mitigations. We have also discussed how you should use the Threat Event List and the Mitigation List to ensure that all the various evaluations of Severity, Strength and Status are aligned among the various Threat Events and Mitigations. Then we have used our experience as Threat Modelers and the STRIDE approach, to identify additional Threats and Mitigations. Finally, we have seen how to validate your threat model, and then how to prepare the additional material required to communicate to the Business Stakeholders and to the Product Owners and Managers the results of the Threat Model.

Those four articles conclude the analysis of how TMS can help your Threat Model exercise, but they have not touched a very important step: the Interviews. This fifth step should have been introduced at the very start of the series, because the Interviews are what starts the Threat Modeling process. Nevertheless, it has been included last, because it is not based on TMS, at least as of today. In fact, the upcoming version of the Threats Manager Studio will include tools to facilitate the Interview phase.

The basic idea

Before delving in the details of the Interview process, it may be useful to introduce some key elements of the process I personally adopt. This is not necessarily the best way to do that, and probably not even the most common, but it is a process I have honed over a period of about 10 years as a Threat Modeler, and that has consistently given great results.

It is important to understand, though, that the Interview process is continuously improving, as it is the whole Threat Modeling process. I know that one year from now I will revisit this article, changing significant aspects here and there, to update it to the latest and greatest. In fact, it is changing already, for instance with an initial involvement of TMS during the Interview phase, thank to improvements under development for the upcoming release.

There are some important principles regulating the Interview phase:

• First of all, you need to be prepared for them, particularly if you are not very experienced at Threat Modeling or about the specific problem space or technologies involved by the solution.
• You need to give yourself time to get all the required information. Even for experts, it is very rare to get all the most important questions lined up to be asked at the first meeting. Matter of fact, you will miss a lot.
• Be sure to interview all the relevant players, starting from the Business Stakeholders and who operates the solution in Production.
• Respect who you interview and do not overburden them with long or unnecessary meetings: they are all very busy!
• Of course you may have additional questions after the interviews. Create an open channel to get the answers fast.

Let’s see all those principles in detail, and how you can implement them.

Prepare for the Interviews

The preparation typically involves three different tasks:

• The definition of the scope for the Threat Model. It is of utter importance to get clarity about what is in scope and what not, particularly if the Threat Model activity is performed on a solution under active development.
• The retrieval of existing documentation on the Design of the solution in scope and about its Security. If the project is new, nothing may be available, but you may still get something from presentations and other available material.
• The definition of the calendar for the Interviews.

You may need to allocate time in the order of a couple of hours to a couple of days for preparing for the Threat Model, depending on your level of proficiency and the available material. For example, if no documentation is available, then the second task would amount to nothing.

The clear identification of the scope is also crucial to understand the effort required. For example, if the system is simple enough, you may be able to perform a Threat Model in a few hours, while achieving the same level of details for average complexity systems would require a few days. Of course, higher levels of assurance would require more time, to get more details for the analyzed solution, and because you would use the additional time to get further insight related to the problem space and on the involved technologies.

It may be tricky to find the right balance between the need to maintain the cost of the Threat Modeling activity limited, and the need to get an higher security assurance, still it is a very important task. It is also important to use the preparation phase to ensure that your counterparty understand the chosen approach and what you are going to produce.

Tips & Tricks
In this phase, your counterparty may be tempted to think that Threat Modeling can identify all potential security issues for the design of the solution in scope. While a longer, higher-assurance delivery would provide more significant Threats and Mitigations and would tend to identify more problems than a Threat Modeling exercise lasting only a few hours, no Threat Model can identify all Threats or Mitigations.

The last task you need to perform during the preparation is to define the calendar for the Interviews. The next Chapter discusses some important considerations you need to take in account to execute this task.

Get yourself the information you need

Threat Modeling is a tricky activity. It requires you to get a very good understanding of the solution you are analyzing, and then to drive that knowledge back to its owners.

Your role as a Threat Modeler

At this point, you may have noticed that the approach discussed in this post is based on an expert driving the Threat Modeling activity. While this approach has demonstrated being very effective to get the job done, it is not the only approach possible. It is not even without potential risks, so much that the Threat Modeling Manifesto authors warn against the risk of drifting toward what they define as the Hero Threat Modeler syndrome, and instead insist on the importance of getting Varied Viewpoints.

Hero Threat Modeling Anti-Pattern
Threat modeling does not depend on one’s innate ability or unique mindset; everyone can and should do it.

Varied Viewpoints Pattern
Assemble a diverse team with appropriate subject matter experts and cross-functional collaboration.

The Threat Modeling Manifesto

For this reason there are alternatives you may consider. For example, you may want to structure the Interviews as a moment for the Team to discuss potential risks for the solution. As a result, the Interviews would not be defined as such anymore, but they would instead be Workshops, where everyone would act at the same time as subject matter expert and would actively identify Threats and Mitigations. The Threat Modeling expert would therefore become a facilitator, ensuring that the right conversation happens. I consider this approach as a wonderful learning opportunity for everyone and as a way to get a great coverage of the actual risks for the solution, potentially even better than what you could do with other approaches. This is something I regularly applied during the first years of my experience of a Threat Modeler.
Why then the different approach, focusing more on the expert? Because getting some value fast is a need, involving the development team only for the strictly necessary time is a requirement, and involving Business Stakeholders for even less is a must. For this reason, the approach has evolved to the execution of multiple Interviews, each one devoted to getting the required information from specific roles.

Who to Interview, and how

What are the typical roles you would want to hear from?

• The Business Stakeholders, to understand the business angle, what is this solution really trying to address, why it is important, and what are the security concerns from a business point of view. This is crucial to prioritize Threats and Mitigations correctly.
• The Architects and potentially Lead Developers of the solution, to get information about the design of the solution.
• Who operates the deployment infrastructure, to understand potential risks associated to the secrets management and deployment, supply chain risks and related problems.
• Who operates the solution in Production, to identify management risks.

Not all Interviews happen every time. It really depends on how you do them. In my experience, it is possible to get the interview with the Business Stakeholders done. It would be a fast, 30′ call, because it is very rare that they have much more time to devote than that. The interviews with the Architects are crucial, because Architects tend to have the best knowledge about the design of the solution, and where they miss details, they will be able to point you to the right person to answer. Why the plural? Because typically it is necessary to do two Interviews. I typically organize them in two consecutive mornings. In fact, this allows to devote the afternoon to analyze the answers and identify open points and potential risks requiring further clarifications. the last two interviews, the first one with those managing the deployment infrastructure and the second one with the managers of the Production environment, are optional and depend on the type of Threat Model. In fact, faster executions will tend to skip that part.

	First day	Second day	Third day
Morning	Kick-off (30′) Meeting with Business Stakeholders (30′) Meeting with Architects (2h)	Meeting with Architects (1h) Meeting with deployment owners (30′) Meeting with Production owners (30′)	Identification of specific Threats and Mitigations Clean up Creation of the Roadmap
Afternoon	Analysis of the notes from the morning meetings First draft of the diagrams	Threats and Mitigations identification Identification of specific Threats and Mitigations	Discussion of the findings with the whole team Discussion of the Roadmap and identification of Quick Wins to be included in the backlog

What happens if you have further questions?

Fast Threat Model activities, like those performed in a few hours, would not allow much interaction besides the planned Interviews. In other situations, you may have the luxury of getting more time. When this happens, you may be able to go more in depth with your analysis and thus identify additional point requiring clarification. For this reason, you will need to ask questions to the stakeholders you have identified during the Interviews. It is important to ensure you have established a privileged channel with them, to get answers fast, because otherwise they may arrive too late.

How to conduct the Interviews

Now that you have organized the Interviews, you need to lead them. How to do that?

If you are starting up, it may be tricky to identify a process and avoid awkward moments where you perceive that there is something you should still ask, but you do not know what. Trust me, I’ve been there. For this reason, preparation is key. Define some clear goals for each Interview. For instance, the interview with the Business stakeholders would be to get their point of view about the solution: what is its value, and what are the most important concerns. I typically use that interview to perform the STRIDE-based calibration as discussed on Simone On Security.

When you Interview the Architects, I usually start by asking them to illustrate their Architecture. After their initial representation, it may be best to identify a starting point for an in-depth discussion of the solution: typically, it is some External Interactor like a user or a service. You should ask the usual questions to understand the various security properties of that component and on how it interacts with the solution, including:

• What data it accesses or provides?
• How confidentiality of data in transit is guaranteed?
• How integrity of data in transit is guaranteed?
• How it authenticates toward the solution and how protects its credentials?
• Is there any mechanism to regularly change the credentials?

The list is actually much longer. A good approach may be to ask questions designed to surface all STRIDE categories. For instance, with the previous list we have touched Spoofing, Tampering, and Information Disclosure, but not Repudiation, Denial of Service, or Elevation of Privilege. Therefore, we may add questions like:

• If a request with wrong credentials is submitted, do you track it? How do you manage such event?
• Do you have some DDoS protection in place?
• Do you have different roles? How do you enforce the rights assignments?

Category	Desired Property	Definition
Spoofing	Authentication	Impersonating something or someone else
Tampering	Integrity	Unwarranted modification of code or data
Repudiation	Non Repudiation	The ability to claim to have not performed some action against the solution
Information Disclosure	Confidentiality	Exposure of information to unauthorized users
Denial of Service	Availability	The ability to deny or degrade a service to legitimate users
Elevation of Privilege	Authorization	The ability of a user to elevate her or his privileges with an application without authorization.

During such interviews, it is very common to get hints regarding potential risks, more or less involuntarily surrendered by those interviewed. You should be on the alert for such situations, and be sure to get all the information required to better understand them. Do not come to conclusions too fast. In fact, you need to really understand how an attack may happen, before saying that there is a potential risk. Sometimes you may think that an attack is possible, and it may be, but you need to somewhat demonstrate it at least from a conceptual level. For example, there are many men in the middle attacks. Some of them are entirely possible: for instance, you may have some rogue access point on the WiFi network of some victim, using attacks like SSLStrip to intercept the flow. Other man in the middle attacks like the random interception of data transferred on Internet would be much less probable and therefore may be dismissed.

Conclusions

The initial phases of the Threat Modeling are most probably the most important of the whole process. Only if you get a good understanding of the system you are going to analyze, you can get significant results. Threats Manager Studio does not help, yet, but it will provide some benefits in the future. In any case, this is where you as a Threat Modeling expert can really do the difference.

This concludes our short series of five articles on Threat Modeling with TMS, but it does not concludes the story of Threat Modeling or of TMS. Both are evolving fast. Join the community of Threats Manager Studio users, and be an active part of the (r)evolution!