Understanding Threat Modeling and Secure by Design Concept with Adam Shostack

TLDR;

• Secure by design is a key step in building a healthy security program. It should not be done, or rather it should be done while designing and building applications and not as an afterthought.
• When it comes to threat modeling, taking a pause and asking questions about possible threats is equally important as finding a solution to the threats.
• Communication is key to evangelizing and championing security programs in the organization. And it goes both ways, security to non-security teams and vice versa. 

Transcript

Host: Hi, everyone. This is Purusottam, and thanks for tuning into the ScaletoZero podcast.

Today's episode is with Adam Shostack. Adam is the author of Threat Modeling, Designing of Security and Threats, what every engineer should learn from Star Wars. I hope we can see the parallels between security and Star Wars today. He is a leading expert on threat modeling, a consultant and a game designer also.

He has decades of experience delivering security. His experience ranges from founding startups to near -decade at Microsoft.

Welcome to the show, Adam. For our audience, do you want to briefly share about your journey?

Adam: Sure. I've always been interested in the back and forth between building and breaking. And I've had the lucky opportunity to do that and to create some things that the CVA, I was a co -creator of, and really the ways in which security change and the ways in which security stays the same over the years have been a thing that I've been really interested in.

And I've gotten a chance to do that at big scale at Microsoft and at smaller scales or different scales, helping companies learn to threat model, learn to build secure by design systems.

And so, you know, I'm happy to be here today to share a little bit with your audience.

Host:Thank you. It's a pleasure to have you here. One of the things that we generally ask before we get into the security section is what does a day in your life look like?

And we get unique answers because everyone has a different way of dealing their day to day. So yeah, what does a day in your life look like?

Adam: So a lot of times my day will start out with a training course that I'm delivering with my team. And so we'll hop on. We need my team and I. You know, we've got a technical producer, we've got extra instructors. We'll hop on, we'll do a prep session where we review the day's material. By the way, you're getting behind the scenes that we usually don't talk about here.

But we do a prep session. What are we gonna cover today? What are the key learning goals for today's session? How do we make sure everything is ready to go when the students come through the door, as it were?

We'll deliver today's material, we'll debrief on it. And you know, that's often an hour or two. And then I'll get on with my day. I'll look at email. I'll think about what big projects I'm working on for the week.

You know, this week I'm working on a white paper. I'm finishing up a course for LinkedIn learning. Normally don't do this much training work in a given day. And then there'll be some, you know, there's some customers who want to improve what they're doing. So I'll work with them.

And so it's a mix of delivery of immediate things. It's a mix of some longer term things. And it's a mix of staying on top of what's happening in the world.

Host: Lovely. So one thing it looks, it sounds like you have like a full scale production setup and you are contributing a lot back to the community, right?

And that is helping folks like me who are trying to get their feets wet in security and get better at security also. So yeah, thank you so much for contributing back to the community.

Adam: You're welcome. Yeah. I'm happy to do so. Thank you.

Host: One of the things that you mentioned earlier is secure by design, right? So we are going to talk about secure by design and threat modeling today. So let's jump in. You are a big advocate of secure by design, but before we dive deep into it,

Can you help our audience understand the concept of secure by design?

I mean, why is secure by design such a crucial philosophy and how can organizations benefit out of it?

Adam: Yeah, so… So let's start with just a physical world analogy, right?

If I wanna build a secure building, I should think about that before I start to build it, right? Maybe there should be a fence. Maybe there should be some bollards out front so people can't drive a truck up to it. And if we think about that, then our ability to secure it is much better than if we take over an existing building and try to patch security onto it. And this is really obvious when we talk about buildings and it's less obvious when we talk about software.

Because we like to think software is malleable. But, even if software really were malleable, right, it doesn't have APIs or file formats or log formats or other things that people take dependencies on which decree, which make it harder to make changes. The work that you and I do to write the software has a cost, right?

