Mike Goodwin -- The OWASP Threat Dragon

0:05Chris RomeoThe Application Security Podcast. Here we go. Hello again. We're back with another episode of the Application Security Podcast. On this episode, we speak with Mike Goodwin, the founder of the OWASP Threat Dragon. We dive into what the Threat Dragon is and how it can work for you. Enjoy. Hey folks, welcome to this episode of the Application Security Podcast where today Robert and I are joined by Mike Goodwin. And Mike is the project lead for the OWASP Threat Dragon project. And this is a project that I've been following closely for the last number of months and I'm very interested in. So I'm very excited for Mike to be able to share his vision with you here. Mike, welcome to the show and let us know your security origin story. How did you get into security?

1:19Mike GoodwinOkay, well, I am— hi guys, by the way. So I used to be a full-time developer and technical architect for a company that does mainly, or did mainly, on-premise software. And I got involved in a project to migrate one of our quite large products to the Azure cloud in the very early days of Azure, actually. As we got into that, we were basically a bunch of desktop software developers doing our first kind of exploration of online software. And we realized quite quickly that we had to significantly raise the game security-wise because the threat surface was obviously much, much bigger for online than it was for on-premise. So I started an initiative within that project as a subproject to form a virtual team, upscale the development team, and really push forward on security. And that's kind of how I got interested in it. And I got so interested that I became more or less obsessed for quite a long time, particularly around threat modeling and the design side of things. And when the project finished, I was kind of looking around for what to do next. And within the same company, an opportunity came up to move into a full-time security role, building the security capability generally within the company. So I just had a chat with the guy who was recruiting that, liked the sound of it, and obviously he liked me a bit. So I just stepped into that, not looked back since.

2:51Chris RomeoOkay. So your history is more on the development side then, as far as before you got to security?

2:57Mike GoodwinYeah, absolutely.

2:59Chris RomeoOkay, cool. Well, tell us a little bit about this OWASP Threat Dragon. I guess we could start by, if you could just describe what it is and kind of give us a definition, and then I'd love to hear kind of kind of where the idea came from. But let's start by just bringing the audience up to speed. What is OWASP Threat Dragon?

3:18Mike GoodwinOkay, well, first of all, it's open source, as all OWASP projects are, and it's a cross-platform threat modeling tool. So it's designed to work on any platform, be completely free. The emphasis of it is around making it enjoyable to use and simple to use, and also to interact well with the SDLC generally. I mean, during my time kind of learning threat modeling and also working with other teams developing it, I've seen a lot of models which have sort of fallen by the wayside, become sort of dusty documents sat on the shelf and never used. So one of the key aims that I have is to to make it a living thing, so to make the models closer to the developers, you know, continually up to date and relevant to what they're doing. But it's basically a simple enough diagramming tool, it's going to have a powerful intelligent threat generation component to that, and it's going to have a number of features which help with that integration into the development lifecycle.

4:31Chris RomeoOkay, cool. So I got a couple of questions on that, but I'm going to hold them for a second because I want to first understand why did you even start this project? What got you into wanting to solve this problem?

4:45Mike GoodwinOkay. Well, I mean, the comedy answer is I used to hate JavaScript and I wanted a project to make me love it. So I selected Node.

4:54Chris RomeoDo you love it now though, is the question.

4:56Mike GoodwinI do love it. It's my language of choice now. So it's been completely successful from that point of view.

5:01Chris RomeoHow I Learned to Love JavaScript by Mike Goodwin.

5:04Mike GoodwinBut I mean, the real serious answer is, I mean, I had a lot of experience using the Microsoft threat modeling tool, particularly the very early versions of it that were based on Visio. And, you know, I'm very grateful for the guys at Microsoft. I mean, their tool essentially got me into threat modeling in the first place. And so I've got a lot to thank them for. I did find, particularly those early versions of the tools, not particularly great from a user experience point of view. Also, in my company, we work sometimes in Windows but in other platforms as well. So obviously, the Microsoft tools runs only on Windows and is kind of oriented really towards Windows applications. So we found it quite limiting organizationally from that point of view. So that was the aim really, is to try and bring that as a tool that we could use across our organization. But really, I mean, I was guessing that there's plenty of other people must be finding the same kind of limitations that we did. So it was just to try and put forward a tool that anyone can use no matter what platform they're on.

6:16Robert HurlbutYeah.

6:17Chris RomeoAnd so Robert, is your experience the same from the Microsoft Threat Modeling Tool where it's more of a Windows-centric type of tool. What's been your experience from that perspective?

