Jeevan Singh -- Threat modeling based in democracy

0:00Chris RomeoJeevan Singh is a Security Engineer Manager at Segment, where he's embedding security into all aspects of the software development process. Jeevan enjoys building security culture within organizations and educating staff on security best practices. Before life in the security space, Jeevan had a wide variety of development and leadership roles over the past 15 years. Jeevan joins us to speak about self-serve threat modeling at Segment, or threat modeling based in democracy. We discussed their focus with the program, how it fits in their development methodology, and their ultimate goal with threat modeling. We hope you enjoy this conversation with Jeevan Singh.

0:39Robert HurlbutAre you trying to build a security champions program?

0:45Chris RomeoEveryone is these days.

0:47Robert HurlbutOne challenge of rolling out security champions is, how do we educate all these new folks? Security Journey has your answer. We provide a Security Dojo environment with level-based security education that gives your newfound champions a path to follow.

1:02Chris RomeoAnd the best part?

1:03Robert HurlbutIt requires almost zero administration by you. Visit www.securityjourney.com to set up a demo and learn how you can use the Security Dojo to connect with your security champions.

1:16Chris RomeoHey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo, co-host of the podcast and CEO of Security Journey. Robert is on a cross-state tour at the moment, right now on his way to a graduation, so it's just going to be me today, and I'm excited to talk about something that we talk about all the time on the Application Security Podcast, and that is in reference to threat modeling. So, I'm joined today by Jeevan Singh, and we are going to talk about threat modeling based in democracy. Jeevan, we always jump right in. We never give our guests even a second to warm up. We jump right into your security origin story and let you tell our audience, how'd you get into this crazy world about security?

2:18Jeevan SinghFantastic. Thanks for having me, Chris. I'm very excited to be on the podcast. My security origin story, I want to start— I want to say started in university. I had— we all have those sort of friends that don't show up to class all the time. I had one particular friend like that, and one day on my way to school, I was picking him up, and he's like, Jeevan, you got to come in. I got to show you something. And I came in, I looked at— he showed me his computer and he'd been going through and trying to break a bunch of usernames and passwords as part of the university. And he went through, he was able to break about a third, never did anything with the information, but it clicked in my mind. I'm like, what's happening here and how can I prevent My friend from getting my username password at university, and it all sort of rolled from there. From there, I took upper-level engineering course where dealt with a lot of crypto cryptography, and then I picked up the code book. I had the big red book of cryptography as well, and then my first job after graduation was at. domain name registrar and e-commerce site. And it was really early days of the internet. And we were looking through some of the logs and we saw a bunch of requests that were very weird. We're like, how did this individual get all this super secret information? And it sort of sparked a little bit more interest. My next job was at a market research company. They made applications for market research. And anytime we did a pen test, I ran over to the director of engineering, grabbed the pen test from his hands, and I'm like, I'm going to fix all these vulnerabilities. So it just kept on sparking more and more interest. I started doing a little bit more work, security work at that company. And then we had a fantastic VP of security that was like, you know what, why don't we just pull you over on the security team full-time? So, after a couple of days of thinking about it, because I always thought I was going to be a developer and stay down the development path, they pulled me over to the security side. And literally, after the first day, I was like, I'm never going back to development. I love development, but security is security. Within the first day, I was so energized, and every day has been like that since. So, that's sort of where I come from on the security side.

4:58Chris RomeoNow, the question I always ask folks that come from a development background, is any of your code still in production anywhere?

5:07Jeevan SinghTerrifying to think. I suspect a lot of it is still in production. I worked really hard at that market research company to try to deprecate as much of the code that I had written, but I think still some is floating out around there.

5:25Chris RomeoI think that's true for all of us. That's why we're so focused on secure coding now, into the future because we know that there's some remnant of our code that's out there floating around somewhere on the internet, which probably prevents us from sleeping just a little bit once in a while. So, we're going to talk about threat modeling though. And I know you've written this blog post that we'll put in the show notes so that people can have some deeper perspective. But I really want to understand this program that you've built because that's one of the things that was really interesting from my perspective is that you You didn't just come out and say, hey, we got this process, we got this new idea about threat modeling. You've taken all of what you've done and you've built a program around it. And so let's start by introducing this idea of self-serve threat modeling. And I'm really curious as to— well, let's start there. Let's start with what is self-serve threat modeling from your perspective?

