---
title: "Stephen de Vries -- Threat Modeling with a bit of #Startup"
url: https://appsecpodcast.com/stephen-de-vries-threat-modeling-with-a-bit-of-startup/
date: 2018-08-20
duration_seconds: 1334
guests: ["Stephen de Vries"]
topics: ["Threat Modeling", "OWASP Projects", "Secure Development"]
audio: https://www.buzzsprout.com/1730684/episodes/8122676-stephen-de-vries-threat-modeling-with-a-bit-of-startup.mp3
transcript: true
---

# Stephen de Vries -- Threat Modeling with a bit of #Startup

*August 20, 2018 · 22 min*

with [Stephen de Vries](https://appsecpodcast.com/guests/stephen-de-vries/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [OWASP Projects](https://appsecpodcast.com/topics/owasp-projects/), [Secure Development](https://appsecpodcast.com/topics/secure-development/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122676-stephen-de-vries-threat-modeling-with-a-bit-of-startup.mp3)

## Show notes

What developers need from a threat model is often a clear set of requirements they can implement. Stephen de Vries explains how that perspective shaped IriusRisk and his move from security consulting into building a product company. He and Chris discuss reusable threats and countermeasures, the role of OWASP ASVS, and the need to translate guidance into instructions that make sense in an issue tracker. They also examine why spreadsheets and separate security systems create friction, and how existing testing and design habits can provide a bridge into security. Stephen’s startup experience frames a broader conversation about making threat modeling repeatable: reuse what is known, focus human attention on the difficult parts, and meet developers inside their normal workflow.

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 Stephen de Vries:  
→ [Stephen de Vries on LinkedIn](https://www.linkedin.com/in/stephen-de-vries-4185a8/)  
→ [IriusRisk](https://www.iriusrisk.com/)

Mentioned in this episode:  
→ [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/)  
→ [OWASP Proactive Controls](https://top10proactive.owasp.org/)  
→ [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)

Chapters:  
00:00 Threat modeling and startup lessons with Stephen de Vries  
00:34 Stephen’s development and security background  
05:01 Starting a security product company  
06:35 From building a product to building a company  
07:48 Threat modeling as a route to security requirements  
10:41 Reusing common threats and countermeasures  
12:00 Connecting requirements management and threat modeling  
13:43 Turning ASVS into actionable developer guidance  
14:16 Meeting developers in their existing tools  
15:33 Removing spreadsheet and email friction  
17:00 Building on testing and design habits  
18:41 Connecting everyday risk thinking to security  
20:06 Behavior-driven testing and useful OWASP resources

## Transcript

*3,756 words · assemblyai*

**0:00 Chris Romeo:** Hey folks, welcome to this episode of the Application Security Podcast. On this episode, I, Chris, was at AppSecEU and I had a chance to sit down with Stephen DeVries from Continuum Security. In this interview, we talk about how Stephen got into security. We talk about the intersection of requirements and threat modeling as Stephen sees it and how he's brought it out into the products that his company produces. And we also get into a little bit of startups and cybersecurity, application security-focused startups, and some of the other details there. So we hope you enjoy.

**0:34 Robert Hurlbut:** The Application Security Podcast. Here we go. All right, this is Chris, and I'm joining you from AppSec EU in the— what appears to be the vendor area, which is why we're getting a little bit of some background noise, but we'll call it some good ambiance here. I'm joined today by Stephen from IRIS Risk, and Stephen, we always ask our guests. First question, what is your security origin story? How did you get into the world of security?

**1:32 Stephen de Vries:** Awesome, thanks, Chris. So my origin story really started when I moved into— from programming, fixing Y2K bugs in banks, to installing firewalls. So I came very much from a development background, then started getting interested into infrastructure, you know, Unix boxes, firewalls, adminning systems, and so on. And so when AppSec started actually becoming a thing was when I realized, you know, this is my place in the world. This is where I can use my development experience as well as my interest in security to help people and help companies build secure software.

**2:10 Robert Hurlbut:** Okay, so what languages were you— so I guess don't even tell me COBOL.

**2:16 Stephen de Vries:** Not that far back. How old do you think I am?

**2:19 Robert Hurlbut:** Well, you said Y2K, so.

**2:21 Stephen de Vries:** So I started off in C, C++. I did some Delphi as well, Pascal. and Delphi.

**2:28 Robert Hurlbut:** Wait, now how old are you?

**2:29 Chris Romeo:** And Java.

**2:31 Robert Hurlbut:** Visual Pascal. I mean, a lot of people are gonna have to look on Wikipedia to see what that actually is.

**2:36 Stephen de Vries:** And actually, you know, one of the turning points I thought would be interesting for the listeners is when I was doing lots of pen testing work and application security work, and I had this interview with a customer where they did this crazy thing where they knew we were going to do a pen test on a new app they were going to build, and 6 months down the line. So they said, well, let's get the security testers in, let's get the development company we've outsourced in, and let's all sit around and discuss what is going to be tested in 6 months' time. And that for me was like a lightning bolt moment because I went through the list of all of the things we were going to test and I would tell the implementation team, right, so we're going to test that your user account is locked out after 3 incorrect attempts. And the developer team would say, well, we're not going to build that. And the customer will say, well, why aren't you going to build that? And they would say, well, because you didn't tell us to build that, right? So it became, as we're going through these questions, it became really obvious that the problem here is not so much widgets and fancy new security gadgets that they needed. They just needed clear communication about what they needed to build to build a secure application.

**3:52 Robert Hurlbut:** Hmm.

**3:53 Stephen de Vries:** And that was kind of the moment for me when I thought, yeah, this is a problem space that needs a solution. We've obviously built a commercial solution, but there are other ways that you can tackle this type of problem space to help people build and design applications securely from the start.

**4:12 Robert Hurlbut:** So you kind of flipped this whole thing upside down. You did what a lot of people are trying to do right now in the whole shift-left movement. Let's move everything And so you got an example of that from a full-on development project. A lot of times people talk about shift left and it's security people talking about how do we move things further. But that's a great example of where you had developers, testers, everybody kind of coming together. And so yeah, that's definitely the way we need to go.

**4:39 Stephen de Vries:** Yeah, and I think it's kind of the— that was probably the first example of a real DevSecOps or SecDevOps type of approach, which is, you know, get people talking together, get everybody in the same room so that they understand what is it we need to do who needs to do what, and are we going to be happy with the level of risk that we have at the end of this exercise?

**5:01 Robert Hurlbut:** Yeah, so how'd you get into starting your own company then to do this stuff?

**5:04 Stephen de Vries:** Yeah, so it was, you know, well, it's a long story. I did some— I was doing consultancy, so lots of testing work and, you know, general how do I— how can I help companies build a secure SDLC. And out of that, I realized I wanted to build a product. You know, that was kind of my dream. And essentially the company was found, was bootstrapped by doing consultancy part-time and building the product the rest of the time. And as we kind of gained traction and sold some licenses to some really interesting customers, we then were able to say, okay, this is now our full-time business. And then we left the consultancy business and now we're 100% doing product.

**5:50 Robert Hurlbut:** Yeah, that's a great— that's an inspiration for me because I'm in the same same kind of place. And I think, you know, we're— this is a security podcast, but we're jumping into the world of startups and things. But everybody thinks you have to go out and you have to get some— I have to get somebody to give me a check for $200,000 or I can't have a company.

**6:08 Chris Romeo:** Yeah.

**6:09 Robert Hurlbut:** I think the example you have is the same example I'm following in. Let's go out and we'll do consulting just to keep— to feed our families and everything and pay the bills. And then build a product and develop that product without taking money from anybody else. I don't know about you, but it gives me a lot of flexibility because I don't have anybody telling me what to do right now as far as like, you have to do this, this is your new plan. No, it's just me. I can make those decisions.

**6:35 Stephen de Vries:** So we bootstrapped for about 2 years, and then last year we did raise some private equity from a VC, from 3 VC funds. And it has been a change for us. So it has been a change from building a product to building a company. And they are different things. And it's— maybe we're getting off track on the security subject here.

**7:02 Robert Hurlbut:** It's an interesting story.

**7:03 Stephen de Vries:** Yeah, so it's been great for many things because suddenly you have the ability to spend the resources that you previously didn't have.

**7:14 Robert Hurlbut:** Yeah.

**7:14 Stephen de Vries:** So, now we can invest in a great dev team, we can invest in great security analysts to build the content for the platform, and we can come to OWASP events and so on. So, those abilities are great. And at the same time, the VCs certainly have a lot to offer in terms of advice about how do you run a business, how do you scale a business. And for me as a technology person, that's not something I'm intimately familiar with. So that kind of advice is really useful.

**7:48 Robert Hurlbut:** Yeah, yeah. So let's transition now and talk a little bit about the problem space that you're working in, because I think the problem space of how do we do threat modeling in a more— just in a better and more repeatable kind of approach and making it easier for developers I think that's a problem that a lot of people in AppSec are dealing with right now. Everybody will agree threat modeling is important. You're not going to find anybody at this AppSecEU conference that's going to debate that topic. Well, maybe it's OWASP, so maybe one or two. But in general, everybody's going to agree that, yeah, threat modeling is important. Now, that's when there's a lot of different approaches and things. There are some people that say whiteboard only. There are some people that say tools. So what is the problem space? How did you come at this problem? What was the problem you were trying to solve?

**8:38 Stephen de Vries:** So I came at this from, I think, from a reverse point of view. I said what developers actually need is a list of security requirements, which are functional and non-functional requirements, that they need to implement to build a secure application. So in my mind, if there were some magic box that you could consult and it would just automatically tell you these are the set of requirements you need to build into your application. For me, that box is fulfilling the same role as threat modeling. So I really view threat modeling as a means to an end, not as an end in itself.

**9:15 Robert Hurlbut:** Okay.

**9:17 Stephen de Vries:** And right now there are, you know, a few different ways that you can get at this box at a really kind of a low-friction low-cost way, and one of them is the OWASP ASVS. So I think the ASVS project is an extremely valuable OWASP resource that can be used to get developers starting building secure code, right? So the problem with ASVS is it's a single standard with 3 levels that tells you this is how you build secure web apps and this is how you build secure mobile apps.

**9:55 Robert Hurlbut:** Yeah.

**9:55 Stephen de Vries:** It obviously tries to cast as wide a net as possible to cover the majority of apps in the world, which means a little bit of extra work for your developers to figure out what is relevant to me and what isn't relevant to me. But it's a great start because it already gives you a list that you can start off with and you can start saying, well, okay, I know how we should implement single-factor authentication. I know how password reset should be done.

**10:21 Robert Hurlbut:** all those things that are crazy to reinvent, even though a lot of places they go back and everybody's reinventing the same things versus using something like ASVS, which is a solid set of requirements that if you implement to those, you don't have to think about how to do, like you said, single-factor or password management or all the things that ASVS really excels at documenting.

**10:41 Stephen de Vries:** Exactly. And there's aspects to threat modeling which I think the majority of people who are interested in threat modeling are smart people who like to solve difficult problems. So naturally they gravitate towards, you know, let's first look at this extremely complex business logic in our application and threat model that and come out with all the threats and how we're going to mitigate those threats. But there's a huge part of threat modeling which is boring, you know. It's templated stuff. It's cookie-cutter threats and countermeasures that apply to web apps that apply to how you're going to deploy to the cloud. And that stuff really doesn't need to be threat modeled more than once. You do it once, you stick it in a template, or you take it from the OWASP ASVS, and that's content that you can reuse on every project that's using that technology.

**11:33 Chris Romeo:** Mm-hmm.

**11:34 Stephen de Vries:** So I think, you know, I enjoy that part of the problem space, which is the scalability part, rather than how can we hire 1,000 smart people to model 1,000 different applications, why don't we break it down and say, can we use a set of common templates, decompose our application, find the commonalities, and let's just use a standard set of templates for all of that.

**12:00 Robert Hurlbut:** And so is that how you're approaching the problem then, is to take the requirements management side and the threat modeling side and bring those together?

**12:11 Stephen de Vries:** Exactly, exactly. So I think there's a What ASVS gives you in terms of security requirements, it's lacking the step before that, which is the threat or the risk that that countermeasure is mitigating. So ASVS will tell you do X, but it won't tell you what happens if you don't do X.

**12:32 Robert Hurlbut:** Mm-hmm.

**12:33 Stephen de Vries:** And if you wanted to know that from a security team perspective, now that's something that you can create as an extension to ASVS. So you almost extend ASVS and say, we've got a map of a threat model for all web applications that tells us if we don't do these countermeasures, these are the threats we're going to be exposed to. And we can make an appropriate decision there about whether we actually do want to mitigate that threat or not.

**13:00 Chris Romeo:** After the break, Stephen gets into ASVS and how that fits into Arius Risk. 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. Let's hear from Stephen now about how Aereus Risk implements ASVS and how these 2 things commingle together.

**13:43 Stephen de Vries:** Definitely. So we've used ASVS as the base, uh, for a lot of the countermeasures that we have, uh, within the, the, the product. Um, and we've also extended it. So ASVS is like a single-line, uh, description of what you need to do. Okay. Um, we need to give developers more advice than that. So we've We've extended ASVS by giving more details about how do you actually do this. And our criteria is if this content is going to appear on somebody's issue tracker in their project, is it going to make sense to them?

**14:16 Robert Hurlbut:** So you're talking to the developer themselves, not the security people?

**14:19 Stephen de Vries:** No, exactly, it's to the developers. For the security team, they can view the threats, they can view what are the countermeasures, have things been implemented, haven't they been implemented, have weaknesses been tested, haven't they been tested. So they have a dashboard to view all of that, and ultimately the developers can continue working in the issue tracking systems.

**14:41 Robert Hurlbut:** Okay.

**14:42 Stephen de Vries:** Which I think is one of the key things to this DevSecOps, SecDevOps type of philosophy, right? You know, be low friction and make it easy for developers. So where possible, work in their systems. Don't try and force them into using security tools.

**14:59 Robert Hurlbut:** And I think that's one of the challenges that have happened in the requirements management tool space, because there's been tools in that area for quite some time, and they've always been about making people operate inside of another system. So it's never— it's not in JIRA, it's not in You know, the places where the issue tracking systems and things. So yeah, so I think that's a big thing is to be where the developers are. Don't drag them into something new. Operate where they are is a wise approach.

**15:33 Stephen de Vries:** And the worst culprit here is email and Excel. Security teams who have checklists in Excel that email them out, you know, send me back your checklist, let me know what has been done and hasn't, and so on. It's just adding more friction to the process. And I've spoken to heads of security in financial institutions, and, you know, a common theme is we as security really need to adapt to the speed of development because it's no longer a question of how much security we're asking for. It's a question of if we don't give them an easy way to implement security in their dev processes, they're just going to skip us. They're going to do whatever they need to do to get that application live, and if security is not something that's accessible and easy to use, then forget it.

**16:24 Robert Hurlbut:** Yeah, that's, you know, I've seen that perspective as well, and I think for too many years security groups have been on the opposite side of that saying it's about us, it's and about everybody— developers, you need to march to what we're telling you to do. And so that sounds like some of the people that you're working with now are very wise to be thinking, okay, let's flip this back around and say it's really about the developer. Let's meet them where they are and operate inside of their process versus trying to lump something on top of the way we want to see things done.

**17:00 Stephen de Vries:** Exactly. And I think the easy thing, or the easy way to approach this is that there are a lot of activities that are going on in development at the moment that are extremely similar to what we want to do in security.

**17:14 Robert Hurlbut:** Yeah.

**17:14 Stephen de Vries:** Developers are already writing unit tests and integration tests for the functional aspects. You know, why aren't they writing security tests? I had a great talk earlier with Stuart Gunter from Equal Experts who came by the booth, and he was saying that he believes that developers are already doing threat modeling even though they don't know it. Because they're doing threat modeling for performance, right? They want to build a performance system, and they know that if they don't have high availability, if they don't have multiple availability zones, that something can go wrong and their system can go down. And, you know, that's a form of threat modeling. It's just that they're not applying it to an intelligent attacker actually trying to break into your system.

**17:55 Robert Hurlbut:** Yeah, that's a great way to think about it as a bridge between between the modern developer who we always think of as not very security savvy to begin with. I had a friend of mine who came up with this illustration. His name is Tony Vargas. I can't steal it. If I steal it a few more times, it'll be mine type of thing. But he always, when we'd start a class on threat modeling, he'd always say, okay, everybody in the room here that knows how to threat model, raise your hand. Nobody's hand would go up in the beginning. And he'd say, Okay, well, let me give you this example. You step out the front door with your, with your child, and all of a sudden you hear the noise of cars going past really fast, and you hear a dog barking off in the distance, and the sun's beating down. What are you doing inside of your head?

**18:40 Chris Romeo:** You're threat modeling.

**18:41 Robert Hurlbut:** You hear the dog, you're like, there's a threat, there's a chance that dog could come after us. So you're keeping an eye, you're not gonna let your kid run out in the street. Yes. So you're already His point was everybody threat models. It's just we have to tap into that same type of perspective that we have. I think that's in the same vein here, this idea of threat modeling for performance. Now I guess the question is how do we tap into that? How do we tap into the fact that folks already know about that and get them to threat model for security using the same process in their brain about performance?

**19:14 Stephen de Vries:** That's right. They're intimately familiar with with performance, and the challenge is now educating them about the possible ways that an intelligent attacker can elevate privilege in their system or gain access to data that they shouldn't have access to. Yeah, and I think, you know, there are a lot of interesting OWASP projects that can help with that, that are kind of good stepping stones. One of them which is really interesting is the OWASP Cloud Security Project.

**19:43 Robert Hurlbut:** Okay, that's a relatively new one too.

**19:45 Stephen de Vries:** Yeah, that's very new, and they're using BDD-style specs and tests to write threat models for cloud architectures. So they're mixing in a few concepts there, but by using BDD, it's a given-when-then type of syntax.

**20:06 Robert Hurlbut:** Which is behavior-driven development, right?

**20:09 Stephen de Vries:** That's right, yeah, behavior-driven development.

**20:10 Robert Hurlbut:** So it's writing your test, it's a test-driven Primarily it's a language for writing test procedures and things, and so they're extending that now into the world of threat model.

**20:20 Stephen de Vries:** Exactly, yeah. And they're kind of extending the way you use the syntax to try and express a threat and also to express the set of countermeasures that you want to implement to mitigate those threats. So it's a really interesting project, and of course the nice thing about it is that all of those specs are not just documents, they're actually executable. So you write the spec, you write some code behind it, and your spec is self-executing and self-verifying.

**20:49 Robert Hurlbut:** Got it.

**20:50 Stephen de Vries:** Which is the great advantage of that. And ASVS, the active, the proactive controls, also a great resource to kind of get people thinking from the perspective of an of an attacker. And of course the OWASP Testing Guide, which is great for QA testers and people who are experienced in testing for strange behavior. And, you know, testing guides can just give them that perspective of this is not just strange behavior, this is behavior introduced by someone who's actively looking to break your application.

**21:24 Robert Hurlbut:** Yeah, yeah, and that's a good list of projects for people to take a look at as they're thinking more about this problem. problem space and everything. So Stephen, thank you for taking the time today to introduce us to kind of some new ideas, new thoughts about threat modeling, and we'll be sure to put some, some things in the show notes where people can find more information about you. So thank you very much.

**21:47 Stephen de Vries:** It's been a pleasure, Chris. Thank you.

**21:49 Robert Hurlbut:** 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/stephen-de-vries-threat-modeling-with-a-bit-of-startup/