---
title: "Abhay Bhargav -- Threat Modeling as Code"
url: https://appsecpodcast.com/abhay-bhargav-threat-modeling-as-code/
date: 2018-10-23
duration_seconds: 1685
guests: ["Abhay Bhargav"]
topics: ["Threat Modeling", "Security Testing", "DevSecOps and CI/CD", "Conferences and Community"]
audio: https://www.buzzsprout.com/1730684/episodes/8122667-abhay-bhargav-threat-modeling-as-code.mp3
transcript: true
---

# Abhay Bhargav -- Threat Modeling as Code

*October 23, 2018 · 28 min*

with [Abhay Bhargav](https://appsecpodcast.com/guests/abhay-bhargav/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [Security Testing](https://appsecpodcast.com/topics/security-testing/), [DevSecOps and CI/CD](https://appsecpodcast.com/topics/devsecops/), [Conferences and Community](https://appsecpodcast.com/topics/conferences-and-community/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122667-abhay-bhargav-threat-modeling-as-code.mp3)

## Show notes

A threat model that lives in an old document rarely keeps pace with the code it describes. Abhay Bhargav explains how threat modeling as code can connect user stories, abuse cases, threat scenarios, and specific controls inside an evolving development process. He describes choosing YAML as a familiar format, compares that approach with behavior-driven specifications, and shows how the result can help both engineering teams and security testers. The conversation introduces Threat Playbook and explores turning concrete mitigations into an attack model and useful testing direction. Abhay also discusses the challenge of automating tools with different interfaces, including ZAP and nodejsscan. The episode makes the case for keeping threat information actionable, versionable, and close to the people building the application.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Abhay Bhargav:  
→ [Abhay Bhargav on LinkedIn](https://www.linkedin.com/in/abhaybhargav/)  
→ [we45](https://www.we45.com/)

Mentioned in this episode:  
→ [Threat Playbook](https://github.com/we45/ThreatPlaybook)  
→ [ZAP](https://www.zaproxy.org/)  
→ [nodejsscan](https://github.com/ajinabraham/nodejsscan)

Chapters:  
00:00 Threat modeling as code with Abhay Bhargav  
01:51 Early work in PCI and security  
03:37 Why traditional threat models become stale  
06:48 From user stories to abuse cases and threats  
08:32 Integrating the model into development  
09:16 YAML specifications and alternative approaches  
11:23 Benefits for DevOps and security teams  
14:13 Attack models and specific mitigations  
17:26 Introducing Threat Playbook  
20:40 The challenge of automated security pipelines  
22:54 Python and tool choices  
23:26 ZAP, nodejsscan, and npm audit  
26:37 Sharing the workshop materials

## Transcript

*4,971 words · assemblyai*

**0:00 Chris Romeo:** Welcome back to the Application Security Podcast. On season 4, episode 13, we talked to Abhay Bhargav about threat modeling as code. He explains how it can help you get more out of a threat model. Enjoy.

**0:10 Abhay Bhargav:** The Application Security Podcast. Here we go. Welcome, friends. We're here in season 4 of AppSec Podcast, Application Security Podcast. And today I'm joined by Abhay Bhargav. I hope I pronounced that correctly. Welcome.

**0:57 Chris Romeo:** Yes, you did. Thank you. Thank you, Robert. Thanks for having me.

**1:01 Abhay Bhargav:** Absolutely. Tell me about you. Tell the listeners who you are and, uh, you know, what you're doing in application security.

**1:08 Chris Romeo:** Sure. Um, so I actually, um, have been in application security for a while now. I've been in application security since 2010, uh, and I've been largely working— I started off in the pen testing side of things largely. But over time, I really started focusing a little bit more on continuous application security testing, threat modeling, and so on. So yeah, that's my journey in application security per se. But yeah, I used to be in PCI before application security. I used to be a PCI auditor. So my start in security really came from there. But after that, it kind of moved into application security only.

**1:51 Abhay Bhargav:** Okay. So in terms of PCI, I mean, what were you doing? Just looking for PCI compliance and verifying companies or customers to verify that they have PCI compliance?

**2:05 Chris Romeo:** Yes, I used to be working for a QSAC. So we used to work with clients all over the world to validate and certify against PCI compliance. So that was where I got my start in security. Uh, so I was working for a PCI company and I started off in security that way. And I used to delve deeper and deeper into different areas, but application security caught my fancy the most.

**2:29 Abhay Bhargav:** Okay. And what about, I know I've been familiar with PCI. I remember actually as a developer, I worked on quite a few applications where we had to be PCI compliant. What about it in particular that attracted you?

**2:42 Chris Romeo:** Actually, that was where I got my start. To be honest, I didn't really, uh, uh, it was not that it was by design. So I used to, I was actually, I qualified as a CPA. And as soon as I qualified, I realized I wanted nothing to do with finance. So that's why I wanted a career that would kind of bridge my audit skills along with IT, because I was already proficient with programming and stuff. So I was always interested in IT, but somehow, you know, I got into CPA. And at the time, once I finished my CPA, I wanted something in security because it was a, I felt it was a good bridge between audit and which I already knew from finance, and then with IT. So that's where I got into this side of the fence. So I spoke to a company that was doing PCI and they said, you know what, come on board, let's get started. And that's where I started off in PCI really.

**3:37 Abhay Bhargav:** Okay, great. And so now fast forward a little bit. So what you're talking about lately is threat modeling as code. So Tell us about that.

**3:48 Chris Romeo:** Sure. So this really is actually a bunch of experiences that I've had, as well as conversations that I'm sure you've been a part of in the industry as well, especially earlier this year at AppSec Cali. It was a pretty big set of events focused around threat modeling. So that really caught my attention in this space. Of course, I used to do threat modeling before, and I constantly saw a standard set of issues emerge from a threat modeling process. For instance, whenever I used to go and meet with a customer or talk to a client, I used to ask them, hey, do you guys do threat modeling? And they invariably said yes. But when you actually get down to it, I realized that their threat modeling was done like an enterprise policy document, like an enterprise risk assessment style thing. So they would typically do it once in 2 years or 3 years. It would not be updated for a very long time. I would also see that a lot of this used to be diagrams and a lot of Visio and stuff like that, but not really a very good understanding of the actual threats. It wouldn't really boil down to the threats very well. So that's something I noticed as well. And earlier this year at AppSec Cali, I had a chance to look at some great talks and hear some very— some people in the industry really get into threat modeling in a very meaningful way. One of you, one of them is you, of course. I think we had a discussion as well as Brooke and Adam's, you know, discussion on the shared stage as well as some other talks. I think Jonathan Marcel's talk on threat modeling, that was really interesting to me, and he had created this threat modeling toolkit. So at that time, obviously I've been involved in DevSecOps for about 2 years now, and automation has always been my jam, so to speak. So I've always tried to automate stuff, especially with tools. I've done a lot of automation with DAST, SAST, a little bit of IAST, and a little bit of RASP even. I've done a lot of automation for clients in different spheres of application security. So this got me thinking, why not make threat modeling a playbook-style thing? So one of the things I always felt about threat modeling when I did it was that it's like a playbook for your applications. It's like a set of plays, or it's a set of things that are always changing. It's always evolving. It's always going through, you know, an evolution of sorts. So it needs to have some level of that flavor built in, you know, a playbook-style flavor. So that is where threat modeling as code kind of evolved. It's not a new concept, to be honest. There are people who have done it before as well, but I just envisioned it differently. I kind of created something like a playbook where I said, I call this threat playbook, and I created some of the components around threat modeling as code. and tried to see how we can incorporate this as code so that you can iteratively threat model. You can introduce automations into it. You can do a lot of, you know, iteration as well as automation as part of the whole threat modeling process.

**6:48 Abhay Bhargav:** Okay. So help me understand a little bit more. Let's dig into a little bit more. So tell me, in this, your approach, what is a threat model essentially then?

**7:02 Chris Romeo:** Right. So one of the things that I was seeing and I felt would be great from a threat modeling perspective is trying to integrate it into existing concepts and paradigms that we're all used to, right? For instance, user stories is something that we're all used to in a Scrum or Agile team. These are concepts that all of us are familiar with. So I thought we could take some of these concepts like a user story or a functionality description and use that as the basis for threat modeling. So, a user story would lead to an abuser story in which we would talk about how that user story could be made evil. So, that would be just an evil version of the user story. So, if I could make a payment, the abuser story could be the adversary could intercept that payment or the adversary could intercept my credit card information or whatever. That would be a high-level abuser story.

**7:56 Abhay Bhargav:** Okay.

**7:56 Chris Romeo:** And then it actually comes down to threat scenarios where we say that, hey, this abuser story can come to life through these scenarios. I could do a SQL injection attack, I could do MITM, man-in-the-middle, I could sniff the traffic, I could do XYZ, I could do a whole bunch of attacks in order to perform this. And from there you derive your controls. So what I felt was that this would be a very easy way of integrating with existing paradigms like user stories that people already know and use and make that part of the ever-evolving product development lifecycle. So that's where So that's where the threat modeling part of it comes into play in my approach.

**8:32 Abhay Bhargav:** So your parts of your threat model really are integrated then into the user stories, it sounds like.

**8:38 Chris Romeo:** Yes, it is. A lot of it is. Yeah. It's one way of doing things. It's not the only way. It's, you can directly get into the scenario or directly start capturing the threats as user stories or something like that and get into it. But I just felt that it would be easier for people to understand it this way.

**8:58 Abhay Bhargav:** Okay, and then in terms of code, you say threat modeling as code, so do you have code snippets? I mean, you also said it's a playbook, so are you putting into place, yeah, code examples, things like that? Is that part of how this works, or how it would look to, let's say, a developer or a team member?

**9:16 Chris Romeo:** Sure, one of the things that I've seen, 2, 3 different versions of something like what I've done. In fact, there's one from Fraser Scott, and I think there are 2 other projects that do threat modeling as code. One of it is a BDD, behavior style definition, where you give a scenario for each threat model. So each threat model is created as a scenario. And the other one is you just capture it as code, where you capture it as descriptions within code. What I went for was that I felt that a lot of things that were spec-like were getting very popular, right? For instance, Kubernetes. uses YAML to define the specification and it deploys your containers using the specification you define in YAML. Same thing with Ansible. If you look at most of these infrastructure as code or container orchestration, a lot of these products today use YAML to write out the spec. So, the user can write out the spec in YAML and then load it through a particular engine and that engine would do the things in that spec. So, my goal was to do kind of the same thing. So, create a bunch of YAML specs that would define your threat models, and that YAML spec would be run as part of an engine, and that threat model would be captured in the database. Diagrams would be automatically generated, and if you need, automations could be triggered off through those threat model descriptions that you have as well.

**10:41 Abhay Bhargav:** After the break, Abhay describes some ways that people can use threat modeling as code in DevOps. The Application Security Podcast operates with support from Security Journey. A security belt program provides the 3 pillars of successful AppSec training: learning, application, and experience. Visit us on the web at www.securityjourney.com to learn how you can teach and empower your developers using a new kind of security training. Abhay dives back in with some ways DevOps can use threat modeling as code.

**11:23 Chris Romeo:** Oh yes, that was the idea. There are 2 major goals to this. One was on the DevOps side and one was for the security side. I'll talk about— although they look the same or they should be the same, I feel that there are different viewpoints to look at this. On the DevOps side, I do believe that if you provide a way to capture this information in an easy, more code-like way with YAML, especially YAML being a very popular way of doing things with most DevOps implementations, I felt that it would become a lot more user-friendly for an engineering team or a DevOps team to take this and move on from there and use this iteratively throughout their software development lifecycle. What I found with the other ways, especially with BDD and others, is that they're very test-focused. They're scenario-based. I felt that maybe it would be— obviously, each of these approaches have positives and negatives, but I felt something that people already understand in terms of YAML specifications would be something that DevOps engineers or engineering itself can take on. My ultimate goal for this would be Hey, you run an engineering team. Your engineering team, with maybe some inputs from security subject matter experts, should be able to create threat models and should be able to iterate through the threat models. Also reuse the threat models. One of the big challenges is to not always have to create original threat models because a lot of it may not have to be original. You could be able to reuse a lot of these models and scenarios elsewhere. For instance, you have another piece of that feature that you're bringing out. you should be able to reuse some of these models for you to be able to, you know, get that faster or get that thing moving as quickly as possible before you get bogged down by just the threat modeling process. The other viewpoint that I had for this was for pentesters, and that's weird because pentesters are not really— a lot of them don't threat model, right? So pentesters, what I feel, at least what we do in our organization, is that whenever we get an app that we need to pentest, We threat model the app. So we threat model it from more an attack perspective where we say that, okay, this is what the app is doing, this is the risk to the app, this is what we need to chase after when we are pen testing, and this is how— this is what we use to pen test. So the other viewpoint that I also have for this tool or this framework is that a pen tester can use this to make her life easier, to make her threat— her pen test a lot more effective and efficient. as well as more data-driven. One of the big questions that a lot of us get, get asked in the pentesting side is, hey, what have you tested? Or what have you tested against? And that sometimes becomes a little difficult to answer, and this I'm hoping would address that challenge.

**14:13 Abhay Bhargav:** Okay, great. Yeah, I was just looking at one of your articles written about this, and it mentions an ATT&CK model for security testers. So that's what you're talking about, is helping them build out ATT&CK models to help them with their testing? Is that correct?

**14:28** Yes.

**14:29 Abhay Bhargav:** Okay.

**14:29 Chris Romeo:** That's correct.

**14:30 Abhay Bhargav:** And then I also noticed another term which is very interesting to me is mitigation models. And so that's, that's for the devs, architects, and DevOps folks. So tell me about that. That's, that's a really interesting term, mitigation model.

**14:41 Chris Romeo:** Right. Um, now one of the things that, uh, again, this came out from, uh, my— some of the frustrations that I used to have with threat modeling where the mitigations used to be very generic. Okay, implement encryption at the transmission between the networks that data is being transmitted. Something very generic and high-level most of the time. This would be the case in a lot of threat models that I used to see. One of the reasons I feel that when you do it as code or when you do it as a specification, especially when you're sitting with the developers and the architects, they tend to give you very specific ways in which they can address this challenge. For instance, encryption, they would say that I would do it this way with probably this, and this would probably make it much easier to do or much more secure. Or we would do a content security, we would design a content security policy this way to make sure that scripts are, you know, our frames are not loaded from this particular source. So what I felt was that each of these are models in themselves, just like we have an ATT&CK model where we say that I'm going to fire Burp at this to find OS command injection, or I'm going to do a TPL map to find template injection. Developers and architects and security architects come up with very granular solutions if they're given the right platform to do so. So that's the idea of the mitigation model where we say, hey, you know what, uh, we have these flaws, we have these threats that we've captured, we are probably not addressing this, but these are the specific steps for mitigation that we would take to address this. So that's what I mean by that.

**16:17 Abhay Bhargav:** Okay, great. So I know that, you know, we're recording here, and you mentioned that we did meet at AppSec Cali, which is one of my favorite conferences, especially as you mentioned, it focuses on threat modeling. It seems to anyway. When I first went a couple years ago, that's where I was able to meet several others who were in threat modeling, and so it seems to be a great place, and they certainly foster a lot of good talks and so forth. So we met there, which I was glad to because I think a couple other times we've sort of passed where we're presenting at the same time. I think we did that at AppSec USA and so on. So it was good to catch up.

**16:58 Chris Romeo:** Yes.

**16:59 Abhay Bhargav:** But speaking of conferences, I know we're speaking here actually in the middle of summer, right before the security summer camp, as they call it, Black Hat, DEF CON. So the timing may be a little off in terms of when this comes out in our season 4, but tell me about Black Hat and DEF CON. I know you've got a couple things going on at both of those. So at Black Hat, you've got Threat Playbook. Tell me about that.

**17:26 Chris Romeo:** Right. So one of the things that, I mean, I was fortunate enough to be selected for both these events, so I'm very thrilled. This is my second time at DEF CON. Last year I presented a workshop, this year I'm doing another workshop, so I'm super thrilled and excited to be there soon. So Black Hat is— I'm going to be presenting Threat Playbook at the Arsenal. So a colleague of mine and me, we're going to be at the Arsenal demo lounge area where we'll be talking about threat modeling as code, especially this framework called Threat Playbook. And by the way, the listeners listening in can download this. It's open source. It's available to you to use, and you can use it. And please let us know if you have any feedback. But Black Hat is going to be where we'll be kind of unveiling this for the first time. We'll be talking about how this works, how you can work with this, the different examples, and we'll also be doing a lot of demos. So we have a lot of preset demos that we have already prepared, like We have some intentionally vulnerable applications that have specific business logic, and we'll be showcasing how you can do threat modeling as well as application security automation. So the idea is you can go right from threat modeling to running a SAST, a DAST, a source composition scanner, as well as generating reports. You can run a complete security pipeline from the start to the finish with Threat Playbook. So that's what we want to showcase. in Black Hat Arsenal. And that's what we hope to, you know, put out there to the audience to say that, hey, use this and please let us know how you can use it, how you're using it, and how we can improve and add to this as well. Because it's open source, we're looking for contributors as well. DEF CON, I'm going to be presenting a workshop on security automation, which is one of my favorite subjects in the world. I'll be talking about something called Robot Framework. It's why, in fact, Robot Framework is the engine that drives Threat Playbook as well. It's a test framework which is very popular in the QA world, in the testing world, but not so popular in the security side of things because it's kind of unknown. So I'll be talking about how you can build out these security pipelines or pen test pipelines as well as the threat modeling piece at DEF CON as a workshop, as a 4-hour workshop as well.

**19:46 Abhay Bhargav:** Okay, great. For our listeners, if they've not been to Black Hat, Arsenal, as was mentioned, is a demo, essentially a demo area, I guess. You go there and they have different stations that you can go to, just move from station to station and see what somebody is trying to demo and try to help you understand how it works and hope that you get interested in it, either free tools or paid tools or other tools. Just to get you interested in taking a look at it. And so it's, yeah, it's been interesting. I like going to the arsenal and checking out the various security tools and see what's there. So congratulations on getting there.

**20:26 Chris Romeo:** Thank you.

**20:27 Abhay Bhargav:** As far as the workshop, 4-hour workshop, tell me about that. What are you helping people understand in the workshop on automation and tools they're using and so forth?

**20:39** Sure.

**20:40 Chris Romeo:** Yeah, so the focus of the workshop is to create automated pipelines. Now, there are major challenges. While automation, the need for automation is kind of established, I think everybody understands that they need to do automation in order to scale security initiatives. But a lot of times automation is hard because you have different tools. Let's say you have a DAST, a SAST, a static code analysis tool, a dynamic assessment tool, or a source composition scanner, whatever, cloud security assessment tool. The problem with this is that each of these tools have different APIs or different ways of being automated, or some of them are more difficult to automate or less difficult to automate depending. So one of the big challenges that I have faced when I started off in automation was how do we get this working on a single platform so that we can create a pipeline? And pipelines are hard. Ask any organization that tries to do security in the pipeline and they'll find it a lot of them have a lot of horror stories to tell because tools are difficult to work with a lot of times. So what I hit upon a while ago was this Robot Framework, which is a generic test framework, and it's really, really powerful. You can write your own API pretty quickly. You can get started, and you can use the existing APIs that you have in order to automate a lot of these tasks. We ourselves have developed a lot of open-source API for OWASP ZAP, Node.js scan, Breakman scanner, most of the open source tools you would have in the application security world, my company would have probably written an open source robot framework library for it. So, the idea is to get the security pipeline working on a single fabric. So, you don't need to have a combination of various technologies and code integrations happening. All of this would be on a single pipeline run as an independent autonomous pipeline. So our idea is to talk about this at the workshop and we'll teach the participants. Of course, we do this for other workshops as well. I'm doing this in a bunch of other trainings as well, but this is a 4-hour insight into how you can do this for yourself and get started with automation for your own organization or for your own academic project, if you will.

**22:54 Abhay Bhargav:** Okay, great. And what tools of choice do you use, Python or some other tools?

**23:01 Chris Romeo:** Most of our automation is in Python. It's simply because Python— most of the security tools have either a Python API or are already authored in Python. So that's the reason why Python is our platform of choice. But that's not necessarily the case all the time. For instance, some great tools out there are in Ruby or something else, but typically give us some kind of API to work with.

**23:25** Yeah.

**23:26 Chris Romeo:** The tools we'll be using in this workshop are going to be OWASP ZAP, which is my number one favorite for testing applications, and it's probably got the best API in the business. Although it's not Python, it's Java, but it has the best API in the business. It's really great. The amount of granularity you can achieve with ZAP's API is mind-boggling compared to most other tools in the market, even the more commercial ones. We are also going to be using Node.js Scan, which is a great tool. It's actually built— I think it's not— it's been built by a security researcher named Ajin Abraham. It's an open-source tool as well. It's a great tool. We'll be using it against a Node.js application, which is the example, but that's a great tool as well. We're also going to be using npm audit, which is a new feature from the Node Package Manager company, which is— what they do is— and this is a great concept that they have— as soon as developers need to install a third-party library, it would tell you what kind of security issues are in that third-party library. So, it kind of gives you that immediate feedback as to the security issues with that third-party library and even deep inside. So, let us say you have a third-party library that has a dependency that has a dependency and that dependency has a vulnerability, this would be able to find it and this would be able to flag that up. And this is free, available to anyone using Node.js in their code. So, that's going to be one of the tools we're going to be using. We're also going to be using Nmap in a completely automated way, which is— Nmap is always popular, and we are going to be using the RoboNmap version to do the automation. We're going to be using another slightly less known directory brute forcing tool called WFuzz to do certain directory brute forcing and fuzzing tasks. And we'll also be using TestSSL to do some SSL testing as well. So we have a bunch of tools planned as well as threat playbook that will bind all of this together, and also from a threat modeling perspective.

**25:23 Abhay Bhargav:** Wow. That sounds fantastic.

**25:25 Chris Romeo:** Thank you.

**25:26 Abhay Bhargav:** I wish I was able to go. Unfortunately, I will not be able to this year, but everyone who is able to, certainly it sounds like a fantastic workshop, and so I'm sure it'll go well. But thanks for, you know, taking us through the list of tools. A lot of those, it sounds like a lot of those are open source or available. We'll make sure that for our listeners, so we'll have some links to some of the the materials. I know certainly to the Threat Playbook and others, so that if anybody would like to follow up, if they unfortunately missed the workshop and like to maybe ask some questions, they can certainly get in touch and get some more information. But thank you for that. I appreciate it, especially in terms of security automation. I mean, that's— I know as a developer for a long time, you know, we talk about in terms of DevOps and how do we automate some of the testing and other kinds of things or development activities, but, you know, being able to automate a lot of the security activities as well and knowing what the tools are that are out there and how to use them and so on, I think it's going to be extremely useful. And so that should be a good workshop.

**26:37 Chris Romeo:** Yes, I am looking forward to it, and I'm sure that we'll have a lot of fun with the trainees, and I'll definitely put out more materials on the workshop. Since it's DEF CON, I would like to share it with the rest of the community as well. So you guys can, the listeners can take advantage of all the exercises that we're doing there as well.

**26:56 Abhay Bhargav:** Fantastic. Okay, Abhi, thanks for joining us. If there are any last words or comments you'd like to give to our listeners today?

**27:05 Chris Romeo:** Yeah, I mean, largely I would say that definitely look at automating things because security can only be scaled with a lot of the automation. And I think, at least from my perspective, believe that threat modeling is one of those things that needs to be there. It needs to be iterative and it needs to be integrated with your development lifecycle.

**27:30 Abhay Bhargav:** Absolutely. Well, thanks again and appreciate the opportunity.

**27:35 Chris Romeo:** Thank you so much. Thanks for having me. It was great.

**27:37** Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a 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.

---

Source: https://appsecpodcast.com/abhay-bhargav-threat-modeling-as-code/