6:25Jeevan SinghYeah, from our perspective here at Segment, our goal of self-serve threat modeling is that the security engineering team, the ones that we, the one, the folks that do threat modeling, sort of detach ourselves from the threat modeling process. We really believe that the engineers, the developers that we have are the ones that should be doing the threat modeling. They have the most context on their feature. They may lack a little bit of the security intuition, which we'll teach, but ultimately they write the code, they're the ones that should know where the vulnerabilities are, and they can find them better. So the process is that at some point the security engineering team will— we won't ever do threat models unless we feel that it is important for us to be there, but the vast majority of threat models should be done by the engineering teams themselves.

7:24Chris RomeoSo, certainly, that's the model that I love as well, as far as how do we enable developers, how do we prepare them so that they can go and do these types of things. I think you see some organizations still using the more classic model of saying, hey, security threat models, and then developers have to fix whatever comes out of it. And so, I think the way you've approached this is the way that I recommend that most people do. I'm curious as to what are the challenges that you've seen in trying to push developers towards taking ownership of this threat modeling approach?

8:07Jeevan SinghYeah, I want to say we didn't run into too many challenges. Segment's really bought into security. Our entire executive team, down all the way to the individual contributors, are super hyper-aware that security is important. So when we were selling this idea to the engineering team themselves, so we sold the fact that, listen, it's only going to be a bit of training that you'll need, and it's not even that much. And with, with how fast things are progressing at Segment, we're growing rapidly, security is going to become more and more of a bottleneck, and we don't want that to happen. We want engineering to be enabled. We want to make sure that you maintain your velocity. So if we spend a little bit of time upfront to train you, it's going to save so much time in the future. In addition, we think that once you're trained, you're going to be way better at threat modeling than we are anyway. So not only are you going to be faster, you're going to perform much, much better threat models because you know the code a lot more, you know where the bodies are buried, It's just with us coming in, we look at the thing for an hour or 2, and then we have to come up with a bunch of threats. But whereas you're in there day in and day out, you know how an adversary can potentially take advantage of the flaws in your system. So, it wasn't that much of a sell in order to get engineering on board.

9:36Chris RomeoSo, when the engineering teams start performing a threat model, what are some of the challenges that you see that they let you know about when they first get in to start using this approach that you've given to them? Do they find that they don't have a perspective on some of the base security knowledge? They don't understand the threats. They don't understand how to get to threats. Like, are there any challenges like that, or is the process just really smooth?

10:09Jeevan SinghGotcha. So, yeah, we spent the past year training the engineering team on threat modeling basics and how to threat model. So it's a 3-part course training that we do. The very first part is, is a simple way of just approaching threat modeling. And then the second part is getting your hands a little bit dirty, going through a few exercises. And the third part is that if we have a specific team that we're training, we'll review some of their systems, and we'll actually threat model one of their systems. And in that particular session, we're co-owning it. So one particular engineer will help us set it all up, and then they will describe the system to everyone in attendance, and then we do a deep dive from there. But in addition to that, we're not just saying, hey, Here, you've got it. It's yours now. We don't throw them off the deep end. We want to make sure that— it took me several years to get better at threat modeling. We want to give them that space and that capacity so that they can learn and get better at it. So now that they've been trained, they are leading the threat modeling sessions. Security is still there, but we try to be a little bit more quiet and sort of coach them to finding some vulnerabilities. So if we discover something, we'll give hints and say, hey, think about this sort of attack, or think about this particular weakness in your system. And we'll try getting them to discover those vulnerabilities themselves. And then once we have confidence that they're able to discover all the critical and high vulnerabilities, we'll take a step back and we'll just have them do it without us being in the room.

12:03Robert HurlbutOkay.

12:03Jeevan SinghAnd we'll just review the artifacts and make sure that everything's on board. And once they are able to, at that point, when we're sort of observing the artifacts, if they're able to do the critical, high, and medium vulnerabilities at that point, we don't— we feel that we don't need to be a part of the process anymore. So it's a nice, slow, multi-year project so that we get our developers into a better place and sort of make them mini security engineers.

