Skip to content
AppSec PodcastThe Application Security Podcast — home
29 min

Izar Tarandach — Command line threat modeling with pytm

With Izar Tarandach

Threat Modeling

What if developers could describe threats in the same place they describe their software? Izar Tarandach introduces pytm, a Python framework that turns a system description into diagrams and a starting list of threats.

Listen

Audio hosted by Buzzsprout. Nothing loads until you press play.

Episode chapters · 14 chapters
  1. 00:00Command line threat modeling with Izar TarandachAudio
  2. 01:10Izar’s security origin storyAudio
  3. 05:26What pytm does and why the team built itAudio
  4. 10:54Where the threat rules come fromAudio
  5. 12:57How developers respond to modeling in codeAudio

About this episode

What if developers could describe threats in the same place they describe their software? Izar Tarandach introduces pytm, a Python framework that turns a system description into diagrams and a starting list of threats. He explains why the team built a command line approach, how element attributes drive threat identification, and why small models belong beside the code they describe. Chris and Izar explore possible CI/CD integration, the knowledge developers need to get started, and the limits of automating a conversation about design. The episode offers a practical starting point: clone the sample model, make its diagram resemble your system, then use that shared picture to discover and discuss the risks automation cannot resolve alone.

The Application Security Podcast is brought to you by Security Journey.

About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
Learn more about Security Journey

Connect with Izar Tarandach:
Izar Tarandach on LinkedIn
OWASP pytm

Resources
pytm source and examples
Microsoft Threat Modeling Tool
Graphviz

Actionable

From this conversation

  1. Describe systems in code with PyTM

    You are describing the system by writing code.

    11:33
  2. Keep threat models small and scoped

    Keep the models small and confined to the pieces of the system that they describe.

    17:06
  3. Start with PyTM's sample model

    I would suggest to clone it from GitHub and start tweaking it and seeing See if you can come up with a data flow diagram that looks like your system.

    25:37
Transcript · 29 min conversation

0:00Chris RomeoHey folks, this is Chris Romeo, CEO of Security Journey and co-host of the Application Security Podcast. On this episode, Robert and I are joined by Izar Terendak. Izar is one of the project leaders for a project called PyTM. And if you've never heard about PyTM, you really gotta listen in here because PyTM is a command line approach to threat modeling that really resonates with developers. So, Please take a listen, and we hope you enjoy. This episode of the Application Security Podcast is brought to you by Security Journey. Security Journey has a new weekly publication called High Five, 5 security articles that are worth your time. We scour the internet looking for the best articles on application and product security. We add in just a touch of sarcasm and snark in our descriptions, just what security people and developers love. To sign up, visit www.securityjourney.com. www.securityjourney.com/highfive.

1:06Izar TarandachThat's /hi, the number 5.

1:10Chris RomeoThe Application Security Podcast. Here we go. It's going to be a surprise, but we're going to talk about a topic that we're pretty passionate about and that we've talked about a lot. But that's okay because there's a lot of innovative things that are happening in the world of threat modeling. And so, we're joined here today by Isar. And Izhar, we always start this podcast off by asking people, what is your security origin story? If there was a comic book about your path into security, what does episode 1 look like?

2:12Izar TarandachSo first of all, thank you for having me here. It's great to talk about this threat modeling thing that apparently all of us like. I think that if I looked at the first page of that comic book, there would be, the iconic image of some kids hunched on the keyboard. That would be an Apple II. Later on, university times, different place, different time, and I had the luck of running with a really, really cool pack of smart people. And one of the things that they liked to play with was security. And it was more of a hey, look at this cool thing that we found here, or this thing that everybody's talking about. And this was the '90s, and over time it just brushed off. And I think that I just naturally branched in that direction. So over, I think, the last 20-something years, I've seen basically almost every facet of security out there— networking, application security, Whatever you can think of.

3:19Chris RomeoAnd so you're— when you kind of started your professional career, did you start on the network security side and kind of make your way through, or where did you— where— what's kind of your origin on the security as a job thing?

3:31Izar TarandachSo I started at the Hebrew University of Jerusalem. Even before I was a student there, I started working at the system programmers group for the computer science department. And part of what I was doing there was managing the Usenet feed and all that stuff.

