WEBVTT 1 00:00:00.080 --> 00:00:01.960 You know, usually when we talk about moving into a 2 00:00:02.000 --> 00:00:05.960 brand new, state of the art luxury high rise, there 3 00:00:06.040 --> 00:00:09.279 is this expectation of well, total safety. Right if you 4 00:00:09.320 --> 00:00:12.000 walk in, you see the security guard stationed in the 5 00:00:12.000 --> 00:00:15.400 marble lobby, you see the key card scanners on the elevators, 6 00:00:15.880 --> 00:00:17.359 the thick concrete wall. 7 00:00:17.160 --> 00:00:20.160 Seems naturally assume, hey, I'm safe here. They have got 8 00:00:20.239 --> 00:00:21.280 those handled exactly. 9 00:00:21.320 --> 00:00:26.320 You just think it's covered. But then you realize something terrifying. Yes, 10 00:00:26.640 --> 00:00:29.320 the building management secures the lobby. I mean they check 11 00:00:29.359 --> 00:00:33.200 the IDs at the front desk, but you left your 12 00:00:33.320 --> 00:00:37.439 actual apartment door wide open. Oh yeah, and your personal 13 00:00:37.520 --> 00:00:41.719 safe city right there in your closet is just completely unlocked. Yeah. 14 00:00:41.840 --> 00:00:45.640 Suddenly that feeling of total security is well, it's just 15 00:00:45.719 --> 00:00:48.719 an illusion. You're looking at a security landscape that you 16 00:00:48.759 --> 00:00:50.439 have entirely misunderstood. 17 00:00:50.600 --> 00:00:53.479 It is the absolute definition of a false sense of security, 18 00:00:53.679 --> 00:00:56.759 and you know it perfectly mirrors the biggest misconception in 19 00:00:56.799 --> 00:01:01.159 digital infrastructure today. We see a massive, multi billion dollar 20 00:01:01.280 --> 00:01:04.359 tech company hosting our data, and we assume that because 21 00:01:04.400 --> 00:01:06.799 their lobby is secure, our apartment is too. 22 00:01:07.280 --> 00:01:10.599 Welcome to the deep dive. That illusion of safety you 23 00:01:10.719 --> 00:01:14.120 just described That is exactly what we are unpacking today. 24 00:01:14.319 --> 00:01:18.280 We're looking at Chris Dotson's guide Practical Cloud Security, a 25 00:01:18.319 --> 00:01:21.760 guide for secure design and deployment. It's such an essential read, 26 00:01:21.920 --> 00:01:25.120 it really is, and our mission today is to take 27 00:01:25.159 --> 00:01:29.799 his framework, strip away all that dense, intimidating jargon, and 28 00:01:29.959 --> 00:01:35.040 just uncover the practical, everyday strategies used to protect digital assets. 29 00:01:35.879 --> 00:01:39.120 We are going to explore everything from managing your risk 30 00:01:39.319 --> 00:01:43.799 to tracking down these ticking time bombs of forgotten servers. 31 00:01:43.959 --> 00:01:47.000 Because while the cloud fundamentally changes how we secure things, 32 00:01:47.040 --> 00:01:49.680 you know, stripping away those physical walls and concrete barriers 33 00:01:49.719 --> 00:01:52.480 we just talked about, the why remains deeply rooted in 34 00:01:52.519 --> 00:01:55.680 common sense. Yeah, the underlying logic of security hasn't changed 35 00:01:55.719 --> 00:01:57.599 at all, just the execution. 36 00:01:57.840 --> 00:01:59.560 So if you're listening to this and you have ever 37 00:01:59.599 --> 00:02:02.359 felt completely overwhelmed by the idea of cloud security, I 38 00:02:02.400 --> 00:02:04.799 mean you are definitely not alone. There is a twenty 39 00:02:04.879 --> 00:02:08.439 seventeen baracouta network survey referenced in our sources that is 40 00:02:08.479 --> 00:02:09.080 just wild to make. 41 00:02:09.159 --> 00:02:10.639 Oh the responsibility one. 42 00:02:10.639 --> 00:02:15.800 Yes, seventy seven percent of it. Decision makers wrongly believe 43 00:02:15.919 --> 00:02:19.680 that cloud providers are fully responsible for securing customer data. 44 00:02:20.039 --> 00:02:23.439 It's just a staggering statistic, seventy seven percent. It shows 45 00:02:23.439 --> 00:02:27.080 a fundamental industry wide misunderstanding of what we call the 46 00:02:27.159 --> 00:02:28.759 shared responsibility model. 47 00:02:28.840 --> 00:02:31.919 Right because in an old school on premises it environment, 48 00:02:32.280 --> 00:02:34.719 the company handles absolutely everything right exactly. 49 00:02:34.719 --> 00:02:37.120 You buy the servers, you hire the guards, you lock 50 00:02:37.199 --> 00:02:40.479 the doors. But in the cloud, there is a literal 51 00:02:40.560 --> 00:02:45.240 line of demarcation, and that line, well, it moves depending 52 00:02:45.280 --> 00:02:47.599 on what kind of service you were actually paying for. 53 00:02:47.800 --> 00:02:50.439 Okay, let's unpack this. Let's think about this like ordering pizza. 54 00:02:50.960 --> 00:02:52.639 I think this is the best way to visualize it. 55 00:02:52.680 --> 00:02:55.080 So imagine you want pizza tonight. Okay, let me keep 56 00:02:55.199 --> 00:02:57.800 the traditional on premises world is like making that pizza 57 00:02:57.840 --> 00:03:01.120 completely from scradge. At home. You buy the dough, the sauce, 58 00:03:01.199 --> 00:03:04.680 the cheese, You provide the oven, the dining table, the electricity, 59 00:03:04.759 --> 00:03:08.000 the soda, right, the soda. You have complete flexibility if 60 00:03:08.000 --> 00:03:11.479 you want an anchovy and cinnamon pizza, I mean gross, 61 00:03:11.520 --> 00:03:13.879 but you could do it. But you do all the 62 00:03:13.879 --> 00:03:15.919 work and you clean up the mess exactly. 63 00:03:16.400 --> 00:03:19.159 Now, let's step up to the first tier of the cloud, 64 00:03:19.319 --> 00:03:23.840 which is infrastructure as a service or I This is 65 00:03:23.960 --> 00:03:25.280 the taken bake model. 66 00:03:25.400 --> 00:03:26.360 Okay, taken bake. 67 00:03:26.479 --> 00:03:28.520 Yeah, you go to the grocery store and they provide 68 00:03:28.520 --> 00:03:30.919 the prepared dough, the sauce, and the cheese. In the 69 00:03:30.960 --> 00:03:35.080 digital world, that's the physical infrastructure and the virtualized environment. 70 00:03:35.159 --> 00:03:35.479 Got it. 71 00:03:36.000 --> 00:03:38.439 But you still have to take it home, bake it yourself, 72 00:03:38.479 --> 00:03:41.919 and provide the dining table and drinks. So you are 73 00:03:41.919 --> 00:03:46.199 responsible for patching the operating system, managing network security, and 74 00:03:46.400 --> 00:03:48.520 most importantly, protecting the data. 75 00:03:48.599 --> 00:03:51.960 Okay, So then we move to platform as a service pass. 76 00:03:52.319 --> 00:03:54.479 This is pizza delivery. Yeah, they bake it, they bring 77 00:03:54.520 --> 00:03:57.000 it to your door in a cardboard box. They're managing 78 00:03:57.000 --> 00:03:59.159 the operating system in the middle, where you just provide 79 00:03:59.199 --> 00:04:02.000 the table and eat it. Right. And finally, software is 80 00:04:02.000 --> 00:04:04.159 a service sauce. This is dining out at a restaurant. 81 00:04:04.280 --> 00:04:06.759 Everything is done for you, the physical infrastructure of the cooking, 82 00:04:06.879 --> 00:04:08.479 the table, service doing the dishes. 83 00:04:08.680 --> 00:04:12.039 But and this is the critical part where that seventy 84 00:04:12.080 --> 00:04:15.599 seven percent of it leaders get it wrong. Even in 85 00:04:15.639 --> 00:04:18.439 a sauce model, even when you are dining at the restaurant, 86 00:04:18.480 --> 00:04:21.600 there is still a shared responsibility. 87 00:04:20.920 --> 00:04:22.560 Right because they just make the food. 88 00:04:22.480 --> 00:04:26.959 Exactly the restaurant provides a safe, clean environment and fully 89 00:04:27.000 --> 00:04:29.800 cooked food, but they are not responsible for how you 90 00:04:29.839 --> 00:04:30.399 consume it. 91 00:04:30.639 --> 00:04:33.000 Right, if you are dining out at a fancy sauce 92 00:04:33.040 --> 00:04:36.000 restaurant and you just inhale your food too fast and 93 00:04:36.120 --> 00:04:38.759 choke on it, you cannot sue the chef. It is 94 00:04:38.800 --> 00:04:42.040 not the restaurant's fault. Meaning, if you set your data 95 00:04:42.120 --> 00:04:45.639 access controls incorrectly, the cloud provider cannot save you. 96 00:04:45.959 --> 00:04:49.560 Think about all those massive headline making data breaches we 97 00:04:49.639 --> 00:04:52.879 see involving open Amazon s three buckets. 98 00:04:52.959 --> 00:04:54.360 Oh, there have been so many. 99 00:04:54.360 --> 00:04:58.439 Hundreds of millions of voters data exposed, auto tracking records, 100 00:04:58.720 --> 00:05:01.959 sensitive credit report. People read those headlines and think, wow, 101 00:05:02.000 --> 00:05:02.920 Amazon got hacked. 102 00:05:03.000 --> 00:05:04.600 So if they didn't, No, they didn't. 103 00:05:04.759 --> 00:05:10.040 Amazon's physical servers, they're biometric scanners, their slab to slab barriers, 104 00:05:10.480 --> 00:05:14.319 those all held up perfectly. Those breaches were customers choking 105 00:05:14.319 --> 00:05:17.560 on their own pizza, basically by leaving their data access 106 00:05:17.560 --> 00:05:20.000 controls wide open to the public Internet. 107 00:05:20.319 --> 00:05:22.839 So before we can even begin to protect our specific 108 00:05:22.920 --> 00:05:26.120 slice of responsibility, we have to identify who actually wants 109 00:05:26.160 --> 00:05:29.879 to attack it. We need to visualize our defenses. We 110 00:05:29.920 --> 00:05:32.720 are dealing with four main thread actors here. 111 00:05:32.839 --> 00:05:34.120 Yeah, four main categories. 112 00:05:34.199 --> 00:05:38.920 First, organized crime who just want financial game, then activists 113 00:05:38.920 --> 00:05:41.560 who are looking to disrupt your operations or discredit you 114 00:05:41.600 --> 00:05:45.759 for ideological reasons, insiders which are usually discardled employees after 115 00:05:45.800 --> 00:05:49.160 money or revenge. And finally state actors who are looking 116 00:05:49.160 --> 00:05:53.160 to steal national secrets, corporate intellectual property, or just cause 117 00:05:53.279 --> 00:05:55.040 major infrastructure disruptions. 118 00:05:55.360 --> 00:05:57.720 And to defend against all four of those groups, you 119 00:05:57.800 --> 00:06:00.600 have to employ what we call defense in depth, meaning 120 00:06:00.680 --> 00:06:04.199 layers right layering your security controls so that if one 121 00:06:04.279 --> 00:06:07.560 single layer fails, you aren't completely exposed. You don't just 122 00:06:07.600 --> 00:06:10.000 put one flimsy lock on the front door. You have 123 00:06:10.120 --> 00:06:13.399 heavy dead bolt, you have a motion sensor alarm, and 124 00:06:13.439 --> 00:06:15.680 you have a fireproof safe hidden inside. 125 00:06:15.759 --> 00:06:17.079 Makes sense to plan this. 126 00:06:17.079 --> 00:06:20.639 Out effectively, you actually need to map your architecture. You 127 00:06:20.639 --> 00:06:23.680 can literally just draw simple stick figures for your standard 128 00:06:23.759 --> 00:06:26.399 user and your administrator, and then draw boxes for your 129 00:06:26.399 --> 00:06:29.920 components like a web server, an application server, and a database. 130 00:06:30.279 --> 00:06:33.240 And then you draw these dotted lines around certain boxes 131 00:06:33.279 --> 00:06:35.279 to create what are called trust boundaries. 132 00:06:35.959 --> 00:06:39.519 Precisely, a trust boundary means that anything inside that dotted 133 00:06:39.560 --> 00:06:43.120 line automatically trusts other things inside that same line, okay, 134 00:06:43.160 --> 00:06:45.920 but anything crossing that dotted line from the outside requires 135 00:06:45.920 --> 00:06:50.360 strict verification. If an attacker manages to breach a trust boundary, 136 00:06:50.639 --> 00:06:53.240 you have to assume they will eventually control every single 137 00:06:53.240 --> 00:06:56.519 thing inside it. By forcing an attacker to cross multiple 138 00:06:56.680 --> 00:06:59.800 verified boundaries, you slow them down significantly. 139 00:07:00.399 --> 00:07:02.639 Let me play Devil's Advocate for a second year. If 140 00:07:02.680 --> 00:07:05.800 I'm listening to this and I run a small local business, 141 00:07:06.639 --> 00:07:09.079 maybe I have a niche scheduling app for local bakeries 142 00:07:09.079 --> 00:07:11.959 to manage their delivery drivers. Do I really need to 143 00:07:11.959 --> 00:07:17.480 spend time and money worrying about well funded nation state actors. 144 00:07:17.759 --> 00:07:19.560 It sounds like absolute overkill. 145 00:07:20.120 --> 00:07:22.839 That is a very common objection, and the answer really 146 00:07:22.879 --> 00:07:26.279 comes down to the core concept of risk management. Security 147 00:07:26.360 --> 00:07:29.279 is not about being terrified of everything all the time, 148 00:07:29.360 --> 00:07:33.519 you know. It's about evaluating the mathematical likelihood of an 149 00:07:33.519 --> 00:07:38.600 event versus its potential impact. So a state actor specifically 150 00:07:38.680 --> 00:07:42.879 targeting your local bakery scheduling app very low likelihood, right. 151 00:07:42.759 --> 00:07:45.399 So why Bob, if it's a practically zero percent chance, 152 00:07:45.720 --> 00:07:48.360 am I really supposed to defend against a ghost. 153 00:07:48.319 --> 00:07:51.079 Because the impact is still catastrophic and the method of 154 00:07:51.120 --> 00:07:54.240 attack doesn't care who you are. State actors and organized 155 00:07:54.279 --> 00:07:57.680 crime rings. They don't always target specific companies manually. They 156 00:07:57.759 --> 00:08:02.160 use bots exactly, use automated scripts that scan the entire 157 00:08:02.199 --> 00:08:05.560 Internet twenty four to seven looking for open doors. They 158 00:08:05.600 --> 00:08:07.959 don't know you're a bakery app. They just see an 159 00:08:08.000 --> 00:08:12.000 unlocked database. And if that database holds thousands of users 160 00:08:12.079 --> 00:08:16.480 personal emails, phone numbers, and maybe reuse passwords, the impact 161 00:08:16.519 --> 00:08:20.680 of that automated brooch could permanently bankrupt your business. When 162 00:08:20.720 --> 00:08:24.360 you identify a risk like that, you generally have four choices. 163 00:08:24.120 --> 00:08:30.040 Right the four strategies avoid, mitigate, transfer, or accept exactly. 164 00:08:30.360 --> 00:08:33.360 You can avoid the risk entirely by just turning the 165 00:08:33.399 --> 00:08:36.120 system off or not offering the feature, just don't do 166 00:08:36.159 --> 00:08:39.039 it right. You can mitigate the risk, maybe by choosing 167 00:08:39.120 --> 00:08:41.639 not to store sensitive personal data in the app in 168 00:08:41.679 --> 00:08:44.559 the first place. You can transfer the risk, which is 169 00:08:44.559 --> 00:08:46.440 what we do when we pay a cloud provider to 170 00:08:46.440 --> 00:08:50.720 handle the physical data center security of Potato exactly. Or finally, 171 00:08:50.799 --> 00:08:53.480 you can accept it, meaning you document that you know 172 00:08:53.559 --> 00:08:57.000 the vulnerability exists, you get the business stakeholders to formally 173 00:08:57.000 --> 00:08:59.480 agree to the danger, and you just move forward. 174 00:09:00.039 --> 00:09:01.399 Makes a lot of sense. You just have to know 175 00:09:01.480 --> 00:09:04.279 exactly what you're dealing with and what you're usually dealing with. 176 00:09:04.399 --> 00:09:07.799 Inside those trust boundaries is the actual prize, which is 177 00:09:07.840 --> 00:09:11.480 the data, the crown jewels. We have to categorize this 178 00:09:11.600 --> 00:09:14.679 data so we know what needs the heaviest protection. You 179 00:09:14.679 --> 00:09:19.039 can break it down simply into low, moderate, and high sensitivity. 180 00:09:18.559 --> 00:09:19.600 Yep, the three tiers. 181 00:09:20.000 --> 00:09:23.159 Low might be your server's public IP addresses, stuff that 182 00:09:23.200 --> 00:09:26.360 wouldn't ruin you if it leaked. Moderate could be routine 183 00:09:26.360 --> 00:09:30.200 internal financial info or basic personnel data. How is your 184 00:09:30.240 --> 00:09:33.799 trade secrets or customer financial data that is subject to 185 00:09:33.840 --> 00:09:35.120 strict compliance laws. 186 00:09:35.559 --> 00:09:37.799 And once you know what level of data you have, 187 00:09:38.039 --> 00:09:40.960 you have to understand how attackers view it. They look 188 00:09:40.960 --> 00:09:43.519 at your data through the lens of the CIA triad, 189 00:09:43.720 --> 00:09:47.480 which stands for confidentiality, integrity, and availability. 190 00:09:47.919 --> 00:09:50.759 Let's break that down. Confidentiality is the obvious one. They 191 00:09:50.759 --> 00:09:54.559 want to breach confidentiality to steal the data read the email, sale, 192 00:09:54.559 --> 00:09:59.200 the credit card numbers. But integrity is well, it's more subtle. 193 00:09:59.279 --> 00:10:03.519 Integrity is a unauthorized modification. An attacker breaches integrity when 194 00:10:03.519 --> 00:10:06.840 they secretly change the data. Oh like altering records right. 195 00:10:07.039 --> 00:10:10.879 Imagine an attacker getting into a bank's database. They don't 196 00:10:10.879 --> 00:10:13.039 need to steal the money directly if they can just 197 00:10:13.120 --> 00:10:16.320 add three zeros to their own account balance. Wow. Yeah, 198 00:10:16.440 --> 00:10:19.639 they've compromised the integrity of the data and the final piece, 199 00:10:19.720 --> 00:10:23.080 availability is exactly what it sounds like. Ransomware is the 200 00:10:23.080 --> 00:10:27.720 classic example here, locking you out Exactly the attacker encrypts 201 00:10:27.720 --> 00:10:30.240 your data so you can't use it, completely, destroying its 202 00:10:30.279 --> 00:10:31.840 availability until you pay up. 203 00:10:32.399 --> 00:10:35.080 So to protect this data while it's just sitting there 204 00:10:35.080 --> 00:10:38.320 on a server, protecting it at rest. Encryption is the 205 00:10:38.399 --> 00:10:42.879 ultimate buzzword, but there is a massive flaw in how 206 00:10:42.919 --> 00:10:44.240 people deploy encryption. 207 00:10:44.559 --> 00:10:45.240 There really is. 208 00:10:45.320 --> 00:10:47.960 You can have the strongest encryption algorithm in the world, 209 00:10:48.200 --> 00:10:50.480 but if you leave the encryption key sitting on the 210 00:10:50.519 --> 00:10:53.720 exact same server as the locked data, what's the point. 211 00:10:54.080 --> 00:10:57.960 It's literally like installing a Titanium vault door and then 212 00:10:58.039 --> 00:11:00.159 leaving the key under the doormat. 213 00:11:00.039 --> 00:11:03.120 Which is incredibly common unfortunately, and this is where key 214 00:11:03.159 --> 00:11:06.200 management services or kms come into play. Think about how 215 00:11:06.240 --> 00:11:10.000 a realtor shows a house. Imagine your highly sensitive data 216 00:11:10.080 --> 00:11:10.519 is a house. 217 00:11:10.600 --> 00:11:12.919 Okay, tracking to get into the house, you need the 218 00:11:12.919 --> 00:11:16.559 house key. In cryptography, this is called the data encryption 219 00:11:16.720 --> 00:11:19.879 key or DET. It directly unlocks the data. 220 00:11:20.080 --> 00:11:20.399 Got it. 221 00:11:20.440 --> 00:11:22.159 But you don't want to just leave the house key 222 00:11:22.240 --> 00:11:25.519 lying around under the mat, so your realtor puts it 223 00:11:25.639 --> 00:11:28.559 inside a sturdy metal lock box attached to the front door. 224 00:11:28.600 --> 00:11:30.120 Knob Oh, I see where this is going. 225 00:11:30.279 --> 00:11:33.679 To open that metal lock box, you need a specific code. 226 00:11:33.759 --> 00:11:36.919 That code is the key encryption key or key EK. 227 00:11:37.279 --> 00:11:40.519 And the overarching realtor service that generates and hands out 228 00:11:40.559 --> 00:11:43.960 those lockbox codes to approved agents that is your key 229 00:11:44.000 --> 00:11:45.480 management service, the KMS. 230 00:11:45.519 --> 00:11:48.399 Here's where it gets really interesting. Because of this lock 231 00:11:48.399 --> 00:11:52.120 box system, we get this concept called cryptographic erasure. Think 232 00:11:52.120 --> 00:11:56.600 about this. Practically destroying a massive multi terabyte database securely 233 00:11:56.720 --> 00:11:59.279 used to be a total nightmare rticck forever. You had 234 00:11:59.279 --> 00:12:03.399 to spend hour, sometimes days, having a computer overwrite the 235 00:12:03.399 --> 00:12:06.759 physical hard drives with random zeros and ones just to 236 00:12:06.799 --> 00:12:09.799 make sure the data was gone, but in the cloud. 237 00:12:10.240 --> 00:12:13.240 Because that multi terabyte database is locked by the house key, 238 00:12:13.480 --> 00:12:15.799 and the house key is logging the realtor's box. If 239 00:12:15.840 --> 00:12:18.360 you want to permanently destroy the data, you don't even 240 00:12:18.399 --> 00:12:18.720 have to. 241 00:12:18.600 --> 00:12:21.960 Touch the house, right You don't overwrite the terabytes of data. 242 00:12:22.039 --> 00:12:24.440 You just go to the cams and instantly destroy the 243 00:12:24.480 --> 00:12:28.279 tiny two hundred and fifty six bit lockbox CAD the 244 00:12:28.480 --> 00:12:29.759 key encryption key. 245 00:12:30.279 --> 00:12:31.279 That is wild. 246 00:12:31.519 --> 00:12:34.399 The second you press delete on that tiny string of text, 247 00:12:34.720 --> 00:12:38.399 that data encryption key inside the lock box is permanently trapped, 248 00:12:38.559 --> 00:12:42.440 and without that, those terabytes of data become an unreadable, 249 00:12:42.600 --> 00:12:46.440 mathematically unrecoverable bag of bits instantly forever. 250 00:12:46.559 --> 00:12:49.279 That is just incredible. The efficiency of that is wild. 251 00:12:49.480 --> 00:12:51.600 And what's really fascinating here is how the cloud has 252 00:12:51.600 --> 00:12:54.559 democratized this level of security. In the old days, to 253 00:12:54.600 --> 00:12:57.600 have that kind of robust key management, a company had 254 00:12:57.600 --> 00:12:59.960 to buy a physical piece of hardware called a hardware 255 00:13:00.039 --> 00:13:01.600 security module or HSM. 256 00:13:01.679 --> 00:13:03.200 Those were not cheap, not at all. 257 00:13:03.279 --> 00:13:08.799 These are incredibly expensive, tamper proof, military grade devices. If 258 00:13:08.799 --> 00:13:11.559 someone tries to pry one open, or change the temperature 259 00:13:11.679 --> 00:13:15.279 or even X ray it, the device senses the intrusion 260 00:13:15.480 --> 00:13:17.399 and physically wipes its own memory. 261 00:13:17.639 --> 00:13:18.080 Wow. 262 00:13:18.360 --> 00:13:23.159 Now, through multi tenant KMS systems provided by cloud platforms 263 00:13:23.200 --> 00:13:26.639 like AWS or Azure, even a small startup with a 264 00:13:26.720 --> 00:13:30.159 modi budget can leverage the power of an HSM under 265 00:13:30.159 --> 00:13:33.799 the hood. It has completely shifted the paradigm of data protection. 266 00:13:34.000 --> 00:13:36.759 Okay, so we've secured the data, we've locked it in 267 00:13:36.759 --> 00:13:39.840 a cryptographic lock box, but what about the millions of 268 00:13:39.919 --> 00:13:43.279 virtual containers and servers actually holding it. This is where 269 00:13:43.279 --> 00:13:46.919 we run into the absolute chaos of cloud asset management. 270 00:13:47.000 --> 00:13:48.759 Chaos is the right word for it, because. 271 00:13:48.519 --> 00:13:50.559 In the old on premise it days, if a developer 272 00:13:50.600 --> 00:13:53.200 wanted a server, it was a capital expenditure. They put 273 00:13:53.200 --> 00:13:56.240 in a formal request, finance approved it. It bought a 274 00:13:56.279 --> 00:13:58.159 physical box, racked it in a cold room, and put 275 00:13:58.159 --> 00:14:00.240 a little barcode inventory sticker on it. 276 00:14:00.240 --> 00:14:02.240 It took months, yep, lots of red tape. 277 00:14:02.360 --> 00:14:04.879 Now it's an operational expense. A developer with a corporate 278 00:14:04.879 --> 00:14:07.519 credit card can spin up a server in three seconds. 279 00:14:07.279 --> 00:14:09.600 Which leads to one of the biggest headaches for any 280 00:14:09.639 --> 00:14:16.559 security team. Shadow it unapproved, untracked digital infrastructure. And it's 281 00:14:16.600 --> 00:14:18.919 not just a billing problem where you're wasting money. It's 282 00:14:18.960 --> 00:14:21.639 a profound security nightmare. 283 00:14:21.320 --> 00:14:24.600 Because you can't protect what you don't know exists exactly. 284 00:14:25.080 --> 00:14:28.679 Every forgotten server is a ticking time bomb waiting to 285 00:14:28.720 --> 00:14:31.759 miss a critical security patch and be exploited. And you 286 00:14:31.840 --> 00:14:34.840 have to deeply understand what kind of assets your team 287 00:14:34.879 --> 00:14:37.320 is actually spinning up. Take a virtual. 288 00:14:37.000 --> 00:14:39.120 Machine for instance, okay, VMS. 289 00:14:39.240 --> 00:14:42.039 A VM is a digital computer that shares a physical 290 00:14:42.039 --> 00:14:46.000 host machine a hypervisor with other customers. Because you are 291 00:14:46.000 --> 00:14:49.840 sharing that physical hardware, you are potentially vulnerable to side 292 00:14:49.919 --> 00:14:53.399 channel attacks like the famous specter and meltdown vulnerabilities. 293 00:14:53.480 --> 00:14:56.679 Let's pause on that. Because side channel attack on a hypervisor, 294 00:14:57.200 --> 00:14:58.799 I mean that sounds like a mouthful. How does that 295 00:14:58.840 --> 00:14:59.919 actually work? In reality? 296 00:15:00.039 --> 00:15:02.399 It's essentially like living in an apartment building. You have 297 00:15:02.480 --> 00:15:05.120 your own locked room, your virtual machine, but you share 298 00:15:05.159 --> 00:15:08.159 the foundation, the plumbing, and the walls with other tenants. 299 00:15:08.360 --> 00:15:10.679 Okay, and that shared foundation is the hypervisor. 300 00:15:11.080 --> 00:15:14.399 Right. In a side channel attack, a malicious neighbor on 301 00:15:14.440 --> 00:15:17.440 that exact same physical server doesn't try to pick the 302 00:15:17.440 --> 00:15:21.240 lock on your door. Instead, they listen very very closely 303 00:15:21.360 --> 00:15:24.879 to how the computer's processor is vibrating or consuming power, 304 00:15:25.279 --> 00:15:27.720 essentially pressing a glass to the apartment wall. 305 00:15:27.879 --> 00:15:29.559 Wait, really just from power consumption. 306 00:15:29.759 --> 00:15:33.960 Yes. By monitoring those subtle physical changes, they can actually 307 00:15:34.080 --> 00:15:37.639 guess the passwords or cryptographic keys you are typing. 308 00:15:37.919 --> 00:15:40.600 Wow, Okay, so that's the danger of virtual machines. But 309 00:15:40.840 --> 00:15:43.440 what about containers. A container doesn't even use a full 310 00:15:43.480 --> 00:15:46.799 operating system. It just shares a kernel. It spins up 311 00:15:46.840 --> 00:15:48.840 to do a job, runs for an hour, and then 312 00:15:48.919 --> 00:15:52.600 completely deletes itself. If a developer is spinning up thousands 313 00:15:52.639 --> 00:15:55.559 of these ephemeral containers a day, how on earth do 314 00:15:55.600 --> 00:15:56.480 you track a ghost? 315 00:15:56.679 --> 00:15:58.559 That is the exact challenge. The answer is that you 316 00:15:58.559 --> 00:16:01.919 don't necessarily track the fleeting container itself. You inventory the 317 00:16:01.919 --> 00:16:06.639 container images, the blueprint, ah the blueprint, right. A native 318 00:16:06.679 --> 00:16:09.480 container is meant to be immutable. It doesn't get updated 319 00:16:09.600 --> 00:16:12.840 or patched while it's running. When a security patch is needed, 320 00:16:13.080 --> 00:16:16.559 the running container is destroyed and instantly replaced by a 321 00:16:16.600 --> 00:16:20.080 new container spun up from a freshly patched image blueprint. 322 00:16:20.240 --> 00:16:22.840 So you control the source material exactly. 323 00:16:23.000 --> 00:16:26.039 You control the blueprints. But to manage all of this effectively, 324 00:16:26.120 --> 00:16:29.320 you have to find where your asset management pipeline is leaking. 325 00:16:29.840 --> 00:16:32.279 Okay, let's play this out in a real world corporate 326 00:16:32.279 --> 00:16:36.159 scenario to see how these plumbing leaks actually happen. Picture 327 00:16:36.200 --> 00:16:39.240 a rogue developer who is tired of waiting for it 328 00:16:39.639 --> 00:16:42.559 approval for a new project. We all know one right, 329 00:16:42.679 --> 00:16:45.799 they pull out their corporate credit card, bypass the official 330 00:16:45.879 --> 00:16:49.320 channels and just spin up a brand new AWS environment. 331 00:16:50.000 --> 00:16:52.080 The security team doesn't even know it exists. That's our 332 00:16:52.120 --> 00:16:53.159 first leak, right. 333 00:16:53.000 --> 00:16:55.559 At the sort exactly. We call that a procurement leak. 334 00:16:55.720 --> 00:16:59.159 You have cloud expenditures happening outside of the security team's visibility. 335 00:16:59.279 --> 00:17:01.879 But let's say secure pready catches that. Then you run 336 00:17:01.919 --> 00:17:04.319 into processing leaks. This is where you see the eight 337 00:17:04.400 --> 00:17:07.359 of US bill. You know the cloud environment exists, but 338 00:17:07.480 --> 00:17:11.079 you forgot to actually enumerate and track the specific servers 339 00:17:11.079 --> 00:17:13.640 being spun up inside it. You're paying for a database, 340 00:17:13.839 --> 00:17:16.599 but it never made it onto your official inventory list, which. 341 00:17:16.480 --> 00:17:19.480 Naturally leads to the next failure tooling leaks. So let's 342 00:17:19.519 --> 00:17:22.200 say the service finally on your official inventory list. The 343 00:17:22.240 --> 00:17:25.640 IT team knows about it, but nobody remembered to plug 344 00:17:25.680 --> 00:17:29.720 that server's IP address into your automated security scanners. It's 345 00:17:29.759 --> 00:17:32.079 on the list, but it's sitting in the dark, completely 346 00:17:32.160 --> 00:17:33.519 unchecked for vulnerabilities. 347 00:17:34.000 --> 00:17:38.599 And then the final and arguably most frustrating failure findings leaks. 348 00:17:38.920 --> 00:17:40.960 Let me guess they find the problem and ignore it. 349 00:17:41.599 --> 00:17:45.200 Basically, the servers on the list the scanner knows about it. 350 00:17:45.240 --> 00:17:49.240 The scanner runs, finds a critical vulnerability, generates a bright 351 00:17:49.319 --> 00:17:51.839 red alert, and a human being ignores the alert or 352 00:17:51.960 --> 00:17:55.359 just gets lost in an overflowing inbox. To fix this 353 00:17:55.599 --> 00:17:59.480 entire chain of leaks, especially the processing ones, manual tracking 354 00:17:59.519 --> 00:18:02.119 is just possible. You have to use cloud native automation. 355 00:18:02.440 --> 00:18:03.960 You must enforce tagging. 356 00:18:04.319 --> 00:18:07.240 Tagging like putting a label on every single moving box 357 00:18:07.279 --> 00:18:10.200 in your house data class coal in, high environment, colan 358 00:18:10.200 --> 00:18:11.519 production department, colon. 359 00:18:11.319 --> 00:18:14.200 Finance exactly, and you automate it. If you have an 360 00:18:14.200 --> 00:18:17.680 automated policy that every single asset must have an environment 361 00:18:17.720 --> 00:18:20.519 tag and a data classification tag, you can run a 362 00:18:20.559 --> 00:18:23.079 simple script to find violations instantly. 363 00:18:23.200 --> 00:18:24.880 Oh that makes it so much easier, right. 364 00:18:25.200 --> 00:18:27.759 If a developer accidentally spins up a server with a 365 00:18:27.839 --> 00:18:31.000 high data class tag but a development environment tag, your 366 00:18:31.039 --> 00:18:34.200 automation can flag it or even automatically shut it down. 367 00:18:34.880 --> 00:18:39.160 You should never ever have highly sensitive real customer data 368 00:18:39.559 --> 00:18:42.359 sitting on a flimsy experimental development server. 369 00:18:42.720 --> 00:18:45.400 So we've mapped our data boundaries, We've locked the data 370 00:18:45.480 --> 00:18:48.480 in a cryptographic lock box. We've fixed the plumbing of 371 00:18:48.480 --> 00:18:51.720 our shadow I by automatically tagging our assets. We've done 372 00:18:51.720 --> 00:18:54.759 a lot, we have, but absolutely none of that matters 373 00:18:54.799 --> 00:18:56.839 if an attacker just walks right through the front door 374 00:18:56.960 --> 00:19:00.920 using stolen valid credentials, which brings to the final and 375 00:19:01.000 --> 00:19:05.039 maybe most crucial piece of the puzzle, identity and access management. 376 00:19:05.680 --> 00:19:09.599 I AM Identity truly is the ultimate perimeter in the cloud. 377 00:19:09.880 --> 00:19:13.240 Physical walls are gone. But before we build that perimeter, 378 00:19:13.359 --> 00:19:16.319 we have to clarify two terms that get hopelessly mixed 379 00:19:16.400 --> 00:19:20.599 up even by professionals, authentication and authorization. 380 00:19:21.119 --> 00:19:25.240 The military base analogy clarifies this perfectly. Imagine you drive 381 00:19:25.319 --> 00:19:27.839 up to the heavily fortified gait of a military base. 382 00:19:28.480 --> 00:19:30.599 You roll down your window and hand the guard your 383 00:19:30.640 --> 00:19:34.119 driver's license. Yep. The guard looks at the photo, looks 384 00:19:34.160 --> 00:19:38.200 at your face, and decides, yes, you are exactly who 385 00:19:38.279 --> 00:19:40.920 you say you are. That is authentication. It is simply 386 00:19:41.240 --> 00:19:43.000 establishing your identity. Correct. 387 00:19:43.039 --> 00:19:45.039 But just because the guard knows exactly who you are 388 00:19:45.079 --> 00:19:47.000 doesn't mean you actually get to drive into the base. 389 00:19:47.079 --> 00:19:50.400 Authentication is not enough, right. The guard then turns around, 390 00:19:50.519 --> 00:19:53.039 checks a clipboard and looks to see if your verified 391 00:19:53.079 --> 00:19:55.319 name is on the approved visitor list and specifically which 392 00:19:55.319 --> 00:19:58.319 buildings you are allowed to enter today. That is authorization. 393 00:19:58.599 --> 00:20:01.119 It is establishing your ax t us who you are 394 00:20:01.240 --> 00:20:02.759 versus what you are permitted. 395 00:20:02.400 --> 00:20:08.359 To do, and managing that relies on the IAM life cycle. Request, approve, create, use, revalidate, 396 00:20:08.400 --> 00:20:11.799 and revoke and revoke is where organizations fail spectacularly. 397 00:20:12.000 --> 00:20:12.799 Oh absolutely. 398 00:20:12.920 --> 00:20:16.039 Let's look at a real world in nightmare scenario. Let's 399 00:20:16.079 --> 00:20:20.519 say you fire a highly privileged systems administrator on premise. 400 00:20:20.599 --> 00:20:23.480 This is easy. You deactivate their physical key card, you 401 00:20:23.519 --> 00:20:25.839