12:33Chris RomeoJust to recap, to make sure I understand how this flow works, because I love it. I love what I'm hearing here. So, part of the training program for you as a security team is we're working ourselves out of a job when it comes to threat modeling.

12:49Jeevan Singh100%.

12:50Chris RomeoDo you have any formal kind of way that you measure when somebody is ready to move to kind of these— the next phase, all the way to the phase where they're completely out on their own? Is it like a— is it just kind of a gut feeling, or is there a formal methodology that you're using to measure to say this team's ready to fly, push them out of the nest?

13:11Jeevan SinghSo we're in that phase right now where we are taking the backseat. We're still in the threat modeling sessions. And as threat modeling sessions come up, we'll just observe and make sure that that the engineering teams are able to and are capable of doing all the threat models on their own. We're hoping that it's a little bit of gut, but measurable as well, because we want to make sure that they are able to identify all the critical and highs while we're observing them. And if they can do it for a consistent amount of time, at that point, we will take a step back. So, probably going to give it like 3 or 5 threat models in a row that we are not helping them discover any critical or high vulnerabilities. At that point, we will take our step back and let them say that, you know what, you're good enough to do it on your own. Just continue to create the threat modeling tickets and just make sure you attach the artifacts after you've threat modeled.

14:13Chris RomeoSo you mentioned threat modeling tickets. Is that a metric that you're using? Are you managing— not managing to that metric, I hate that idea of managing to a metric. Is that something that you're watching just to see how broad and wide your threat modeling program is operating?

14:32Jeevan SinghYeah, so every time there is— we have a software design document, SDD. Once that's generated, and there are— we give a checklist of security questions, If they answer yes to any of those security questions, the engineering team knows that they need to generate a threat modeling ticket or secure security review ticket, we call it internally. And then at that point, a security engineer will be assigned to the ticket. And we'll, we'll have a once over, make sure everything we should be threat modeling or reviewing this particular design. And we keep track of the— so those are the tickets themselves. And then when we are closing off the ticket, we have a little box that we fill in, a dropdown, to see who actually— what type of threat model was done. Was it security-led, or did security do it completely on their own? Was it security-led? Was it engineering-led? Was security even in the room?

15:40Chris RomeoYeah.

15:41Jeevan SinghAnd did security even look at it? So those are the different type of options that we have. And right now it's mostly been engineering-led just because we're trying to make sure that they are trained in the right fashion for doing the threat models themselves. Hmm.

15:58Chris RomeoSo is Segment operating in a full DevOps mode from a general software delivery perspective?

16:09Jeevan SinghDevOps is a very loaded term.

16:11Chris RomeoI love that answer. I love that answer because I agree 100% with you. That's a very loaded term. I'm just trying to understand what software development methodology you're using so that then I can understand how your threat modeling or where your threat modeling is layered in reference to whether you're doing Agile, whether you're doing DevOps, whether you're doing Kanban, whether you're doing Waterfall. Pretty sure you're not doing waterfall, but I had to throw it in there for all my waterfall fans out there.

16:41Jeevan SinghYeah. So, the engineering team, they own everything end-to-end. We have internal CI/CD tools that help them deploy code to production, but they're responsible for deploying their own systems, measuring, making sure that the uptime is there, things are— the errors, there's not too many great errors. So they completely own that entire end-to-end mechanism for it. We don't have a particular application operations team where they're monitoring and making sure everything— they're not. The individual teams are deploying code themselves rather than having a centralized team that does code deployments.

17:24Chris RomeoSo then does your threat modeling, your self-serve threat modeling, does it fit kind of like somebody gets a— they grab a user story, or there's some user story that's been committed, it's already been approved by product management, and then it undergoes a threat model before anybody starts writing any code? Or is it, you know, kind of— tell me a little bit more about that process, if you would.