3:50Chris RomeoOh, I miss Usenet. I miss that.

3:53Izar TarandachAnd I think that that was my first brush with actual formal security and access control and all that stuff.

4:00Chris RomeoSo would you identify yourself as a developer? Are you somebody that came to security from the developer side of the world, or would you say you're kind of coming more from the admin or network side?

4:13Izar TarandachI would say that I started in the admin, in the system group in there. We did a lot of Unix admin stuff, and eventually I went back to the developer side and basically stayed there, always with an eye on security. So I worked on Guardio, that was an SQL firewall, and I worked on a scanner called HackerShield. back in the day. So, it was always development work with an eye on security tools or some aspect of security. So, I always stayed close enough to that space, to the point that at some time I looked around and I noticed that I was what's called a security engineer or security architect and just naturally fell in the role.

5:01Chris RomeoYeah. Now, is any of the code that you wrote still in production somewhere?

5:06Izar TarandachI think that SQL Guardian still has one or two lines of mine. I guess that's probably the only thing that's out there that's relatively well known that still has something of mine.

5:26Chris RomeoYeah. So, that's great. You kind of came from both sides of the house, from the admin. You had admin experience and developer experience, which It's kind of like the, the really, a really nice combo as we make our way through. Well, hey, thanks for sharing that, that origin story with us. And I want to switch gears and talk about the primary thing that we're, that we're kind of here to talk about, and that is this tool that you work on and develop called PyTM. And so let's start by just, you know, give me just the basic introduction to what is PyTM?

6:04Izar TarandachSo PyTM is first of all the, the fruit of the collaboration of 4 people, not only me. There's also Matthew Coles, Nicholas Moore, and Rohit Shambhoni. And at some point in the not so distant past, we, the 4 of us, worked at Dell EMC at the product security office, and in different capacities we, we were able to observe the the lack of some kind of tooling that would help product teams work on their threat models. Eventually we got to use the Microsoft tool, the Microsoft Threat Modeling tool, and we all recognize the value of the tool. It's really great for some aspects of work, but unfortunately we were in an environment where the product teams themselves were so different and Perhaps inside the product teams themselves, you have somebody working on the Windows part of the product, somebody working on the Unix part, and having a tool that was so heavily dependent not only on a specific operating system, but also on having— at the time, you needed a Visi license to use it, and so on and so forth. And it was something that many programmers, they they had a bit of a difficulty working on a GUI, like working on something that's basically Visio-based and you go putting boxes and connecting them. Many of them saw that as time not very well spent. And there wasn't at the time any provision, I think there still isn't any provision for people to share models in a way. So at some point, Dell EMC had a chance of helping Microsoft or working with Microsoft. I'm not quite sure what the relationship there was, but we could do some changes to the tool that would adapt it more or less to the way that we did threat modeling at WNC. And it was clear that there was a need for a tool like that, a need for something that would let people rapidly put down the characteristics of the system and get back a list of the possible threats to that system based on those characteristics. So the 4 of us started talking about how we could make that something more accessible and something more extensible, and we got to this idea that ended up being PyTM, which is basically a library written in Python that gives out elements and produces some form of output based on the attributes of those elements, of those objects. So the whole philosophy of the thing is to have a small tool that does a couple of small things well done, but at the same time permits you to keep all the information that you need to describe your CAD model close to the code so that developers will be able to do it. And the input is itself code so that a developer doesn't have to get out of their comfort zone to develop that input that eventually will generate the threat model. So the capabilities that we have today with PyTM, you write your Python description of the system, and by that you import a couple of basic elements that we provide. Server, an actor, or data flow, and a couple more. And then you set attributes on those elements, and at the end you call the library, you call an entry point in the library, and depending on what you put on the command line for that script that you just wrote, you're going to get different kinds of output. So today we can generate data flow diagrams that get interpreted by Graphviz via DOT and give you a flow diagram. Or the same input can generate a sequential diagram if you are just modeling a protocol, and then you're able to look at it that way with exactly the same inputs. We can also— we have a very basic template language that lets you create formats for reports that we're going to use so that we have one format that always comes back, and we can talk more about that later on. And today we have 31 threats based on those elements, on the attributes of those threats that we already look at. But the important thing here is that the threats are defined with Boolean expressions based on the attributes of the elements.