We're doing that instead of other work. And so Secure by Design is really about thinking through what you're going to do and integrating security at the same time as you're thinking about, are we gonna build this as a full -on app where we ship apps? Are we gonna do it as web pages and react and pretend it's an app? Are we gonna do it purely as a website? Are we gonna do it, you know, there's lots of delivery modalities. And once you've picked one, you're sort of stuck with it. And you should think about security in the same way. The security decisions you make should be designed in. And I'll give you a security specific example.

Host: Sure. Thank you.

Adam: You know, you're working on something with a database backend. If you build a lot of dynamic SQL queries, surprise, you're going to have SQL injection.

If from the start you build with prepared statements, you're going to have fewer security problems. And so the by design is let's make sure everyone is building with prepared statements rather than dynamically constructing SQL as they go. Right?

And so we built it in and we're happier at the end than we are, if we're trying to bolt it on.

Host: Yeah. So I love your analogy of building and how it relates to security, right? The message that I'm getting is security should not be an afterthought. That you have built your building and then you're thinking about security, but you should think about it before even you start building the building or even during, but not once it is built.

And the example that also you gave about the DB, like dynamic queries and prepared statements, if you do not start with prepared statements, if you start writing dynamic queries, there is a chance that junior developers or somebody else in your team thinks that that's maybe the right practice. And they continue to do it. And they also learn that as a practice, even though that's not the right practice.

Adam: Yeah, exactly. exactly! The things we do teach people even when we don't intend for them to.

Host: Right. Right. So there is another term in the market also, right? Similar to, which sounds very similar to secure by design, which is secure by default. So are they the same thing?

Are they different? Like, how do you see them next to each other?

Adam: So, so it's a great question. Let's say our application supports password controls and multi -factor authentication. We could hide that multi -factor authentication three layers deep, or we can turn it on by default and maybe give people a checkbox to not use it. So the default matters. If we put it in people's normal account creation path, we're going to have way more people who are secure than if we just let them put whatever password they want in.

And, you know, maybe we don't even have a password meter to encourage them to use stronger passwords.

So the design can support the thing we want it to do, but the defaults may not push people to do what we want them to do.

Host: That's a very good example, like MFA generally. And also the password strength that you highlighted, right? I guess like five years ago, there were not many websites which were adopting that password strength control, maybe on the web app. But nowadays we see a lot of adoption in which sort of teaches or trains people to start using MFA systems or start using the passwords strength, like start writing better passwords in a way. So yeah, that's a very good example again.

Adam: Can we dive deep in that one for a second? Sure, sure. I think this is one of those places where the choices we make within good design are so important because it's hard for human beings to remember lots of good passwords.

And so we've spent a lot of energy telling people to use better passwords and change them regularly. And hey, it's hard for people to maintain hundreds of good, unique passwords without writing them down. So the thing I want people to do is use a password manager that helps you with this.

And so picking not just secure by design, but the right designs is such an important part of things and it's a nuance that sometimes we miss. So I just want to thank you for letting me.

Host: No, no, absolutely. That's a very good addition. So yeah, thanks for doing that. So, okay, now I understand the concept of secure by design. And one of the things that a lot of folks talk about, and you were also highlighting, right? So it should be integrated maybe as part of the development cycle, the security and secure by design thought process should be followed as part of the development cycle.

So what are some of the key steps that organizations can take so that they embed this principle into the development?

Adam: So let me start with the word design, because a lot of people today get really focused on design as a dirty word. It's too heavyweight. We don't do that architecture thing anymore.

But you do. Nobody starts coding by writing like import OS or into their Python file, right? You start by thinking about what is this module going to do? Hey, you're designing. And what we need are approaches to security design that are feasible for people to use. Right?

And that are lightweight and work in today's agile world. And I spend a lot of time working on threat modeling and helping organizations learn to threat model. And so let me explain what threat modeling is.

Threat modeling is the measure one, measure, measure once good Adam. It's the measure twice cut once. There we go. Of software. How do we anticipate what can go wrong? And it's a collection of techniques. And at the heart of those techniques are four questions. And we're always answering these questions. What are we working on? What can go wrong? What are we gonna do about it? And did we do a good job? And if we simply ask those four questions, we give it so much value. And...