6:30Robert HurlbutYes, definitely it's the Windows-centric tool. I've had experiences where I've worked with a client where they wanted some threat modeling. We talked about tools and they told me, we don't have a single Windows machine in our shop. What can you do for us? At that point, I can't offer the Microsoft Threat Modeling Tool. It's not available. I can certainly suggest, I guess, they run a VM and run it in there, but there's a limitation there. So I found the same thing, that it's a great tool. I've enjoyed using it myself for a number of years, including the most recent version, 2016, with templates and so forth, being able to customize those. But it's a limitation. It's not cross-platform.

7:17Chris RomeoYeah, that's been my experience as well, is it certainly has laid a solid foundation for threat modeling across the industry, but it doesn't do enough stuff for what we actually need it to do. So yeah, Mike, when you were putting this together then, what were some of the— so you talked about some of the design considerations to say you were going to— you wanted to learn JavaScript, you wanted to keep it simple. How does— Well, why don't you walk us through the user flow here? If I'm somebody, a new user, and maybe I know a little bit about threat modeling, What does the user flow look like for me in the OWASP Threat Dragon tool?

7:59Mike GoodwinSo it's easiest if I compare it to the Microsoft tool. So the templates and the stencils that you have in the diagramming part of the Microsoft tool are quite comprehensive. There's a lot of different elements you can put on the diagrams. It's a regular data flow diagram, but kind of enriched with different styles of data store and different styles of external actor and things like that. And I just find that that's quite overwhelming, especially for somebody quite new to threat modeling or new to the tool. So the Threat Dragon approach is really just to boil that down to the fundamentals, so you have just the straightforward types of elements, not really enriched in any particular way, so it's simple to get you drawing your diagrams out, understanding the data flows quickly without having to try and figure out, well, okay, well, what type of a process is this out of the several that might be on offer from the Microsoft tool. The kind of next step after that, and again, I should say that, I mean, the project, I mean, it's still an incubator project in OWASP terms, which means it's quite early stage. But the next stage after the diagramming will be to have the tool suggest some threats to you. Now, again, Microsoft tool and other tools, they do a quite comprehensive job of that, but to me, it's a little— they try actually to do a little bit too much. So one of the visions, I guess, I would have for Threat Dragon is that it emphasizes having the developers and having the threat modelers thinking about the solution and doesn't attempt to give a, you know, a very very comprehensive set of automated threats that are generated, and then they just have to kind of say, okay, well, now I have to implement mitigations for these 17 threats that have generated in a kind of mechanistic way. I really want it to suggest more, somehow more high-level threats, and then have the people, the teams, the threat modeling teams discuss them, kind of critically evaluate them, and figure out for themselves what exactly is the threat, is it real?

10:13Robert HurlbutYeah.

10:15Mike GoodwinHow do we mitigate it without trying to do too much for them? Obviously, that's a quite delicate balance to strike because you run the risk of making it so high-level actually that it's worthless in terms of helping people. But at the same time, I think, you know, I see it as much as anything as an educational tool to get people thinking critically about what threats their applications are facing.

10:36Chris RomeoYeah, and that's the same way I think of this. In previous conversations, I told you about how I've built a threat modeling tool inside a large enterprise, and one of the goals that we had for that tool was we wanted the tool to be obsolete in 5 years. What we meant by that is we wanted the human brains that were using the tool to be able to ingest the idea or the concept of threat modeling so that they would begin to threat model as they were writing design specs or as they were drawing on a whiteboard and scoping out, drawing a new feature. They would begin to do that threat modeling without having to go through a separate step. And so that's one of the things I saw about ThreatDragon that I thought was going in that same vein where it was going to be more simple, which is good from my perspective. I think there's a lot of different tools on the market that are too complex or too specific to a given industry. Threat Dragon's giving you this very— not very— it's giving you a generic approach so that you can model almost anything within the constraints.

11:44Mike GoodwinYeah, that's exactly it. That's the idea. I think more is less. Once you achieve a certain level of sophistication, more is less when it comes to a tool like a threat modeling tool or anything similar really. Yeah.

11:59Chris RomeoI mean, we definitely want to get the human brains in this process working on the threats versus this just being a tool that dumps out a list of all the possible things that could happen and then people just start thinking of them as false positives or something.

12:14Mike GoodwinYeah, totally.

12:15Chris RomeoSo what, I guess, what are the kind of big things? I mean, you talked about a database backend or something that would be driving threats. What else do you see as kind of big things that could assist this tool in really having a big impact inside of an organization?

