Apr 21, 2023

Understanding Threat Modeling with Jeevan Singh

Host: Hi, everyone. Thanks for tuning into another episode of Scale to Zero. I’m Purusottam co-founder and CTO of Cloudanix. For today’s episode, we’ll be focusing on threat modeling, how it should be used, what are the benefits of it, what are the challenges of it, and some areas around culture as well. To discuss on these topics, we have gone saying with us. Jivan is the Director of Product Security at Twilio, where he is sort of embedding security into all aspects of software development process. He’s responsible for architecting security solutions, working with development teams to resolve security vulnerabilities, and building out security features in the products.

He enjoys building a security culture within organizations and educating the staff on security best practices. Jeevan, it’s wonderful to have you here. Thank you so much for taking your time and joining us today.

Jeevan: Thank you for inviting me. I’m really excited to have more conversations around threat modeling. I think it’s somewhat not as popular as it should be in the industry.

Host: Yeah, it’s a pleasure to have you here. So the way we do the recording is we have two sections. The first section focuses on security questions. The second section is the more fun one, the rapid-fire section. So let’s start with the security questions. So generally, for any organization, for any organization, security policies or privacy requirements, or regulatory requirements, all of those cannot be met without evaluating or mitigating a risk or threat. Right. So that brings me to threat modeling, which is one of the important parts of the design and development process.

So to begin the conversation, can you explain what threat modeling is?

Jeevan: Yeah, that’s a great question to start off with. And I want to say that a lot of different individuals and organizations, they approach threat modeling different. And how I like to approach it is that threat modeling is asset centric. So when you have a design or a feature that you want to look at, you want to focus on what are the assets in this particular feature, and then you want to figure out what are the risk to those assets? It’s very simple, just as simple as that. And threat modeling process itself should be simple. It should be very transparent, and it should also be democratized. Everyone that you join that joins the threat modeling session should have a voice, and they should be able to provide their input. Everyone comes with different experiences. They come with different career and educational backgrounds. So the more input we have, the better threat model that we get in general.

Host: Okay, that makes sense. So let’s say, yeah, I know the assets of the organization. How does threat modeling work? Let’s say the first part is figured out. Then

How should organizations go about it, and why should they even do it?

Jeevan: Yeah, perfect. I’ll start with the why should they do it? I like that question in general, because threat modeling is the cheapest way that you will be able to fix vulnerabilities, especially if you do it right. So a lot of folks do threat modeling in the design phase. So as part of the SDLC, you have requirements, design, then development, and then it gets released and you have maintenance mode. So after the requirements you do the design and it’s possible that you can fix security vulnerabilities before you write a single line of code. So if you discover a security vulnerability after, maybe you’re doing a pen test, or worse off, a threat actor actually finds a vulnerability in your system. It is very costly, but threat modeling is done very early on. When developers have come up with a design based on the requirements and you’re reviewing the design, does this make sense? How can an attacker actually take over your assets or have access to your assets? So when you do, at that point all you have to do is re-envision the design.

You make modification to the design and theoretically that’s it, you’re good to go. So it’s really cheap at that point to actually just change the architecture. Whereas after you’ve developed it, it could be months that you have developed it and then you have to rearchitect it after that. That could be very costly in itself, right? So that’s why should we do it? Let’s talk a little bit about the how. So we talked a little bit about the process. You get it from requirements, then you get it to design. And there are a bunch of steps within threat modeling and Oasp has a lot of good resources around it. And what I usually simplify what is out there. The first step is you want to be able to review the design. It’s important that developers, they document the design, and provide architectural documents, and diagrams so that you can actually understand what’s going on. And then what you want to do is you want to gather all of the right subject matter experts with respect to that system, get them into a room, and you want to find the threats. Once you’ve discovered some threats, you want to actually prioritize them, you want to make sure that you do it in the right order.