When people talk about threat modeling, they often will talk about threat model diagrams or data flow diagrams. They'll talk about stride. These are ways of answering those questions, but literally taking two minutes and saying, what can go wrong with this thing I'm building?

If you never do that, you're never going to answer the question. If you stop and think, then you can say, you know, this new feature I'm building has this potential problem. And I'll give you a silly example.

I'm going to a music festival in a few months and I've got a lot of bands. So, I was playing with an AI this weekend and I was like, hey, write me some code to create a Spotify playlist with the bands on this website.

So it's like, okay, so now what can go wrong? I'm giving this code access to my Spotify account, okay. And then along the way, you know, fuzzy matching is hard. And so I was like, okay, take the URL that Spotify sends back and pipe it into the web browser for me. And I paused there and I'm like, okay, now Spotify can run code on my computer. Am I okay with this?

And I said, yeah, if somebody is going to take over Spotify to pop my machine while I'm running this code, okay, I don't really need to validate that this thing is a URL, but maybe, maybe I should have, right?

And I can think about how am I gonna validate what came back from Spotify?

Does it start with HTTPS, Spotify, and then there's a slash within a certain number of characters?

Is there a semicolon in it because then it could get command injection, right?

Little bits of thinking. I don't need to spend hours doing some complicated threat modeling thing. I can just ask what can go wrong? What am I going to do about it?

And we get huge security value instead of, would you look at what just happened there? So, sorry, that was a very long answer. Let me get back to your question of that is what threat, that's the heart of threat modeling.

Host: Right, so one thing that I liked about the answer is that, of course, you can have many frameworks, you can get answers to your questions, but it's equally important to pause and ask the questions. Like as you were saying, right?

That let's say I'm writing dynamic queries. Is it possible that somebody can do SQL injection here? Right? So taking a pause and asking those questions is equally important as getting answers to the questions. Yeah. And this is really at the heart of what organizations should do, which is to learn that these relatively simple techniques, right?

A lot of times people get hung up on, my gosh, threat modeling is big and complicated. No, don't need to be big and complicated.

Just asking four simple questions gets you so much progress.

Host:Yeah, yeah, absolutely. So now continuing on the same topic like threat modeling, like you're right, you're highlighting that threat modeling should be done early on as part of the STLC. It can avoid a lot of future headache.

But while doing threat modeling, as you rightly pointed out, there may be so many questions that come up.

Let's say you are building an app which has a database. So there are many areas, right? You have a database, you have an app. Let's say you're hosting it in the cloud.

So when you are doing the threat modeling exercise, which areas should you cover and maybe which areas you can ignore? Is that a possibility?

Like how do you see threat modeling in these scenarios?

Adam: So the first question is what are we working on? OK. And that question helps me answer your question. Right. What are we working on? What are we working on right now? Right?

There's a friend of mine is our Taran Dhok, who talks about threat model every story. What are we working on right now? And so if there's a team that's working on the front end, someone else is working on the database. The front end team shouldn't be worrying about the database. And the database team shouldn't be worrying about the front end.

Right? And that lets me get focused on asking productive questions that are meaningful to the work that I'm doing today. And oftentimes people will want to threat model the whole shebang, which is great, right? You can have architecture debt, you can have security debt, you can have other technical debts.

But really, threat modeling can align to the work I'm doing and it gets better because it's focused. And if what I'm doing this sprint is we're doing a pay down technical debt sprint, then yeah, focus on the whole. If I'm gonna add whole new components, focus on the whole, right? How does that play in the whole thing? And if you do it, and so the more alignment we have, the happier we are.

Host: Right. Right. So now let's I agree that threat model each story makes a lot of sense, but at the same time it means additional effort. Right. You are doing some design reviews and stuff like that. Imagine you are running a startup with limited resources or limited budget or limited number of security folks. You do the design.

Now, how do you validate the design? Do you do externally? Do you do internally? What would you recommend?

Adam: So, you know, when resources are limited, the thing we want to do is to minimize our cost, to accelerate our speed. And yes, there is a cost to doing the threat model and work. And it can pay off in avoiding rework, in avoiding, right? Let's say we're gonna move so quickly, we never stop to have a conversation about prepared statements versus dynamic SQL. Now we have to rewrite half our code. Exactly. That's, you know, you can move very quickly and find yourself in a lot of trouble.