10:54Chris RomeoWhere did those come from, those 31 threats? Is those things that you and the team kind of put together yourself, or is there another source?

11:01Izar TarandachUh, no, some of them we put, uh, put up ourselves. Some of them we actually inherited from things that we saw in the, uh, Microsoft tool. Okay, so we, we said that we had to have minimally the same coverage as we had in there.

11:15Chris RomeoSo Stride, are we talking about Stride in general?

11:18Izar TarandachWe're talking about Stride, but the threats appear as specific things in, in the elements.

11:25Chris RomeoGot it.

11:25Izar TarandachSo they are a manifestation of Stride, but Stride doesn't appear as a methodology on top of the thing.

11:32Chris RomeoOkay.

11:33Izar TarandachSo what you end up with is a list of threats on top of the elements that you defined, and they are basically not— you don't get any peek behind the process of how you— how the tool came to them. But they live in a separate file in JSON, and you can just go and define new threats or you can ignore those. We have a flag to ignore those that you consider not important for you so that you can eliminate false positives and things like that. The important thing to keep in mind here is that one of the reasons why we choose the— we chose the input to be a Python script is that at the end of the day, you can describe a system based on its attributes without really considering that you that you are writing Python. Anybody who with any experience or knowledge of object-oriented languages will immediately recognize that for what it is. You are creating a new object and then you are saying, well, this object, the OS is such and such. It's hardened, true or false. So it becomes a very clear and natural description of a system for a developer. They don't have to learn a new language. They don't have to learn a new syntax. You are describing the system just by writing code.

12:57Chris RomeoSo, this is definitely a new approach to threat modeling in that you're giving developers an opportunity to operate in the code at the code level. What's the response that you hear from people as far as their kind of approach? Like, is this well received? Do developers just love it? How much work is it for them to learn the constructs of this library?

13:22Izar TarandachIt's been very well received because basically you get some kind of result, perhaps not the optimal result, but some kind of result right off of the bat as soon as you start defining your elements. The difficulty today, and this is going to sound, I guess, very well known for everybody, is that we don't have good documentation. So in order to figure out what are the attributes of each one of the, uh, the possible elements, you have to actually write a skeleton script using PyTM and call it asking, hey, what are the attributes that could exist in this particular element? And then you go and you continue writing your code with those specific elements. So we are looking at ways to to making that more user-friendly. But for you to have an idea, one way that we have been very successful in using it is in that initial encounter with the product team when we sit down to discuss the system that's going to be modeled. We find ourselves writing code as we discuss so that at the end of the discussion, you can already hand out a DFD and they are able to look at it and say, well, yes, that looks like my system.

14:34Chris RomeoMm-hmm.

14:35Izar TarandachSo you are able to build that first draft very quick. and only then start putting the attributes on it. And once you have the attributes in place, then you can start generating threads.

14:47Chris RomeoSo are developers that are using this, are they keeping their— this PyTM, their Python file that uses a library, are they keeping that right in their source repository right next to their source code?

14:59Izar TarandachYeah.

14:59Chris RomeoSo it becomes a living document then, or a living process. versus a one-time thing.

15:06Izar TarandachYes, and that's basically the final state that we wanted to achieve with this, to have developers treat the threat model description the way that they treat their code and to go back there and update it every time that they update their code on one side. And to be able to, since it's just basically a script that runs, to be able to include that into the CI/CD and have the reports coming out and the threat models coming out together with each new iteration of the building system.

15:38Chris RomeoSo, I guess that's fascinating. I want to dive deeper into that last statement you just made about embedding this in the CI/CD pipeline. So, how does that work then? Is it— are you saying that As— so, you make it part of the pipeline so that as developers are adding new things, so is there like a master Python TM file that developers are adding new pieces to so that whenever the CI/CD kind of runs, it's going to potentially identify new threats? And is there like a break the build? Are you going for a break the build approach when you think about this from a DevOps perspective?

16:21Izar TarandachSure. We have had discussions in that space, and especially when we look around at other projects that are out there, and you have already spoken about those in your podcast, and we're talking about ThreatSpec and Threat Playbook. Those are great sources of inspiration. We can look at what they're doing and learn a lot from that. And because basically you're writing Python in here, nothing stops you from turning something that you would write the value of an attribute in place. So if it's hardened true or false, there's nothing stopping you from actually writing something that will go and check if it's hardened yes or no and then come back with a result.

