Speaker 1: Welcome to your deep dive. Today, we're tackling something that, well,
Speaker 1: it might sound a bit intimidating at first, threat modeling,
Speaker 1: but trust me, it's way more interesting and way more
Speaker 1: practical than you might think, even if you're not a
Speaker 1: cybersecurity you know, guru or anything.
Speaker 2: Yeah, No, you're absolutely right. Threat model is really just
Speaker 2: a structured way to kind of brainstorm what could possibly
Speaker 2: go wrong. And you know, we're not just talking about
Speaker 2: software here. It applies to systems processes, even a new
Speaker 2: product launch exactly.
Speaker 1: And the cool thing is we're using Adam Shostak's book
Speaker 1: Threatmodeling dot pdf as our guide today. And you know,
Speaker 1: I've got to admit when I first saw that title,
Speaker 1: I thought, uh, oh, this is going to be dense.
Speaker 1: But Shostak he actually makes it pretty engaging, even funny
Speaker 1: at times.
Speaker 2: Yeah, he does have a good sense of humor. One
Speaker 2: of my favorite parts is where he compares learning threat
Speaker 2: modeling to learning a musical instrument. You know, it takes practice,
Speaker 2: for sure, but anyone can grasp the basics and start
Speaker 2: kind of start playing, so to speak.
Speaker 1: Oh, I love that analogy. So let's say you're working
Speaker 1: on project, where do you even begin with this whole
Speaker 1: threat modeling thing, Like what's step one?
Speaker 2: Well, you start by building a model kind of like
Speaker 2: a simple diagram of whatever it is you're building, break
Speaker 2: it down into its core components, the data flows, and
Speaker 2: then you start looking for these things called trust boundaries
Speaker 2: trust boundaries.
Speaker 1: Okay, now you're making me feel like I need security
Speaker 1: clearance just to listen to this.
Speaker 2: Not at all. Think of it this way. A trust
Speaker 2: boundary is just like a line that you draw between
Speaker 2: areas with different levels of well trust, like data moving
Speaker 2: within your own secure network, you know, that's one level
Speaker 2: of trust. But anything coming in from the internet, you know,
Speaker 2: users that you don't know, that's that's crossing a boundary,
Speaker 2: and that's where you need to be extra careful.
Speaker 1: Okay, ah, that makes sense. So once you've got your
Speaker 1: you know, your diagram and your boundaries all figured out,
Speaker 1: how do you actually spot those threats?
Speaker 2: Well, Shastek introduces this really handy framework. It's called STRIDE
Speaker 2: and it's a mnemonic. It stands for spoofing, tampering, repudiation,
Speaker 2: information disclosure, denial of service, and elevation of privilege.
Speaker 1: Oh you know what, it's funny you mentioned that I
Speaker 1: actually played the Elevation of Privileged card game once at
Speaker 1: a security conference and it was a blast. It really
Speaker 1: drove home how even seemingly small details can open the
Speaker 1: door to these big security problems.
Speaker 2: Oh it's fantastic. It's a fantastic way to learn, and
Speaker 2: it highlights how threat modeling can be, you know, collaborative,
Speaker 2: it can even be fun. Doesn't have to be all
Speaker 2: doom and gloom.
Speaker 1: Right right, Okay, So let's get practical here. Let's say
Speaker 1: we're building a simple web application like the ACME Corporation
Speaker 1: example from the book. How would we how would we
Speaker 1: apply stry to find those potential threats?
Speaker 2: Well, let's take information disclosure as an example. If ACME
Speaker 2: isn't super careful about validating user input on their web forms,
Speaker 2: an attacker could use something called seql injection to you know,
Speaker 2: sneak into their database and access all sorts of sensitive information.
Speaker 1: Ouch. Yeah, that's that's not good. And I bet there
Speaker 1: are a ton of other threats lurking out there, just
Speaker 1: depending on the system.
Speaker 2: Absolutely, and showstak makes it clear there are different ways
Speaker 2: to go about this whole threat modeling process. You can
Speaker 2: focus on your most valuable assets or you can think
Speaker 2: like an attacker, you know, get in their head or
Speaker 2: and this is often the best starting point. You can
Speaker 2: really dig into the software itself. It's architecture and how
Speaker 2: it all works together.
Speaker 1: So it's like it's like choosing the right tool for
Speaker 1: the job, you know, Yeah, depending on what you're building
Speaker 1: and what you're most worried about exactly.
Speaker 2: The key is to have a structured approach, and Stride
Speaker 2: is a great framework to start with. But it's not
Speaker 2: just about finding these threats. It's also about figuring out
Speaker 2: how to deal with them right.
Speaker 1: Right, Because let's be honest, you can't eliminate every single threat,
Speaker 1: can you. I mean that would probably be like impossible.
Speaker 2: You're absolutely right, and that's where risk management comes in.
Speaker 2: You got to prioritize Some risks might be so minor
Speaker 2: that you can just accept them. Others you might transfer
Speaker 2: to a to a vendor or a specialist. But for
Speaker 2: the big ones, the critical ones, you need to actively
Speaker 2: mitigate them.
Speaker 1: So you're saying, it's all about choosing your battles wisely,
Speaker 1: don't sweat the small stuff, but be prepared to go
Speaker 1: all in on the threats that could really hurt you.
Speaker 2: Precisely. And one thing Shostak emphasizes is that you can't
Speaker 2: just assume and tacker will stop at the first hurdle.
Speaker 2: You know, you need what he calls a defense in depth,
Speaker 2: multiple layers of security, so that even if one fails,
Speaker 2: you've got back up.
Speaker 1: Oh, like a castle with multiple walls and moatsh I
Speaker 1: like that. It's making me think about my own online accounts.
Speaker 1: Maybe just having a strong password isn't enough.
Speaker 2: You're catching on. And here's where Shostak's book gets really practical.
Speaker 2: Chapter twelve, The Requirements Cookbook is packed with specific security recommendations.
Speaker 2: He covers everything from authentication to logging to data integrity.
Speaker 1: Okay, I have to admit when I skim that chapter,
Speaker 1: my head started to spin a little. Do you really
Speaker 1: think people need to implement every single thing that in
Speaker 1: that cookbook?
Speaker 2: Of course not. It's a starting point, a menu of options,
Speaker 2: not a you know, a mandatory checklist. But here's the thing.
Speaker 2: Even picking a few key items from that chapter and
Speaker 2: applying them to your project can dramatically improve its security.
Speaker 1: That's reassuring. So it's more about being smart and strategic,
Speaker 1: not about becoming some kind of you know, security Superhero
Speaker 1: Overnight exactly.
Speaker 2: You start with the basics and you build from there.
Speaker 2: The key is to make threat modeling a habit, a
Speaker 2: part of your process, not just a you know, a
Speaker 2: one time thing.
Speaker 1: Right right. This is all incredibly helpful, but I have
Speaker 1: to ask, how does this apply to like the world
Speaker 1: of web applications and cloud platforms, because things are changing
Speaker 1: so fast in that space.
Speaker 2: Oh, you're right. The landscape is constantly evolving, and that's
Speaker 2: why chapter thirteen is so important. It dives into the
Speaker 2: specific challenges of web and cloud security, things like insider threats,
Speaker 2: tenant behavior in shared cloud environments. You know, these are
Speaker 2: all things you need to be thinking about.
Speaker 1: Insider threats. Huh, that's a scary thought. You're basically saying
Speaker 1: you can't even trust everyone within your own organization.
Speaker 2: Well, it's not about you know, assuming the worst in people,
Speaker 2: but it is about understanding that that not all threats
Speaker 2: come from you know, these external attackers. Sometimes the vulnerabilities
Speaker 2: lie within.
Speaker 1: Okay, so you're telling me to trust no one, not
Speaker 1: even my own team.
Speaker 2: Not quite. It's more about being aware of the different
Speaker 2: ways data can be accessed, misused, or even accidentally exposed,
Speaker 2: and of course. A big part of this is protecting
Speaker 2: user data, especially when it comes to accounts and identity.
Speaker 1: Management, which is perfect segue to chapter fourteen. Yeah right,
Speaker 1: that felt like a bit of a crash course. In
Speaker 1: all things accounts and passwords, it's.
Speaker 2: Essential reading and one of the most insightful things Shastak
Speaker 2: says is you have to accept account existence as something
Speaker 2: an attacker can learn, so you focus on usability from
Speaker 2: that point on, and he really slams knowledge based authentication.
Speaker 2: You know those security questions that are often anything but secure.
Speaker 1: Oh yeah, I hate those. Yeah, what street did you
Speaker 1: grow up on? Like, I'm going to remember that off
Speaker 1: the top of my.
Speaker 2: Head exactly, and Deck points to things like multi factor
Speaker 2: authentication as a much, a much stronger alternative. It's about
Speaker 2: adding layers of security, just like we talked about with
Speaker 2: defense and depth.
Speaker 1: Okay, so we've got our diagrams, our stride framework, our
Speaker 1: requirements cookbook. But there's still one piece missing, isn't there?
Speaker 1: The human element?
Speaker 2: You're absolutely right, and that's where chapter fifteen gets really interesting.
Speaker 2: It dives into the psychology of security, how our own
Speaker 2: brains can sometimes well work against us.
Speaker 1: Our brain's working against us. Yeah, Okay, now I'm really intrigued.
Speaker 2: It's all about these things called cognitive biases, things like anchoring,
Speaker 2: where we get fixated on the first piece of information
Speaker 2: we see, even if it's even if it's wrong or
Speaker 2: WYSIID what you see is all there is, which can
Speaker 2: make us kind of blind to potential dangers lurking just
Speaker 2: outside our immediate view.
Speaker 1: Wow, that's fascinating. So it's not just about building secure systems,
Speaker 1: it's about understanding how people actually use those systems right
Speaker 1: and designing them in a way that minimizes, you know,
Speaker 1: the risk of human error exactly.
Speaker 2: And Shasta gives some great examples of how this plays
Speaker 2: out in the real world, like those phishing emails that
Speaker 2: create this this sense of urgency to trick you into
Speaker 2: clicking on a malicious link.
Speaker 1: Oh man, I've totally fallen for those before. You feel
Speaker 1: like you have to act immediately and you don't start
Speaker 1: to think critically about it.
Speaker 2: That's exactly what the attackers are counting on. So part
Speaker 2: of threat modeling is understanding these these psychological traps and
Speaker 2: designing systems that help users, you know, avoid them.
Speaker 1: This is blowing my mind. It's like it's like security
Speaker 1: meets behavioral science.
Speaker 2: It really is, and it highlights how security is not
Speaker 2: just a technical problem, it's a human problem. We need
Speaker 2: to understand both sides of the equation to build truly
Speaker 2: secure systems.
Speaker 1: After all that, I'm starting to feel a little overwhelmed.
Speaker 1: Is there any hope for those of us who aren't
Speaker 1: you know, cryptography experts.
Speaker 2: You're not alone. But here's the good news. You don't
Speaker 2: have to be a cryptogenius to build secure systems. In fact,
Speaker 2: Shastak has some very reassuring words for us in chapter sixteen.
Speaker 1: Okay, call me more. I need some good news right
Speaker 1: about now.
Speaker 2: He basically says, don't reinvent the wheel when it comes
Speaker 2: to cryptography. Use well vetted, you know, existing cryptosystems. Don't
Speaker 2: try to create your own, your own encryption algorithms unless
Speaker 2: you're you know, a world renowned expert, because the odds
Speaker 2: of you messing it up are pretty high.
Speaker 1: Yeah, that makes sense. Why reinvent the wheel if someone's
Speaker 1: already done the hard work for you.
Speaker 2: Exactly, and he calls this the cryptographic doom principle. Get
Speaker 2: crypto right and you're good. Get it wrong and the
Speaker 2: consequences can be catastrophic. It all comes back to understanding
Speaker 2: those trust boundaries.
Speaker 1: So trust the experts, know your boundaries, for the love
Speaker 1: of all that is secure. Don't try to create your
Speaker 1: own encryption algorithm.
Speaker 2: You got it. And that's just scratching the surface of
Speaker 2: what Shashtak covers in the book. We've still got so
Speaker 2: much more to unpack, including how to actually make threat
Speaker 2: modeling a regular part of your process, how to con
Speaker 2: vince your team to you know, to get on board,
Speaker 2: and even a glimpse into the future of threat modeling
Speaker 2: with things like threat genomics and adversarial machine learning.
Speaker 1: Wow, I am definitely feeling inspired, but also a little
Speaker 1: overwhelmed by all this information. Maybe we should take a
Speaker 1: quick break here and come back for part two of
Speaker 1: our deep dive to explore these more these more advanced concepts.
Speaker 2: Sounds like a plan. We've laid a solid foundation, and
Speaker 2: now it's time to build on it and see how
Speaker 2: we can apply these ideas to create a more secure
Speaker 2: digital world. All right, so let's jump back into this
Speaker 2: fascinating world of threat modeling. One thing that really struck
Speaker 2: me as we were, you know, prepping for this deep
Speaker 2: dive was how much emphasis Adam Shastak puts on clarity
Speaker 2: when it comes to diagramming systems.
Speaker 1: Oh. Absolutely, a messy diagram is like a recipe for
Speaker 1: disaster when you're when you're trying to threat model. Yeah,
Speaker 1: it's it's got to be crystal clear so you don't
Speaker 1: miss any any crucial vulnerability.
Speaker 2: Exactly. It's not just about having a diagram, it's about
Speaker 2: having a good one. And data flow diagrams or DFDs,
Speaker 2: they seem to be like the gold standard for threat
Speaker 2: modeling because they visually show how that data is moving
Speaker 2: through your system.
Speaker 1: Yeah, DFDs there, they're fantastic for visualizing those trust boundaries
Speaker 1: we talked about earlier. Yeah, it's like shining a spotlight
Speaker 1: on those on those exact points where an attacker might
Speaker 1: try to sneak in.
Speaker 2: Yeah. And once you've got those those entry points you know, highlighted,
Speaker 2: you can systematically analyze each one using the Stride framework.
Speaker 2: Are they susceptible to spoofing, tampering, repudiation? You go through
Speaker 2: the whole list and really dissect those potential weaknesses.
Speaker 1: It's like having a mental checklist almost for security vulnerabilities.
Speaker 1: And it's amazing how many things you might overlook if
Speaker 1: you don't have that structured approach.
Speaker 2: Absolutely, and Shastak goes beyond just you know, theory. He
Speaker 2: gives tons of practical tips in the book, like the
Speaker 2: importance of validating data from from untrusted sources. Never never
Speaker 2: just blindly trust user input or data coming from external systems.
Speaker 1: Oh, I've learned that lesson the hard way a few times. Yeah,
Speaker 1: it's so easy to assume that that data is, you know,
Speaker 1: clean and well intentioned, but you really, you really have
Speaker 1: to treat everything with a with a healthy dose of suspicions.
Speaker 2: Yeah, you got it. Input validation. It's it's like that
Speaker 2: first line of defense against against a whole range of
Speaker 2: injection attacks, including that that sneaky sequel injection we talked
Speaker 2: about earlier.
Speaker 1: Yeah, and let's not forget about logging. I used to
Speaker 1: think of logs as like just boring technical stuff, you know,
Speaker 1: but the book, the book really opened my eyes to
Speaker 1: how crucial they are for security, especially when it comes
Speaker 1: to those those tricky repudiation threats.
Speaker 2: You're right, logs can be like a life saver when
Speaker 2: you need to investigate a security incident. They're like a
Speaker 2: detective's notebook, you know. Helping you piece together what happened,
Speaker 2: who is involved, and how to prevent it from happening again.
Speaker 1: But but logs are only useful if they're protected right
Speaker 1: and reliable. What's the point of having a you know,
Speaker 1: a security camera if someone can just just tamper.
Speaker 2: With the footage exactly. Shastak really stresses the importance of
Speaker 2: protecting those those log files from tampering and making sure
Speaker 2: they're stored securely. You don't want to create a vulnerability
Speaker 2: while you're you know, while you're trying to solve another one.
Speaker 1: That's true, that's true. You know. One of the things
Speaker 1: that really that really clicked for me was this concept
Speaker 1: of defense in depth. So tempting to just think, Okay,
Speaker 1: I've implemented this one security measure, I'm good. But but
Speaker 1: that's rarely enough, is it?
Speaker 2: Not? At all? Shostak really drives home the point that
Speaker 2: you need you need multiple layers of security. It's it's
Speaker 2: like building a castle with walls and moats and guard towers.
Speaker 2: You know, each layer makes it that much harder for
Speaker 2: an attacker to breach your defenses.
Speaker 1: It makes you realize that security is not a you know,
Speaker 1: not a destination. It's a journey. Yeah, you have to
Speaker 1: constantly be evaluating your defense is, looking for looking for
Speaker 1: weak points, and making improvements.
Speaker 2: Absolutely, it's it's an ongoing process and it requires vigilance
Speaker 2: and a willingness to adapt as the threat landscape changes.
Speaker 2: You know. Shostak also talks about the importance of understanding
Speaker 2: trade offs when it comes to security. Sometimes the most
Speaker 2: secure solution just isn't feasible, right, Right, Like.
Speaker 1: You could build an impenetrable fortress, but if it's so
Speaker 1: restrictive that no one can actually use it, what's the
Speaker 1: point exactly?
Speaker 2: It's about finding the right balance between security and usability
Speaker 2: and cost. Sometimes you might choose to accept a certain
Speaker 2: level of risk if the cost of mitigating it is
Speaker 2: just just too high.
Speaker 1: Right. So it sounds like threat modeling forces you to
Speaker 1: be to be really honest with yourself about what you're
Speaker 1: willing to risk, yeah, and what you absolutely need to
Speaker 1: to protect. It's a tough call, but an essential one,
Speaker 1: you know.
Speaker 2: Couldn't agree more. And one thing Shostak emphasizes is that
Speaker 2: threat modeling shouldn't be a one time event. It needs
Speaker 2: to be like beaked into your entire development life cycle.
Speaker 1: So it's not like checking a box and moving on.
Speaker 1: It's more about making threat modeling a part of your DNA,
Speaker 1: part of how you how you approach every every project
Speaker 1: from from start to finish.
Speaker 2: You nailed it. Whether you're using an agile methodology or
Speaker 2: a more traditional, you know, waterfall approach, threat modeling should
Speaker 2: be should be woven into into every stage of development, design, implementation, testing, deployment,
Speaker 2: you know, it all needs to be considered through a
Speaker 2: through a security lens.
Speaker 1: It's it's like you're you're constantly checking your blind spots,
Speaker 1: anticipating potential problems before they even even.
Speaker 2: Arise, exactly. And it's not just about that initial development
Speaker 2: phase either. As you add new features, you know, make
Speaker 2: changes to your your code or integrate with with external systems,
Speaker 2: you need to revisit your your threat model and it
Speaker 2: makes sure it's still relevant.
Speaker 1: It's like that that old saying eternal vigilance is the
Speaker 1: price of liberty, except in this case it's the price
Speaker 1: of security.
Speaker 2: Uh huh. That's a great analogy. And and Shastak gives
Speaker 2: some really practical advice on how to integrate threat modeling
Speaker 2: into into different different development methodologies, even fast paced ones
Speaker 2: like like agile and DevOps.
Speaker 1: That's that's where're sureing. I think a lot of people
Speaker 1: assume that threat modeling is like too cumbersome for those
Speaker 1: types of those types of environments, but it sounds like
Speaker 1: it can be. It can be adapted to fit to
Speaker 1: fit any workflow.
Speaker 2: Absolutely. The key is to break down threat modeling activities
Speaker 2: into into smaller, more manageable tasks that can be integrated
Speaker 2: into your existing process.
Speaker 1: So it's not about adding this this whole new layer
Speaker 1: of bureaucracy. It's it's about incorporating incorporating security thinking into
Speaker 1: into everything you do.
Speaker 2: You got it, And that even extends to you know,
Speaker 2: testing activities. Shawstak talks about how how threat modeling can
Speaker 2: inform your testing strategy, helping you develop more, more targeted
Speaker 2: and effective test cases.
Speaker 1: It's like you're not just testing to see if the
Speaker 1: software works. You're testing to see if it's if it's secure,
Speaker 1: if it can withstand withstand attacks.
Speaker 2: Exactly. By understanding those those potential threats, testers can really
Speaker 2: put those defenses to the test and try to break them,
Speaker 2: which ultimately leads to a more secure and resilient system.
Speaker 1: Okay, okay, I'm loving all this practical advice. But I
Speaker 1: want to circle back to something we touched on earlier,
Speaker 1: the human element. We talked about cognitive biases and how
Speaker 1: our own brains can can sometimes make us make us
Speaker 1: vulnerable to attacks. Can you can you go a little
Speaker 1: deeper into that. I'm really fascinated by this whole, this
Speaker 1: whole psychology of security thing.
Speaker 2: I'm glad you brought that up. It's it's such an
Speaker 2: important aspect of security, and in Shostak dedicates a whole
Speaker 2: chapter to it in the book. He really dives deep
Speaker 2: into how our cognitive biases can make us susceptible to
Speaker 2: things like like social engineering attacks.
Speaker 1: Okay, so so remind me again what are cognitive biases.
Speaker 1: I feel like I need a refresher course in psychology.
Speaker 2: Think of them as as mental shortcuts almost that our
Speaker 2: brains take to process information quickly. They're often helpful in
Speaker 2: everyday life, but when it comes to security, they can
Speaker 2: they can kind of lead us astray.
Speaker 1: So it's it's like our brains are trying to help us,
Speaker 1: but they're actually making us, making us more more vulnerable.
Speaker 2: To attack sometimes. Yes, Shostak talks about biases like anchoring,
Speaker 2: where we where we get fixated on the first piece
Speaker 2: of information we see, even if it's even if it's wrong,
Speaker 2: and uh, and confirmation bias, where we tend to seek
Speaker 2: out information that confirms our our existing beliefs, even if
Speaker 2: those those beliefs are flawed.
Speaker 1: Oh, I'm totally guilty of that. If if I've already
Speaker 1: made up my mind about something, it's it's hard to
Speaker 1: convince me otherwise, even if there's even if there's evidence
Speaker 1: to the contrary.
Speaker 2: We all do it. It's it's just how our brains
Speaker 2: are wired. But in the context of security, that can
Speaker 2: be that can be dangerous. For example, if you're if
Speaker 2: you're convinced that that a certain type of attack can't
Speaker 2: happen to you, you might be less likely to take
Speaker 2: precautions or to recognize the warning signs, you know, right.
Speaker 1: Right, So it's not just about building, you know, building
Speaker 1: secure systems. It's about understanding how people actually use those
Speaker 1: systems and designing them in a way that that minimizes
Speaker 1: the risk of human error exactly.
Speaker 2: And that's where the idea of usable security comes in.
Speaker 2: You want to build systems that are not only technically
Speaker 2: you know, robust, but also but also user friendly, intuitive, right.
Speaker 1: So, so it's about guiding users towards safe choices without
Speaker 1: making them feel like they're they're constantly walking through through
Speaker 1: a minefield of security warnings and restrictions.
Speaker 2: That's a great way to put it. You want you
Speaker 2: want security to be almost invisible, seamlessly integrated into the
Speaker 2: into the user experience, so people so people don't even
Speaker 2: realize they're being protected.
Speaker 1: That's really interesting. It reminds me of that analogy that
Speaker 1: Shastak uses in the book about security being like a
Speaker 1: like a shepherd, you know, gently guiding users toward towards
Speaker 1: safe pastors rather than than locking them up in a
Speaker 1: in a fortress.
Speaker 2: I love that analogy. It perfectly captures the essence of
Speaker 2: usable security. It's about it's about enabling people to use
Speaker 2: technology safely and effectively without feeling like they're they're constantly
Speaker 2: fighting against the system.
Speaker 1: Okay, so, so we've talked about diagrams and frameworks the
Speaker 1: psychology of security, but we haven't delved into the the
Speaker 1: nitty gritty of cryptography yet. Is that is that where
Speaker 1: we're hitded next? Because I have to admit that's the
Speaker 1: part that that intimidates me the most.
Speaker 2: Uh huh, you're not alone. Cryptography can seem can seem daunting,
Speaker 2: but uh but Shostak does it does a great job
Speaker 2: of breaking it down in a in a way that's
Speaker 2: that's accessible even for those of us who aren't you know,
Speaker 2: math whizzes.
Speaker 1: Okay, I'm all ears, give me the give me the
Speaker 1: Cryptography for Dummies version.
Speaker 2: Okay. Well, the the key takeaway is that you you
Speaker 2: don't have to be a cryptographer to build secure systems.
Speaker 2: In fact, it's it's usually best to rely on on
Speaker 2: well vetted, existing cryptosystems that have been thoroughly tested and
Speaker 2: proven secure.
Speaker 1: Okay. So, so don't try to be a cryptographic superhero
Speaker 1: and and invent my own my own algorithms exactly.
Speaker 2: Reinventing the wheel in cryptography is is almost always a
Speaker 2: recipe for disaster. There's a reason why those algorithms are
Speaker 2: so so complex. It's because a lot of a lot
Speaker 2: of brilliant minds have have worked on them to make
Speaker 2: sure there's a secure as possible.
Speaker 1: Okay. So it's it's more about choosing the right the
Speaker 1: right tools for the job and using them correctly, rather
Speaker 1: than trying to create something entirely entirely new from.
Speaker 2: Scratch, you got it and and Shostak calls this the
Speaker 2: cryptographic doom principle. Get it right and you're golden. Get
Speaker 2: it wrong and you could be setting yourself up for
Speaker 2: a major security breach.
Speaker 1: Okay, I'm definitely getting the message don't mess with crypto
Speaker 1: unless you unless you really know what you're doing. But
Speaker 1: I'm still curious. What what are some of the key
Speaker 1: things to keep in mind when it comes to, you know,
Speaker 1: choosing and using cryptosystems.
Speaker 2: Well, one of the one of the most important things
Speaker 2: is is key management. Your your encryption keys are like
Speaker 2: like the keys to your castle. If if someone gets
Speaker 2: a hold of them, they can they can unlock all
Speaker 2: your secrets.
Speaker 1: Oh, that's a that's a great analogy. So so key
Speaker 1: management is all about all about keeping those keys, those
Speaker 1: keys safe and secure, making sure they don't they don't
Speaker 1: fall into the wrong hands exactly.
Speaker 2: And that involves things like like storing keys securely, controlling
Speaker 2: and controlling access to them, and having procedures in place
Speaker 2: for revoking and replacing keys if they're ever if they're
Speaker 2: ever compromised.
Speaker 1: So it's not just about the technology itself, it's about
Speaker 1: the processes and procedures that you have in place to
Speaker 1: manage that technology securely.
Speaker 2: You're catching on and this all ties back to the
Speaker 2: idea that security is a holistic challenge. It's it's not
Speaker 2: just about technology, it's about it's about people and processes
Speaker 2: and a deep understanding of the threats you're you're facing.
Speaker 1: Okay, so we've covered so much ground already, from diagrams
Speaker 1: and frameworks to the psychology of security and the importance
Speaker 1: of not reinventing the cryptographic wheel. What else does? What
Speaker 1: else is shuss Deck cover in the book? Is there
Speaker 1: anything we've we've missed?
Speaker 2: There's still a lot to explore. We haven't even touched
Speaker 2: on the more experimental approaches to threat modeling, like like
Speaker 2: threat genomics and adversarial machine learning, and of course there's
Speaker 2: there's the big question of how to actually implement threat
Speaker 2: modeling in your organization.
Speaker 1: Wow, I'm starting to feel like we need a whole
Speaker 1: series of deep dives just just to cover all of this.
Speaker 1: But before we before we get too overwhelmed, why don't
Speaker 1: we take a pause here and come back for part
Speaker 1: three to delve into those those more advanced topics.
Speaker 2: That sounds like a great plan, we've we've laid a
Speaker 2: solid foundation and now it's now it's time to build
Speaker 2: on it and explore the cutting edge of threat modeling.
Speaker 1: All right, So we're back for the final part of
Speaker 1: our deep dive into threat modeling. And you know, one
Speaker 1: thing I've been thinking about is, as we've been prepping
Speaker 1: for this, I was I was kind of struck by
Speaker 1: just how many different approaches there are to tow threat
Speaker 1: modeling out there. It's it's kind of overwhelming.
Speaker 2: Yeah, yeah, it's true. There's there's no there's no one
Speaker 2: size fits all, you know, some are some are very structured,
Speaker 2: while others are are more adaptable, you know. But but
Speaker 2: don't worry. They all they all share the same core principles.
Speaker 2: You know, understand your system, find the threats, and figure
Speaker 2: out how to how to deal with them.
Speaker 1: Right In shastak he he highlights three main strategies in
Speaker 1: the book asset centric, attacker centric, and UH software centric.
Speaker 1: And we touched on these briefly before, but I think
Speaker 1: it's it's worth worth digging a little deeper.
Speaker 2: Oh absolutely, so, UH an asset centric approach it's all about,
Speaker 2: you know, identifying those those crown jewels in your system.
Speaker 2: The things that you absolutely need to protect, and then
Speaker 2: you analyze the threats that could target those specific those
Speaker 2: specific assets.
Speaker 1: So it's it's kind of like building a security perimeter
Speaker 1: almost around your around your most prized possessions. Like you're saying,
Speaker 1: these are the things that that absolutely cannot be compromised,
Speaker 1: so let's let's focus all our all our efforts on
Speaker 1: protecting them precisely.
Speaker 2: It's it's a great approach for for systems where the
Speaker 2: assets are are clearly defined and and the consequences of
Speaker 2: losing them are are very high. You know, think, I
Speaker 2: think findinancial data, medical records, anything anything super sensitive.
Speaker 1: Right, But what about those situations where you know you're
Speaker 1: you're not even sure what the what the biggest threats are.
Speaker 1: That's where that that attacker centric approach comes in, right, right,
Speaker 1: you got it?
Speaker 2: With With this approach, you try to think like like
Speaker 2: a hacker. You know, what are there, what are their motivations,
Speaker 2: what are their pactics, what tools might they use? You
Speaker 2: put yourself in the in the attacker's shoes, and and
Speaker 2: try to try to find those vulnerabilities that they could exploit.
Speaker 1: It's it's like playing a constant game of cat and mouse,
Speaker 1: always trying to anticipate the attacker's next move and stay
Speaker 1: one step ahead. Sounds sounds exhausting, It can be.
Speaker 2: It can be, but it's but it's essential for for
Speaker 2: systems where where the threat landscape is constantly, constantly changing
Speaker 2: and you need to be super you know, proactive. So
Speaker 2: think think like online gaming platforms, e commerce sites, anywhere
Speaker 2: there's this like this constant stream of of new attacks
Speaker 2: and vulnerabilities.
Speaker 1: Right, and and then there's that software centric approach, which
Speaker 1: seems to be kind of the most popular, uh starting point,
Speaker 1: especially for for new projects.
Speaker 2: Yeah, it's a it's a great foundation with with this approach,
Speaker 2: you you really dig into the software itself, you know,
Speaker 2: it's architecture, the the components, how it how it all
Speaker 2: works together, and you're looking for any any weaknesses in
Speaker 2: the design that could that could compromise security.
Speaker 1: It's almost like you're you're an architect. You're examining like blueprints,
Speaker 1: looking for for structural flaws that could they could make
Speaker 1: the building you know, collapse.
Speaker 2: Uh huh. That's a that's a great analogy. And and
Speaker 2: the beauty of the the software centric approach is that
Speaker 2: you can you can bake security into the design from
Speaker 2: from day one. You know, you're not you're not trying
Speaker 2: to bolt it on as an as an afterthought.
Speaker 1: Right, So it sounds like choosing the right approach it
Speaker 1: really depends on on what you're building, Yeah, and what
Speaker 1: you're what you're most most worried about.
Speaker 2: Exactly. There's there's no one right way to do this.
Speaker 2: The key is to is to find an approach that
Speaker 2: that fits your your specific needs and helps you achieve
Speaker 2: your your security goals.
Speaker 1: Now, one thing that really stood out to me in
Speaker 1: the in the book was the emphasis on on validating
Speaker 1: your threat model. You know, it's one thing to identify threats,
Speaker 1: but how do you know if you've actually you know,
Speaker 1: dealt with them effectively.
Speaker 2: Yeah, that's that's where the rubber meets the road, right,
Speaker 2: You've got to you've got to make sure those those
Speaker 2: mitigations are actually actually working and they haven't you know,
Speaker 2: accidentally created new vulnerabilities and uh and Shostak he talks
Speaker 2: about several several validation techniques including UH, code reviews, penetration testing,
Speaker 2: even even something called.
Speaker 1: Attack trees penetration testing. Huh, Yeah, that sounds that sounds intense.
Speaker 1: Is that where you you hire those those ethical hackers
Speaker 1: to try and break into your system.
Speaker 2: Exactly. It's it's like a like a controlled experiment where
Speaker 2: you let the good guys try to to hack you
Speaker 2: so you can so you can find and fix those
Speaker 2: those weaknesses before the before the bad guys exploit them.
Speaker 1: And code reviews that sounds a bit less uh, less adrenaline.
Speaker 2: Pumping, definitely. Code reviews are more about having you know,
Speaker 2: experienced developers carefully examine the code, you know, line by line,
Speaker 2: looking for any any security flaws or vulnerabilities. It's it's
Speaker 2: like having a second set of set of eyes, you know,
Speaker 2: catching those those subtle errors that can easily slip through
Speaker 2: the cracks.
Speaker 1: And what about those those attack trees. That sounds pretty
Speaker 1: pretty hardcore there.
Speaker 2: They're actually a really a really useful tool for for
Speaker 2: visualizing potential potential attack paths. You break down, you know,
Speaker 2: a complex attack into into smaller, more manageable steps, kind
Speaker 2: of kind of like a flow chart almost for for hackers.
Speaker 1: That's a that's a great way to think about it. Yeah,
Speaker 1: it makes that the whole process seem less less daunting.
Speaker 1: You know, you're not tackling this huge amorphous threat. You're
Speaker 1: you're breaking it down into into smaller, more more manageable
Speaker 1: pieces exactly.
Speaker 2: And by by understanding those those attack paths, you can
Speaker 2: you can identify those those most critical points to defend
Speaker 2: and make sure you're your mitigations are are focused on
Speaker 2: on those areas.
Speaker 1: Yeah. Yeah, now all this, all this technical stuff is fascinating,
Speaker 1: but I'm also curious about, you know, that that human
Speaker 1: element again and showstack. He even talks about using threat
Speaker 1: modeling too to inform user documentation, which seems, you know,
Speaker 1: a bit unexpected at.
Speaker 2: First, it makes sense when you when you think about it.
Speaker 2: By by documenting those those security assumptions that you've made
Speaker 2: and the and the mitigations that you've that you've put
Speaker 2: in place, you can you can help users understand those
Speaker 2: those security implications of using your software.
Speaker 1: Yeah, so it's not just about protecting the system. It's
Speaker 1: about it's about empowering those those users to make, you know,
Speaker 1: informed decisions about about their own security.
Speaker 2: Absolutely, it's about transparency and building trust. You're you're saying,
Speaker 2: here's what we've done to protect you, and here's what
Speaker 2: you can do to protect yourself.
Speaker 1: Well, I love that. Yeah, it's a. It's a collaborative
Speaker 1: approach to to security, recognizing that we all, we all
Speaker 1: had a role to play in keeping our systems and
Speaker 1: data safe exactly.
Speaker 2: And it's not just about you know, the technical stuff.
Speaker 2: It's it's about communication and education and working together to
Speaker 2: to create a more a more secure, secure digital world.
Speaker 1: Okay, So so let's say I'm totally sold on this
Speaker 1: whole on this whole threat modeling thing. I I want
Speaker 1: to bring it to my to my team, yeah, to
Speaker 1: my to my organization. But how how do I convince
Speaker 1: everyone else? Because people are people are busy, They've they've
Speaker 1: got their own priorities, and security isn't always at the
Speaker 1: at the top of the list.
Speaker 2: Yeah, it's a it's a real challenge. But uh Shawstak
Speaker 2: offers some some great advice in the book. He says
Speaker 2: it starts with building awareness and getting getting buy in
Speaker 2: from from those those key those key decision makers.
Speaker 1: So it's not just about showing up at a meeting
Speaker 1: and saying, hey, everyone, we need to we need to
Speaker 1: start threat modeling. You've got to You've got to make
Speaker 1: a case for sure people, why why.
Speaker 2: It matters Exactly? You need to you need to articulate
Speaker 2: the benefits both in terms of, you know, reducing risk
Speaker 2: and improving the overall the overall quality of your of
Speaker 2: your software. And and it can't just be talk. You've
Speaker 2: you've got to walk the walk, you know, start small
Speaker 2: threat model a a manageable project, and showcase the value
Speaker 2: it brings.
Speaker 1: Oh so lead by example, show people how it, how
Speaker 1: it works, how it can it can make a real difference. Yeah,
Speaker 1: and hopefully they'll they'll start to start to come around exactly.
Speaker 2: And and don't be afraid to start small. You don't
Speaker 2: have to, you know, boil the ocean right away. Focus
Speaker 2: on the most critical systems, the ones that would cause
Speaker 2: the biggest headache if they were if they were compromised.
Speaker 1: Right, So, start with the low hanging fruit, prove the concept,
Speaker 1: and then and then gradually expand from there.
Speaker 2: You got it. And and Shostak also talks about the
Speaker 2: the importance of integrating thread modeling into your your existing processes.
Speaker 1: So it's it's not about creating this this whole new,
Speaker 1: you know, separate thing. It's about weaving it into the
Speaker 1: into the fabric of how you how you already work,
Speaker 1: whether that's that's agile or or waterfall or or something
Speaker 1: else entirely.
Speaker 2: Yeah, that's the that's the key to sustainability. Make make
Speaker 2: threat modeling a natural part of of how you build software,
Speaker 2: not just an extra, you know, an extra chore that
Speaker 2: that everyone dreads.
Speaker 1: Okay, yeah, this is this is starting to click for
Speaker 1: me now. It's it's about it's about shifting the mindset,
Speaker 1: making making security a core part of of everything you do,
Speaker 1: not just not just an afterthought.
Speaker 2: Precisely, and that's how you create a culture of security
Speaker 2: where where everyone on the on the team understands the
Speaker 2: importance of of thinking about about potential threats and proactively
Speaker 2: addressing them. It's it's no longer the security team's problem.
Speaker 2: It's it's everyone's everyone's responsibility.
Speaker 1: Right, No, I love that. Yeah, it's a it's a
Speaker 1: much more, much more holistic and proactive approach to to security.
Speaker 1: And speaking of proactive, one thing that that Shostak emphasizes
Speaker 1: throughout the book is that the importance of iteration. Yeah,
Speaker 1: and and continues improvement.
Speaker 2: Yes, that's that's so crucial. Threat modeling isn't a one
Speaker 2: and done activity. It's an it's an ongoing process of
Speaker 2: learning and adapting and refining your your security posture as
Speaker 2: you go.
Speaker 1: Yeah, so you're you're constantly revisiting your your threat model,
Speaker 1: tweaking it, updating it, making sure it's it's still relevant. Yeah,
Speaker 1: you know, as yours your system evolves and the threat landscape,
Speaker 1: the threat landscape changes exactly.
Speaker 2: You're always you're always learning, you're always improving, always always
Speaker 2: staying one step ahead of the bad guys.
Speaker 1: Right, It's it's a never ending game of cat and mouse. Yeah,
Speaker 1: but but at least now we've got some we've got
Speaker 1: some really powerful tools and strategies to help us, to
Speaker 1: help us play the game actively.
Speaker 2: Absolutely, And that's what's so what's so exciting about this
Speaker 2: about this field, you know, it's it's constantly it's constantly evolving,
Speaker 2: and there's always always something new to to learn.
Speaker 1: Well, I think we've covered a lot of ground in
Speaker 1: this in this deep dive, from from the fundamentals of
Speaker 1: threat modeling to some of the more the more advanced
Speaker 1: concepts and techniques, and I've I'm feeling it inspired, but
Speaker 1: also a little a little overwhelmed by by all this
Speaker 1: all this information.
Speaker 2: It's it's a lot to take in. But uh, but
Speaker 2: remember the journey of a thousand miles begins with a
Speaker 2: single step. You know, start start small, pick pick a system,
Speaker 2: and start applying the principles we've we've discussed.
Speaker 1: And remember there are tons of resources out there to
Speaker 1: help you, including including Shaskacs book, which is is an
Speaker 1: absolute treasure trove of information and practical advice.
Speaker 2: Absolutely, and and don't be afraid to reach out to
Speaker 2: to other security professionals for for guidance that the security
Speaker 2: community is incredibly welcoming and supportive and there are there
Speaker 2: are so many people willing to to share their their
Speaker 2: knowledge and expertise.
Speaker 1: Yeah, that's that's a good point. Well, as we as
Speaker 1: we wrap up this this deep dive, what's the what's
Speaker 1: the one key takeaway you want our listeners to to remember.
Speaker 2: I think the the biggest thing is that threat modeling.
Speaker 2: It's it's not just for security experts, it's it's for
Speaker 2: everyone who's involved in build and managing technology. It's about
Speaker 2: taking a proactive approach to to security, thinking about those
Speaker 2: potential those potential threats before they become before they become
Speaker 2: real problems.
Speaker 1: Right, don't wait for a for a security breach to happen.
Speaker 1: Start start thinking like a like an attacker, identify those
Speaker 1: vulnerabilities and put those those mitigations in place exactly.
Speaker 2: And remember it's it's a journey, not a not a destination.
Speaker 2: There's always there's always more to learn, and the more
Speaker 2: we the more we learn, the better we can we
Speaker 2: can protect ourselves and the and the technology that we
Speaker 2: that we rely on.
Speaker 1: Well said, well thanks for thanks for joining us on
Speaker 1: this deep dive into the world of threat modeling. We
Speaker 1: we hope you found it uh informative and inspiring.
Speaker 2: It's been a it's been a pleasure exploring this this
Speaker 2: fascinating topic with you.
Speaker 1: Yeah. Likewise, and as always, stay curious, keep learning, and
Speaker 1: stay secure out there.