And so the trick is to say, how can we do this fast? How can we just ask what can go wrong with this? And if we push threat modeling to a review, and this is really, really common, don't do it as a review, do it as part of backlog grooming, do it as part of story writing.

Because once you wait for a review, somebody's written code, And now we're having an argument of should I have written the code that way and we're being less efficient.

Host: Yeah. Which would mean rework, right? Yeah. If you get some review comments, you have to rework.

Adam: Yep. Yeah. So maybe spend two minutes saying, Hey, I'm going to do this. What can go wrong with it? Rather than a day writing code, then you check it in. Then you get a review comment that says, yeah, this rewrite this, we go faster by taking the time to set up our workspace, to clean our desks a little bit versus not.

Host: Yeah. Yeah, I like your suggestion of doing this as part of the backlog grooming or sprint planning. That way you're not doing it later. You're rather thinking it out loud or thinking it through during the design phase, which also, or during the grooming, which also helps in scoping the work properly. Maybe without the threat modeling, you were thinking it's a story point one versus when you introduce security, it's story point three. So that means you need to have that conversation earlier than later, which affects the delivery in a way, right?

Adam: And, and you know, let's, let's go with the story points here. If I think it's story point one and I want shifts and then somebody takes a dependency on the API I've just written.

And then I find a security problem. Now it's 10 story points because I have to rewrite my code. I have to coordinate with the people who have a dependency on that API. I have to support two APIs for a while. I have to write some monitoring code to determine if somebody's taking advantage of it. I have to hire a consultant to do an operational security response. And so I've bought myself a little bit of speed and a lot of re -work.

Host: Yeah, exactly. Which is not helping. Like if you're running a startup, it's anti or it's not helpful at all. Right. So yeah, makes a lot of sense.

So you have written a book, I slightly want to pivot. So you have written a book on threats and the title itself says what every engineer should learn from Star Wars. So I'm trying to see how you see parallels between them. So for our audience who maybe are not familiar with Star Wars, hopefully not many, can you tell us like, what do you see?

How do you see parallels between Secure by Design and Star Wars?

Adam: Sure. And so the first thing I want to say, since you mentioned we may have listeners who are not Star Wars fans, one of my beta readers hates Star Wars. And I've had her read it because I don't want the book to be so deep divey into Star Wars that you can't get the point if you're not familiar with the movies or the books or the video game. No.

So let me start at the beginning of Star Wars. R2 -D2 refuses to play a video for Luke Skywalker. How does R2 -D2 know who Luke Skywalker is? or how does he know who Ben Kenobi is? So he can say, I'm only gonna play this video for Ben Kenobi. And so, yep, little bit of movie geekdom, but you've seen, most people have seen this scene or something that riffs off or alludes to this scene. And so we can ask the question of authentication. We can ask a question about identity management. Right? We can get a little bit geekier and ask, how does Princess Leia program R2D2 to know who Ben Kenobi is?

And by the way, these questions are not answered in the movie. It's okay, it's a movie. It's a plot device.

But the reason I enjoy using Star Wars for these questions is, it's part of the storytelling that R2 -G2 isn't going to play the movie for one person, but he'll play it for another. And right there, we've got a whole stack of important security questions that we can ask. And so I use these little vignettes out of Star Wars to introduce these concepts, which are really helpful as we start to ask what can go wrong.

Cause one of the sorts of things that can go wrong are failures of authentication, failures of authorization. And so it's really helpful for people to have a way of organizing their thinking about these security issues. It's not essential, right? You can ask what can go wrong at a very open-ended sort of way. And that's great. And I encourage people to do so because in our lives, we all know about things that can go wrong.

And, you know, not as a critique, but just as a sort of fun example of this. You know, your call, as we were prepping this call,

One of the things that went wrong was I couldn't hear your colleague. Right? And as we were prepping, there's make sure your microphone works with the Riverside tool that we're using. These are not, you know, we could get silly and say these are denial of service issues with the system, but who cares?