17:05Hmm.

17:06Izar TarandachSo in that sense, we have had these discussions. We don't have anybody that I know of right now using it this way. But it is one of the future directions that we have looked at. Now, in terms of integrating it, what I have seen and what I have suggested to people to do is to keep the models small and confined to the pieces of the system that they actually describe. So instead of building one big thing and maintaining that thing, then just have small descriptions per module or per system or per element of your actual developed system. So keep the thing in place.

17:48Chris RomeoSo a series of small threat models that describe each of the individual pieces or features of the system versus having one master Python file that's got everything and it's 5,000 lines long. Is that what you're saying?

18:02Izar TarandachYes. And I think that the One of the offshoots of doing it that way is that if you notice that there starts to be a drift between the last time that that model was touched and the source code being touched, you could come and say, hey, there might be some problem here because the threat model is not being updated, which is one of the big challenges that we see with threat modeling, that it's done in the beginning and then the system changes a lot and it doesn't describe the system anymore. So, now we have a chance to at least have a bit of an idea if the description is going together with the development of the system.

18:43Chris RomeoSo, how much knowledge are you seeing that a developer has to have to actually use this? Do they have to know anything about security to use this or can they be— so, how are you abstracting them away from security knowledge? in doing this?

19:00Izar TarandachBy adding the, the attributes. And again, we do have a problem with documentation. It's one of the PRs that we have open. But, uh, by just adding the attributes, they should be able to say, I did this or I didn't do this, or at least start an exploration of what is it that they mean by these attributes being true. And, uh, we have to be very honest here and say that the threats that those 31 threats that currently we look at, they are low-hanging fruit. They are not exactly some crazy logic or discovery or something. But the point is that by moving that low-hanging fruit to something automated, we hope to be freeing the developers to think at higher levels, deeper levels of the system, and start finding those threats that are not immediately apparent from a description.

19:53Chris RomeoSo do you see this— so does PyTM, from a programmatic perspective, does PyTM work together with the whiteboard? Are these 2 things that we're kind of 2 different methods we're using for threat modeling, one for the easy stuff and one for the harder stuff?

20:07Izar TarandachI think that one of the good things that come from PyTM is that it can substitute the whiteboard in a sense in creating the diagrams and giving visibility to the system and the description of the system.

20:21Okay.

20:22Izar TarandachI don't see it completely replacing the whiteboard, especially because we need that view of the system to discuss those things that are more complicated or less dependent on the nature of each one of the elements and more important on the way that they interact with each other. But we have had good experiences with people using it to look at data flow diagrams and sequential diagrams. And coming out with findings, or at least being able to start the dialogue that leads to good findings.

20:55Chris RomeoSo any thoughts of a GUI kind of front end, web-based front end to this, or do you want to stay true to your command line roots in this tool?

21:04Izar TarandachWe are talking about something like that, but always, at least my personal view, I don't speak for the 4 of us here, My personal view is that we should, uh, whatever GUI goes on top of this should be creating, if not Python code, at least some JSON that we can translate back to that, so that at some point those people who don't want to work with a GUI, which apparently are some, a good number of them, they do have the capability of still looking at that system as a description in code.

21:40Chris RomeoOkay, so you want to keep the compatibility between the two equal so that it's— your GUI is always spitting out the same code that you would have gotten if you would have put it together manually.

21:51Izar TarandachYes. At the end of the day, if it's through the library itself by ingesting JSON and coming out as Python, or if we write a converter or something like that that does that work, I would like to keep the nature of PyTM as a Python library that uses Python code.

22:12Chris RomeoZara, I have a question regarding that in terms of Python versus maybe other languages.