12:35Mike GoodwinSo I think the developer flow integration is going to be key for me. As I said at the start, I mean, I've seen a lot of models that have been done in a, you know, probably in a kind of waterfall style early in development cycle. Someone, you know, spends quite a few hours or days even putting together a very detailed model, and then, you know, like any document of that type, it quickly becomes obsolete, and it becomes very, very onerous to try and keep it up to date with the way the code's going, especially in iterative, you know, agile type of development methodologies. I think the ability to iterate it fast, to integrate it with the kind of issue tracking system, for example. So in really simplistic terms, if unmitigated threats become issues, then as they close, the threat model is up to date. That's one really simple way of keeping the model tight with the code and close to the code.

13:39Chris RomeoAnd this— in this example, though, you're actually with the alpha, you're pretty well tied into— you've got it tied into GitHub, given— so the concept is that somebody would be able to have threat models that are embedded within their GitHub repository. So the tool allows you to create a threat model and then you store that threat model right next to the code. Is that— am I understanding that correctly?

14:05Mike GoodwinYeah, that's exactly it. I mean, you know, that was partly driven by just a desire to have the application hosted in an extremely cheap way, admittedly. But also, I think it's really important, I think, that it sits close to the code. So my kind of aim is that, you know, I take inspiration from a lot of the CI-type tooling that's around for development generally. So, you know, every time we do a check-in, you know, in many teams, I mean, any number of tools kind of kick into action when a commit happens and do all sorts of different kinds of analysis on the code, you know, styling, dependency checking, all sorts of different things. And my vision for threat modeling and for Threat Dragon is that it does the same kind of job. So again, really simply, it might just say, okay, do you realize you've done this commit, but the last time the threat model was updated was a month ago?

15:00Chris RomeoHmm.

15:01Mike GoodwinThat's something really simple that you could just see in the developer flow, and it would just be a prompt. I mean, arguably, you could make it refuse to do a commit if it's been too long since the threat model was updated. But more sophisticated ways of doing that, you could look at the number of open threats and make it like part of the unit testing. If you have open threats that have remained unmitigated for X amount of time, fail the build. That's the way I think that in agile teams and fast-moving teams that tools stay useful, is by proactively inserting themselves into people's consciousness and not have to not have to have people remember to go and do things with them. The tools that I've enjoyed using as a developer have been the ones which help me in that way.

15:50Chris RomeoYeah, this is a— I love your developer-centric view of this because I think we can all admit DevOps has taken the industry by storm, and slowly over the next 10 years, everything is going to end up in that that style of development. So you have to be thinking about how are we going to integrate and automate to the best degree possible. And so I think you've got a good strategy here because I realize that threat modeling, since it's not really— it's not a scriptable or automatable process from end to end, but I think you've still got the right checkpoints there too so that when somebody checks in code, if it's been like 6 months, I love the fact that it's going to pop up a window and say, Hey, your threat model is greater than 6 months old and you need to take another look at it here. So any other ways you're thinking about automating into the developer kind of workflow here from a ThreatDragon perspective?

16:51Mike GoodwinWell, to be honest, I'm kind of welcoming and looking for feedback from people in real life. I mean, I kind of have plenty of my own ideas, but what I mean, you know, if you ask me what's the most important thing for the project right now, I think it's collaboration, I think. It's been not entirely solo. I've had help and I've had conversations with people, but it's not been used in anger by enough people to allow me to really confidently talk about specific use cases. I mean, one thing I will say that I want to do is generation of reports. So one of the very early prototypes of ThreatDragon had a report generation capability where a little bit like the Microsoft tool again, it would generate you out all the diagrams and list out the different elements on there and the threats which were defined for it in a way which, you know, the idea was you could, I don't know, print it, view it, show it to somebody who wasn't a user of the tool and so on like that. That got dropped at some point during the development, but I think it's a kind of important thing, and I think the The advantage that I'm going to have now with GitHub integration is that I'm going to— the idea is to generate that model rather than as a kind of separate standalone report, but to generate essentially as the README for where the model is stored in GitHub. Or obviously other source code repositories are available, and I kind of look to extend into those as well. Specifically, someone's asked already for Bitbucket. But there are 2 generate the report in Markdown that's linkable to the product itself, because in the tool, all of the threat elements, so that the individual elements of the models are deep linkable. So if you click it in one of the diagrams, the idea is it'll take you straight to the tool with that element selected, and you'll be able to see kind of live in the tool what the context is and start editing straight away if you need to. So again, really streamlining the navigation between those kind of reports, which again can be dust gatherers, really streamline that into the tool itself.