17:46Jeevan SinghAbsolutely. So, we try fitting into our security development lifecycle like that. So, product management will come up with a bunch of requirements. We have security folks that will review the requirements to make sure everything is fine. Then it gets switched over to the SDD, the software design document, where the developers, they look at the requirements, come up with a design, have an architecture for it, and then before any— they'll answer the security questions and create the security operational tickets. And before any code is written, it is expected that we threat model. So we really believe that if you can do a security review in the design phase, is the cheapest way to fix vulnerabilities. We're just— no code is being written, no architecture has been deployed to production. So everything is in the design phase. It's very easy and cheap to fix it at that point. But having said that, we still do a lot of retrospective ones, not because individuals had deployed it recently, but older stuff. We want to make sure that we're continuously reviewing older systems, and we— it may not be even looked at it in a year. There might have been smaller changes that weren't threat model worthy, but we want to make sure that we do retrospective threat models just to make sure the state of our systems as well.

19:10Chris RomeoAre those retrospective threat models being done by the engineering team as well, or is that something that you as security are doing?

19:18Jeevan SinghThat's a great question, and yes, we're pushing the engineering teams to lead those sessions. And we're there listening in, helping them find vulnerabilities there. So it's, even though security is wanting to do those retrospective threat models, we still want to have a coachable moment where we're teaching the engineering team how they should be threat modeling. So every opportunity, every interaction that we have with engineering, we want to make sure that they're learning, they're growing, and they're going to be doing security Ken, I think it's worth stopping for just a second and acknowledging this kind of design point that you're specifically putting forth.

20:06Chris RomeoThis is really an industry best practice. Not enough people are doing this the way you are, where they're saying, hey, this is going to be developer-first. We're going to empower and assist our developers in doing threat modeling instead of telling them exactly how everything needs to be. I think right now, in our industry, there's a good amount of tension still between security and dev. And I think the tide is really changing, though. The days of developers saying, we don't care about security, it's kind of becoming more towards security trying to grab on and hold on to what they own, what they're responsible for, what their expertise is. I'm not saying— and your example is the opposite of this model that I'm— But that's what I think a lot of folks are struggling with. is, hey, we're security, we know how to threat model, we do the threat modeling, we give you the results, you flip that model upside down. And I think that's one, it's the only thing that scales, right? Because we know you can't have a security engineer for every developer. Like, imagine how big companies would be. Let's just double our engineering team and that'll be the security people over there. Like, that's just such a crazy idea, it couldn't even be possible. So, I think what you're doing right now is really where everybody in the industry needs to be going towards. And as security people, we got to start being more comfortable going, we're going to let a little bit of this go. How do you— now I've got another question based on that. How do you balance the perfection of a threat model, which we all know there's no such thing as a perfect threat model, but as security people that have done threat modeling for a long time, how do you balance the output that comes from an engineer-led threat model versus what would have come from your threat model? How do you not be annoying? I can't think of another way to say it, but how do you not be annoying to the engineering team as a security person? What are some recommendations you'd have for people that might struggle more in this area?

22:12Jeevan SinghI love that question because the very first engineering-led threat model that I was a part of, It was me and another staff-level engineer. So we joined, we had already reviewed the system, we already had some thoughts, and we were ready to sort of coach the engineering team. So this particular engineer, it was either a staff or principal, and there were a couple of senior folks there. And everything that we had considered was something that they considered as well. And it was such a the opposite of an ego boost. I felt like, what am I even doing here? These engineers are way smarter than me. My goal was to sort of displace me as a threat modeler. Now I felt like I was no use to the company at all because they're so much better. I'm like, oh. So, I don't think the security folks will be annoying. Once you start teaching the development team how to threat model, They're going to be way, way better than you. So you just have to, as a security professional, you just have to prepare yourself that they are going to be better than you. And it's okay if they're better than you because they know their system so much better. So yeah, your ego will definitely be hurt as a part of this process.

23:35Chris RomeoYeah.

23:35Jeevan SinghSo I was not ready for that. But now every time it happens, I'm so excited because the developers will be considering things that I would never even consider. So, it has made the threat models so much more robust, and you don't even get the chance to be annoying.

23:55Chris RomeoAll right, I got a term for you. We're going to call this, it's going to be called the threat modeling gut punch. And it's that moment where you're sitting there in the room, and the engineers are just going back and forth, and they're drawing on the whiteboard, and you're like, trying to raise your hand and nobody, you know, you're off to the side. But that's a good thing from my perspective.