22:18Izar TarandachI mean, essentially, are you requiring someone to be programming in Python to be able to use this? Is there a possibility if they're writing .NET, Java, or any other kind of language to be able to use this, or would it have to be translated into another library in order to use something along these lines or similar to this? So if we look at the basic description of a threat model, of a system, if we don't go into all the discussion about calling other things and checking other things, at the end of the day, what you need for a bare-bones threat model in here is 3 lines of Python. One is an import, then you create a TM object, and then you call tm.process. In the middle of that creation of the TM object and calling tm.process, you're going to just basically create objects and give them attributes. So there's no logic, there's no syntax that would be too strange for anybody familiar with C++, JavaScript, or anything. Perhaps you work in a language that separates between the object and the attribute with an arrow or something like that, and that would become a dot. But apart from that, any programmer would be able to look at it and recognize it for what it is, which is an object and its attributes. So I don't think that it would be too, too much to say that anybody with programming, any kind of programming experience, would be able to jump into this pretty quick.

23:55Chris RomeoYeah, that's definitely a great, great feature that I really love about this project as I'm learning more more and more about it here is that you're meeting developers where they are and you're meeting them and interacting with them in the way that they think versus security coming to them and saying, here's the tool and here's how you use it. And so, I think that's really— I think you're very wise to have met them where they are because they already want to argue with you about what we're going to do, what the plan is, right? We all work with developers. Maybe we are developers, so we know we can be difficult people sometimes. So yeah, it's good. Give them something where they are. What developer doesn't want to be in the code? I mean, come on, that's where they live.

24:36Izar TarandachAt the end of the day, I think that threat modeling is already something that some people approach with a certain amount of caution. And I think that if we are able to remove as many bumps in the road to actually having a threat model that you can look at and discuss and get to findings, together as a team, I think that any bump that we can remove is a good thing.

25:00Chris RomeoAgreed.

25:01Izar TarandachSo bringing developers into the room and all of a sudden, you know, they don't have to understand UML symbology or some specific language or something like that. At the end of the day, the dialogue becomes clear and everybody's looking at the same picture and it's a picture that everybody recognizes as the system. I think that we all win.

25:21Chris RomeoSo how do you recommend somebody get started? with PyTM? If let's say some of the people that are listening to this, they're not doing any threat modeling right now, they're part of a dev team, what are— what's kind of the, the getting started guidance that you would give them?

25:37Izar TarandachSo together with the library, of course, we have a sample threat model. I would suggest to just clone it from GitHub and start tweaking it and seeing See if you can come up with a data flow diagram that actually looks like your system. Once you can recognize that those boxes and arrows actually represent your system, then you should look into learning what the attributes for each one of the elements are, start finding the correct values from them, and only then go and produce a report, a full report, and see what threats the system comes up with.

26:16Okay.

26:16Izar Tarandachwith. And then the loop is change the attributes, find the threats, fix the threats, change the attributes, see what else comes up.

26:25Chris RomeoSo where does somebody go then to learn more about PyTM and things that, you know, they could be just trying to get into it and trying to find all the stuff you've written about it? Where do we find that?

26:40Izar TarandachSo we are on GitHub. The repository is izar/pytm. That's the one place to go and get it. We are not creating any sites or anything for it right now.

26:58Chris RomeoYeah, I mean, it's a command line tool. I wouldn't expect a website for a command line tool.

27:03Izar TarandachRight. I mean, we could go and get a nifty logo and whatnot, but no. And we are trying to keep the discussion happening there as well.

27:12Chris RomeoOkay, so using the GitHub discussion forum.

27:14Izar TarandachYeah, and some of us hang in the O* modeling channel, which is, apart from PyPM, apart from anything else, an extremely valuable resource. A lot of knowledgeable people in there to discuss, and there's always somebody ready with a suggestion if you need, or a pointer. So we try to hang in there, and we are more than happy to get requests, get bugs, get suggestions. That's what we're looking for.

27:43Chris RomeoGreat. Well, thanks, Yizar, for taking the time today to educate us and our audience about PyTM. And I'm sure you're going to get some additional downloads as a result of this, as people feel, you know, that may not have heard about it figure out, hey, there's a command line way to meet devs where they are with threat modeling. And so thank you to you and the team also for working on this project and, and making it kind of a passion to bring that command line perspective here. We definitely appreciate it as we can recommend it to other people. So thank you very much.

28:14Izar TarandachAnd thank you guys for helping make threat modeling a more popular practice and for giving everybody so many pointers and so much information on it.

28:25Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor favor and visit the iTunes Store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org.

4,546 words · transcript by assemblyai

More on Threat Modeling

View all episodes →

Get Reasonable AppSec: new episodes and useful picks from the archive.