WEBVTT 1 00:00:00.120 --> 00:00:04.440 Welcome to your deep dive. Today, we're tackling something that, well, 2 00:00:04.480 --> 00:00:07.160 it might sound a bit intimidating at first, threat modeling, 3 00:00:07.519 --> 00:00:10.720 but trust me, it's way more interesting and way more 4 00:00:10.759 --> 00:00:13.240 practical than you might think, even if you're not a 5 00:00:13.240 --> 00:00:15.720 cybersecurity you know, guru or anything. 6 00:00:16.039 --> 00:00:18.239 Yeah, No, you're absolutely right. Threat model is really just 7 00:00:18.280 --> 00:00:21.399 a structured way to kind of brainstorm what could possibly 8 00:00:21.440 --> 00:00:23.199 go wrong. And you know, we're not just talking about 9 00:00:23.199 --> 00:00:27.320 software here. It applies to systems processes, even a new 10 00:00:27.359 --> 00:00:28.920 product launch exactly. 11 00:00:29.359 --> 00:00:32.000 And the cool thing is we're using Adam Shostak's book 12 00:00:32.039 --> 00:00:35.799 Threatmodeling dot pdf as our guide today. And you know, 13 00:00:35.799 --> 00:00:37.679 I've got to admit when I first saw that title, 14 00:00:37.719 --> 00:00:39.479 I thought, uh, oh, this is going to be dense. 15 00:00:39.679 --> 00:00:43.840 But Shostak he actually makes it pretty engaging, even funny 16 00:00:43.840 --> 00:00:44.240 at times. 17 00:00:44.439 --> 00:00:46.000 Yeah, he does have a good sense of humor. One 18 00:00:46.000 --> 00:00:48.799 of my favorite parts is where he compares learning threat 19 00:00:48.799 --> 00:00:52.960 modeling to learning a musical instrument. You know, it takes practice, 20 00:00:53.000 --> 00:00:55.840 for sure, but anyone can grasp the basics and start 21 00:00:56.039 --> 00:00:57.520 kind of start playing, so to speak. 22 00:00:57.759 --> 00:00:59.799 Oh, I love that analogy. So let's say you're working 23 00:00:59.799 --> 00:01:03.479 on project, where do you even begin with this whole 24 00:01:03.520 --> 00:01:06.000 threat modeling thing, Like what's step one? 25 00:01:06.319 --> 00:01:08.560 Well, you start by building a model kind of like 26 00:01:08.640 --> 00:01:12.200 a simple diagram of whatever it is you're building, break 27 00:01:12.239 --> 00:01:15.280 it down into its core components, the data flows, and 28 00:01:15.319 --> 00:01:18.239 then you start looking for these things called trust boundaries 29 00:01:18.319 --> 00:01:19.079 trust boundaries. 30 00:01:19.120 --> 00:01:21.120 Okay, now you're making me feel like I need security 31 00:01:21.159 --> 00:01:22.439 clearance just to listen to this. 32 00:01:22.680 --> 00:01:25.159 Not at all. Think of it this way. A trust 33 00:01:25.159 --> 00:01:27.799 boundary is just like a line that you draw between 34 00:01:27.879 --> 00:01:31.799 areas with different levels of well trust, like data moving 35 00:01:31.840 --> 00:01:34.640 within your own secure network, you know, that's one level 36 00:01:34.680 --> 00:01:37.439 of trust. But anything coming in from the internet, you know, 37 00:01:37.560 --> 00:01:40.200 users that you don't know, that's that's crossing a boundary, 38 00:01:40.280 --> 00:01:41.920 and that's where you need to be extra careful. 39 00:01:42.000 --> 00:01:45.159 Okay, ah, that makes sense. So once you've got your 40 00:01:45.439 --> 00:01:47.760 you know, your diagram and your boundaries all figured out, 41 00:01:48.000 --> 00:01:49.760 how do you actually spot those threats? 42 00:01:50.000 --> 00:01:54.000 Well, Shastek introduces this really handy framework. It's called STRIDE 43 00:01:54.480 --> 00:01:59.200 and it's a mnemonic. It stands for spoofing, tampering, repudiation, 44 00:02:00.079 --> 00:02:04.400 information disclosure, denial of service, and elevation of privilege. 45 00:02:04.480 --> 00:02:06.280 Oh you know what, it's funny you mentioned that I 46 00:02:06.280 --> 00:02:10.080 actually played the Elevation of Privileged card game once at 47 00:02:10.080 --> 00:02:14.000 a security conference and it was a blast. It really 48 00:02:14.120 --> 00:02:17.599 drove home how even seemingly small details can open the 49 00:02:17.599 --> 00:02:19.439 door to these big security problems. 50 00:02:19.479 --> 00:02:21.560 Oh it's fantastic. It's a fantastic way to learn, and 51 00:02:21.599 --> 00:02:24.479 it highlights how threat modeling can be, you know, collaborative, 52 00:02:24.560 --> 00:02:26.199 it can even be fun. Doesn't have to be all 53 00:02:26.240 --> 00:02:27.199 doom and gloom. 54 00:02:27.039 --> 00:02:29.639 Right right, Okay, So let's get practical here. Let's say 55 00:02:29.639 --> 00:02:32.560 we're building a simple web application like the ACME Corporation 56 00:02:32.639 --> 00:02:35.120 example from the book. How would we how would we 57 00:02:35.159 --> 00:02:38.639 apply stry to find those potential threats? 58 00:02:38.800 --> 00:02:41.599 Well, let's take information disclosure as an example. If ACME 59 00:02:41.719 --> 00:02:44.960 isn't super careful about validating user input on their web forms, 60 00:02:45.199 --> 00:02:48.240 an attacker could use something called seql injection to you know, 61 00:02:48.599 --> 00:02:51.680 sneak into their database and access all sorts of sensitive information. 62 00:02:51.919 --> 00:02:55.520 Ouch. Yeah, that's that's not good. And I bet there 63 00:02:55.520 --> 00:02:57.879 are a ton of other threats lurking out there, just 64 00:02:57.960 --> 00:02:58.919 depending on the system. 65 00:02:59.319 --> 00:03:02.400 Absolutely, and showstak makes it clear there are different ways 66 00:03:02.439 --> 00:03:05.319 to go about this whole threat modeling process. You can 67 00:03:05.400 --> 00:03:09.039 focus on your most valuable assets or you can think 68 00:03:09.120 --> 00:03:11.560 like an attacker, you know, get in their head or 69 00:03:12.000 --> 00:03:14.639 and this is often the best starting point. You can 70 00:03:14.680 --> 00:03:18.680 really dig into the software itself. It's architecture and how 71 00:03:18.680 --> 00:03:19.599 it all works together. 72 00:03:19.759 --> 00:03:21.680 So it's like it's like choosing the right tool for 73 00:03:21.719 --> 00:03:24.120 the job, you know, Yeah, depending on what you're building 74 00:03:24.199 --> 00:03:26.560 and what you're most worried about exactly. 75 00:03:26.719 --> 00:03:30.080 The key is to have a structured approach, and Stride 76 00:03:30.120 --> 00:03:33.199 is a great framework to start with. But it's not 77 00:03:33.280 --> 00:03:35.800 just about finding these threats. It's also about figuring out 78 00:03:35.879 --> 00:03:37.680 how to deal with them right. 79 00:03:37.599 --> 00:03:40.199 Right, Because let's be honest, you can't eliminate every single threat, 80 00:03:40.240 --> 00:03:43.159 can you. I mean that would probably be like impossible. 81 00:03:43.240 --> 00:03:45.520 You're absolutely right, and that's where risk management comes in. 82 00:03:45.560 --> 00:03:48.639 You got to prioritize Some risks might be so minor 83 00:03:48.680 --> 00:03:51.199 that you can just accept them. Others you might transfer 84 00:03:51.280 --> 00:03:54.199 to a to a vendor or a specialist. But for 85 00:03:54.280 --> 00:03:56.560 the big ones, the critical ones, you need to actively 86 00:03:56.680 --> 00:03:57.280 mitigate them. 87 00:03:57.520 --> 00:03:59.960 So you're saying, it's all about choosing your battles wisely, 88 00:04:00.479 --> 00:04:03.240 don't sweat the small stuff, but be prepared to go 89 00:04:03.360 --> 00:04:05.560 all in on the threats that could really hurt you. 90 00:04:05.919 --> 00:04:09.719 Precisely. And one thing Shostak emphasizes is that you can't 91 00:04:09.759 --> 00:04:11.960 just assume and tacker will stop at the first hurdle. 92 00:04:12.080 --> 00:04:15.840 You know, you need what he calls a defense in depth, 93 00:04:16.399 --> 00:04:19.720 multiple layers of security, so that even if one fails, 94 00:04:19.879 --> 00:04:20.800 you've got back up. 95 00:04:20.879 --> 00:04:24.800 Oh, like a castle with multiple walls and moatsh I 96 00:04:24.959 --> 00:04:28.040 like that. It's making me think about my own online accounts. 97 00:04:28.040 --> 00:04:30.480 Maybe just having a strong password isn't enough. 98 00:04:30.519 --> 00:04:34.199 You're catching on. And here's where Shostak's book gets really practical. 99 00:04:34.279 --> 00:04:40.120 Chapter twelve, The Requirements Cookbook is packed with specific security recommendations. 100 00:04:40.319 --> 00:04:44.879 He covers everything from authentication to logging to data integrity. 101 00:04:45.040 --> 00:04:47.480 Okay, I have to admit when I skim that chapter, 102 00:04:47.839 --> 00:04:50.800 my head started to spin a little. Do you really 103 00:04:50.839 --> 00:04:55.000 think people need to implement every single thing that in 104 00:04:55.040 --> 00:04:55.720 that cookbook? 105 00:04:55.839 --> 00:04:58.839 Of course not. It's a starting point, a menu of options, 106 00:04:58.879 --> 00:05:02.160 not a you know, a mandatory checklist. But here's the thing. 107 00:05:02.959 --> 00:05:05.399 Even picking a few key items from that chapter and 108 00:05:05.439 --> 00:05:09.079 applying them to your project can dramatically improve its security. 109 00:05:09.240 --> 00:05:12.040 That's reassuring. So it's more about being smart and strategic, 110 00:05:12.160 --> 00:05:15.680 not about becoming some kind of you know, security Superhero 111 00:05:15.720 --> 00:05:16.680 Overnight exactly. 112 00:05:16.680 --> 00:05:18.879 You start with the basics and you build from there. 113 00:05:18.920 --> 00:05:21.120 The key is to make threat modeling a habit, a 114 00:05:21.160 --> 00:05:23.199 part of your process, not just a you know, a 115 00:05:23.240 --> 00:05:24.079 one time thing. 116 00:05:24.120 --> 00:05:26.959 Right right. This is all incredibly helpful, but I have 117 00:05:27.000 --> 00:05:30.199 to ask, how does this apply to like the world 118 00:05:30.279 --> 00:05:34.160 of web applications and cloud platforms, because things are changing 119 00:05:34.199 --> 00:05:35.199 so fast in that space. 120 00:05:35.439 --> 00:05:38.680 Oh, you're right. The landscape is constantly evolving, and that's 121 00:05:38.680 --> 00:05:41.120 why chapter thirteen is so important. It dives into the 122 00:05:41.199 --> 00:05:47.279 specific challenges of web and cloud security, things like insider threats, 123 00:05:47.920 --> 00:05:51.920 tenant behavior in shared cloud environments. You know, these are 124 00:05:51.920 --> 00:05:53.439 all things you need to be thinking about. 125 00:05:53.560 --> 00:05:56.959 Insider threats. Huh, that's a scary thought. You're basically saying 126 00:05:57.000 --> 00:05:59.920 you can't even trust everyone within your own organization. 127 00:06:00.160 --> 00:06:02.800 Well, it's not about you know, assuming the worst in people, 128 00:06:02.839 --> 00:06:05.959 but it is about understanding that that not all threats 129 00:06:06.000 --> 00:06:09.720 come from you know, these external attackers. Sometimes the vulnerabilities 130 00:06:09.759 --> 00:06:10.160 lie within. 131 00:06:10.279 --> 00:06:12.480 Okay, so you're telling me to trust no one, not 132 00:06:12.560 --> 00:06:13.439 even my own team. 133 00:06:13.720 --> 00:06:16.079 Not quite. It's more about being aware of the different 134 00:06:16.079 --> 00:06:20.480 ways data can be accessed, misused, or even accidentally exposed, 135 00:06:20.800 --> 00:06:22.759 and of course. A big part of this is protecting 136 00:06:22.879 --> 00:06:27.600 user data, especially when it comes to accounts and identity. 137 00:06:27.160 --> 00:06:30.639 Management, which is perfect segue to chapter fourteen. Yeah right, 138 00:06:30.639 --> 00:06:32.800 that felt like a bit of a crash course. In 139 00:06:32.839 --> 00:06:35.040 all things accounts and passwords, it's. 140 00:06:34.959 --> 00:06:37.920 Essential reading and one of the most insightful things Shastak 141 00:06:38.000 --> 00:06:41.759 says is you have to accept account existence as something 142 00:06:41.800 --> 00:06:45.240 an attacker can learn, so you focus on usability from 143 00:06:45.279 --> 00:06:49.079 that point on, and he really slams knowledge based authentication. 144 00:06:49.920 --> 00:06:52.639 You know those security questions that are often anything but secure. 145 00:06:52.800 --> 00:06:56.160 Oh yeah, I hate those. Yeah, what street did you 146 00:06:56.199 --> 00:06:58.439 grow up on? Like, I'm going to remember that off 147 00:06:58.480 --> 00:06:58.879 the top of my. 148 00:06:58.920 --> 00:07:03.519 Head exactly, and Deck points to things like multi factor 149 00:07:03.560 --> 00:07:07.000 authentication as a much, a much stronger alternative. It's about 150 00:07:07.040 --> 00:07:09.680 adding layers of security, just like we talked about with 151 00:07:09.759 --> 00:07:10.600 defense and depth. 152 00:07:10.639 --> 00:07:13.480 Okay, so we've got our diagrams, our stride framework, our 153 00:07:13.480 --> 00:07:17.319 requirements cookbook. But there's still one piece missing, isn't there? 154 00:07:17.439 --> 00:07:18.319 The human element? 155 00:07:18.519 --> 00:07:21.839 You're absolutely right, and that's where chapter fifteen gets really interesting. 156 00:07:21.920 --> 00:07:24.879 It dives into the psychology of security, how our own 157 00:07:24.959 --> 00:07:28.360 brains can sometimes well work against us. 158 00:07:28.399 --> 00:07:31.399 Our brain's working against us. Yeah, Okay, now I'm really intrigued. 159 00:07:31.759 --> 00:07:35.839 It's all about these things called cognitive biases, things like anchoring, 160 00:07:36.480 --> 00:07:38.800 where we get fixated on the first piece of information 161 00:07:38.879 --> 00:07:41.360 we see, even if it's even if it's wrong or 162 00:07:42.959 --> 00:07:47.360 WYSIID what you see is all there is, which can 163 00:07:47.360 --> 00:07:51.120 make us kind of blind to potential dangers lurking just 164 00:07:51.240 --> 00:07:53.199 outside our immediate view. 165 00:07:53.360 --> 00:07:56.839 Wow, that's fascinating. So it's not just about building secure systems, 166 00:07:56.839 --> 00:08:01.040 it's about understanding how people actually use those systems right 167 00:08:01.199 --> 00:08:04.800 and designing them in a way that minimizes, you know, 168 00:08:05.040 --> 00:08:06.839 the risk of human error exactly. 169 00:08:06.879 --> 00:08:09.040 And Shasta gives some great examples of how this plays 170 00:08:09.040 --> 00:08:11.879 out in the real world, like those phishing emails that 171 00:08:11.920 --> 00:08:14.639 create this this sense of urgency to trick you into 172 00:08:14.680 --> 00:08:16.279 clicking on a malicious link. 173 00:08:16.360 --> 00:08:19.240 Oh man, I've totally fallen for those before. You feel 174 00:08:19.240 --> 00:08:21.079 like you have to act immediately and you don't start 175 00:08:21.120 --> 00:08:22.199 to think critically about it. 176 00:08:22.240 --> 00:08:24.519 That's exactly what the attackers are counting on. So part 177 00:08:24.519 --> 00:08:27.800 of threat modeling is understanding these these psychological traps and 178 00:08:27.800 --> 00:08:30.879 designing systems that help users, you know, avoid them. 179 00:08:30.920 --> 00:08:33.399 This is blowing my mind. It's like it's like security 180 00:08:33.440 --> 00:08:34.639 meets behavioral science. 181 00:08:34.960 --> 00:08:37.840 It really is, and it highlights how security is not 182 00:08:38.000 --> 00:08:40.960 just a technical problem, it's a human problem. We need 183 00:08:40.960 --> 00:08:44.120 to understand both sides of the equation to build truly 184 00:08:44.240 --> 00:08:45.240 secure systems. 185 00:08:45.679 --> 00:08:48.639 After all that, I'm starting to feel a little overwhelmed. 186 00:08:49.200 --> 00:08:50.679 Is there any hope for those of us who aren't 187 00:08:50.919 --> 00:08:52.440 you know, cryptography experts. 188 00:08:52.559 --> 00:08:55.840 You're not alone. But here's the good news. You don't 189 00:08:55.879 --> 00:08:59.000 have to be a cryptogenius to build secure systems. In fact, 190 00:08:59.399 --> 00:09:03.600 Shastak has some very reassuring words for us in chapter sixteen. 191 00:09:03.679 --> 00:09:06.080 Okay, call me more. I need some good news right 192 00:09:06.120 --> 00:09:06.559 about now. 193 00:09:06.639 --> 00:09:09.840 He basically says, don't reinvent the wheel when it comes 194 00:09:09.840 --> 00:09:15.120 to cryptography. Use well vetted, you know, existing cryptosystems. Don't 195 00:09:15.120 --> 00:09:18.159 try to create your own, your own encryption algorithms unless 196 00:09:18.159 --> 00:09:21.039 you're you know, a world renowned expert, because the odds 197 00:09:21.039 --> 00:09:23.120 of you messing it up are pretty high. 198 00:09:23.240 --> 00:09:25.480 Yeah, that makes sense. Why reinvent the wheel if someone's 199 00:09:25.480 --> 00:09:26.519 already done the hard work for you. 200 00:09:26.840 --> 00:09:32.399 Exactly, and he calls this the cryptographic doom principle. Get 201 00:09:32.440 --> 00:09:35.399 crypto right and you're good. Get it wrong and the 202 00:09:35.399 --> 00:09:39.120 consequences can be catastrophic. It all comes back to understanding 203 00:09:39.159 --> 00:09:40.399 those trust boundaries. 204 00:09:40.840 --> 00:09:44.320 So trust the experts, know your boundaries, for the love 205 00:09:44.320 --> 00:09:46.840 of all that is secure. Don't try to create your 206 00:09:46.840 --> 00:09:48.120 own encryption algorithm. 207 00:09:48.240 --> 00:09:50.559 You got it. And that's just scratching the surface of 208 00:09:50.559 --> 00:09:52.600 what Shashtak covers in the book. We've still got so 209 00:09:52.679 --> 00:09:56.240 much more to unpack, including how to actually make threat 210 00:09:56.279 --> 00:09:59.919 modeling a regular part of your process, how to con 211 00:10:00.080 --> 00:10:02.440 vince your team to you know, to get on board, 212 00:10:02.720 --> 00:10:05.279 and even a glimpse into the future of threat modeling 213 00:10:05.679 --> 00:10:09.679 with things like threat genomics and adversarial machine learning. 214 00:10:09.759 --> 00:10:13.639 Wow, I am definitely feeling inspired, but also a little 215 00:10:13.639 --> 00:10:15.960 overwhelmed by all this information. Maybe we should take a 216 00:10:16.000 --> 00:10:17.960 quick break here and come back for part two of 217 00:10:18.000 --> 00:10:22.399 our deep dive to explore these more these more advanced concepts. 218 00:10:22.600 --> 00:10:25.120 Sounds like a plan. We've laid a solid foundation, and 219 00:10:25.159 --> 00:10:26.799 now it's time to build on it and see how 220 00:10:26.799 --> 00:10:29.080 we can apply these ideas to create a more secure 221 00:10:29.159 --> 00:10:33.120 digital world. All right, so let's jump back into this 222 00:10:33.159 --> 00:10:36.159 fascinating world of threat modeling. One thing that really struck 223 00:10:36.200 --> 00:10:38.080 me as we were, you know, prepping for this deep 224 00:10:38.120 --> 00:10:41.960 dive was how much emphasis Adam Shastak puts on clarity 225 00:10:42.240 --> 00:10:44.000 when it comes to diagramming systems. 226 00:10:44.200 --> 00:10:46.879 Oh. Absolutely, a messy diagram is like a recipe for 227 00:10:46.960 --> 00:10:49.960 disaster when you're when you're trying to threat model. Yeah, 228 00:10:50.000 --> 00:10:51.720 it's it's got to be crystal clear so you don't 229 00:10:51.759 --> 00:10:53.840 miss any any crucial vulnerability. 230 00:10:53.919 --> 00:10:56.440 Exactly. It's not just about having a diagram, it's about 231 00:10:56.440 --> 00:11:00.639 having a good one. And data flow diagrams or DFDs, 232 00:11:00.679 --> 00:11:03.080 they seem to be like the gold standard for threat 233 00:11:03.080 --> 00:11:06.919 modeling because they visually show how that data is moving 234 00:11:06.960 --> 00:11:07.639 through your system. 235 00:11:08.240 --> 00:11:12.840 Yeah, DFDs there, they're fantastic for visualizing those trust boundaries 236 00:11:12.879 --> 00:11:15.159 we talked about earlier. Yeah, it's like shining a spotlight 237 00:11:15.200 --> 00:11:18.000 on those on those exact points where an attacker might 238 00:11:18.000 --> 00:11:19.159 try to sneak in. 239 00:11:19.320 --> 00:11:24.320 Yeah. And once you've got those those entry points you know, highlighted, 240 00:11:24.360 --> 00:11:28.519 you can systematically analyze each one using the Stride framework. 241 00:11:28.559 --> 00:11:32.399 Are they susceptible to spoofing, tampering, repudiation? You go through 242 00:11:32.440 --> 00:11:35.559 the whole list and really dissect those potential weaknesses. 243 00:11:35.960 --> 00:11:39.840 It's like having a mental checklist almost for security vulnerabilities. 244 00:11:40.039 --> 00:11:42.759 And it's amazing how many things you might overlook if 245 00:11:42.759 --> 00:11:44.720 you don't have that structured approach. 246 00:11:45.399 --> 00:11:49.000 Absolutely, and Shastak goes beyond just you know, theory. He 247 00:11:49.039 --> 00:11:52.320 gives tons of practical tips in the book, like the 248 00:11:52.360 --> 00:11:57.360 importance of validating data from from untrusted sources. Never never 249 00:11:57.480 --> 00:12:01.879 just blindly trust user input or data coming from external systems. 250 00:12:01.879 --> 00:12:03.960 Oh, I've learned that lesson the hard way a few times. Yeah, 251 00:12:04.039 --> 00:12:06.759 it's so easy to assume that that data is, you know, 252 00:12:06.960 --> 00:12:09.879 clean and well intentioned, but you really, you really have 253 00:12:09.919 --> 00:12:12.559 to treat everything with a with a healthy dose of suspicions. 254 00:12:12.679 --> 00:12:15.440 Yeah, you got it. Input validation. It's it's like that 255 00:12:15.519 --> 00:12:18.440 first line of defense against against a whole range of 256 00:12:18.879 --> 00:12:23.360 injection attacks, including that that sneaky sequel injection we talked 257 00:12:23.399 --> 00:12:24.000 about earlier. 258 00:12:24.080 --> 00:12:26.320 Yeah, and let's not forget about logging. I used to 259 00:12:26.360 --> 00:12:29.159 think of logs as like just boring technical stuff, you know, 260 00:12:29.559 --> 00:12:31.600 but the book, the book really opened my eyes to 261 00:12:31.639 --> 00:12:34.919 how crucial they are for security, especially when it comes 262 00:12:34.919 --> 00:12:37.519 to those those tricky repudiation threats. 263 00:12:37.720 --> 00:12:40.840 You're right, logs can be like a life saver when 264 00:12:40.840 --> 00:12:44.159 you need to investigate a security incident. They're like a 265 00:12:44.159 --> 00:12:48.120 detective's notebook, you know. Helping you piece together what happened, 266 00:12:48.200 --> 00:12:50.759 who is involved, and how to prevent it from happening again. 267 00:12:50.919 --> 00:12:54.200 But but logs are only useful if they're protected right 268 00:12:54.799 --> 00:12:57.320 and reliable. What's the point of having a you know, 269 00:12:57.440 --> 00:13:00.960 a security camera if someone can just just tamper. 270 00:13:00.639 --> 00:13:03.799 With the footage exactly. Shastak really stresses the importance of 271 00:13:03.840 --> 00:13:07.559 protecting those those log files from tampering and making sure 272 00:13:07.559 --> 00:13:10.279 they're stored securely. You don't want to create a vulnerability 273 00:13:10.320 --> 00:13:13.000 while you're you know, while you're trying to solve another one. 274 00:13:13.080 --> 00:13:15.200 That's true, that's true. You know. One of the things 275 00:13:15.240 --> 00:13:18.399 that really that really clicked for me was this concept 276 00:13:18.440 --> 00:13:23.200 of defense in depth. So tempting to just think, Okay, 277 00:13:23.639 --> 00:13:27.240 I've implemented this one security measure, I'm good. But but 278 00:13:27.240 --> 00:13:28.519 that's rarely enough, is it? 279 00:13:28.879 --> 00:13:31.399 Not? At all? Shostak really drives home the point that 280 00:13:31.440 --> 00:13:34.279 you need you need multiple layers of security. It's it's 281 00:13:34.279 --> 00:13:39.039 like building a castle with walls and moats and guard towers. 282 00:13:39.080 --> 00:13:40.879 You know, each layer makes it that much harder for 283 00:13:41.320 --> 00:13:43.159 an attacker to breach your defenses. 284 00:13:43.799 --> 00:13:46.600 It makes you realize that security is not a you know, 285 00:13:46.639 --> 00:13:48.879 not a destination. It's a journey. Yeah, you have to 286 00:13:48.879 --> 00:13:52.480 constantly be evaluating your defense is, looking for looking for 287 00:13:52.519 --> 00:13:54.000 weak points, and making improvements. 288 00:13:54.039 --> 00:13:57.399 Absolutely, it's it's an ongoing process and it requires vigilance 289 00:13:57.480 --> 00:14:02.440 and a willingness to adapt as the threat landscape changes. 290 00:14:02.720 --> 00:14:05.879 You know. Shostak also talks about the importance of understanding 291 00:14:06.679 --> 00:14:09.639 trade offs when it comes to security. Sometimes the most 292 00:14:09.679 --> 00:14:12.480 secure solution just isn't feasible, right, Right, Like. 293 00:14:12.600 --> 00:14:14.919 You could build an impenetrable fortress, but if it's so 294 00:14:15.000 --> 00:14:17.679 restrictive that no one can actually use it, what's the 295 00:14:17.679 --> 00:14:18.559 point exactly? 296 00:14:18.600 --> 00:14:23.639 It's about finding the right balance between security and usability 297 00:14:23.919 --> 00:14:27.200 and cost. Sometimes you might choose to accept a certain 298 00:14:27.240 --> 00:14:29.840 level of risk if the cost of mitigating it is 299 00:14:29.879 --> 00:14:30.960 just just too high. 300 00:14:31.039 --> 00:14:34.080 Right. So it sounds like threat modeling forces you to 301 00:14:33.679 --> 00:14:36.039 be to be really honest with yourself about what you're 302 00:14:36.840 --> 00:14:39.960 willing to risk, yeah, and what you absolutely need to 303 00:14:39.960 --> 00:14:42.840 to protect. It's a tough call, but an essential one, 304 00:14:42.879 --> 00:14:43.080 you know. 305 00:14:43.240 --> 00:14:46.240 Couldn't agree more. And one thing Shostak emphasizes is that 306 00:14:46.840 --> 00:14:49.879 threat modeling shouldn't be a one time event. It needs 307 00:14:49.919 --> 00:14:53.519 to be like beaked into your entire development life cycle. 308 00:14:53.639 --> 00:14:55.519 So it's not like checking a box and moving on. 309 00:14:55.600 --> 00:14:58.879 It's more about making threat modeling a part of your DNA, 310 00:14:59.159 --> 00:15:02.559 part of how you how you approach every every project 311 00:15:02.559 --> 00:15:03.639 from from start to finish. 312 00:15:03.720 --> 00:15:06.360 You nailed it. Whether you're using an agile methodology or 313 00:15:06.399 --> 00:15:10.639 a more traditional, you know, waterfall approach, threat modeling should 314 00:15:10.679 --> 00:15:17.039 be should be woven into into every stage of development, design, implementation, testing, deployment, 315 00:15:17.159 --> 00:15:18.919 you know, it all needs to be considered through a 316 00:15:19.120 --> 00:15:20.200 through a security lens. 317 00:15:20.320 --> 00:15:22.919 It's it's like you're you're constantly checking your blind spots, 318 00:15:23.799 --> 00:15:26.840 anticipating potential problems before they even even. 319 00:15:26.639 --> 00:15:30.320 Arise, exactly. And it's not just about that initial development 320 00:15:30.320 --> 00:15:33.240 phase either. As you add new features, you know, make 321 00:15:33.360 --> 00:15:38.080 changes to your your code or integrate with with external systems, 322 00:15:38.120 --> 00:15:40.559 you need to revisit your your threat model and it 323 00:15:40.559 --> 00:15:41.639 makes sure it's still relevant. 324 00:15:41.759 --> 00:15:44.840 It's like that that old saying eternal vigilance is the 325 00:15:44.879 --> 00:15:49.000 price of liberty, except in this case it's the price 326 00:15:49.000 --> 00:15:49.679 of security. 327 00:15:49.879 --> 00:15:53.320 Uh huh. That's a great analogy. And and Shastak gives 328 00:15:53.320 --> 00:15:56.759 some really practical advice on how to integrate threat modeling 329 00:15:57.279 --> 00:16:02.320 into into different different development methodologies, even fast paced ones 330 00:16:02.399 --> 00:16:04.480 like like agile and DevOps. 331 00:16:04.279 --> 00:16:05.879 That's that's where're sureing. I think a lot of people 332 00:16:05.960 --> 00:16:08.399 assume that threat modeling is like too cumbersome for those 333 00:16:08.440 --> 00:16:11.039 types of those types of environments, but it sounds like 334 00:16:11.080 --> 00:16:13.480 it can be. It can be adapted to fit to 335 00:16:13.519 --> 00:16:14.559 fit any workflow. 336 00:16:14.799 --> 00:16:18.440 Absolutely. The key is to break down threat modeling activities 337 00:16:18.440 --> 00:16:22.000 into into smaller, more manageable tasks that can be integrated 338 00:16:22.039 --> 00:16:23.759 into your existing process. 339 00:16:23.840 --> 00:16:26.000 So it's not about adding this this whole new layer 340 00:16:26.039 --> 00:16:30.840 of bureaucracy. It's it's about incorporating incorporating security thinking into 341 00:16:31.120 --> 00:16:32.080 into everything you do. 342 00:16:32.559 --> 00:16:34.799 You got it, And that even extends to you know, 343 00:16:34.879 --> 00:16:38.799 testing activities. Shawstak talks about how how threat modeling can 344 00:16:38.840 --> 00:16:42.639 inform your testing strategy, helping you develop more, more targeted 345 00:16:42.720 --> 00:16:44.279 and effective test cases. 346 00:16:44.360 --> 00:16:46.720 It's like you're not just testing to see if the 347 00:16:46.759 --> 00:16:49.360 software works. You're testing to see if it's if it's secure, 348 00:16:49.600 --> 00:16:51.679 if it can withstand withstand attacks. 349 00:16:51.759 --> 00:16:56.039 Exactly. By understanding those those potential threats, testers can really 350 00:16:56.080 --> 00:16:59.080 put those defenses to the test and try to break them, 351 00:16:59.240 --> 00:17:03.600 which ultimately leads to a more secure and resilient system. 352 00:17:03.879 --> 00:17:07.279 Okay, okay, I'm loving all this practical advice. But I 353 00:17:07.319 --> 00:17:09.799 want to circle back to something we touched on earlier, 354 00:17:10.279 --> 00:17:15.200 the human element. We talked about cognitive biases and how 355 00:17:15.200 --> 00:17:17.799 our own brains can can sometimes make us make us 356 00:17:17.880 --> 00:17:19.799 vulnerable to attacks. Can you can you go a little 357 00:17:19.799 --> 00:17:22.640 deeper into that. I'm really fascinated by this whole, this 358 00:17:22.680 --> 00:17:24.240 whole psychology of security thing. 359 00:17:24.519 --> 00:17:26.079 I'm glad you brought that up. It's it's such an 360 00:17:26.119 --> 00:17:30.039 important aspect of security, and in Shostak dedicates a whole 361 00:17:30.119 --> 00:17:32.920 chapter to it in the book. He really dives deep 362 00:17:33.000 --> 00:17:37.440 into how our cognitive biases can make us susceptible to 363 00:17:38.359 --> 00:17:40.960 things like like social engineering attacks. 364 00:17:41.000 --> 00:17:44.400 Okay, so so remind me again what are cognitive biases. 365 00:17:44.680 --> 00:17:47.880 I feel like I need a refresher course in psychology. 366 00:17:48.400 --> 00:17:51.559 Think of them as as mental shortcuts almost that our 367 00:17:51.559 --> 00:17:55.880 brains take to process information quickly. They're often helpful in 368 00:17:55.920 --> 00:17:58.960 everyday life, but when it comes to security, they can 369 00:17:59.160 --> 00:18:00.680 they can kind of lead us astray. 370 00:18:00.839 --> 00:18:02.839 So it's it's like our brains are trying to help us, 371 00:18:02.839 --> 00:18:06.440 but they're actually making us, making us more more vulnerable. 372 00:18:06.000 --> 00:18:10.200 To attack sometimes. Yes, Shostak talks about biases like anchoring, 373 00:18:10.279 --> 00:18:12.480 where we where we get fixated on the first piece 374 00:18:12.480 --> 00:18:14.839 of information we see, even if it's even if it's wrong, 375 00:18:15.200 --> 00:18:18.079 and uh, and confirmation bias, where we tend to seek 376 00:18:18.119 --> 00:18:21.920 out information that confirms our our existing beliefs, even if 377 00:18:21.920 --> 00:18:23.720 those those beliefs are flawed. 378 00:18:23.960 --> 00:18:26.079 Oh, I'm totally guilty of that. If if I've already 379 00:18:26.079 --> 00:18:27.920 made up my mind about something, it's it's hard to 380 00:18:27.960 --> 00:18:30.480 convince me otherwise, even if there's even if there's evidence 381 00:18:30.480 --> 00:18:31.200 to the contrary. 382 00:18:31.319 --> 00:18:33.640 We all do it. It's it's just how our brains 383 00:18:33.680 --> 00:18:38.039 are wired. But in the context of security, that can 384 00:18:38.039 --> 00:18:41.039 be that can be dangerous. For example, if you're if 385 00:18:41.079 --> 00:18:44.079 you're convinced that that a certain type of attack can't 386 00:18:44.119 --> 00:18:47.039 happen to you, you might be less likely to take 387 00:18:47.039 --> 00:18:50.599 precautions or to recognize the warning signs, you know, right. 388 00:18:50.559 --> 00:18:52.839 Right, So it's not just about building, you know, building 389 00:18:52.920 --> 00:18:57.240 secure systems. It's about understanding how people actually use those 390 00:18:57.279 --> 00:19:00.680 systems and designing them in a way that that minimizes 391 00:19:00.720 --> 00:19:03.079 the risk of human error exactly. 392 00:19:03.200 --> 00:19:05.960 And that's where the idea of usable security comes in. 393 00:19:06.039 --> 00:19:08.559 You want to build systems that are not only technically 394 00:19:09.240 --> 00:19:14.039 you know, robust, but also but also user friendly, intuitive, right. 395 00:19:14.079 --> 00:19:17.640 So, so it's about guiding users towards safe choices without 396 00:19:17.680 --> 00:19:20.920 making them feel like they're they're constantly walking through through 397 00:19:21.640 --> 00:19:24.200 a minefield of security warnings and restrictions. 398 00:19:24.640 --> 00:19:26.160 That's a great way to put it. You want you 399 00:19:26.200 --> 00:19:30.039 want security to be almost invisible, seamlessly integrated into the 400 00:19:30.200 --> 00:19:33.119 into the user experience, so people so people don't even 401 00:19:33.160 --> 00:19:34.960