24:17Robert HurlbutIt is.

24:17Chris RomeoThat's always been my goal in threat modeling too, is how do I get myself out of this room in the future and still have awesome things happening? And to your point, like developers, engineers, architects, they know their system, testers, even product managers, they all know their system and their feature 10 times better than I ever will. All I do when I come in the room is I just ask crazy questions that I think I may know the answer to, and a lot of times I don't, just to see what happens. But it's really them. They're the experts in what they build. And so, that's such a powerful concept for them to be able to lead that out. And I love this idea of security taking a backseat because of the threat modeling gut punch that occurred.

25:01Jeevan SinghYeah. So, not only is self-serve threat modeling, it helps you scale, because you don't have to be in every single conversation. It helps the organization go faster because security is not the roadblock anymore. It also produces better threat modeling results. So it is a win-win-win going down this path.

25:21Chris RomeoYeah, that's great. That is great. Okay, so tell me just a tiny bit more about— just a little bit more depth about the training process that you've taken, because A lot of our listeners are going to be people who are trying to roll out threat modeling, and they are probably taking everything in that we're talking about here, thinking about how can I apply this to my program? But one thing I think that they could struggle with would be more on kind of like the training side of what you've been able to do. So tell us in just a little bit, give us a little more depth, but explain it more from the perspective of, hey, pretend I'm somebody who's new to this and I'm trying to build threat modeling in my organization. Like, what would you recommend to me that I do That from a training perspective?

26:10Jeevan SinghYeah, so I'll make a small plug. We have open sourced the training. So if folks want to look at how we're doing training, definitely have a look at Segment's GitHub. The training is in there. And feel free to hit me up if you have any questions. I have my email address in there as well. So what we looked at was we want to train the developers how we sort of learned how to threat model in the past. So we split up the training into 3 parts and we set it up over a 6-week period. So week 0 is you get the first training, it's an hour and a half, and then 3 weeks later we'll have the second training, it's another hour and a half, and 3 weeks later it's a 2-hour training. And we set it up this way because An hour and a half is a long time. There's a lot of information coming at you. We want you to be able to digest it and think about it before the next time you have a next session. And the next session, we'll do a small recap to remind you what we did in the first session. And then it's enough information for you to digest. And again, the third one. So we want to really spread it over time to give people the ability to sort of digest it. The first training just assumes that you don't know anything about threat modeling. And what we do is we explain to folks that, guess what, you're threat modeling today. What we call threat modeling in the security world is really just thinking about personal safety. And the first example that we go through is asking folks how they changed their grocery shopping habits after COVID-19 hit. So we'll ask a random person, they'll volunteer information. Someone may say that, oh, We go at a different time of the day. And I want to dig in. So why do you go at a different time of the day? They're like, okay, there's less people in the grocery store. And I'm like, why is it important that there's less people in the store? And then it sort of clicks at that point. And they're like, oh, the risk of catching COVID is less. And that's what we want them to get at, the risk, the threats. And once that clicks, Then we have a series of exercises that are relatable in human terms and not software terms, and then we slowly make that transition over to the software side. So the first half of the first training is just trying to get you familiar with thinking about risks, thinking, considering threats, and getting you familiar with the threat modeling workflow. And then the second part of the first training is we go through STRIDE, and talk about the various vulnerability classes within STRIDE and sort of map those back to some of the threats that you're thinking when you're going through those personal experiences. That's the first training. The second training, which happens 3 weeks later, is that we do a little recap on what happened in the first training. Then we bring up a couple of different concepts. We talk about assets. And assets are things that you want to protect. And then we relate that back to a data classification standard and data in itself. And then we talk a little bit about infrastructure. But there you have different type of assets, some assets that you think are— it's okay if you don't protect it as much. It's still important that you protect it, but you maybe not put as much effort. And there's company-ending assets as well. So we want to make sure that they identify assets as part of their systems and where they fall into the spectrum. The second new concept that we bring up is diversity and how important it is that you have a diverse set of individuals looking at your threat model. Every single time someone will come up and talk about a threat, a vulnerability, a risk that I never considered. I'm living in my box, and they're coming in with their perspective. So we make it a point to tell the senior engineers, if you notice folks not speaking up as part of the threat modeling exercise, please encourage them to speak, DM them, call them out. But it's really important that everyone gets involved as part of the process, because the more more people that are involved, the more robust your threat model will become. And the last part of the second training is we go through a couple of hands-on exercises because I want them to get used to threat modeling. And they do that. And then we have the third training, which is threat modeling one of their systems and going through that whole exercise so that they're— something familiar, they know where the bodies are buried, so they'll come up with a bunch of threats. So very— a lot of material at you, which is why we split it up into a 6-week period.