It doesn’t make business sense to fix all of the vulnerabilities. So you want to prioritize which order you want to do it. And then the next step is actually to mitigate them. So some of them might be just design changes, but other of them might require more effort. So maybe you’ve discovered that there is no TLS within this system, so there might cause some more feature work just in general. So you want to make sure that you actually go ahead and mitigate those things. Another important part of threat modeling is reflecting after you’ve done the threat model, making sure that everyone is sort of satisfied, did we do a good enough job here? You don’t have to have a consensus, not everyone has to agree. But if the vast majority think they’ve done a good enough job, that’s good enough, then you know that you’ve done a decent job for threat modeling.

Host: Okay, so there are a few things that you highlighted are very important. The first and most important one is the cheapest way of resolving vulnerabilities, right? Because most organizations, let’s say after an attack has happened, are scrambling to fix the vulnerability. Something which happened to, let’s say, with the log for shell, right, or do not have a proper process in place. So they are scrambling to figure out and that costs organizations, right? And the other thing that you highlighted is the consensus. Like you do the design review, you then sort of mitigate or prioritize and mitigate. And then if majority of the stakeholders agree, then maybe that’s good enough you cannot satisfy everyone, right. In that I like those points.

So let’s say for an early stage company, if they are trying to implement threat modeling programs, of course we understand that for bigger organizations they can afford, they have time and money to do all of this.

For smaller organizations, which areas should they cover and which areas maybe are not mandatory to be covered as part of this exercise?

Jeevan: This is a great question. So I’ve been fortunate enough to be at a few startups and you run into so many different type of challenges because one, your security engineer might be involved with 14 projects and maybe they have a lot of threat models that come in and you have to prioritize which threat models that you actually can do. You can’t do all of the things. So what I usually recommend for startups is as part of the design phase, just have some common security questions to first figure out ‘should we actually do the threat model?’ , maybe there’s a concept of a pay path within engineering where if you follow the pay path, that’s where as a security engineer, I want to spend most of my time securing the pay path. These are the common type of tools that we use to deploy to production. And if we’re all using it and we secure it, then we know that 80% of the business is fine.

So if the engineer is using the PayPal, then maybe it’s not as important to actually review it or if they’re using the PayPal and it’s not sensitive information, phi, credit card information, that sort of stuff. So what I typically recommend is during the design phase, have those security questions, but also pause, pause and just ask yourself what are some of the bad things that can happen? So a lot of these startups don’t have security engineers, but they will have engineers that do care about security. And I want to make sure that if it’s a ten person, 25 person, 50 person startup that may be not able to afford a security engineer, ask those security questions as a part of it and then just think about what are some of the bad things that can happen and not everything. I always like to point back to having strong security.

It just means you have good engineering. So it’s just another engineering practice. And similar to the SRE folks as well, if you have strong reliability practices, it’s just good engineering. So asking those questions, asking reliability questions, asking security questions, and just pausing and thinking about the design, it will greatly help you down the path. When you do have a security engineer that you’ve hired, the security engineer will review those designs and see, okay, what questions are answered and does it make sense for me to prioritize my efforts to review these things? So even at larger companies, we still have to do prioritizations. We have hundreds of requests coming in a month, and what we do is we look at it, okay, are you using the PayPal? Yeah. You’re using the PayPal? You don’t have very critical sensitive information.

It’s okay, just make sure you’re doing the right thing. Whereas, okay, you’re not using Paypath or you’re using the PayPal, but you have sensitive information. I want to have a look. So it doesn’t matter if you are a small security team or a very large one. We still have to prioritize our threat models. So we want to make sure that we spend the time looking at the ones that make a bigger impact to the business.

Host: I like few things, again, that you highlighted, right? One is asking that question, does it even apply to us? Like, do we need to do threat modeling, which not many organizations do, right? Particularly when you are starting up and you have a very tight budget or you have a small team, everybody thinks that, yeah, everybody is doing threat modeling. Let’s say an enterprise is doing threat modeling, we should also do, right. That should not be the approach. Rather ask that question.

And the other thing that you highlighted is asking the security questions. If you do not have a security team, it’s even more important that you ask those questions to the engineers so that you can prioritize whether you what areas to focus and then document so that when you hire a security engineer, they can take action based on that documentation. Totally agree.