Right? The answer is we know what can go wrong because of our life experience. And in the book, I use a mnemonic stride, which I mentioned earlier, didn't explain. Stride stands for spoofing, tampering, repudiation, information, disclosure, denial of service, and elevation of privilege. I say it a lot.

I can imagine. And… And we can use that to organize our thinking. And I use it to organize the book and it's helpful. And that's the goal of the book is to give people this framework for understanding and getting more systematic, more structured in how we answer the question, what can go wrong so that they get better answers faster.

And the thing I want to be really, really careful about as I say this is I'm really proud of the book. I'm happy to have written it. People really like it. You do not need to read the book in order to threat model in the same way that you don't need to read a book on Python in order to write Python code. But if you read some books on Python, you'll get, you'll become a better program.

Host: I, I. Now I see how you see the parallels between both the worlds, right? The Star Wars and the security.

Are there any examples that you can share which show, like in the Star Wars itself, which shows the importance of secure by design principles?

Adam: Yeah, yeah. So the Death Star has this thermal exhaust port, which doesn't have, you know, any kinks in it or any anti torpedo netting. And you could, okay, look, we can get really, really deep into an alias of this.

But I'm going to stick with I'm going to stick with Star Wars itself, where there's a, there's two crucial things. One is it only takes the rebels like 30 seconds, right? They're getting chased. The Millennium Falcon is getting chased to the rebel moon and it's the Death Star is about to show up and they've got time to analyze the plans. They've got time to brief their pilots, get them in the air.

This is a really obvious flaw. The Death Star is not secure by design. It doesn't have any blowout panels in case of a reactor problem. Right? It's full. It's full of flaws. And the flaws are obvious enough that some flunky goes up to the bad guy and says, sir, we've analyzed their attack and there is a danger. Should I prepare a shuttle for you?

And then the Death Star blows up. Which if you're on the side of bad guys is very sad. Lots of bad guys die because it's not secure by design.

Host: So yeah, makes a lot of sense. Like how you again draw the parallel between secure by design and Star Wars. I can see how much you love Star Wars and how much you use that to teach people or communicate security principles. So yeah, love that.

One of the things you highlighted earlier, right? That let's say doing the threat modeling maybe early as part of backlog grooming or sprint planning. So that means you are interacting with multiple teams, not just your own team. Maybe you are interacting with product team or some other teams. And communication often plays a major role when it comes to… Maybe pushing is not the right term that I'm looking for, but evangelizing security within your organization.

So what role do you see like the collaboration or the communication when it comes to implementing or evangelizing the security secured by design within the organization?

Adam: So anything that you want to have happen in a modern organization, somebody needs to be responsible for. And when you get into cross -cutting sorts of responsibilities, effective communication, I would like you to do this because -

You know, one of the, one of the things that slows security people down is a lot of us are cynical. A lot of us are good at being critical. A lot of us are snarky. And nobody appreciates somebody coming in and saying, dude, your code sucks. Right?

So learning to communicate in ways that are effective is just key to our success. And a lot of times the people doing the work, whether it's development work or operations work, know there are security things they need to be doing. And if we're helpful and we listen and we engage, then they come back. And if we don't, if we're mean, if we're rude for unavailable, they'll stop coming.

Host: Yeah, I agree. The communication has to be both ways, right? Both from a, let's say the engineering team, when working with security team, be receptive, be listen to the feedback, and then of course use that for prioritization.

Similarly, security teams, often they are seen as a team of saying no, right? I have been into some meetings where, when the security experts are invited, folks are like, this meeting is not going anywhere because they will say no to everything. So there is that perception and friction between security and non-security as well. So it goes both ways. The communication goes both ways so that you can collaborate better and run a healthy and successful security program.

Adam: Yes.

Host: So a follow -up question to that is, How do you increase that awareness of importance of security or communication or building that relationship with security team or the other way around as well?

Adam: So, unfortunately, we have a lot of real examples in the news today about security failures. Right?

