WEBVTT 1 00:00:00.080 --> 00:00:03.839 Welcome to the deep dive. Today. We're really getting into 2 00:00:03.839 --> 00:00:05.759 the weeds of cloud penetration testing. 3 00:00:05.839 --> 00:00:08.720 Yeah, we're using Kim Crawley's book Cloud Penetration Testing for 4 00:00:08.759 --> 00:00:10.960 Red Teamers as our guide. 5 00:00:10.640 --> 00:00:12.880 Right, and the idea is to pull out the key stuff. 6 00:00:13.000 --> 00:00:17.519 You know how security pros actually test places like Aws, Azure, GCP, 7 00:00:18.519 --> 00:00:19.719 find the holes. 8 00:00:19.559 --> 00:00:21.600 Make things stronger, and we want to get you the 9 00:00:21.719 --> 00:00:26.559 core insights those sort of aha moments about cloud security. 10 00:00:26.120 --> 00:00:31.480 Testing exactly Crawley's book. It's pretty thorough good for experienced 11 00:00:31.480 --> 00:00:34.240 folks moving to cloud, but also if you're just starting out. 12 00:00:34.359 --> 00:00:37.399 It really maps out the tools the methods for each 13 00:00:37.479 --> 00:00:39.920 big cloud player because they are different. 14 00:00:39.759 --> 00:00:42.039 And for you listening, maybe you're prepping for a meeting, 15 00:00:42.240 --> 00:00:44.600 trying to get your head around this, or just curious. 16 00:00:45.399 --> 00:00:47.000 We're aiming to cut through the noise. 17 00:00:47.159 --> 00:00:50.479 We'll focus on like the big shift from old school 18 00:00:50.560 --> 00:00:51.320 pen testing to. 19 00:00:51.320 --> 00:00:54.960 Cloud, that shared responsibility thing. Definitely need to cover that. 20 00:00:55.119 --> 00:00:57.039 Oh yeah, and the kinds of attacks you see, the 21 00:00:57.079 --> 00:00:58.200 defenses that work. 22 00:00:58.119 --> 00:01:02.399 Without drowning you in Jurgen, just the actionable stuff. Okay, 23 00:01:02.479 --> 00:01:03.240 let's get started. 24 00:01:03.439 --> 00:01:07.519 So foundational point cloud platforms are well basically everywhere. Now. 25 00:01:07.879 --> 00:01:10.359 AWS kicked it off, what two thousand and six. 26 00:01:10.280 --> 00:01:13.280 Yeah, and then Azure GCP around two thousand and eight. 27 00:01:13.400 --> 00:01:17.719 Now most big companies use at least one, often more. 28 00:01:17.799 --> 00:01:20.319 It's easy to see why. Right. The scalability is huge. 29 00:01:20.359 --> 00:01:24.799 Oh, absolutely, spin up resources, spin them down, No need 30 00:01:24.840 --> 00:01:26.799 to build your own massive data centers. 31 00:01:26.959 --> 00:01:30.840 Think about services like Netflix or Dropbox. They couldn't exist 32 00:01:30.879 --> 00:01:32.920 like they do without the clouds flexibility. 33 00:01:33.040 --> 00:01:35.599 It really enables that kind of business agility. 34 00:01:35.760 --> 00:01:37.920 And it's not just using the cloud, it's how they're 35 00:01:38.000 --> 00:01:41.439 using it. You've got companies that are all in everything's. 36 00:01:41.000 --> 00:01:42.760 Cloud, right, the all cloud approach. 37 00:01:42.920 --> 00:01:45.640 Then there's hybrid mix of their own servers in cloud, 38 00:01:45.959 --> 00:01:49.079 maybe for compliance reasons or old systems they can't move easily. 39 00:01:49.120 --> 00:01:52.239 Makes sense. And then the other one you mentioned multi cloud, Yeah. 40 00:01:52.120 --> 00:01:56.920 Using services from say both AWS and Azure, maybe GCP too. 41 00:01:57.040 --> 00:02:00.000 Okay, that sounds complicated. Why add that layer? 42 00:02:00.280 --> 00:02:03.280 Good question. Sometimes one provider just has a killer service 43 00:02:03.319 --> 00:02:06.400 the others don't like. Maybe one's way ahead on AI tools. 44 00:02:06.120 --> 00:02:10.560 Ah, okay, best of breed for specific tasks exactly, Or 45 00:02:10.599 --> 00:02:13.639 maybe it's about not being locked into one vendor gives 46 00:02:13.639 --> 00:02:15.840 you more leverage, redundancy too. 47 00:02:15.879 --> 00:02:19.000 Right, avoiding that vendor lock in. Okay, so that maps 48 00:02:19.000 --> 00:02:23.759 out the landscape. Let's switch gears to security. This shared 49 00:02:23.800 --> 00:02:28.560 responsibility model feels like ground zero for understanding cloud security. 50 00:02:28.800 --> 00:02:31.879 It absolutely is. It's the framework defining who handles what. 51 00:02:32.520 --> 00:02:37.759 The basic idea the cloud provider Amazon, Microsoft, Google. They 52 00:02:37.800 --> 00:02:40.159 secure the underlying infrastructure. 53 00:02:39.520 --> 00:02:42.159 The physical buildings, the core network, that sort of thing. 54 00:02:42.240 --> 00:02:44.400 Yeah, security of the cloud itself, but this is non 55 00:02:44.439 --> 00:02:45.520 negotiable the customer. 56 00:02:45.560 --> 00:02:49.319 So your company, you're always responsible for your data period. 57 00:02:49.120 --> 00:02:51.759 Always, no matter what service you use. Where it gets 58 00:02:51.840 --> 00:02:54.919 nuanced is the other stuff, the apps, the network settings, 59 00:02:54.919 --> 00:02:57.520 inside your cloud environment, the operating systems, and. 60 00:02:57.479 --> 00:03:00.400 That changes based on whether it's iass, poly ass or 61 00:03:00.479 --> 00:03:04.400 sauce right infrastructure platform or software as a service. 62 00:03:04.560 --> 00:03:07.319 Precisely, the lines shift depending on that model. 63 00:03:07.360 --> 00:03:10.080 Okay, let's get specific, Like the book does, how does 64 00:03:10.120 --> 00:03:13.280 Azure break it down? People might assume it's the same everywhere. Well, 65 00:03:13.319 --> 00:03:17.199 with Azure, you're responsible for your info, your data obviously, 66 00:03:17.439 --> 00:03:20.039 also the devices people use to connecting the user accounts. Okay, 67 00:03:20.199 --> 00:03:23.879 Azure handles the physical hosts, the network, the data center security, 68 00:03:24.000 --> 00:03:28.800 but things like identity applications, network controls OS. That depends 69 00:03:28.800 --> 00:03:31.199 if it's PANS, we ouris. 70 00:03:30.800 --> 00:03:33.159 Got it and GCP. How do they draw the lines. 71 00:03:33.240 --> 00:03:35.800 GCP says you're always responsible for your content and your 72 00:03:35.800 --> 00:03:39.120 access policies. That's true across size pans. 73 00:03:38.960 --> 00:03:40.919 IGAs okay, consistent there. 74 00:03:41.000 --> 00:03:43.680 If you use PANS on GCP, you also take on 75 00:03:43.719 --> 00:03:46.680 responsibility for how you use it, deploy it and secure 76 00:03:46.719 --> 00:03:49.400 your web apps running on it. Go to ISS and 77 00:03:49.479 --> 00:03:54.120 you add even more identity management your operational stuff, access control, 78 00:03:54.319 --> 00:03:57.479 network security can fig the actual guest os and the 79 00:03:57.560 --> 00:03:58.639 data itself. 80 00:03:58.280 --> 00:04:00.840 So you're managing a lot more at the level what's 81 00:04:00.919 --> 00:04:01.719 left for GCP. 82 00:04:01.840 --> 00:04:05.879 Then GCP handles things like audit logging for their infrastructure, 83 00:04:05.919 --> 00:04:09.360 their network security, data encryption, the hard and NOS kernels 84 00:04:09.360 --> 00:04:12.120 they use secure boot the physical hardware. 85 00:04:12.560 --> 00:04:14.960 It really highlights that you need to know the specifics 86 00:04:15.000 --> 00:04:17.079 for your provider and your serf ball. You can't just. 87 00:04:17.120 --> 00:04:20.519 Guess absolutely not, and that leads right into actually testing 88 00:04:20.560 --> 00:04:23.040 the security. You can't just go wild ah the. 89 00:04:22.959 --> 00:04:26.639 Pen testing policies right. Each provider has rules and you. 90 00:04:26.600 --> 00:04:28.720 Have to follow them. It doesn't matter what your boss wants, 91 00:04:28.959 --> 00:04:32.279 you play by their rules. It's their playground essentially. 92 00:04:31.920 --> 00:04:34.360 Okay, so give us the rundown. What are the big 93 00:04:34.399 --> 00:04:36.240 dos and don'ts for AWS? 94 00:04:36.480 --> 00:04:40.399 With AWS, generally, you can pentist most services without asking first. 95 00:04:40.519 --> 00:04:42.079 Okay, that's fairly open. 96 00:04:41.879 --> 00:04:45.360 But big restrictions. No missing with root fifty three DNS, 97 00:04:45.480 --> 00:04:50.480 zone walking, hijacking, no DUFTA or DDOST attacks, mostly no 98 00:04:50.560 --> 00:04:51.480 protocol flooding. 99 00:04:51.759 --> 00:04:54.720 Right, don't break things for other customers. 100 00:04:54.240 --> 00:04:56.839 Exactly, And if you want to use things like command 101 00:04:56.839 --> 00:05:00.759 and control servers or network stress tools like IPER, or 102 00:05:00.839 --> 00:05:04.079 run phishing simulations or test malware, you need to get 103 00:05:04.160 --> 00:05:05.399 explicit permission first. 104 00:05:05.519 --> 00:05:08.600 Gotcha approval needed for the more aggressive stuff. What about 105 00:05:08.639 --> 00:05:10.519 Azure and the Microsoft Cloud? 106 00:05:10.720 --> 00:05:13.759 Microsoft's also pretty open. Most pen testing is okay without 107 00:05:13.879 --> 00:05:14.959 prior notice. 108 00:05:14.720 --> 00:05:15.800 But again there are lines. 109 00:05:15.959 --> 00:05:20.240 Oh yeah, Crucially, don't test anyone else's stuff. Only your 110 00:05:20.240 --> 00:05:24.079 own assets and data. No massive floods of automated traffic, 111 00:05:24.439 --> 00:05:28.680 no dusty dass standard stuff. Network fuzzing is okay, but 112 00:05:28.800 --> 00:05:31.639 only against your own vms. And if you find an 113 00:05:31.639 --> 00:05:34.600 infrastructure issue, just show a proof of concept, don't exploit 114 00:05:34.639 --> 00:05:38.000 it further, and definitely no trying to social engineer or 115 00:05:38.000 --> 00:05:38.879 Microsoft staff. 116 00:05:38.959 --> 00:05:42.879 Right, common sense really and g. 117 00:05:42.040 --> 00:05:46.000 GCP allows pen testing without notification, but you have to 118 00:05:46.000 --> 00:05:49.120 stick to their acceptable use policy and terms of service, 119 00:05:49.199 --> 00:05:53.319 which means no disrupting other customers, So no d doo ass, 120 00:05:53.600 --> 00:05:57.519 no malware spreading, no trying to access other people's projects, 121 00:05:58.040 --> 00:06:02.160 and obviously nothing illegal. You can do vulnerability scanning within 122 00:06:02.199 --> 00:06:05.519 your own projects, but you need your company's written permission first. 123 00:06:05.720 --> 00:06:08.560 So the takeaway is know the rules for the specific 124 00:06:08.600 --> 00:06:11.560 cloud you're testing. You're a guest in their house in 125 00:06:11.600 --> 00:06:12.160 a way. 126 00:06:12.160 --> 00:06:16.199 A guest with responsibilities. Now understanding those boundaries, let's talk 127 00:06:16.199 --> 00:06:18.839 about how attackers actually come after these cloud setups. 128 00:06:18.879 --> 00:06:20.600 Right where did the attacks usually start? 129 00:06:20.759 --> 00:06:24.000 You can broadly think about external versus internal attacks. External 130 00:06:24.079 --> 00:06:28.079 gets the headlines, you know, the hacker and a hoodie stereotype, 131 00:06:28.240 --> 00:06:33.759 but internal attacks leveraging someone already inside, someone trusted, those 132 00:06:33.800 --> 00:06:36.199 can be really damaging and harder to spot. 133 00:06:36.319 --> 00:06:38.639 The book had that kind of chilling example, the janitor 134 00:06:38.680 --> 00:06:39.680 with a USB stick. 135 00:06:39.800 --> 00:06:43.920 Yeah, it illustrates the insider risk perfectly. Imagine a janitor 136 00:06:44.279 --> 00:06:47.600 has legitimate access to the server room, not an impostor 137 00:06:47.920 --> 00:06:51.480 a real employee doing their job. Because they have that 138 00:06:51.560 --> 00:06:56.160 trusted physical access, they could theoretically plug in a USB 139 00:06:56.360 --> 00:06:57.800 drive with malware into a. 140 00:06:57.759 --> 00:07:01.040 Server bypassing all the external firewalls defenses. 141 00:07:00.639 --> 00:07:04.560 Completely, and suddenly that server could infect all the client 142 00:07:04.600 --> 00:07:07.920 machines it manages. Shows how exploiting trust can be a 143 00:07:07.959 --> 00:07:09.120 powerful attack vector. 144 00:07:09.279 --> 00:07:12.879 That's a really stark reminder. So besides physical access like that, 145 00:07:13.079 --> 00:07:16.120 what are the more common digital entry points the attack vectors. 146 00:07:16.160 --> 00:07:19.680 Often it's vulnerabilities and web applications facing the Internet or 147 00:07:19.920 --> 00:07:20.680 open ports that. 148 00:07:20.600 --> 00:07:22.759 Shouldn't be misconfigurations exactly. 149 00:07:22.839 --> 00:07:25.959 Or attackers might go after accounts trying to crack passwords 150 00:07:26.000 --> 00:07:29.839 or fish credentials, especially for accounts with high privileges. 151 00:07:29.319 --> 00:07:32.519 Gain a legitimate log in from their perspective right. 152 00:07:32.959 --> 00:07:36.959 And sometimes, though maybe less common, it's bribing or coercing 153 00:07:36.959 --> 00:07:40.160 an actual insider to help them get access or plant something. 154 00:07:40.319 --> 00:07:42.519 Okay, so they get in, what are they trying to 155 00:07:42.560 --> 00:07:44.120 do once they're inside? What's the goal? 156 00:07:44.519 --> 00:07:47.680 Most attacks boiled down to hitting one or more aspects 157 00:07:47.680 --> 00:07:52.680 of the CIA triad Confidentiality, integrity, availability. 158 00:07:52.040 --> 00:07:57.279 Right, the classic security principles, So confidentiality first, keeping secret secret. 159 00:07:57.079 --> 00:08:00.720 Pretty much preventing unauthorized access to sense in seative data. 160 00:08:01.120 --> 00:08:04.120 A data breach is a direct hit on confidentiality. 161 00:08:04.319 --> 00:08:07.279 The book mentioned the DC health Link breach from March 162 00:08:07.319 --> 00:08:08.959 twenty twenty three. What happened there? 163 00:08:09.079 --> 00:08:12.240 Yeah, DC health Link handles insurance for government folks. They 164 00:08:12.319 --> 00:08:15.839 reported that data for like fifty six thousand customers was 165 00:08:15.879 --> 00:08:22.120 exposed names, social security numbers, health plan info, really sensitive. 166 00:08:21.720 --> 00:08:23.920 Stuff, ouch and the likely cause. In a cloud. 167 00:08:23.680 --> 00:08:27.160 Context, the book suggests data from cloud storage based on 168 00:08:27.240 --> 00:08:29.920 the IATT and CK framework, which we should talk more 169 00:08:29.920 --> 00:08:33.960 about later. Basically, data stored in the cloud wasn't properly secured. 170 00:08:33.679 --> 00:08:38.080 A major confidentiality failure with real consequences. Okay, what about integrity? 171 00:08:38.200 --> 00:08:42.399 Integrity is about preventing unauthorized changes to data, making sure 172 00:08:42.519 --> 00:08:44.200 data is accurate and trustworthy. 173 00:08:44.279 --> 00:08:46.759 So a tax might involve what. 174 00:08:47.120 --> 00:08:50.559 Things like injecting malicious code into a website or database, 175 00:08:51.519 --> 00:08:53.759 or man in the middle attacks where they intercept and 176 00:08:53.799 --> 00:08:57.600 alter data as it travels. Stealing TLS certificates could also 177 00:08:57.679 --> 00:09:01.879 let them impersonate a legit service sing within integrity. 178 00:09:01.480 --> 00:09:04.600 Right, corrupting the data or the process. And the last 179 00:09:04.600 --> 00:09:07.320 one availability, Availability. 180 00:09:06.679 --> 00:09:09.519 Is just making sure authorized users can actually access the 181 00:09:09.600 --> 00:09:11.080 data and services when they need to. 182 00:09:11.480 --> 00:09:14.120 So denial of service attacks fit here exactly. 183 00:09:14.519 --> 00:09:18.440 DTOs distributed denial of service is the classic example, overwhelm 184 00:09:18.440 --> 00:09:21.080 the server with so much junk traffic that legitimate users 185 00:09:21.080 --> 00:09:21.639 can't get through. 186 00:09:21.720 --> 00:09:24.159 The book mentioned a huge one against a Google Cloud customer. 187 00:09:24.240 --> 00:09:27.480 Yeah, August twenty twenty two peaked at something crazy like 188 00:09:27.559 --> 00:09:32.080 forty six million requests per second an HTTPS d DOOS attack. 189 00:09:32.200 --> 00:09:33.480 Wow did it work? 190 00:09:33.799 --> 00:09:37.320 Fortunately, Google Cloud Armor, their protection service, managed to block it. 191 00:09:37.639 --> 00:09:39.639 But it shows the scale of threats trying to knock 192 00:09:39.679 --> 00:09:40.840 services offline. 193 00:09:41.000 --> 00:09:46.240 So attackers are constantly probing for ways to break confidentiality, integrity, 194 00:09:46.320 --> 00:09:50.559 or availability. Now, say they succeed in getting that initial foothold, 195 00:09:51.039 --> 00:09:53.279 what happens next? They don't just sit. 196 00:09:53.120 --> 00:09:56.519 There, No, rarely, that's where lateral movement comes in. Once 197 00:09:56.519 --> 00:09:59.639 they're inside, the goal is usually to move deeper, find 198 00:09:59.639 --> 00:10:00.799 more valvaluable targets. 199 00:10:00.960 --> 00:10:02.080 How does that work in the cloud? 200 00:10:02.480 --> 00:10:04.600 They might try to jump from one compromise service to 201 00:10:04.639 --> 00:10:07.120 another within the same cloud account, say from a web 202 00:10:07.120 --> 00:10:10.320 server to a database, or in a multi cloud setup, 203 00:10:10.519 --> 00:10:13.559 maybe pivot from Aws to Azure if there's a. 204 00:10:13.519 --> 00:10:18.720 Connection, trying to escalate privileges or find sensitive data stores exactly. 205 00:10:18.399 --> 00:10:22.200 Find accounts with more power access, more systems spread their control. 206 00:10:22.360 --> 00:10:26.159 That sounds really dangerous moving silently inside the perimeter. How 207 00:10:26.200 --> 00:10:28.559 do you defend against that kind of internal spread? 208 00:10:29.039 --> 00:10:31.679 This is really where the zero trust model shines. The 209 00:10:31.759 --> 00:10:34.840 old way was perimeter security, build a strong wall, assume 210 00:10:34.840 --> 00:10:35.960 everything inside is safe. 211 00:10:36.000 --> 00:10:37.799 The castle and mote approach right. 212 00:10:37.960 --> 00:10:40.679 Zero trust throws that out. It assumes no user or 213 00:10:40.720 --> 00:10:44.320 device is inherently trustworthy, even if it's already inside the. 214 00:10:44.279 --> 00:10:47.120 Network, So you verify everything all the time. 215 00:10:47.440 --> 00:10:51.360 Pretty much every request to access a resource gets checked 216 00:10:51.360 --> 00:10:56.559 for authentication and authorization continuously. It doesn't matter if you're 217 00:10:56.559 --> 00:10:59.200 coming from outside or supposedly inside. 218 00:10:59.320 --> 00:11:01.519 That must make it much harder for an attacker to 219 00:11:01.679 --> 00:11:03.159 just wander around after getting in. 220 00:11:03.279 --> 00:11:06.440 It does. They might compromise one thing, maybe steal some 221 00:11:06.480 --> 00:11:10.039 initial credentials, but to move laterally they have to keep 222 00:11:10.120 --> 00:11:13.559 passing these checks, keep reauthenticating and proving their allowed access 223 00:11:13.559 --> 00:11:14.120 to the next thing. 224 00:11:14.240 --> 00:11:17.720 More hurdles, more chances to get caught significantly more. 225 00:11:18.159 --> 00:11:21.519 It prevents a small breach from easily becoming a full 226 00:11:21.600 --> 00:11:22.559 network compromise. 227 00:11:23.200 --> 00:11:26.080 Okay, that makes sense, so we understand the threats the 228 00:11:26.120 --> 00:11:29.519 defenses like zero trust. Let's get back to the testing part. 229 00:11:30.360 --> 00:11:33.399 What are the core concepts pen testers need for the cloud? 230 00:11:33.879 --> 00:11:36.679 Well, first things first, before you launch any tools, you 231 00:11:36.759 --> 00:11:39.000 need a solid vulnerability assessment. 232 00:11:39.200 --> 00:11:40.759 Understanding the target. 233 00:11:40.559 --> 00:11:44.039 Yeah, mapping out what's there, what services are running, what's exposed, 234 00:11:44.360 --> 00:11:47.039 defining the scope, what are you actually testing and what's 235 00:11:47.080 --> 00:11:49.120 off limits? You need that clear picture. 236 00:11:49.399 --> 00:11:53.080 The book emphasizes the ININTI att and SK framework. You 237 00:11:53.120 --> 00:11:56.840 mentioned it briefly. Why is it so important for pen testers, 238 00:11:56.919 --> 00:11:58.000 especially red teams? 239 00:11:58.360 --> 00:12:03.519 Minor? ATT and CK is basically a massive, organized library 240 00:12:03.840 --> 00:12:07.519 of attacker tactics and techniques. It breaks down how real 241 00:12:07.559 --> 00:12:10.159 world cyber attacks happen, step by step. 242 00:12:10.000 --> 00:12:11.559 Like a playbook of bad guy moves. 243 00:12:11.919 --> 00:12:14.720 Kind of yeah. It gives everyone a common language. For 244 00:12:14.840 --> 00:12:19.200 red teams trying to simulate real attackers. Its gold. They 245 00:12:19.200 --> 00:12:21.799 can use ATT and CK to model their tests after 246 00:12:21.840 --> 00:12:25.240 specific threat groups or known attack patterns. Makes the simulation 247 00:12:25.440 --> 00:12:26.399 much more realistic. 248 00:12:26.639 --> 00:12:30.559 Very useful resource. What about cloud integrations systems talking to 249 00:12:30.600 --> 00:12:31.000 each other? 250 00:12:31.200 --> 00:12:34.720 Huge area. Most organizations connect different cloud services or link 251 00:12:34.759 --> 00:12:36.559 their on prem stuff to the cloud, and. 252 00:12:36.519 --> 00:12:38.600 The connections themselves can be weak points. 253 00:12:38.600 --> 00:12:43.320 Absolutely Often these connections use API's application programming interfaces. If 254 00:12:43.320 --> 00:12:46.799 those APIs aren't secured properly, they become a major vulnerability. 255 00:12:47.360 --> 00:12:49.720 They can be vulnerable to injection attacks like feeding the 256 00:12:49.799 --> 00:12:53.120 malicious commands, or they might have weak access controls, letting 257 00:12:53.159 --> 00:12:56.159 an attack, or do things they shouldn't. Testing these APIs is. 258 00:12:56.120 --> 00:12:58.919 Critical, so don't just test the services, test how they 259 00:12:58.919 --> 00:13:02.519 talk to each other. The book also talks about vulnerability 260 00:13:02.600 --> 00:13:04.799 databases like CVE right. 261 00:13:05.279 --> 00:13:09.080 CVE stands for Common Vulnerabilities and Exposures. It's a public 262 00:13:09.120 --> 00:13:12.679 list of known security flaws in software and hardware, so. 263 00:13:12.639 --> 00:13:14.559 If you find something, you can check if it's already 264 00:13:14.600 --> 00:13:15.440 known exactly. 265 00:13:15.960 --> 00:13:19.600 Each known vulnerability gets a unique ID like CVE twenty 266 00:13:19.639 --> 00:13:23.039 twenty three something something helps everyone track the same issue. 267 00:13:23.080 --> 00:13:24.919 And those CVSS. 268 00:13:24.279 --> 00:13:27.679 Scores CVSS Common Vulnerability scoring System. It's a way to 269 00:13:27.799 --> 00:13:30.919 rate how severe vulnerability is. Goes from point zero to ten. 270 00:13:30.960 --> 00:13:33.799 Point zero, higher is worse, much worse. Yeah, gives you 271 00:13:33.840 --> 00:13:35.759 a quick idea of how critical it is to fix. 272 00:13:36.080 --> 00:13:39.480 You often find CVE details and CVSS scores on the 273 00:13:39.559 --> 00:13:42.360 NIST National Vulnerability Database the NVD. 274 00:13:42.279 --> 00:13:46.879 Okay, so CVE identifies it, CVSS ranks its severity. Helpful 275 00:13:46.919 --> 00:13:50.000 context for a pen tester what about purple teaming? That 276 00:13:50.080 --> 00:13:50.840 sounds colorful. 277 00:13:51.039 --> 00:13:53.679 Huh Yeah, So usually have a red team the attackers 278 00:13:53.679 --> 00:13:55.960 the pen testers, and a blue team that defenders the 279 00:13:55.960 --> 00:13:57.600 security operations center. 280 00:13:57.360 --> 00:13:59.320 Folks, offensive ver's defensive. 281 00:13:59.120 --> 00:14:02.039 Right teaming is when they work together. Instead of the 282 00:14:02.039 --> 00:14:03.879 red team trying to be sneaky and the blue team 283 00:14:03.919 --> 00:14:06.639 trying to catch them, they collaborate during the test. 284 00:14:06.840 --> 00:14:07.600 How does that help? 285 00:14:07.879 --> 00:14:10.759 The red team finds vulnerability, they immediately share it with 286 00:14:10.799 --> 00:14:13.559 the blue team. The blue team can then test their 287 00:14:13.559 --> 00:14:16.480 detection and response in real time. It speeds up the 288 00:14:16.519 --> 00:14:20.000 feedback loop improves both offense and defense much faster. 289 00:14:20.240 --> 00:14:24.840 More collaborative, less adversarial. Makes sense. Yeah, And finally, the 290 00:14:24.879 --> 00:14:27.120 pentist report. Why is that so important? 291 00:14:27.639 --> 00:14:30.240 The report is the whole point. Really, it's the formal 292 00:14:30.320 --> 00:14:32.480 ride up of everything The pendester found. 293 00:14:32.519 --> 00:14:33.399 A list of problems. 294 00:14:33.440 --> 00:14:37.279 Oh no, much more. It details the vulnerabilities, explains the 295 00:14:37.320 --> 00:14:40.360 impact what could actually happen if an attack or exploited this, 296 00:14:40.960 --> 00:14:44.399 and crucially, it gives clear recommendations on how to fix things. 297 00:14:44.559 --> 00:14:46.799 So it's the roadmap for improvement exactly. 298 00:14:47.120 --> 00:14:49.440 It needs to be clear enough for managers to understand 299 00:14:49.440 --> 00:14:52.240 the risk and technical enough for the security team to 300 00:14:52.240 --> 00:14:55.519 actually implement the fixes. It's a critical communication tool. 301 00:14:55.639 --> 00:14:58.919 Okay, concepts covered, let's talk tools. The book lists quite 302 00:14:58.919 --> 00:15:01.320 a few. Can you give us some examples for say, 303 00:15:01.480 --> 00:15:02.879 AWS Sure On. 304 00:15:02.840 --> 00:15:06.600 The AWS side, there's AWS Security Hub. It's not exactly 305 00:15:06.600 --> 00:15:09.080 a pen testing tool, but it pulls together findings from 306 00:15:09.279 --> 00:15:13.480 aus's own security services i AM Access Analyzer, Guard Duty 307 00:15:13.519 --> 00:15:14.799 inspector MACY. 308 00:15:15.159 --> 00:15:18.120 Still like a dashboard for AWS security posture. 309 00:15:18.240 --> 00:15:20.720 Yeah, a good starting point to see what AWS itself 310 00:15:20.759 --> 00:15:24.159 is flagging. For more active scanning, Prowler is really popular. 311 00:15:24.200 --> 00:15:28.120 Prowler Yeah, open source. It scans AWS but also Azure 312 00:15:28.120 --> 00:15:33.240 and GCP looking for misconfigurations, hardening checks, following benchmarks like CIS. 313 00:15:33.320 --> 00:15:36.399 You can run it easily, install via pip or Docker. 314 00:15:36.399 --> 00:15:40.120 Multi cloud capable, nice, any others for AWS. 315 00:15:40.279 --> 00:15:43.200 Puku is another well known open source framework specifically for 316 00:15:43.240 --> 00:15:46.480 AWS pen testing. Again, installable via pip. 317 00:15:46.320 --> 00:15:51.159 So Prowler for broader checks, Pakuo for more focused AWS exploitation. 318 00:15:50.840 --> 00:15:53.600 Kind of yeah. Then you have simpler tools like cred scanner, 319 00:15:53.759 --> 00:15:56.960 just a Python script to hunt for exposed credentials line around. 320 00:15:56.720 --> 00:15:59.919 In files oooh finding those accidental secrets. 321 00:15:59.519 --> 00:16:03.759 Exactly, and cloud Front, which focuses specifically on finding misconfigurations 322 00:16:03.759 --> 00:16:05.960 in AWS cloud Front their CDN service. 323 00:16:06.000 --> 00:16:08.840 Okay, good examples for AWS. What about Azure or GCP 324 00:16:09.120 --> 00:16:09.679 For Azure? 325 00:16:09.759 --> 00:16:13.120 The book mentions MFA swoop it checks if multi factor 326 00:16:13.159 --> 00:16:17.399 authentication is enabled to cross different Azure services. Basic but 327 00:16:17.519 --> 00:16:18.320 really important. 328 00:16:18.519 --> 00:16:20.399 Can't stress MFA enough right. 329 00:16:20.879 --> 00:16:24.679 Scout Suite is another multi cloud tool like prowler. It 330 00:16:24.720 --> 00:16:29.519 audits AWS, Azure, and GCP, pulling config data and highlighting risks. 331 00:16:29.840 --> 00:16:34.080 Good forgetting that cross cloud view. What about containers? Docker 332 00:16:34.440 --> 00:16:35.799 Kubernetes are huge now? 333 00:16:36.000 --> 00:16:39.039 Definitely Trevia has mentioned it's a scanner for container images 334 00:16:39.240 --> 00:16:42.559 looking for known vulnerabilities. Works for Docker, Kubernetes images and 335 00:16:42.639 --> 00:16:43.240 other things. 336 00:16:43.080 --> 00:16:45.000 Too important for supply chain security. 337 00:16:45.159 --> 00:16:48.879 Absolutely for Kubernetes specifically, there's tools like cube hunter and 338 00:16:48.960 --> 00:16:52.799 Digger designed to probe Kubernetes clusters for security weaknesses. 339 00:16:52.960 --> 00:16:55.399 And GCP specific tools. 340 00:16:55.080 --> 00:16:57.840 Yeah, things like GCP bucket Brute for checking Google Cloud 341 00:16:57.879 --> 00:17:01.360 Storage bucket permissions and GCP Scanner for looking at credential 342 00:17:01.440 --> 00:17:03.679 access levels within a GCP project. 343 00:17:04.119 --> 00:17:06.440 Wow. Quite the toolkit seems like there's a tool for 344 00:17:06.480 --> 00:17:07.240 almost everything. 345 00:17:07.559 --> 00:17:10.720 There often is, but knowing how and when to use 346 00:17:10.720 --> 00:17:13.319 them effectively and how to interpret the results. 347 00:17:13.559 --> 00:17:17.640 That's the key skill right now, Let's quickly loop back 348 00:17:17.680 --> 00:17:22.480 to those service models, ISS, PASSSAS and how security differs. 349 00:17:22.559 --> 00:17:24.519 We touched on it with shared responsibility. 350 00:17:24.599 --> 00:17:28.519 Yeah, it's worth recapping. With SAS, think Gmail salesforce. The 351 00:17:28.559 --> 00:17:32.279 provider handles almost all the security. Your main job is 352 00:17:32.319 --> 00:17:35.640 managing your data within the app and user access. Pen 353 00:17:35.680 --> 00:17:38.240 testing SAS is often very restricted by the provider. 354 00:17:38.440 --> 00:17:40.720 Makes sense. You don't own the underlying app or infra. 355 00:17:41.160 --> 00:17:42.200 What about PASS. 356 00:17:42.519 --> 00:17:46.240 Platform is a service Here, the provider gives you the platform, 357 00:17:46.240 --> 00:17:49.960 maybe a database service or a Kubernetes environment like aws EKS. 358 00:17:50.799 --> 00:17:51.839 You build your apps on. 359 00:17:51.799 --> 00:17:54.680 It, so you secure your app. They secure the platform mostly. 360 00:17:54.759 --> 00:17:57.920 Yeah, you're responsible for your application code, it's configuration, how 361 00:17:57.920 --> 00:18:00.400 it uses the platform services. They handle the OA patching 362 00:18:00.480 --> 00:18:04.359 underneath the platform, resilience, etc. Pen testing focuses on your 363 00:18:04.359 --> 00:18:07.319 application and its interaction with the PASS Okay and I 364 00:18:07.599 --> 00:18:09.759 infrastructure as a service. That's where you have the most 365 00:18:09.759 --> 00:18:13.559 control and therefore the most responsibility. You get virtual machines, 366 00:18:13.680 --> 00:18:15.359 storage networking. 367 00:18:15.160 --> 00:18:16.200 Like renting the hardware. 368 00:18:16.359 --> 00:18:20.240 Essentially pretty much, you manage the operating system, patching it 369 00:18:20.640 --> 00:18:24.920 installing software, configuring firewalls within your virtual network, securing your 370 00:18:24.960 --> 00:18:28.359 data on those vms. The provider just secures the physical 371 00:18:28.440 --> 00:18:30.079 data center and the virtualization layer. 372 00:18:30.519 --> 00:18:33.599 So is pen testing looks more like traditional network pen 373 00:18:33.640 --> 00:18:34.759 testing closer? 374 00:18:35.039 --> 00:18:38.319 Yes, but you still need to understand the cloud provider 375 00:18:38.400 --> 00:18:41.599 specific services and control plane because that's part of your 376 00:18:41.640 --> 00:18:43.200 attack surface too, got it? 377 00:18:43.640 --> 00:18:46.279 And across all these zero trust remains. 378 00:18:45.880 --> 00:18:50.880 The best approach, definitely, because that perimeter is so blurry 379 00:18:51.000 --> 00:18:53.759 or non existent in the cloud. Assuming zero trust and 380 00:18:53.839 --> 00:18:57.160 verifying everything is the way to go, regardless of IAS, 381 00:18:57.200 --> 00:18:58.599 pass or sauce elements. 382 00:18:58.880 --> 00:19:01.880 And the book also brought up RBAC again, role based 383 00:19:01.920 --> 00:19:04.079 access control. Why is that fundamental? 384 00:19:04.480 --> 00:19:06.960 RBAC is how you manage who can do what in 385 00:19:07.000 --> 00:19:10.000 the cloud. Instead of giving permissions to individual users, you 386 00:19:10.039 --> 00:19:12.480 create roles like database admin or. 387 00:19:12.480 --> 00:19:14.440 Web developer and assigned permissions to. 388 00:19:14.400 --> 00:19:17.480 The roles exactly. Then you assign users to those roles. 389 00:19:17.519 --> 00:19:21.039 It's much cleaner, easier to manage, especially at scale, and 390 00:19:21.079 --> 00:19:24.400 it enforces the principle of least privilege poll LP. Giving 391 00:19:24.480 --> 00:19:27.440 users only the minimum permissions they absolutely need to do 392 00:19:27.480 --> 00:19:31.079 their job nothing more. Reduces the potential damage if an 393 00:19:31.079 --> 00:19:35.240 account gets compromised. RBAC is also native to Kubernetes, making 394 00:19:35.240 --> 00:19:36.160 it vital there too. 395 00:19:36.680 --> 00:19:39.720 Okay, this has been a really comprehensive look at cloud 396 00:19:39.759 --> 00:19:42.200 pen testing. If you had to boil it down, what 397 00:19:42.240 --> 00:19:44.640 are the absolute key takeaways for our listener? 398 00:19:44.759 --> 00:19:49.400 I'd say one, cloud pen testing is different and essential. Two, 399 00:19:49.799 --> 00:19:53.559 you must understand the shared responsibility model for your specific services. 400 00:19:53.640 --> 00:19:55.920 It's not just someone else's computer, not at all. 401 00:19:56.359 --> 00:19:59.640