Jeevan: On the first part. I want to double down on it as well a little bit because we get a certain amount of say, if we have five things to review in a week, I much rather spend that time focusing on the one and two and spending way more time on those one and two. If I know it has very sensitive information, because I much make that system a lot stronger than the other ones that I know aren’t as sensitive. If I had 5 hours, I’m going to spend those 5 hours on those two items. Rather than spread 1 hour for everything, I’d much rather focus on those more sensitive areas.

Host: Like prioritize the right task, which has the highest impact, rather than spreading yourself through all the tasks and not being able to complete even one or provide enough have enough impact on all of those areas. Right?

Jeevan: You’re speaking my language. It’s a risk based approach.

Host: Yeah, I totally agree. So let’s say I have a follow up question on this.

Let’s say we have one security engineer and we do the design and we have a solution in place. How do we validate that whatever we have followed makes sense, is right for our organization?

Jeevan: Yeah. I’m going to actually ask a clarifying question. Do you mean validate as in did the organization follow through or do you mean validate that the security engineer made the right decision?

Host: Now, I want to ask you both the questions. Actually, I just had the first one in mind that how do organization validate that they are following the right practices? But if you can highlight on both the areas, that would be lovely.

Jeevan: Okay, we’ll start with did the security engineer make the right decision? And they may or may not. And it’s okay. What security is a lot about is balance and making sure that we’re balancing business needs versus security needs. So the most secure system that we can have is one that’s not even on the Internet. But a lot of us, we live on the Internet and we have to sell our businesses on the Internet. So we have to be on there and there’s going to be a risk to having our information there. So what I like doing is working with strong engineers and coming up we’ll come up with some guidelines as part of our threat modeling process. We’ll come up with some mitigations, some controls that we recommend and working directly with them and saying, okay, which one, are these properly feasible? And does it bring the risk down enough for us to be able to feel that we’re happy about it as a security team as well? So really establishing those partnerships with engineering is critical as part of the threat modeling process, that’s part one.

Part two, sometimes the security engineering team is smaller so that you don’t have the time to validate. But what I like to do is especially for critically sensitive information. This conversation reminds me of a time where we were refactoring our authentication service. So as part of the threat modeling process, one of the things that we do is we make assumptions. We assume that the threat actor can’t do this or they can’t do that. So we have a strong document that comes out of threat modeling. And what I like to do in for those critically sensitive areas, I like to hire pen testing organizations and say, here’s our threat model. Can you validate that our assumptions are correct? Can you make sure that you can’t get into these particular systems and the more information you provide them, the better validation that you can have as well. So I always enjoy doing it that way so that it’s not just my perspective and my assumptions that I make.

I bring in a third party or we can have an offensively gifted security engineer go in and validate the assumptions just in general. So there’s a bunch of different ways that you can actually approach that particular challenge.

Host: I love your approach in this, right. Particularly around Pen testing because generally what organizations do is they do a Pen test of the whole system. Of course that has its benefits, I’m not saying no to that, but particularly asking them to focus on the assumptions that you have made and double down on that. That helps you in a way sort of asking them to focus on one area which maybe you are not 100% confident on and they can give you any vulnerabilities around that or any attack paths that you might have missed so that you can prioritize them and address them rather than looking at the Pen test report of the entire system maybe.

Jeevan: Exactly. And you’re right, we do miss things as security engineers. We’re human all this happens, which is why defense and depth is really important just in general. So having someone check validate our work is always important. So, yeah, I really appreciate when we can bring in vendors. Obviously we can’t do it all the time, but it’s for those critically sensitive areas that we are refactoring or building out that we want to partner with our vendors and make sure that they can validate that we’re doing the right thing.

Host: Makes sense. So I have one follow-up question on this. So most organizations follow some sort of software development lifecycle, right, to build high-quality software when it comes to threat modeling.

When do you think, what’s the right time to work on threat modeling in a SDLC process?

Jeevan: Yeah, I will always say always is the right time, but the best time is you want to do it in the design stage. So I always say always is a good time because we know in reality security resources are constrained. So if you are putting out software and if I have the opportunity to actually threat model even after it’s in production, we might gain some benefit reviewing things after the fact and seeing if we need to change things. But again, I always like to push it to the design phase in itself. So if we are able to do it in the design phase, then it’s really cheap for the organization. So one other thing that I want to point out is that one practice that we’ve come across that work really well is teaching our developers how to do threat modeling.