31:11Robert HurlbutThat's great.

31:13Chris RomeoAnd for folks out there that are building their own program, I mean, this is gold that was just shared with you here. And to Jeevan's point there, the segment GitHub, we'll put the link in the show notes so you can go and download the training and adapt it for your own perspectives. But that's something that'll give you really a great starting point to get to where kind of where they operate at today, if that's your goal. I want to ask a forward-looking question now. So, let's imagine we're 5 years— I've always wanted a time machine, and it would be the Back to the Future DeLorean, because that's the only real time machine that's ever existed in modern fiction or whatever. But let's say we could travel 5 years into the future. What's success for you as a threat modeling program? 5 years in the future? Like, what are the things that if you're able to look at the program and kind of see where it is, like, what are the things where you're going to be like, we have won, we have victory, we declare victory based on what we see? What are those things?

32:17Jeevan SinghThat's a fantastic question. One of some of the things that we would consider success is that the security engineering is only brought into the hairiest of threat models. So anything we consider a T0 service where we have assets or end-user data that's being processed through our system or authentication authorization system. So those are the only ones that we want to be a part of. Everything else is taken care of on its own. And I hate to say it, but I want to make sure that it's really hard for bug bounty researchers to find vulnerabilities in our system. So hopefully our payout rates for P0s, P1s are something ridiculous. And yeah, so that whoever can find those sort of vulnerabilities, they're going to be very, very happy. But if we start seeing a lot of all those P0, P1, P2s sort of disappear from what we reward to our bug bounties, that'll be an amazing event for us.

33:26Robert HurlbutAwesome.

33:28Chris RomeoAwesome. Well, Jeevan, what would be a key takeaway or call to action that you would want to leave with our audience? We always try to leave folks with, like, one big thing. You can call it homework, you can call it call to action, whatever we want to call it. But what is that for you?

33:44Jeevan SinghYeah, it'd be really understanding who your engineers are. So, figure out who they are, what they care about, and use the training and modify it for your use. Um, our— the training at Segment works great for Segment because we know our engineers very well. We know how to deliver the content to them. Definitely take the content, mash it up, do what you need to do with it. Ask me questions. My email address is part of that GitHub repo. And provide the content as well as you can for your audience. The community has given us so much with respect to Segment. We want to make sure that we can give back to the community. So feel free to do what you need to do with our training. And I'd love to hear stories of how you're delivering it at your organization.

34:39Chris RomeoVery cool. Very, very cool. Jeevan, thank you for taking the time to share the details of the program that you built and answer a lot of different questions about it. I've learned a lot about this new style of approach. I've heard a lot of things that are kind of principles that I agree with and have been trying to do as well, but she also gave me some other things to think about as I'm looking at other threat modeling programs in the future. So, thank you for that, and we look forward to a future conversation about something else cool that you're doing at Segment.

35:10Jeevan SinghSounds exciting. And if you have any questions, my email address is part of the GitHub. You can hit me up at @AskJeevanSingh on Twitter. And the one last plug would be there's a Pacific Northwest conference happening June 19th. OWASP Vancouver, Victoria, and Portland have gotten together and we're going to be announcing our keynotes very shortly. So definitely if your speakers want to hear great AppSec content coming out of the Pacific Northwest, join us there.

35:43Chris RomeoVery good. Thank you.

35:44Robert HurlbutThanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast and on the web at www.securityjourney.com/resources/podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, with application security, there are many paths, but only one destination.