WEBVTT 1 00:00:00.120 --> 00:00:05.160 Imagine waking up to an alert that your company's entire 2 00:00:05.240 --> 00:00:08.679 customer database has just been exposed to the public internet. 3 00:00:08.759 --> 00:00:11.519 Oh, that is the absolute nightmare scenario. 4 00:00:11.320 --> 00:00:15.279 Right, So you scramble to figure out, like what sophisticated 5 00:00:15.359 --> 00:00:19.440 hacking syndicate managed to breach your firewalls, only to discover 6 00:00:19.519 --> 00:00:22.839 there was no hack yet, none at all. A developer 7 00:00:22.839 --> 00:00:25.280 simply made a typo in a text file and your 8 00:00:25.320 --> 00:00:29.320 network automatically deleted its own security walls. And you know, 9 00:00:29.440 --> 00:00:33.000 under European GDPR laws, you now have exactly seventy two 10 00:00:33.079 --> 00:00:35.079 hours to report that personal data breach. 11 00:00:35.240 --> 00:00:38.119 Yeah, and you are staring down a potential fine of 12 00:00:38.359 --> 00:00:42.840 twenty million euros or four percent of your global revenue, 13 00:00:43.000 --> 00:00:43.719 whichever is. 14 00:00:43.719 --> 00:00:46.280 Higher, which is just wild. But I mean, it's a 15 00:00:46.359 --> 00:00:49.159 terrifying scenario, and it happens way more often than companies 16 00:00:49.200 --> 00:00:50.280 actually want to admit. 17 00:00:50.119 --> 00:00:52.039 It really does. I mean the physical reality we used 18 00:00:52.039 --> 00:00:54.280 to rely on for security, you know, the concrete building, 19 00:00:54.320 --> 00:00:56.880 the heavy steel vault, the single front door with a 20 00:00:56.920 --> 00:00:58.840 security guard, that is entirely gone. 21 00:00:58.920 --> 00:01:03.320 It's completely gone. Operating in this invisible shape shifting architecture 22 00:01:03.520 --> 00:01:05.400 where the vault might be spinning of and down a 23 00:01:05.480 --> 00:01:09.359 thousand times a day exactly. So whether you are prepping 24 00:01:09.400 --> 00:01:12.319 for a massive infrastructure meeting this week, or you're just 25 00:01:12.439 --> 00:01:16.239 inherently curious about the invisible plumbing that powers the modern Internet, 26 00:01:16.879 --> 00:01:19.079 you are in the right place to figure out how 27 00:01:19.120 --> 00:01:21.640 this actually works. Welcome to today's deep dive. 28 00:01:21.920 --> 00:01:23.840 Glad to be here for this one. It's a big. 29 00:01:23.640 --> 00:01:27.079 Topic, it really is. Today we are pulling from a massive, 30 00:01:27.359 --> 00:01:31.760 multi author dossier titled The Practical Guide to Security in 31 00:01:31.799 --> 00:01:35.000 the AWS Cloud, and our mission here is pretty simple. 32 00:01:35.359 --> 00:01:39.040 Cloud security is no longer just like an IT problem. 33 00:01:39.239 --> 00:01:42.959 It is a fundamental business driver. So we are going 34 00:01:43.000 --> 00:01:46.599 to extract the most critical insights from these expert blueprints 35 00:01:47.079 --> 00:01:50.359 and really build a comprehensive mental model of how to 36 00:01:50.400 --> 00:01:52.920 actually lock down a cloud environment. And we're going to 37 00:01:52.959 --> 00:01:55.319 try to do it without drowning you an acronym soup. 38 00:01:55.480 --> 00:01:57.760 Which is hard to do in this industry, but we'll try. 39 00:01:58.239 --> 00:02:01.079 What makes this particular dossier so valuable, though, is that 40 00:02:01.159 --> 00:02:03.680 it forces us to look past the endless catalog of 41 00:02:03.719 --> 00:02:07.480 security products, right It makes us understand the underlying mechanics 42 00:02:07.480 --> 00:02:08.039 of the cloud. 43 00:02:08.159 --> 00:02:10.800 Because if you don't understand the logic of the environment, 44 00:02:11.240 --> 00:02:13.360 you can't possibly secure. 45 00:02:12.960 --> 00:02:15.479 It exactly, you're just flying blind. 46 00:02:15.680 --> 00:02:18.919 So before we can even talk about, you know, encrypting 47 00:02:19.000 --> 00:02:22.439 data or setting up firewalls, the guide makes this really 48 00:02:22.479 --> 00:02:26.520 compelling case that we have to fundamentally rewire how we 49 00:02:26.599 --> 00:02:27.719 view it assets. 50 00:02:28.159 --> 00:02:30.639 Yeah, you can't just take an old on premise mentality 51 00:02:30.639 --> 00:02:32.599 and lift and shift it into the cloud. It's a 52 00:02:32.639 --> 00:02:34.639 complete recipe for disaster, which is. 53 00:02:34.639 --> 00:02:37.400 Probably the most common architectural mistake companies make. Right. 54 00:02:37.439 --> 00:02:42.280 Oh by far, organizations try to treat virtual assets the 55 00:02:42.400 --> 00:02:45.560 exact same way they treated physical hardware, and to break 56 00:02:45.560 --> 00:02:49.479 this habit, the text highlights this brilliant industry analogy originally 57 00:02:49.479 --> 00:02:53.400 introduced by Bill Baker. It's the concept of pets versus cattle. 58 00:02:53.840 --> 00:02:58.039 Okay, I love this analogy. So historically, on premise servers 59 00:02:58.039 --> 00:03:01.960 were pets, right, They were highly nurtured, uniquely named, deeply 60 00:03:02.000 --> 00:03:05.080 cared for. Like if your main database server started throwing 61 00:03:05.080 --> 00:03:07.400 aerror codes, it was an all hands on deck emergency. 62 00:03:07.479 --> 00:03:09.319 Oh yeah, you brought in the crash cart, you diagnosed 63 00:03:09.360 --> 00:03:12.840 the issue, and you basically nursed that specific, highly expensive 64 00:03:12.919 --> 00:03:14.120 machine back to health. 65 00:03:14.319 --> 00:03:16.479 But in the cloud, assets are cattle. 66 00:03:16.599 --> 00:03:21.000 Yes, they are purely functional, they are highly scalable, and importantly, 67 00:03:21.080 --> 00:03:23.919 they are designed to be easily replaced. Right if a 68 00:03:23.919 --> 00:03:26.960 cloud server goes down or you know, gets infected with something, 69 00:03:27.240 --> 00:03:29.680 you don't spend hours trying to fix it. You just 70 00:03:29.919 --> 00:03:30.439 terminate it. 71 00:03:30.520 --> 00:03:32.199 You literally just shoot it, exactly. 72 00:03:32.199 --> 00:03:35.599 You shoot it and let an automated script spin up 73 00:03:35.639 --> 00:03:39.479 a perfectly clean, identical replacement in a matter of seconds. 74 00:03:39.800 --> 00:03:43.599 And that fundamentally changes the entire premise of disaster recovery because, 75 00:03:43.919 --> 00:03:46.599 I mean, recovering a pet requires massive amounts of human 76 00:03:46.639 --> 00:03:50.960 intervention and delicate process to minimize downtime yep, But recovering 77 00:03:50.960 --> 00:03:56.080 cattle requires almost zero people, just automated technology. It completely 78 00:03:56.159 --> 00:03:58.599 rewrites your security posture, it really does. 79 00:03:58.960 --> 00:04:02.000 But to build that automated posture, you need a highly 80 00:04:02.039 --> 00:04:05.719 accurate blueprint, and that's where the dossier brings in Josh Thurston. 81 00:04:06.159 --> 00:04:09.680 He provides a methodology for mapping industry security frameworks like 82 00:04:10.599 --> 00:04:14.280 the NIST Cybersecurity Framework to actual technology. 83 00:04:13.800 --> 00:04:16.639 Because buyers and sellers are constantly getting lost trying to 84 00:04:16.639 --> 00:04:20.759 map a theoretical security control to like a specific software 85 00:04:20.800 --> 00:04:21.959 product exactly. 86 00:04:22.040 --> 00:04:25.639 So Thurston outlines three primitives to solve this. The first 87 00:04:25.720 --> 00:04:31.079 primitive asks is the control requiring people process or technology? 88 00:04:31.319 --> 00:04:32.600 Okay, break that down for me. 89 00:04:32.879 --> 00:04:36.480 So a security guard checking an ID that's people, the 90 00:04:36.639 --> 00:04:39.959 checklist they follow on their clipboard that is process, and 91 00:04:40.000 --> 00:04:43.319 the actual digital badge scanner on the wall that's technology. 92 00:04:43.639 --> 00:04:46.399 You have to isolate what you are actually solving for. 93 00:04:46.600 --> 00:04:50.120 First, that makes sense. But the second primitive this is 94 00:04:50.160 --> 00:04:54.199 where organizations just hemorrhage money. Oh, absolutely primitive too, asks 95 00:04:54.600 --> 00:04:58.240 what is the primary function of the technology you're evaluating, Like, 96 00:04:58.360 --> 00:05:01.319 does it fundamentally do the thing the control requires? Because 97 00:05:01.399 --> 00:05:04.279 vendors will constantly try to sell you one magic tool 98 00:05:04.639 --> 00:05:09.759 that claims to do everything identify, protect, detect, respond and recover. 99 00:05:09.560 --> 00:05:11.720 Which is incredibly rare in practice. 100 00:05:11.720 --> 00:05:13.600 Okay, let's unpack this for a second, because the guide 101 00:05:13.680 --> 00:05:16.319 uses a specific example of companies trying to map a 102 00:05:16.360 --> 00:05:19.839 SIME tool, a security information an event management tool to 103 00:05:19.920 --> 00:05:22.839 the NIS control labeled protect data at rest. 104 00:05:23.000 --> 00:05:24.560 Yes, the sign example is perfect. 105 00:05:24.879 --> 00:05:27.800 To me. Buying a sign to protect data is like 106 00:05:27.839 --> 00:05:30.639 buying a smoke detector and claiming it puts out fires. 107 00:05:30.959 --> 00:05:32.519 That is a great way to put it. 108 00:05:32.560 --> 00:05:36.279 Right, because a SIME only logs and aggregates alerts after 109 00:05:36.319 --> 00:05:39.879 the fact it recedes telemetry to tell you someone access 110 00:05:39.920 --> 00:05:43.399 the data, much like a camera recording a burglar, but 111 00:05:43.480 --> 00:05:46.439 it cannot physically protect the data from being accessed in 112 00:05:46.439 --> 00:05:47.120 the first place. 113 00:05:47.279 --> 00:05:51.000 Exactly, you basically mapped a detection tool to a protection 114 00:05:51.120 --> 00:05:53.879 requirement and it gives you a false sense of security. 115 00:05:54.079 --> 00:05:58.040 And why does this specific mapping matter so much for 116 00:05:58.399 --> 00:05:59.680 the listener's actual. 117 00:05:59.399 --> 00:06:02.839 Business Because when you use a framework like NIST correctly 118 00:06:03.319 --> 00:06:06.839 and you prioritize the actual primary function of your technology, 119 00:06:07.240 --> 00:06:11.439 you unlock a massive advantage. You can finally translate highly 120 00:06:11.480 --> 00:06:14.839 technical operational metrics into actual business language. 121 00:06:14.839 --> 00:06:17.079 For the board of directors, Oh that is huge. So 122 00:06:17.160 --> 00:06:19.879 you stop boring the board with stats about your time 123 00:06:19.920 --> 00:06:22.399 to detect dropping by three minutes, right. 124 00:06:22.319 --> 00:06:24.319 They don't care about that. You start showing them how 125 00:06:24.360 --> 00:06:27.920 the security team is actively decreasing the realized financial impact 126 00:06:28.000 --> 00:06:31.879 of residual risks. That is how security leaders actually secure budget. 127 00:06:32.079 --> 00:06:36.000 Makes total sense. So once that blueprint is sorted and 128 00:06:36.079 --> 00:06:38.839 you know your cameras aren't locks, we have to look 129 00:06:38.879 --> 00:06:42.199 at what we are actually protecting the payload the data. 130 00:06:42.319 --> 00:06:45.360 It's that data itself. And this is where companies fall 131 00:06:45.399 --> 00:06:49.560 into a massive, highly publicized trap. They assume moving to 132 00:06:49.600 --> 00:06:52.000 the cloud means the cloud provider just handles all the 133 00:06:52.040 --> 00:06:52.839 security for them. 134 00:06:52.920 --> 00:06:55.639 Yeah. Matt Bromley warns about this explicitly in the text. 135 00:06:55.639 --> 00:06:58.279 He says, someone else's server does not equate to someone 136 00:06:58.279 --> 00:06:59.040 else's problem. 137 00:06:59.279 --> 00:07:00.000 I love that quest. 138 00:07:00.399 --> 00:07:02.879 It's so true. We are operating in what's called the 139 00:07:02.920 --> 00:07:08.759 shared responsibility model. The cloud provider, whether that's Aws, Azure, Google, 140 00:07:09.800 --> 00:07:12.480 they are responsible for the security of the cloud, meaning 141 00:07:12.560 --> 00:07:15.759 the physical stuff exactly. They manage the physical data center, 142 00:07:15.759 --> 00:07:19.160 the arm guards, the actual hardware, the core network infrastructure. 143 00:07:19.839 --> 00:07:22.959 But the customer, you are responsible for security in. 144 00:07:22.959 --> 00:07:28.120 The cloud, so data integrity, identity management, compliance. That is 145 00:07:28.279 --> 00:07:31.040 entirely your job, one hundred percent your job. And the 146 00:07:31.079 --> 00:07:34.560 text provides a pretty brutal cautionary tale of ignoring this 147 00:07:35.079 --> 00:07:39.959 based on real industry events. They use this fictionalized rapidly 148 00:07:40.040 --> 00:07:43.480 scaling payment processing company called Bobby's. 149 00:07:43.040 --> 00:07:47.120 Bits or Bobby's Bits. They chose speedover security. They experienced 150 00:07:47.160 --> 00:07:50.279 hyper growth and migrated rapidly to the cloud, and to 151 00:07:50.360 --> 00:07:53.680 basically remove any friction for their developers, they just handed 152 00:07:53.680 --> 00:07:55.759 out shared administrative accounts to everyone. 153 00:07:55.839 --> 00:07:57.600 Wow, okay, bad start, very bad. 154 00:07:58.160 --> 00:08:01.439 Then they deployed no SQL database. Now, noseql is a 155 00:08:01.480 --> 00:08:05.120 type of non relational database that is incredibly fast and flexible, 156 00:08:05.120 --> 00:08:08.879 which is perfect for scaling web apps. But historically many 157 00:08:08.879 --> 00:08:13.439 Noseql platforms prioritize speeds so heavily that they actually deployed 158 00:08:13.480 --> 00:08:15.680 without default authentication enabled. 159 00:08:15.720 --> 00:08:17.720 Wait, so they just assumed the cloud was inherently a 160 00:08:17.720 --> 00:08:18.480 private network. 161 00:08:18.600 --> 00:08:21.720 Yep, they left the default network ports completely open and 162 00:08:21.759 --> 00:08:23.639 directly accessible to the public Internet. 163 00:08:23.800 --> 00:08:26.519 Oh man, And as the guide points out, this specific 164 00:08:26.560 --> 00:08:30.439 configuration error led to massive global ransomware attacks on no 165 00:08:30.560 --> 00:08:33.600 SQL databases back in twenty seventeen. It did. 166 00:08:33.759 --> 00:08:37.159 Hackers literally just scanned the Internet for open ports, walked 167 00:08:37.240 --> 00:08:40.759 right in and deleted the data, leaving a ransom note behind. 168 00:08:40.960 --> 00:08:44.919 They completely failed their end of the shared responsibility model spectacularly. 169 00:08:45.440 --> 00:08:47.879 But here's where it gets really interesting to me. Let's 170 00:08:47.879 --> 00:08:50.840 talk about the sheer physics of doing this correctly, especially 171 00:08:50.879 --> 00:08:53.960 for a massive enterprise. If a company has an absurd 172 00:08:54.000 --> 00:08:58.080 amount of sensitive data, like petabytes of it, they can't 173 00:08:58.120 --> 00:09:00.879 just upload that over a standard corporate Internet connection. 174 00:09:01.200 --> 00:09:04.919 No, it would take decades, literally decades, and it would 175 00:09:05.000 --> 00:09:07.679 expose the data to interception. The entire time. 176 00:09:08.159 --> 00:09:10.279 So how do you even get that much data there 177 00:09:10.360 --> 00:09:12.639 securely without exposing it over the internet. 178 00:09:12.720 --> 00:09:16.240 So AWS built a physical solution to this digital problem. 179 00:09:16.279 --> 00:09:18.200 It's called the AWS Snowmobile. 180 00:09:18.399 --> 00:09:20.240 Okay, a physical solution, what does that mean? 181 00:09:20.519 --> 00:09:24.240 It is an exabate scale data transfer service. They literally 182 00:09:24.320 --> 00:09:29.240 drive a forty five foot long ruggedized shipping container pulled 183 00:09:29.279 --> 00:09:32.960 by a semi truck directly to your corporate data center. 184 00:09:33.039 --> 00:09:34.879 Wait, really a semi truck, a. 185 00:09:34.840 --> 00:09:40.240 Literal semi truck, and the container is Tampa resistant, water resistant, 186 00:09:40.360 --> 00:09:44.960 temperature controlled, GPS tracked. They run massive fiber optic cables 187 00:09:44.960 --> 00:09:48.320 from the truck directly into your local servers, ingest the 188 00:09:48.399 --> 00:09:52.000 data at ridiculous speeds, and then physically drive the truck 189 00:09:52.120 --> 00:09:54.600 back to the AWS data center to plug it directly 190 00:09:54.600 --> 00:09:55.240 into the cloud. 191 00:09:55.559 --> 00:09:59.919 That is insane. It is basically a digital Brinks truck exactly. 192 00:10:00.039 --> 00:10:03.320 But once that payload is safely inside the cloud, you know, 193 00:10:03.360 --> 00:10:05.000 you don't just leave it sitting out in the open. 194 00:10:05.480 --> 00:10:09.679 The dossier details using AWS Key Management Service or KMS 195 00:10:10.159 --> 00:10:13.799 to encrypt everything at rest, and then they highlight Amazon Macy, 196 00:10:13.879 --> 00:10:17.320 which is fascinating. It's a service that actively uses machine 197 00:10:17.399 --> 00:10:20.639 learning to automatically discover and classify sensitive data. 198 00:10:20.799 --> 00:10:24.240 Yeah, Macy is brilliant. It continuously scans your storage buckets 199 00:10:24.279 --> 00:10:27.039 looking for patterns that match you know, credit card numbers, 200 00:10:27.039 --> 00:10:30.240 social security numbers, private keys and flags them. It continuously 201 00:10:30.279 --> 00:10:32.679 profiles the environment so you know exactly where the gold 202 00:10:32.759 --> 00:10:33.200 is buried. 203 00:10:33.360 --> 00:10:35.559 So the date is in the cloud, it's encrypted and 204 00:10:35.600 --> 00:10:39.320 it's classified. But where are the walls Because in the cloud, 205 00:10:39.519 --> 00:10:43.879 the traditional network perimeter is just entirely dead. You cannot 206 00:10:43.879 --> 00:10:46.720 rely on a single massive firewall at the edge of 207 00:10:46.720 --> 00:10:50.480 your network because your users are remote, your apps are distributed, 208 00:10:50.600 --> 00:10:52.840 and there's just no defining edge anymore. 209 00:10:52.960 --> 00:10:56.159 That's where Dave Shackelford's chapter comes in. He dives deep 210 00:10:56.240 --> 00:11:01.799 into the solution micro segmentation micro. Yes, we basically have 211 00:11:01.919 --> 00:11:06.039 to build micro revaults around every single individual asset using 212 00:11:06.120 --> 00:11:10.399 identity and network controls. He explains the concept of least 213 00:11:10.480 --> 00:11:14.840 privilege architecture, where Identity and Access Management or IM is 214 00:11:14.879 --> 00:11:15.399 the new. 215 00:11:15.200 --> 00:11:17.200 Perimeter meaning what exactly. 216 00:11:16.879 --> 00:11:18.799 Meaning when you create a new user or a new 217 00:11:18.840 --> 00:11:22.879 server in the cloud, it has an implicit deny all policy. 218 00:11:22.919 --> 00:11:24.919 It can do absolutely nothing by default. You have to 219 00:11:25.000 --> 00:11:27.399 explicitly grant every single permission. 220 00:11:27.480 --> 00:11:30.000 Okay, so that identity perimeter has to be paired with 221 00:11:30.120 --> 00:11:31.919 a granular network perimeter, then. 222 00:11:31.919 --> 00:11:34.360 Right, and the guide breaks down the two main tools 223 00:11:34.360 --> 00:11:38.919 for this network, ACLS and security groups. Understanding the mechanical 224 00:11:38.960 --> 00:11:41.639 difference between these two is absolutely vital. 225 00:11:41.679 --> 00:11:42.519 Okay, let's hear it. 226 00:11:42.679 --> 00:11:47.200 So, network access control lists or nacls are applied to 227 00:11:47.480 --> 00:11:52.279 entire subnets broad sections of your network, and importantly, they 228 00:11:52.279 --> 00:11:55.639 are stateless. Security groups, on the other hand, are applied 229 00:11:55.639 --> 00:11:59.879 to individual instances, the actual virtual servers themselves, and they 230 00:12:00.080 --> 00:12:00.720 are stateful. 231 00:12:00.840 --> 00:12:03.879 Okay, let's translate stateless versus stateful for a second. I 232 00:12:03.960 --> 00:12:05.720 like to think of it with a hotel analogy. 233 00:12:05.759 --> 00:12:06.440 Okay, let's hear it. 234 00:12:06.720 --> 00:12:10.159 Think of the entire hotel property as your cloud environment. 235 00:12:10.879 --> 00:12:14.000 The network ACL is the security guard standing at the 236 00:12:14.000 --> 00:12:17.720 front doors of the building checking IDs. They evaluate your 237 00:12:17.759 --> 00:12:20.480 credentials when you walk in, but they have no memory. 238 00:12:20.559 --> 00:12:23.159 They are stateless, so when you try to walk back 239 00:12:23.159 --> 00:12:25.200 out the front door an hour later, they have to 240 00:12:25.240 --> 00:12:28.000 evaluate your ID all over again. Every single packet of 241 00:12:28.080 --> 00:12:29.960 data is evaluated coming and going. 242 00:12:30.120 --> 00:12:32.960 That's exactly how an NaCl work and security groups act 243 00:12:33.000 --> 00:12:36.000 like the electronic lock on your specific hotel room door 244 00:12:36.360 --> 00:12:39.480 deep inside the building. If your key card successfully lets 245 00:12:39.480 --> 00:12:42.279 you into the room, the lock inherently knows to let 246 00:12:42.320 --> 00:12:44.480 you back out. It remembers the state of the connection. 247 00:12:45.120 --> 00:12:48.159 It is stateful if traffic is allowed in. The return 248 00:12:48.200 --> 00:12:51.039 traffic is automatically allowed out without a second evaluation. 249 00:12:51.559 --> 00:12:55.120 That makes total sense, But relying solely on those built 250 00:12:55.120 --> 00:13:00.039 in cloud controls isn't always enough for advanced enterprise security. 251 00:12:59.799 --> 00:13:00.159 Right Oh? 252 00:13:00.279 --> 00:13:03.559 Usually not, because modern cloud firewalls take this further by 253 00:13:03.639 --> 00:13:07.840 utilizing deep Packet Inspection or DPI. They aren't just looking 254 00:13:07.840 --> 00:13:09.759 at the shipping label to see where the network traffic 255 00:13:09.840 --> 00:13:13.000 is going. They are actually opening up the digital envelopes 256 00:13:13.039 --> 00:13:17.720 to look inside from malicious payloads as it traverses the infrastructure. 257 00:13:17.240 --> 00:13:20.759 And managing all of this is where the dossier introduces SESS, 258 00:13:21.200 --> 00:13:24.600 which stands for Secure Access Service Edge. It is basically 259 00:13:24.639 --> 00:13:27.720 a convergence of security as a service and SD one. 260 00:13:28.000 --> 00:13:30.679 Let's define SD one really quickly. It stands for software 261 00:13:30.679 --> 00:13:33.879 to find wide area network. In the past, companies bought 262 00:13:33.919 --> 00:13:39.000 incredibly expensive private physical network lines to connect their global offices. 263 00:13:39.399 --> 00:13:43.919 Very expensive SD one uses software to route traffic securely 264 00:13:44.200 --> 00:13:48.600 and intelligently over the standard public Internet instead. 265 00:13:48.440 --> 00:13:52.279 Precisely, and SaaS takes that smart routing and bundles it 266 00:13:52.320 --> 00:13:55.960 directly with security checkpoints. Instead of routing a remote workers 267 00:13:56.000 --> 00:13:58.919 traffic all the way back to a central corporate firewall 268 00:13:59.120 --> 00:14:02.759 just to inspect it, SAZ pushes the security checks out 269 00:14:02.799 --> 00:14:04.559 to the edge of the network. 270 00:14:04.240 --> 00:14:05.840 As close to the user as possible. 271 00:14:06.000 --> 00:14:10.679 Exactly, It provides identity driven protection in a completely boundary 272 00:14:10.759 --> 00:14:11.559 less environment. 273 00:14:11.639 --> 00:14:13.600 Okay, so walking down the network in the data is 274 00:14:13.679 --> 00:14:17.679 a great baseline, but developers are constantly renovating the building 275 00:14:17.720 --> 00:14:18.399 from the inside. 276 00:14:18.440 --> 00:14:19.519 Oh yeah, constantly. 277 00:14:19.799 --> 00:14:22.879 We live in the era of CICD, continuous integration and 278 00:14:22.919 --> 00:14:26.200 continuous deployment. In the old days, software companies pushed a 279 00:14:26.240 --> 00:14:29.440 massive update maybe twice a year. Today developers are writing 280 00:14:29.480 --> 00:14:32.720 code and pushing it live to customers multiple times a day. 281 00:14:32.679 --> 00:14:35.279 And the sheer speed of CICD is exactly why the 282 00:14:35.279 --> 00:14:39.720 industry shifted to DevSecOps. Dev sacops basically means building automated 283 00:14:39.720 --> 00:14:43.440 security tests directly into that fast moving assembly line, rather 284 00:14:43.480 --> 00:14:45.679 than waiting for a manual security review at the very 285 00:14:45.759 --> 00:14:46.600 end of the process. 286 00:14:46.960 --> 00:14:51.159 Because a manual review just creates massive bottlenecks. 287 00:14:50.519 --> 00:14:54.759 Exactly, and Sean McCullough's chapter introduces the dread framework to 288 00:14:54.799 --> 00:14:58.159 help prioritize risks in this totally chaotic environment. 289 00:14:58.279 --> 00:15:04.519 So dread Sandford damage potential, reproducibility, exploitability, affected users, and discoverability. 290 00:15:04.679 --> 00:15:07.600 Right, let's walk through how a team actually uses dread. 291 00:15:07.960 --> 00:15:11.000 Imagine a developer accidentally configure as a cloud storage bucket 292 00:15:11.039 --> 00:15:12.200 to be publicly readable. 293 00:15:12.399 --> 00:15:13.360 Okay, bad news. 294 00:15:13.919 --> 00:15:18.919 First, damage potential it is extremely high as customer data 295 00:15:18.960 --> 00:15:22.279 could be stolen. Reproducibility dot high. Anyone with a web 296 00:15:22.320 --> 00:15:26.919 browser can access it. Exploitability very easy, it requires zero 297 00:15:26.960 --> 00:15:31.559 hacking skills. Affected users, all of your customers. Discoverability incredibly 298 00:15:31.639 --> 00:15:35.000 high because automated bot nets constantly scan the Internet for 299 00:15:35.080 --> 00:15:36.159 open buckets, so. 300 00:15:36.080 --> 00:15:38.519 The dread score for that vulnerability would be maxed out 301 00:15:38.519 --> 00:15:41.360 across the board. The system flags it, and it gets 302 00:15:41.399 --> 00:15:44.480 fixed immediately, well before the team worries about like a 303 00:15:44.519 --> 00:15:47.440 minor bug in the user interface. But wait, let me 304 00:15:47.480 --> 00:15:49.080 push back on this a little bit. So what does 305 00:15:49.120 --> 00:15:52.360 this all actually mean. If we are automating everything so 306 00:15:52.480 --> 00:15:55.639 code can be deployed instantly, aren't we basically just giving 307 00:15:55.679 --> 00:16:00.600 ourselves the ability to deploy catastrophic vulnerabilities at leasing speed. 308 00:16:00.759 --> 00:16:03.000 That is such a good question, and honestly, it is 309 00:16:03.039 --> 00:16:08.159 the ultimate paradox of DevSecOps. Automation absolutely reduces human error, 310 00:16:08.200 --> 00:16:11.960 but it can hide unforeseen problems and deploy them at scale. 311 00:16:12.000 --> 00:16:15.840 The guide actually highlights a specific, terrifying use case for 312 00:16:15.879 --> 00:16:17.639 this credential disclosure. 313 00:16:17.840 --> 00:16:19.000 Okay, how does that happen? 314 00:16:19.159 --> 00:16:22.440 Well, imagine a developer is testing a database connection. They 315 00:16:22.519 --> 00:16:26.320 hardcode the database username and password directly into a configuration 316 00:16:26.440 --> 00:16:27.399 file on their laptop. 317 00:16:27.519 --> 00:16:30.360 Oh no, and then they accidentally commit that file into 318 00:16:30.360 --> 00:16:32.679 a distributed version control system like get up. 319 00:16:32.879 --> 00:16:37.240 Exactly, the automated CICD pipeline immediately detects the new code, 320 00:16:37.279 --> 00:16:40.759 it integrates, it builds it, and pushes that vulnerability live. 321 00:16:41.120 --> 00:16:44.159 You have now exposed your production database credentials to the 322 00:16:44.159 --> 00:16:47.960 world entirely automatically. This is why the pipeline itself must 323 00:16:48.000 --> 00:16:51.720 be threat modeled. You must implement automated scanning tools that 324 00:16:51.759 --> 00:16:57.320 specifically look for strings of text resembling passwords or apikeys. 325 00:16:56.679 --> 00:16:57.879 Right like a pre flight check. 326 00:16:58.320 --> 00:17:01.600 Exactly, if a c SURE is detected in the code, 327 00:17:01.679 --> 00:17:04.640 the tool must automatically break the build and reject the 328 00:17:04.680 --> 00:17:06.440 merge before it ever reaches production. 329 00:17:07.000 --> 00:17:09.359 It is basically like putting a metal detector on the 330 00:17:09.400 --> 00:17:12.640 assembly line. It stops the conveyor built before the flawed 331 00:17:12.640 --> 00:17:13.680 product gets out the door. 332 00:17:13.880 --> 00:17:14.039 Yep. 333 00:17:14.279 --> 00:17:17.319 So the code is secure, the network is micro segmented, 334 00:17:17.559 --> 00:17:20.839 and that data is encrypted. But at the end of 335 00:17:20.839 --> 00:17:23.200 the day, a human being is going to access that 336 00:17:23.359 --> 00:17:26.119 data on a device, and this brings us to the 337 00:17:26.160 --> 00:17:29.000 final vulnerability point, the new end. 338 00:17:28.839 --> 00:17:32.480 Point right because the definition of an endpoint has completely changed. 339 00:17:32.559 --> 00:17:34.440 It is no longer just a laptop sitting on a 340 00:17:34.440 --> 00:17:38.319 physical desk. In the cloud. Endpoints are provider hosted servers, 341 00:17:38.480 --> 00:17:41.119 virtual instances, and micro services. 342 00:17:40.640 --> 00:17:43.960 And securing them is completely non negotiable, which brings us 343 00:17:44.000 --> 00:17:46.480 back to those massive GDPR stakes we talked about at 344 00:17:46.480 --> 00:17:50.079 the very beginning. A compromise virtual server can lead directly 345 00:17:50.160 --> 00:17:53.079 to a twenty million euro fine very quickly. 346 00:17:53.480 --> 00:17:56.319 Visibility into these endpoints is critical, but there is this 347 00:17:56.559 --> 00:17:59.680 mind bending concept from the text that totally changes how 348 00:17:59.680 --> 00:18:04.480 we view visibility. It is called infrastructure as code or IAC. 349 00:18:04.960 --> 00:18:06.000 I love this concept. 350 00:18:06.200 --> 00:18:10.079 It's wild in the cloud, your entire network, your firewalls, 351 00:18:10.079 --> 00:18:13.799 your subnets, your servers. It isn't physical hardware bolted to 352 00:18:14.119 --> 00:18:17.279 a rack somewhere. It is literally just a text file, 353 00:18:17.720 --> 00:18:20.559 a template file that tells the cloud provider exactly what 354 00:18:20.680 --> 00:18:21.440 to build, right. 355 00:18:21.519 --> 00:18:25.279 It's fully programmable infrastructure exactly. It's like having a magical 356 00:18:25.319 --> 00:18:28.359 three D printer that can print an entire fully functioning 357 00:18:28.440 --> 00:18:30.559 bank vault out of thin air, and the only thing 358 00:18:30.640 --> 00:18:33.640 protecting that vault from being altered or deleted is the 359 00:18:33.640 --> 00:18:35.319 blueprint file fed into the printer. 360 00:18:35.480 --> 00:18:37.960 That analogy is spot on, and this is exactly why 361 00:18:38.000 --> 00:18:41.359 traditional antivirus is completely useless here. It's why endpoint detection 362 00:18:41.440 --> 00:18:45.200 and Response tools or EDR, alongside cloud native monitoring like 363 00:18:45.279 --> 00:18:47.839 AWS cloud Trail are so vital. 364 00:18:47.559 --> 00:18:51.039 Because traditional antivirus just looks for known signatures. 365 00:18:50.519 --> 00:18:54.559 Of malware right right, whereas EDR looks for behavioral anomalies 366 00:18:54.599 --> 00:18:57.880 and suspicious patterns across the environment. And cloud trail goes 367 00:18:57.880 --> 00:19:00.960 a step further. It logs every single API. 368 00:19:00.640 --> 00:19:03.039 Call made in your account, and an API call is 369 00:19:03.079 --> 00:19:06.200 basically just a digital request that software uses to talk 370 00:19:06.200 --> 00:19:09.799 to other software. Every single action in the cloud, you know, 371 00:19:10.000 --> 00:19:12.839 creating a user, deleting a server, changing a firewall rule 372 00:19:13.039 --> 00:19:13.359 is an. 373 00:19:13.240 --> 00:19:17.119 API call exactly so if someone maliciously or you know, 374 00:19:17.400 --> 00:19:21.960 even accidentally alters that infrastructure text file, they can rewrite 375 00:19:22.000 --> 00:19:26.480 your entire security posture in seconds. Wow, a critical firewall 376 00:19:26.559 --> 00:19:29.079 rule that's blocking malicious traffic can be deleted with a 377 00:19:29.160 --> 00:19:33.079 single backspace key. By monitoring API calls, you monitor the 378 00:19:33.079 --> 00:19:36.000 code that builds the infrastructure just as closely as you 379 00:19:36.039 --> 00:19:37.559 monitor the infrastructure itself. 380 00:19:38.160 --> 00:19:40.720 We have covered a massive amount of ground today. I mean, 381 00:19:40.920 --> 00:19:43.920 we started by realizing we needed a totally new mental framework, 382 00:19:44.000 --> 00:19:47.799 moving from nurturing delicate pets to managing automated cattle. 383 00:19:47.880 --> 00:19:49.440 Yeah, that's the foundational shift. 384 00:19:49.680 --> 00:19:52.839 And we learned that under the shared responsibility model, we 385 00:19:52.880 --> 00:19:55.519 are still completely on the hook for protecting the payload. 386 00:19:55.759 --> 00:19:58.200 Whether we use machine learning to find it or a 387 00:19:58.240 --> 00:20:00.599 forty five foot snowmobile SEM truck to. 388 00:20:00.519 --> 00:20:02.480 Move it, they still can't get over the truck, right. 389 00:20:02.799 --> 00:20:07.359 And we explored how micro segmentation uses explicit identity controls 390 00:20:07.559 --> 00:20:11.359 and stateful security groups to lock down this new boundaryless 391 00:20:11.359 --> 00:20:13.680 perimeter while SaaS protects the edge. 392 00:20:13.759 --> 00:20:16.599 And we secured the DevOps assembly line using the dread 393 00:20:16.640 --> 00:20:20.960 framework to prevent automating our own destruction, which is key. 394 00:20:21.200 --> 00:20:23.680 And we redefine what an endpoint actually is in the 395 00:20:23.720 --> 00:20:27.000 era of programmable infrastructure. But I want to leave you 396 00:20:27.000 --> 00:20:29.680 with a final thought to mull over, building directly on 397 00:20:29.799 --> 00:20:31.880 that concept of infrastructure as code. 398 00:20:31.920 --> 00:20:32.599 Okay, what is it? 399 00:20:32.839 --> 00:20:36.720 So? The guide stresses that cloud infrastructure is defined by 400 00:20:36.759 --> 00:20:39.759 text files and that we should treat virtual servers as 401 00:20:39.799 --> 00:20:45.279