19:02Chris RomeoYeah. And I think the report generation's a good idea. I think that's a— I'm kind of coming at this from more of an enterprise, even though I don't work in an enterprise anymore, but I tend to wear enterprise shaded glasses, I guess, when I when I think of features and capabilities and how would this scale to handle 5,000, 10,000 developers or something like that. So, you know, reporting is something that goes into that process. A lot of bigger enterprises have secure development lifecycles, and they require artifacts to be generated from those lifecycles so that they can prove compliance with their own process and whatnot.

19:44Mike GoodwinMm-hmm.

19:46Chris RomeoThat would— that's one reason to have a report generation feature is because they want to archive it. They might like the fact that it's in the source code repository, but that may not be stamped enough for the audit perspective. So they need something that's kind of more of a concrete deliverable. So I think that's a good— I think that's a good feature that will provide a lot of benefit to many users.

20:07Mike GoodwinI mean, I still have a lot of the code for the actual generation still available. So it's just a question of plugging it back into the new storage.

20:17Robert HurlbutYeah. Yeah.

20:18Chris RomeoSo Robert, you work with a lot of different companies to do threat modeling. If you were an enterprise, what do you think you'd be looking for in, or maybe some of the other customer types that you work with, what do you think they're looking for in this OWASP Threat Dragon style tool?

20:37Robert HurlbutWell, definitely reporting, as you mentioned. I remember working with enterprise where we were using the Microsoft Threat Modeling Tool, and while it does have reports, there are some things that are missing. And so having the ability to customize for that enterprise certain bits of data that they're interested in would be really useful, I think. Beyond that, I think you also mentioned collaboration, you know, being able to pull a lot of those threat models together, verify them, be able to check to make sure that different teams do have a threat model. That's a requirement in some enterprises where every team must have a threat model. Well, hopefully this tool allows you, or a tool like this would allow you to find that out and monitor it, make sure and keep track. Things like that would be really useful, I think, for any enterprise.

21:30Chris RomeoYeah, so what happens from a concurrency perspective right now, Mike? Does the tool handle 2 people kind of working together on a model, or is it just one person at a time?

21:43Mike GoodwinIt uses Git as its backend, so if 2 people were concurrently editing a model, it would be a little bit like 2 people concurrently modifying source code. It's possible, but there might be a kind of manual merge.

21:59Robert HurlbutSo merging the modes. Yeah.

22:03Chris RomeoAnd I think, Robert, you mentioned something else that I've often thought about as— because when you think about how we break down threat modeling, I always advise people, if you can, try to threat model at the feature level for a given product. I've spent a lot of time in the product space. model for a feature because what I'm trying to do is I'm trying to minimize the amount of thinking and interfaces and things that somebody needs to consider there. But one of the challenges that that always brings is how do you take a bunch of threat models together and look at them as a whole, like as a release now? So now I want to look at a threat model of all of the features. And so that's another thing that I'd be that I'd be thinking about for a future tool would be, is there a way to bring together multiple threat models and see like a super threat model where it shows you all of the threats when you put those things together into a system?

23:05Mike GoodwinThat's a really interesting question though, especially if, I mean, so this potential potential complexity there, isn't there, of the— of just the actual kind of representation of, of multiple models, maybe in different diagrams, and some other splicing together of those things. And I wonder whether— yeah, I wonder whether some kind of hierarchical, um, sort of hierarchical modeling capability would be a way to achieve that.

23:34Chris RomeoYeah, something to think about for the future. But I, I think this— I think you're off to a great start right now as far as the foundation that you've laid in the alpha. And so one of the things we'll ask our listeners to do is go check out the tool and give Mike any feedback you have, suggestions, things like that. And we'll get to, I guess, at the end, we'll let you kind of tell people how to get in touch with you. But Robert, did you have any other specific questions you wanted to throw Mike's way about threat modeling in this tool?

24:02Robert HurlbutWell, if I understand correctly, because you're also modeling it after Microsoft's threat modeling tool, you're using STRIDE? to basically think about building out data flow diagrams, that sort of thing. Is that correct?

24:16Mike GoodwinYeah, yeah, that's right. Yeah, you just try just to categorize the threats.

24:20Robert HurlbutOkay. And then as far as somebody who may be completely brand new, they still have to have some basic understanding of threat modeling to be able to use the tool, I'm assuming?