So we’ve done that with a good chunk of engineers. I remember a couple of years ago, I trained about 120 myself as a part of the process and it was quite impressive. It was an experiment we didn’t know if it’s going to work or not, but I was very impressed with the results because the developers themselves were way better at threat modeling and the security engineers. So that seems kind of weird because I come in, I have many years of threat modeling experience.

How can a developer be better than me? So what we’ve learned is that developers, they understand security. Once you train them to think about security, they understand security and they have very deep knowledge on their system. So something that may take me days, maybe weeks to discover within their system vulnerability, they already know. They know their systems inside out very well.

So we would go into these threat models and developers would be discovering these vulnerabilities that we could not even think about or didn’t even know the type of questions to ask about it. So partnering with them and discovering these vulnerabilities were really able to remediate a lot of the major issues in itself. So it was a great experiment. It went really well, and we’re looking at sort of scaling it at a much larger level at Twilio itself.

Host: I might copy that, honestly, because it makes a lot of sense. Right. It’s somewhat similar to how earlier in engineering practices, dev and QA used to be very separate functions. Right. And then came the TDD, where developers started writing tests. So in a way, developers know about what are the areas that need to be Cubaed or tested. So I totally love what you have done and the value it might bring long term. Right. Of course, in short term it may not help a lot, but long term, it would be amazing. I can see that.

Jeevan: You completely nailed it. And that’s how we approached it as well. We know that late 90s, early 2000s, there was that shift from the developers who would throw their code over the wall to the QA team. Completely separate, no communication there. Once you brought those silos down, once there was a lot more communication between those teams, the overall quality of the software went considerably higher. And we feel that this sort of evolution is happening on the security side as well. Engineers have to be responsible for the security of their feature. They’re the ones that own the risk. We don’t.

As security professionals, as security professionals, it’s our job to bubble up the risk and say, these are the things that you should be concerned with. But ultimately, the security of the system belongs to the engineering. So breaking down those silos, teaching them how to discover vulnerabilities as a part of their own system, will really allow your businesses to scale when it comes to security as well.

Host: Yeah, makes a lot of sense. I want to sort of talk about threat modeling, of course, but in a slightly different way. Let’s say we talked about what threat modeling is, the practice and stuff like that, but at the end of the day. When it comes to threat modeling, you have to work with many teams and senior leadership is one of those teams, right? And you have to have budget, you have to have team members so that you can do the threat modeling. And often what happens is security is not always a priority for small or mid sized organizations and that impacts the budget. And security teams get less budget compared to engineering, right?

So how should organizations deal with these types of challenges, particularly in terms of budget, so that they can do their job in a way?

Jeevan: Fantastic question. And I know that I’ve experienced this a lot of times in my career as well. There’s a few approaches to this. One is we want to work with the executives, our engineering leadership, to make sure that they understand why security is important. And if they don’t really understand that, you might be in a wrong organization. I always have that hard discussion with folks, my peers and other companies that are really struggling with it. But I’ve noticed a lot, especially in the last decade as prominent hacks have happened, the execs, they get it, they get how important security is, so they understand that there is a workflow that we should follow when it comes to security practices. So I usually invest a lot of time trying to influence the leadership side, saying that we should invest into security mostly because it is going to reduce the amount of time you have to spend on security.

So when I go back to threat modeling, we’re discovering things as part of the design base. It’s really cheap. So spending an hour or 2 hours working on a design that may take quarters to actually implement the investment in itself is quite minimal. So it makes sense to do that. But additionally, if you get a breach, if you get hacked, the amount of cost associated with that is going to be very high. So I’ve been at organizations where we had an incident and the costs are high because now you’re diverting a lot of resources from that feature work that you were working on onto do reactive security work. And that in itself now you’re diverting engineering resources, enterprise resources, security resources to all focus on that. So that has an additional cost. If we were just a little bit proactive, it would have been able to allow us to ensure that we sort of mitigate some of those potential problems. So security is very cheap in that perspective. So really hammer that home that it is cheap to do it that way.