Two stories that I'm tracking. One, and this is in the United Kingdom, but the British Library has been having a ransomware incident that has dramatically crippled their ability to serve the public. It's been on the nightly news. It's, you know, it's it's been there.

And here in the United States, the United Health issues that have been going on for weeks that are breaking people's ability to get their prescriptions filled.

Talking about those sorts of things, because they're in the news, they're real things that are happening. And you can say, you know, if somebody broke into our systems, how might they do that? What would happen? Could we kick them out? Could we recover? What if they get into our Git repository and start modifying code? What are the right things for us to do? What if they got into our AWS root account? How hard would it be for us to build out a new AWS instance? Is everything managed by Terraform, Kubernetes, Docker? And so it's all really crops or is it only half crops and half pets that we couldn't rebuild?

And so you can use these stories in the news. And the more that they're impacting people, you know, is somebody saying, gosh, I'm sorry, I'm late for the meeting. I had to go and spend an hour on the phone with my doctor and the pharmacy to get my kids some drugs.

Allow me to interject as a security person. Wow, I'm so sorry, that's really awful. And can we take a minute to talk about how that might impact, a similar thing might impact us. Right, so you're making it real, you're being, as we were just talking about, right, we're being human, we're being sympathetic, instead of saying, what's wrong with you? Why can't you get your kids damn medicine?

Host: Yeah, having that empathy for others, like for other teams or other developers or security folks even. So yeah, makes a lot of sense.

So you highlighted about the public infrastructure, right? Like in UK. So there is a term going on which is called cyber public health. So what do you think about that and how does it relate to threat modeling?

Adam: Sure. So let me explain the term, because it's something that I and some colleagues have been working on for the last few years. In the real world, we have things like vital statistics, right? How many people are there? We have information about diseases. Measles is on an uptick. We can talk about the incidence of new cases in a population being much higher than it's been.

What is the incidence of SQL injection? Or what is the incidence of ransomware? We don't have statistics. We believe that it's increasing. But we lack something like the Centers for Disease Control who track new measles cases. We've got a bunch of people, some companies, some enthusiasts, some reporters who pay attention to ransomware cases, but we don't have anyone doing that on behalf of the public to provide us with information about what's happening.

And so the tide of threat modeling is often when we threat model, we come up with lots and lots of possible issues.

We don't have great information about how often, for example, account takeover happens in the real world. We don't have information about say, and I really don't have information about this, do accounts at Yahoo mail get taken over more frequently than accounts at Gmail? If I knew that, maybe I could feed that information into my security operations and add additional controls if someone's using a Yahoo account or an AOL account.

You know, I don't want to be prejudicial. I can guess that AOL is not investing in account security at the same rate as Gmail. Of course, yeah. But I don't know it. Right.

And so the, I, the goal of the public health work is to better inform our defenses so that we can say, yeah, this information feeds into how we track model and how we take the information we're learning and make it operational.

Host: I see how you're trying to build that. Maybe if I use the term database of all the attacks happening, ransomware phishing and stuff like that, which can feed into folks building their security programs in a much better way. Helps with threat modeling and all. So yeah, I'm pretty hopeful that the initiative will help a lot of security enthusiasts.

Adam: It's going to take time building it, building programs and infrastructure takes effort. But.

We have a lot of people who are enthusiastic about it. So I'm excited about it.

Host: Yeah, I'm excited.

Adam: Actually, if I could just mention, I'm doing that work in association with a nonprofit, Cyber Green. So if you want to learn more about cyber public health, go to cybergreen.net/research. And you'll find a lot of the things that we are publishing along with get in touch with us about that work sort of links.

Host: lovely. So what we'll do is when we publish the episode, we'll make sure to tag cybergreen.net/research so that our audience can also go there, learn and they can contribute as well. Awesome. In whichever capacity they can. Cool. Okay. So that's a great way to end the security questions.

So let's go to the next section, which is focused on rating security practices.

Rating Security Practices

Host: The way it works is I'll share a security practice and you can rate between one to five, five being the best. So the first practice is conduct periodic security audits to identify vulnerabilities, threats and weaknesses in your systems and applications.