24:29Mike GoodwinYeah, I mean, definitely today. I mean, the threat generation today really is just a stub to kind of prove out the the rule engine library that I was— that I'd selected for the thing. So it just does extremely generic— I mean, so generic as to be not very useful, really— threat generation. So yeah, today I would say that as far as the alpha is concerned, you can do full lifecycle threat modeling, but you're coming up with the threats yourself.

24:56Robert HurlbutOkay, thanks.

25:00Chris RomeoSo what is a What are you thinking of as far as a beta? And how far are we from a 1.0 release of this thing?

25:08Mike GoodwinI think that a beta would be something that involves a genuine threat generation engine. This is probably the main area of my focus at the moment. I just got to the end of developing the kind of installable Electron-based version of the app. Oh yeah, I should say it comes in 2 variants. There's an entirely online version, but there's also for people who— well, that requires you currently to use GitHub for the model storage. I mean, other source control will follow. If people don't have that, you can still get exactly the same threat modeling experience using the installable Electron tool. The difference is that that one just simply uses the local file system for storage, but it will run on, definitely on Windows, which is where it has most of its testing. It runs on Macs, where it's had some testing, and it should run also on other Linux flavors.

26:11Chris RomeoYeah, very cool. So that's the beta then, is the threat generation engine being completed, and a 1.0 then is probably pretty far into the future?

26:24Mike GoodwinWell, hopefully not too far. I mean, I would say that the step from the beta to the 1.0 really will be on key usability features and bug fixing, and then any kind of build-out of the rule engine. But the rule engine, I think, is— it definitely feels like it's going to be an incremental thing. So I don't think there'll be a really hard Okay, well, you must have this rule set before we could consider it a 1.0. It's something which we should be able to extend much more, in a much more continuous way than that. So I think the step from beta to 1.0 would be relatively short, I think. I think certainly the step from 0 to alpha and from alpha to beta are probably bigger than the step from beta to 1.0.

27:17Robert HurlbutYeah.

27:18Chris RomeoOkay, so I guess how can folks get you feedback? What's the best way for folks to get in touch with you? I'm going to challenge all of our listeners to go check out Threat Dragon, and we'll put the link to it and whatnot in the show notes if you haven't seen it yet. But how can they get in touch with you? What's the best way to communicate with you about what they're seeing or features and stuff like that?

27:46Mike GoodwinWell, I mean, the 2 best ways probably, anything which is framed or discrete enough to form an issue on GitHub is the best way just to do that. So if it's a feature, a specific feature request or a bug, GitHub Issues is the right way. It's very easy for me to track those things. But I'd welcome any kind of feedback. I know that some of it doesn't really fit well into the context of an issue. So my OWASP email address, [email protected], is probably the best way to contact me if you want something that's just more of a discussion.

28:22Robert HurlbutOkay.

28:24Chris RomeoAnd are you looking— I mean, if folks wanted to actually collaborate with you, what type of skills do they need to have? Who are you looking for to join the development team? team with you?

28:37Mike GoodwinI'd say there's 2 types really. So on the developer side, the applications, the backend is written in Node. All of the Electron shell obviously is Node and the frontend is written in Angular. So it's JavaScript from top to bottom. So people with JavaScript development skills, very, very welcome. People who are wanting to learn JavaScript, actually, there's a lot of things that can be done on a on an open-source project to help people who are looking to upscale or cross-train into a particular framework. And there's always discrete things that can be done, and I welcome people of all abilities, really, on that side of it. In my experience, open source is a great way to learn those kind of things. On the other side, for people who are more threat modeling practitioners, discussions or suggestions around the rule engine, well, any kind of feature request for one thing, but discussions about the rule engine is, I think, where I'd really, really benefit the most. I mean, that's the kind of thing which I think, and obviously I've done quite a bit of threat modeling over the years, but I think people have different takes on it. And certainly every time I've worked with new people in my sort of day job, I've come across different takes on things and different ways of thinking about it. So anything around how the rule threat generation, the rule engine should work, is something that a non-developer could definitely contribute to.

30:16Chris RomeoVery, very cool. So Mike, I'm a big supporter of this project, and I think you're doing some really cool stuff here, and so we definitely wish you luck as you continue forward. I know I'm gonna be paying very close attention and testing things out and giving you feedback along the way. I'm sure Robert will as well. So thank you for taking the time to introduce this to our audience, and we want to say thank you because you're doing something really cool for the whole industry here. We look forward to the continued work that you're doing on this project. So thank you very much for your time.

30:50Mike GoodwinWell, great. Thanks for having me. It's been really interesting. Thanks.

30:53Chris RomeoThanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Morgan Teejay, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.org.