Host: Okay, that makes sense. So you highlighted cost to the company as one of the biggest advantages. Let’s say you are pitching to your execs or your senior leadership. What are maybe two other advantages that you’d like to highlight?

Jeevan: Specifically? Yeah, I always go back to the costs. So one of the costs is like we have bug bounty, pen testing that is happening. So we actually have actual costs that we can actually show them and say, hey, if we were to threat model these critical and high vulnerabilities, they come with actual dollar value that we have to pay security researchers or pen testing vendor partnerships. So it is very costly that way and we want to reduce it. But I also want to flip it a little bit because a lot of the slowdown as part of the selling process. So a lot of our enterprise customers, they want to make sure that we have a very strong security posture. While if we have a number of critical and high vulnerabilities that come in through our pen test and we want to share those executive summaries, it’s going to take us a lot longer to convince these potential clients that they should use our systems.

So overall, if we invest a little bit into the security and to the threat modeling side, those high and critical vulnerabilities will slow down and we’ll have fewer and fewer over time, but it will also help the velocity of us selling our software to our potential clients as well. So there’s a bunch of different ways, but you always want to relate it back to the business because ultimately the executives understand dollars and cents and we want to make sure that we point back to why it’s important for them to really invest into it.

Host: Yeah. So in a way, no matter what advantage we like, you show that all comes down to the cost to the organization. Right. Either you are paying to the external pen testers or bug bounty, or you are losing business, let’s say, if you do not have a solid security posture. So, yeah, cost definitely would resonate with Execs as well. Right? That makes a lot of sense. So the last question that I have is so you have worked with several organizations and you have worked on the security programs.

Do you think security is more of a bottom up based approach or it should be a top down approach or if you have any examples, that would be lovely.

Jeevan: Absolutely love this question. Yeah. And the answer is both, actually. So you have to have that top down influence to make sure that the organization that you’re working at actually cares about security.

You can’t convince executives that don’t care about security to now care about security. So that’s always a challenge. Unless there’s a breach, they’re not going to care. So you really need to make sure that they have already bought in before you actually even join the organization. But the Execs are not the ones writing code and deploying it. So you actually have to work with the engineers and managers to build a culture of security. They should want to care about security.

We talked a little bit earlier that strong security is just strong engineering and engineers are very proud of the type of work that they put into production, I would know. I was an engineer before I joined the security side. So I care deeply on the high level of quality of code that I shipped and my team ships. So you do have to have that bottom up approach and convince engineers that this is just a very regular item that we need to do. But engineers are not going to need that guidance from their execs before that they can invest in it, because you have product managers, you have their engineering managers, you have other people clients. All these people are all trying to get attention of the individual engineers to make sure that they’re doing what all of us, all of us stakeholders want them to do. So you need to make sure you have the buy in from the executive leadership in order to make sure that they have time to actually focus on the security aspect of things.

Host: Yeah, I love your answer in this, because most of the times it’s either or. It feels like either or. Either your execs are saying that, hey, we need to be secure, and then engineers maybe are not that passionate about it, or engineers are very much interested in building a secure system, but they do not get support from the execs or the senior leadership, and they lose that interest right slowly. So having the sort of push from both the sides would help organizations to build a security culture. So. Yeah, I love that.

Jeevan: Yeah, building security culture is hard. It is really hard. I’ve done it at a few organizations, and if you have that, it’s sort of like Wind at your back. If the execs already care about security, automatically, everyone slowly starts caring about security as well.

Host: Makes a lot of sense, and that’s a great way to end the security questions section as well. Thank you for sharing your thoughts on threat modeling on the culture, and I hope our viewers will learn something from this.

Summary

Here are a few important points that I could gather from the conversation.

The first one is, threat modeling is the most cost effective way to improve security, and it helps in avoiding future costs incurred, like through bug bounties or breaches or pen testing.
Second one is, while prioritizing threat modeling areas, instead of boiling the ocean, focus on the most important assets, the critical assets, and their exploitability.
Third point is, security should always be a joint collaboration between the execs and the engineers. Execs need to influence and support the engineers so that they can build a strong security system.
The last one is train your engineers on threat modeling and ask security questions. It helps in building a strong security foundation.