Adam: So I'm going to rate this both a two and a four. And it's a two if that's all you do. If you're not doing any secure by design, And this is, and you're always chasing things down. It's a two and it's a four if you're doing secure by design and you're tracking yourself.

Host: So I see, right? That if you're doing the basics correctly, then you're at a much better position versus if you're not make sense.

The second one is provide training and awareness programs to employees so that they can easily identify and respond to potential security threats.

Adam: Is this for developers? Is this for everybody? Is this like phishing training or is this secure coding training?

Host: So this is more like phishing training to everyone in your organization.

Adam: I'm going to give it a two. And the reason is it's hard to identify a phishing email. It's hard to… to know what to do about it, it's much better if we push for MFA everywhere. So the credential theft matters a lot less. Right? And so a lot of organizations are like, Puru, you didn't catch the phishing email, we're gonna come yell at you. Seriously, this is good use of who's time exactly.

Host: I was hoping you'll… maybe say three or something because we are doing training, but I see the context, like why you feel it should be a two.

Adam: There are times when it makes sense for sure. It's just when we treat it as the main line of defense that I start to worry a lot.

Host: The last one, and we briefly touched on this is, Use a strong password that contains a mix of uppercase, lowercase, numbers, and symbols, and also change your passwords frequently.

Adam: So if by changing your password frequently, you mean every minute, I think we've got to five. Hopefully not. Hopefully not. Well, no, that's what MFA is, right? You get a new password every minute.

But. But really it's, unless we're using a password manager, it's a one. It's impossible to do. I mean, I was in my password manager the other day. I have 900 different accounts. I could literally spend a minute changing each of them. And let's see, that would be like five hours.

Aww. And so I think for all of these, the threat modeling and the public health come together to say, can we really do this? One of the important things about public health is that there's a focus on what we can achieve. What can we convince people to do? And things like change your password all the time, it turns out they won't do.

So we have to come up with other measures that will protect them in a world where people have other things on their plates.

Host: And I'm glad that we have like password managers and all today. Otherwise, what we ended up doing is either write it in a notebook somewhere or use the same password everywhere. Right. Which is even more scary. Right. In a way, if you are using the same password for your it's a social media account and your financial transactions, then I don't know who will save you. Like if your social media is a hack.

Adam: You have to click between write it down in a notebook and use the same password everywhere. We know, we know that attackers steal password lists and use them that they've taken over once they've taken from one site, they use them on another site.

So write them down. Ideally, you're writing them down in a password manager. It's easier. It's usually more secure. And I mean, I don't want to have to type in a good password every time I go to a site. And so that's a good balance for most folks.

Host: Yeah. So the recommendation that I'm getting out of this is use a password manager, use MFA.

Yeah. So yeah, that's a great way to end the episode. But before we let you go, do you have any recommendation for our audience? It can be a blog or a book or a podcast, anything.

Adam: So we talked about the Star Wars book and I'm very pleased with how it came out. And I think that if you are new to threat modeling, and we spent a bunch of time on the assumption that listeners were new to threat modeling, New to Secure by Design World. I'm proud of the work. It's designed to be readable and accessible even if you're not a Star Wars fan.

But okay, so here's my actual recommendation. If you are not a Star Wars fan, go watch Star Wars again. How's that?

Host: Love that recommendation.

And we'll also tag your recommendation, like your book, when we are publishing the episode so that our audience can go in and they can buy and they can read and learn about secure fire design. Okay. Actually, can I give you the recommendation in a slightly different form for edit? Sure.

Adam: Okay. So if you're a Star Wars fan, I recommend my book, Threats, What Every Engineer Should Learn From Star Wars. If...somehow you're not a Star Wars fan, then my recommendation is go watch Star Wars again. You'll learn a lot about security.

Host: Love that. Love that. Yeah. So thank you so much, Adam, for joining and sharing your knowledge and helping us understand what threat modeling is, what secure by design is, and how it can be utilized in the organization for building a security program.

So yeah, thank you so much.

Adam: You're welcome. It was really a pleasure talking with you today. Thanks. Thank you.

Host: And to our audience, thank you so much for watching. See you in the next episode.