Threat modeling isn’t a new concept, but it remains one that many development teams struggle to understand. Threat modeling processes in the software development lifecycle, or SDLC, remain alien to development teams, which is what Izar Tarandach and Matthew J. Coles hope to combat with their book, Threat Modeling: A Practical Guide for Development Teams.
“We want readers to have knowledge of the language of security and what those concepts mean,” Coles said. “We were very careful to teach principles about what a system is, what system security is, what the language is and what we mean when we say ‘security vs. privacy’ or ‘confidentiality vs. authentication.'”
In this Q&A, Tarandach and Coles discuss the best audience for their threat modeling book and why they felt the book was needed, as well as two methods of automated threat modeling.
For more information on automated threat modeling, read an excerpt of Chapter 4 of Threat Modeling.
Editor’s note: This transcript has been edited for length and clarity.
What made you decide it was time to collaborate and write this book?
Matthew J. Coles: There’s the easy answer that it needed to be done. The more extensive answer is that a couple of other books talk about threat modeling, but there aren’t a lot of books targeting developers. Many are geared toward security experts and not necessarily enabling people without security experience to get up to speed. We wanted to focus on delivering this knowledge in an easy-to-use fashion to a different target audience.
Izar Tarandach: We wrote it because we needed it. As practitioners, we deal with a lot of developers, teams and organizations constantly asking, ‘Hey, can we have something digestible that we can just hand to developers and say come back to me knowing more than you knew before?’
From reading through the book, it’s clear that, while the audience is mainly developers, it isn’t only for them. Why is that?
Click here to learn moreabout
Threat Modeling:
A Practical Guide for
Development Teams
by Izar Tarandach and
Matthew J. Coles.
Tarandach: We had this image of developers picking it up. But, as we wrote the book, we started noticing it went beyond the developer and the person writing code. It became a text we think is useful for anybody involved in the development process — product managers, product owners, development managers. It’s for people who have to understand writing and designing a secure product. We don’t say this book is the bible for threat modeling, that it’s the end-all be-all. But it’s an easy way for people in those roles to get into threat modeling and get a common view of the threat landscape.
In Chapter 4, you discuss automated threat modeling. Is that an easier sell for executives compared to hiring multiple developers with threat modeling knowledge?
Tarandach: In security, like in so many other areas, people are constantly looking for the silver bullet that’s going to solve all the problems with one click of the mouse. We are careful in the book to point out that threat modeling is a conceptual exercise. We show how you can automate that process to the extent it’s possible but not beyond that. Without disparaging any other tools out there, we look at the way they operate. We took care to let readers make up their minds on what tool is appropriate for their environment or process.
Coles: For Chapter 4, we wanted to take the threat modeling methodologies from Chapter 3 and introduce the concept of automation to help facilitate a threat model, facilitate information sharing or facilitate threat detection. We weren’t trying to sell any specific tools. We used Pytm as one example because we use it. But we made sure we talked about how there are other tools in the space and how they do different things. Some tools automate data collection, modeling or identification, and they all do it differently. That’s what we wanted to introduce readers to in Chapter 4. It’s not about just providing information, but also providing a launching point for people to do their own research and figure out what works for them.
You explain two approaches to automating threat modeling: threat modeling with code and from code. Does their spot in the SDLC affect which approach development teams choose?
Coles: Yes, because both threat modeling with code and threat modeling from code have different goals. We have to be careful. There’s the approach that the tool stores data versus the tool creates data. We can take a system like Threatspec, where you’re documenting your threats. You have to know what the threats are, and you have to understand the system and the properties. You’re documenting them and use the tool to stitch all that information together — compared to Pytm, for example, where you’re defining your system in code and then the tool generates threat models and diagrams.
Both approaches are valuable. You may have a tool that processes an input language or system description language that then does the same thing Pytm does. It depends on what you’re comfortable using. Pytm requires someone to know how to write the basic object.attribute syntax and use a Python program, which some people have difficulty with. Threatspec, on the other hand, requires someone to use a text editor. They don’t do the same thing, but the approach they take is important for accomplishing a particular task. It’s hard to say which is more effective or more appropriate because it depends on the goal and the comfort level.
Tarandach: Another important distinction to make is where you’re coming from. Threat modeling from code implies that you already have code and a system and that you’re threat modeling. So, it becomes a heavy documentation process: Let’s look at this code, let’s figure out what this code represents, etc. From there, let’s bring out the threats it may be subject to or the mitigations it may be bringing. Whereas threat modeling with code is more like: ‘I’m thinking about this system that’s going to look like this and do this, so now let’s start building this model from scratch and see what threats I may encounter. Then, I’m going to add mitigations to it.’
Coles: Another thing to consider is capability and maturity levels. Some tools are better focused for a security practitioner. For example, Izar and I could use a tool to facilitate a threat modeling conversation with those writing code versus a development team using a results-oriented tool themselves. We provide initial knowledge in the early chapters, but companies still may want to supplement that with automated tools. They can use some of these tools so they can concentrate on applying the principles of threat modeling correctly and not necessarily on the minutiae of running a threat modeling exercise.
Tarandach: That’s a great observation. I think it translates to the tool as part of the process, the tool as part of the conversation or the tool as the facilitator for the process and the conversation.
How has threat modeling progressed over the last few years?
Coles: It’s not new, but it’s not well understood. System developers and designers have been doing threat analysis; they’ve been doing risk analysis and risk assessments. They’ve been doing vulnerability detection. So, the notion of threat modeling is a mature concept. But the maturity of organizations applying it is not, and that’s really a problem.
What’s next for the threat modeling industry as it expands beyond security practitioners?
Coles: As an industry, we’ll start to get some consistency in the language, which will allow us to better penetrate organizations. As developers and others build up that body of knowledge and start doing threat modeling regularly, more and more people enter the conversation. Existing techniques, tools and approaches will get refined, and the ones that don’t yet exist will be created and potentially replace older ones. With improved tools comes greater accessibility. With greater accessibility, you have more individuals doing the activity or more businesses funding and investing in that activity. And, with that, you’ll get better system security, which, ultimately, is the goal is of the activity.