Host: Now let’s go to the Rapid fire section.

Rapid Fire

Host: The first question in that is one liner quote that keeps you going.

Jeevan: Okay, I think I have a good one for this. A long, long time ago, when I was in elementary, my grade four. Teacher always stated, anything worth doing is worth doing well. So if you’re going to put your effort into doing something, put your effort to actually do it well and do it all the way, completely do it. So I’ve really taken that back for my security work as well. Anything I build out, any program that I build out, I want to make sure it lasts even longer than I last out of the organization.

Jeevan: Yeah, and that shows in the answers that you have given to the security question. So I can totally understand the next question is, what’s the biggest misconception you have heard in cybersecurity?

Jeevan: Yeah, that’s a good one too. I know a good one. Yesterday I was talking to someone that was thinking about joining want to learn more about information security and how to join the industry. And he was worried because he has a non technical background. So he came with a linguistic background. Is there even an opportunity? And I’m like some of the best engineers that I’ve worked with come from a nontraditional background, so I really encouraged him. I know that you’ll have to obviously have to become technical if you want to be part of security engineering. So it’s really important that we embrace the differences, the different backgrounds, different education, different career paths. That when we join security, because we all look at the problem very differently. One of the people on my team, he comes with a philosophy degree, and I love talking to him, and he really approaches security differently, and he can see things that I can’t see just because of the background that I have.

Host: So you bring in sort of a different perspective to the work, right? Because generally, engineers, we have a way of thinking, but if we have somebody who is from a non engineer background, they might think from a different perspective as well. So, yeah, that makes a lot of sense as well.

Jeevan: Definitely on the educational side, but also having very gender diverse and different races. And we want to make sure we have ultimately a very diverse set of individuals working on security. Because, again, if we all have people that go through the same schooling and look like me, we’re going to have really bad threat models.

Host: Yeah, I can totally relate to that. So the last question that I have is what advice would you give to your 25 year old self starting in security?

Jeevan: That’s a good one. I think the biggest thing that I was afraid of when I was younger was failure. So what I would definitely educate myself would be, don’t be afraid to fail.

And I was always afraid to voice my opinions because it might be wrong and it might look bad, but I felt that I learned the most when I wasn’t right. So people would educate me or I would go down the wrong path, and then I would never make that mistake again in my career. So what I definitely would tell myself when I was younger is, ‘Don’t be afraid to fail. Speak up if you’re wrong, it’s okay. You’ll learn. You’ll grow from that experience, and you’ll grow much faster when you speak up.’

Host: Yeah. Fear of failure or fear of being wrong. Fear of being called out. Right. That, hey, what are you talking about? That sort of holds a lot of people back. So, yeah, I totally love that. And that’s a great way to learn new things, right. From others, from other backgrounds, other cultures, or other races as well. So yeah, thank you so much for sharing that.

It was a fun conversation. I learned a lot around threat modeling and culture as well. I have something I am going to copy from you, the experiment that you ran. So thank you so much for joining and sharing your knowledge with us.

Jeevan: Yeah, no problem at all. We’ll point out that we actually open sourced a lot of the training that we did for threat modeling. So if you search for that Jeevan Singh Self Service threat modeling, you might be able to find that.

But the community is small, and the community gave me so much when I was starting to learn. If anyone ever has questions, hit me up on LinkedIn. Ask me questions. I’ll make sure that I answer your questions. I’ll make time for you because there are a lot of random people in my life that gave me help and support. I want to be able to do that for the community as well.

Host: Thank you for offering that. And we’ll make sure to tag the content that you just shared so that others can learn and also they can reach out to you if they need guidance and knowledge from you as well.

Jeevan: Perfect.

Host: And I want to thank our audience as well. Hope you have learned something new. If you have any questions around security, share those at scaletozero.com. We’ll get those answered by an expert in the security space. See you in the next episode.

Thank you.