WEBVTT 1 00:00:00.160 --> 00:00:04.120 Welcome to a deep dive into serverlest security. We've got 2 00:00:04.480 --> 00:00:07.400 quite a stack of resources this time, including excerpts from 3 00:00:07.440 --> 00:00:11.679 the book serverlest Security, Understand, Assess, and Implement Secure in 4 00:00:11.759 --> 00:00:14.800 Time by miguel A. Collis. So today we're going to 5 00:00:14.800 --> 00:00:18.160 try to extract the essential nuggets and help you get 6 00:00:18.199 --> 00:00:19.760 up to speed on serverlest security. 7 00:00:19.879 --> 00:00:23.239 Yeah, we're gonna be looking at what makes serverlest security unique, 8 00:00:23.559 --> 00:00:26.559 how to think about risk, and the practical steps you 9 00:00:26.600 --> 00:00:28.160 can take to protect your applications. 10 00:00:28.399 --> 00:00:32.679 It's interesting how serverleists can work with any cloud model, right, private, public, 11 00:00:32.880 --> 00:00:35.679 or even a hybrid setup. But you know, the book 12 00:00:35.679 --> 00:00:38.439 makes it very clear that regardless of the model, threats exist. 13 00:00:38.759 --> 00:00:41.759 Why focus on serverleist security specifically, It seems like these 14 00:00:41.799 --> 00:00:44.119 platforms already have some security built in. 15 00:00:44.560 --> 00:00:47.560 You're right, they do come with some inherent security features, 16 00:00:47.840 --> 00:00:51.320 but it's a shared responsibility model. The provider takes care 17 00:00:51.359 --> 00:00:54.079 of the underlying infrastructure, but you're in charge of securing 18 00:00:54.159 --> 00:00:56.719 your apps and your data. And server list brings its 19 00:00:56.759 --> 00:00:58.560 own unique set of security challenges. 20 00:00:58.880 --> 00:01:02.880 Okay, I'm all ears, let's unpack these unique challenges. The 21 00:01:02.880 --> 00:01:05.519 next part of the book focuses on understanding the application 22 00:01:05.599 --> 00:01:09.680 you're trying to secure. It's like know your enemy right exactly. 23 00:01:10.560 --> 00:01:14.480 Every serverless application is unique, so it needs a tailored 24 00:01:14.480 --> 00:01:18.159 security approach. The book recommends starting with a good old 25 00:01:18.200 --> 00:01:22.920 fashioned documentation review. Architecture diagrams are key. They're like blueprints, 26 00:01:23.159 --> 00:01:26.400 mapping out your applications components and how they interact, giving 27 00:01:26.439 --> 00:01:27.719 you a visual guide, so. 28 00:01:27.719 --> 00:01:30.799 Getting a bird's eye view of the application landscape precisely. 29 00:01:31.400 --> 00:01:33.920 Then we move on to source code review. This is 30 00:01:33.920 --> 00:01:36.079 where you get your hands storty, looking at the functions, 31 00:01:36.159 --> 00:01:39.159 run time engines, and event triggers that make up your application. 32 00:01:39.680 --> 00:01:43.000 By understanding the code, you can spot vulnerabilities, things like 33 00:01:43.079 --> 00:01:45.879 insecure coding practices or risky dependencies. 34 00:01:46.120 --> 00:01:47.599 This is where we roll up our sleeves and get 35 00:01:47.599 --> 00:01:50.079 into the nuts and bolts. What about system accounts? The 36 00:01:50.120 --> 00:01:51.319 book mentioned those right. 37 00:01:51.359 --> 00:01:54.599 System account review is critical. You're looking for threats both 38 00:01:54.640 --> 00:01:58.120 from the outside and the inside. By analyzing user accounts, permissions, 39 00:01:58.120 --> 00:02:01.000 and access controls. We want to make sure that only 40 00:02:01.000 --> 00:02:05.319 the right people can access sensitive resources. Got it, locking 41 00:02:05.359 --> 00:02:08.000 things down, making sure the right people have the right access. 42 00:02:08.919 --> 00:02:12.039 But this next part is interesting. The book actually suggests 43 00:02:12.159 --> 00:02:15.919 using the application to understand its security hands on approach. 44 00:02:16.159 --> 00:02:16.520 I like it. 45 00:02:16.719 --> 00:02:18.919 H By actually using the app, you can see its 46 00:02:18.919 --> 00:02:21.680 network traffic in real time. You see how data is 47 00:02:21.719 --> 00:02:24.879 transmitted and identify any red flags. Think of it as 48 00:02:24.879 --> 00:02:26.120 a security test drive. 49 00:02:26.400 --> 00:02:30.000 I love it. We've got the application blueprint from the documentation, 50 00:02:30.280 --> 00:02:32.560 we've looked under the hood with the source code, and 51 00:02:32.560 --> 00:02:35.360 we've taken it for a security test drive. Now let's 52 00:02:35.400 --> 00:02:36.199 talk threats. 53 00:02:36.560 --> 00:02:40.000 Okay, but first we've got to define the security enclave, 54 00:02:40.280 --> 00:02:43.520 sometimes called the trust boundary. It's like drawing a line 55 00:02:43.560 --> 00:02:46.400 around the parts of your application that you're responsible for securing. 56 00:02:47.000 --> 00:02:49.719 Anything outside that line might have different security needs or 57 00:02:49.759 --> 00:02:51.000 be managed by someone else. 58 00:02:51.120 --> 00:02:55.199 Okay, establishing the defensive perimeter exactly. Now, about those threats. 59 00:02:55.840 --> 00:03:00.240 The FBI's Internet Crime Complaint Center or IC three, they've 60 00:03:00.240 --> 00:03:03.360 seen a huge increase in Internet crime costs, going from 61 00:03:03.360 --> 00:03:05.520 five hundred and eighty one point four million dollars in 62 00:03:05.520 --> 00:03:08.800 twenty twelve to a whopping two point seven billion dollars 63 00:03:08.840 --> 00:03:12.520 in twenty eighteen. And you know, serverless applications, with all 64 00:03:12.520 --> 00:03:15.439 their moving parts and reliance on other services they could 65 00:03:15.439 --> 00:03:16.319 be attempting target. 66 00:03:16.520 --> 00:03:19.120 Those numbers are scary, So who are we up against? 67 00:03:19.360 --> 00:03:22.400 The book mentions script kitties, who are they? And should 68 00:03:22.439 --> 00:03:23.120 we be worried? 69 00:03:23.400 --> 00:03:26.719 Script kitties are individuals, usually with limited skills, who use 70 00:03:26.759 --> 00:03:29.599 pre made tools and scripts to launch attacks. They're mostly 71 00:03:29.680 --> 00:03:33.120 driven by curiosity, maybe a desire to cause little chaos. 72 00:03:33.520 --> 00:03:36.759 Think of them as like digital graffiti artists. Annoying but 73 00:03:36.840 --> 00:03:38.599 not super sophisticated, so. 74 00:03:38.680 --> 00:03:40.479 More of a nuisance than a serious threat. 75 00:03:40.759 --> 00:03:43.599 Yeah. Generally, basic security hygiene like keeping your systems up 76 00:03:43.599 --> 00:03:46.280 to date and using firewalls can usually keep them away. 77 00:03:46.599 --> 00:03:48.919 Good to know. What about cybercriminals? They sound much more 78 00:03:48.960 --> 00:03:49.879 formidable they are. 79 00:03:50.039 --> 00:03:54.520 Cybercriminals are motivated by profit, plan and simple. They use malware, phishing, scams, 80 00:03:54.560 --> 00:03:58.199 social engineering, all kinds of tactics to steal data, compromise systems, 81 00:03:58.240 --> 00:03:59.199 basically make money. 82 00:03:59.240 --> 00:04:00.919 These are the pro the ones who really know what 83 00:04:00.919 --> 00:04:02.560 they're doing exactly. 84 00:04:02.439 --> 00:04:05.680 And they're constantly evolving. Defending against them takes a multi 85 00:04:05.759 --> 00:04:11.400 layered approach, strong authentication, intrusion detection systems, security audits, you 86 00:04:11.520 --> 00:04:13.280 name it. It's a constant battle. 87 00:04:13.560 --> 00:04:16.120 Sounds like we need to stay agile to stay ahead. 88 00:04:17.000 --> 00:04:22.040 The book also mentions activists, how are they different activists. 89 00:04:21.439 --> 00:04:26.160 Are groups sometimes individuals, driven by a cause or an ideology. 90 00:04:26.439 --> 00:04:29.439 They might target organizations or governments they don't agree with, 91 00:04:29.800 --> 00:04:34.120 to facing websites, leaking information, disrupting operations, that kind of thing. 92 00:04:34.199 --> 00:04:37.959 Hacking with a purpose. Their motives seem unpredictable, which makes 93 00:04:37.959 --> 00:04:39.279 them harder to anticipate. 94 00:04:39.519 --> 00:04:41.920 Yeah, their motivations can make them tough to defend against. 95 00:04:42.399 --> 00:04:45.519 They might not care about financial loss or legal consequences. 96 00:04:46.040 --> 00:04:49.040 To mitigate this risk, you really need to understand their 97 00:04:49.079 --> 00:04:50.959 ideology who they might target. 98 00:04:51.199 --> 00:04:54.680 So we've got curious kids, criminals after money, and activists 99 00:04:54.720 --> 00:04:57.800 with an agenda. Is there anyone else lurking around that 100 00:04:57.839 --> 00:04:58.920 we need to worry about? 101 00:04:59.199 --> 00:05:04.360 Unfortunately? Yeah, yes, state sponsored attackers. These groups have backing 102 00:05:04.399 --> 00:05:08.480 from governments, and they often have significant resources and very 103 00:05:08.480 --> 00:05:13.800 advanced techniques. They might go after critical infrastructure, steal intellectual property, 104 00:05:13.920 --> 00:05:15.240 or conduct espionage. 105 00:05:15.399 --> 00:05:17.920 Wow, the heavy hitters of the cyber world. 106 00:05:18.120 --> 00:05:22.279 That's right. Defending against these guys takes proactive threat intelligence 107 00:05:22.480 --> 00:05:25.800 and advanced security measures. You've got to be one step ahead. 108 00:05:25.560 --> 00:05:29.920 Constantly monitoring the threat landscape, trying to anticipate their moves. 109 00:05:30.360 --> 00:05:32.839 Any other threats we need to consider don't forget. 110 00:05:32.680 --> 00:05:35.639 About insider threats. These can be current employees or even 111 00:05:35.680 --> 00:05:40.360 former employees, contractors, partners, anyone with legitimate access to your systems, 112 00:05:40.839 --> 00:05:45.240 but they misuse that access, either intentionally or unintentionally, like 113 00:05:45.319 --> 00:05:47.959 stealing data or accidentally leaking information. 114 00:05:48.120 --> 00:05:49.959 The wolf in sheep's clothing exactly. 115 00:05:50.360 --> 00:05:53.079 They often have a deep understanding of your systems in security, 116 00:05:53.240 --> 00:05:54.879 which makes them especially dangerous. 117 00:05:55.199 --> 00:05:57.600 This threat landscape is pretty intense. So where do we 118 00:05:57.639 --> 00:06:00.360 even begin to assess all these risks and feel a 119 00:06:00.360 --> 00:06:01.240 little overwhelmed. 120 00:06:01.360 --> 00:06:04.279 That's where a risk assessment comes in. It's a systematic 121 00:06:04.319 --> 00:06:07.879 way to identify potential threats, figure out how likely they 122 00:06:07.879 --> 00:06:10.000 are to happen and what their impact could be, and 123 00:06:10.040 --> 00:06:12.040 then come up with the right mitigation strategies. 124 00:06:12.120 --> 00:06:15.959 Okay, so we're bringing some order to the chaos, prioritizing 125 00:06:15.959 --> 00:06:18.920 our efforts based on a clear understanding of the risks. 126 00:06:19.160 --> 00:06:22.399 Right. The book suggests using a risk assessment table. It's 127 00:06:22.439 --> 00:06:26.680 simple but effective. You list your assets, the threats they face, 128 00:06:26.879 --> 00:06:30.360 the likelihood of those threats actually happening, their impact, and 129 00:06:30.360 --> 00:06:31.480 what you can do to mitigate them. 130 00:06:31.519 --> 00:06:33.639 Can you give me a simplified example just to see 131 00:06:33.639 --> 00:06:34.120 this in action. 132 00:06:34.279 --> 00:06:37.439 Sure. Let's say one of your assets is accounts. One 133 00:06:37.480 --> 00:06:41.279 potential threat would be account hijacking, where someone gains unauthorized 134 00:06:41.319 --> 00:06:45.279 access to your cloud provider account. Now, thinking about how 135 00:06:45.319 --> 00:06:48.000 advanced cyber attacks are these days, we could say the 136 00:06:48.079 --> 00:06:50.680 likelihood of this happening is probable. 137 00:06:50.240 --> 00:06:53.160 And the impact if we've got strong security measures in 138 00:06:53.160 --> 00:06:56.319 place for our accounts, the impact could be minor. 139 00:06:56.120 --> 00:06:59.279 Right, But without those measures, the impact could be catastrophic. 140 00:07:00.000 --> 00:07:02.279 Imagine losing control of your entire cloud setup. 141 00:07:02.399 --> 00:07:04.399 I definitely don't want to think about that. So how 142 00:07:04.399 --> 00:07:05.600 do we mitigate that risk? 143 00:07:05.920 --> 00:07:09.600 The most effective mitigation would be multi factor authentication MFA. 144 00:07:10.000 --> 00:07:12.480 It adds an extra layer of security, making a lot 145 00:07:12.519 --> 00:07:14.639 harder for attackers to get in, even if they do 146 00:07:14.759 --> 00:07:15.839 manage to get your password. 147 00:07:15.959 --> 00:07:18.040 Right, MFA the security superhero. 148 00:07:18.160 --> 00:07:21.199 You got it? And you do this same process for 149 00:07:21.360 --> 00:07:24.839 each asset and each potential threat, building a complete picture 150 00:07:24.879 --> 00:07:28.519 of your risks. This lets you prioritize your security efforts effectively. 151 00:07:28.680 --> 00:07:31.759 Okay, I like how organized and visual that is. Now. 152 00:07:31.800 --> 00:07:35.040 The book also mentions a risk matrix. What is that 153 00:07:35.160 --> 00:07:37.759 exactly and how is it different from the risk assessment table? 154 00:07:38.199 --> 00:07:41.079 A risk matrix combines how likely a threat is to 155 00:07:41.120 --> 00:07:43.639 occur with its impact, and that gives you an overall 156 00:07:43.720 --> 00:07:47.000 risk level. So something that's unlikely but would be devastating 157 00:07:47.040 --> 00:07:49.279 if it did happen might still need your attention. 158 00:07:49.439 --> 00:07:52.439 So not just looking at the probability, but also the 159 00:07:52.480 --> 00:07:54.879 potential fallout. It's a more holistic approach. 160 00:07:55.079 --> 00:07:58.399 You got it. It's a powerful tool for making informed 161 00:07:58.399 --> 00:08:02.160 security decisions, helping prioritize your efforts based on a combination 162 00:08:02.199 --> 00:08:05.959 of factors. Okay, we've mapped out our application, We've identified 163 00:08:06.000 --> 00:08:09.199 the bad guys, we've assessed the risks. Where do we 164 00:08:09.240 --> 00:08:12.160 go from here on our serverlest security journey? 165 00:08:12.480 --> 00:08:14.600 Now it's time to dive into the code itself and 166 00:08:14.639 --> 00:08:17.360 secure the very heart of your serverless application. 167 00:08:17.560 --> 00:08:19.879 This is where it gets interesting. I know code is 168 00:08:19.920 --> 00:08:23.120 often where vulnerabilities hide. What's the first thing we need 169 00:08:23.160 --> 00:08:25.120 to think about when it comes to securing. 170 00:08:24.680 --> 00:08:28.079 Our code choosing the right run time engine and its version. 171 00:08:28.560 --> 00:08:32.120 That's the environment where your functions run. For instance, with 172 00:08:32.200 --> 00:08:36.159 AWS Lambda you have options like no JS, Python, Java, 173 00:08:36.320 --> 00:08:36.840 and so on. 174 00:08:37.200 --> 00:08:39.879 Wait, so the choice of environment affects security. I hadn't 175 00:08:39.879 --> 00:08:40.440 thought about that. 176 00:08:40.519 --> 00:08:44.440 Oh, it definitely does. Different runtime engines have different security profiles. 177 00:08:44.639 --> 00:08:47.840 Some are more mature with fewer known vulnerabilities, while others 178 00:08:47.879 --> 00:08:50.200 are newer and might still be a bit rough around 179 00:08:50.240 --> 00:08:50.639 the edges. 180 00:08:50.879 --> 00:08:53.759 So how do we pick the right one? From a security. 181 00:08:53.279 --> 00:08:57.080 Perspective, do your research? Websites like cve details keep track 182 00:08:57.120 --> 00:09:00.600 of common vulnerabilities and exposures known as cvees. You can 183 00:09:00.639 --> 00:09:03.559 search for a specific runtime engine and version and see 184 00:09:03.559 --> 00:09:06.639 its track record how many vulnerabilities have been reported, so 185 00:09:06.720 --> 00:09:09.879 it's like a security report card for different runtime engines. 186 00:09:10.399 --> 00:09:12.720 You could say that the book has a great suggestion 187 00:09:13.360 --> 00:09:16.000 use a bar chart to compare the number of cvees 188 00:09:16.159 --> 00:09:19.480 across different versions. This way you can quickly see which 189 00:09:19.559 --> 00:09:21.600 versions have a better security history. 190 00:09:21.879 --> 00:09:24.159 Okay, we've chosen our run time one with a clean 191 00:09:24.200 --> 00:09:26.600 bill of health, or as clean as we can find. 192 00:09:27.200 --> 00:09:29.559 What's next on our code security checklist? 193 00:09:29.879 --> 00:09:33.759 Now we dive into the sometimes complicated world of the 194 00:09:33.799 --> 00:09:36.279 dependency tree A. This is where things can get a 195 00:09:36.320 --> 00:09:36.799 little messed. 196 00:09:36.799 --> 00:09:39.240 Okay, you've got my attention. Tell me more about this 197 00:09:39.279 --> 00:09:41.320 dependency tree and why it's so important. 198 00:09:41.720 --> 00:09:45.200 Serverless apps, just like most software today, rely on external 199 00:09:45.200 --> 00:09:48.240 libraries and packages. These are pre built code modules that 200 00:09:48.320 --> 00:09:52.799 handle specific tasks, but these dependencies often have their own dependencies, 201 00:09:52.919 --> 00:09:54.919 creating a complex web of connections. 202 00:09:55.159 --> 00:09:56.840 Sounds like a tangled web, it can be. 203 00:09:57.360 --> 00:09:59.799 And the problem is vulnerabilities can be hidden deep within 204 00:09:59.799 --> 00:10:03.639 this tree of vulnerability and a seemingly small dependency can 205 00:10:03.679 --> 00:10:05.279 impact your entire application. 206 00:10:05.759 --> 00:10:08.759 Yikes, that's a little scary. So how do we untangle 207 00:10:08.799 --> 00:10:11.559 this mess and find those vulnerabilities before they cause trouble? 208 00:10:11.799 --> 00:10:14.559 Dependency tree tools are your friends. They can help you 209 00:10:14.679 --> 00:10:19.200 visualize and understand the relationships between your applications dependencies. 210 00:10:18.799 --> 00:10:21.360 So we can see the whole ecosystem and its potential 211 00:10:21.399 --> 00:10:23.159 weak points exactly well. 212 00:10:23.200 --> 00:10:25.960 For example, if you're working with NOJS, there's a tool 213 00:10:26.000 --> 00:10:29.080 called an vodka that creates a visual map of your 214 00:10:29.080 --> 00:10:32.360 dependency tree. Once you have that map, you can assess 215 00:10:32.399 --> 00:10:34.279 each package's security individually. 216 00:10:34.600 --> 00:10:37.120 So it's not just about picking a package that does 217 00:10:37.159 --> 00:10:39.759 the job, but also making sure it's secure absolutely. 218 00:10:40.200 --> 00:10:42.879 Look for packages that are well maintained, have a solid 219 00:10:42.879 --> 00:10:46.320 security track record, and ideally are actively supported by a 220 00:10:46.399 --> 00:10:47.159 large community. 221 00:10:47.240 --> 00:10:49.840 So looking for packages that are not just functional, but 222 00:10:49.919 --> 00:10:52.559 also have a good reputation for security. 223 00:10:52.159 --> 00:10:55.679 Right and remember, security is an ongoing effort. You need 224 00:10:55.679 --> 00:10:57.919 to keep your dependencies up to date and watch out 225 00:10:57.919 --> 00:11:00.759 for new vulnerabilities. Things are all always changing. 226 00:11:01.000 --> 00:11:04.080 Got it? Okay, so we've picked a secure run time 227 00:11:04.159 --> 00:11:08.120 engine and we've vetted our dependencies. What else can we 228 00:11:08.159 --> 00:11:09.399 do to secure our code? 229 00:11:09.600 --> 00:11:12.480 Static code analysis is a must. It's where you use 230 00:11:12.559 --> 00:11:15.960 tools to scan your code for potential security flaws without 231 00:11:15.960 --> 00:11:16.799 actually running it. 232 00:11:17.000 --> 00:11:19.799 So like a spell checker for code catching mistakes that 233 00:11:19.840 --> 00:11:20.960 could lead to problems. 234 00:11:21.320 --> 00:11:23.879 That's a good way to think about it. These tools 235 00:11:23.960 --> 00:11:28.440 can find things like buffer overflows, SEQL injection vulnerabilities, cross 236 00:11:28.440 --> 00:11:31.519 site scripting issues, and so on. There are tons of 237 00:11:31.519 --> 00:11:35.039 tools out there, some free, some paid. Pick one that 238 00:11:35.080 --> 00:11:37.679 works for you and make it part of your development process. 239 00:11:38.039 --> 00:11:40.759 Got it? Static code analysis? Check what's next? 240 00:11:41.039 --> 00:11:44.559 Unit tests and regression tests. Don't underestimate their importance. 241 00:11:44.720 --> 00:11:47.919 Testing testing, I know it's important, but why is it 242 00:11:48.000 --> 00:11:49.200 so crucial for security? 243 00:11:49.840 --> 00:11:52.840 Unit tests verify that individual parts of your code work 244 00:11:52.919 --> 00:11:56.679 as expected. But you can also use them to simulate attacks. 245 00:11:57.039 --> 00:11:59.039 Hold on, we can attack our own code? Sounds a 246 00:11:59.080 --> 00:11:59.639 little strange. 247 00:12:00.639 --> 00:12:04.440 You can, and you should. By simulating attacks like SEQL 248 00:12:04.480 --> 00:12:07.039 injection or cross eight scripting, you can see how your 249 00:12:07.039 --> 00:12:09.879 code handles it and make sure it can withstand those attacks. 250 00:12:10.039 --> 00:12:12.919 So finding the weaknesses in our defenses before the attackers do. 251 00:12:13.159 --> 00:12:15.960 Exactly, and regression tests make sure that any changes you 252 00:12:16.000 --> 00:12:19.559 make to your code don't accidentally introduce new security flaws. 253 00:12:19.879 --> 00:12:22.559 Right, making sure that fixing one thing doesn't break something 254 00:12:22.559 --> 00:12:24.399 else and open up a new vulnerability. 255 00:12:24.480 --> 00:12:27.600 You got it. By automating these tests, you're creating a 256 00:12:27.600 --> 00:12:31.360 safety net that catches security issues early in the development process. 257 00:12:31.360 --> 00:12:34.240 Okay, that makes sense. We've analyzed the code, We've tested 258 00:12:34.240 --> 00:12:37.039 it thoroughly. Anything else we need to consider when it 259 00:12:37.039 --> 00:12:38.080 comes to the code itself. 260 00:12:38.360 --> 00:12:41.919 Input validation is a big one. Serveralist functions are often 261 00:12:41.919 --> 00:12:45.200 triggered by different events, like an HTDP request or a 262 00:12:45.200 --> 00:12:48.120 file upload. You need to validate that the data coming 263 00:12:48.159 --> 00:12:49.759 in is what you're expecting. 264 00:12:49.679 --> 00:12:51.519 So don't just trust the data blindly. 265 00:12:51.720 --> 00:12:54.440 Right. Attackers can try to sneak malicious code in through 266 00:12:54.480 --> 00:12:57.240 those inputs. They might try to inject SQL into a 267 00:12:57.279 --> 00:13:00.600 database query or upload a file with a hidden and payload. 268 00:13:00.720 --> 00:13:02.480 Okay, I can see how that could be a problem. 269 00:13:02.600 --> 00:13:04.639 How do we validate these inputs and keep the bad 270 00:13:04.679 --> 00:13:05.200 stuff out? 271 00:13:05.240 --> 00:13:07.240 It depends on where the data is coming from. If 272 00:13:07.240 --> 00:13:10.279 it's an HTTP request, you can validate the body content, 273 00:13:10.720 --> 00:13:13.480 check for required fields, and make sure the data types 274 00:13:13.559 --> 00:13:16.840 match what you expect. For example, if you're expecting a number, 275 00:13:17.279 --> 00:13:19.639 verify that it is a number, not some text that 276 00:13:19.639 --> 00:13:21.039 could contain harmful code. 277 00:13:21.080 --> 00:13:25.080 So being cautious and double checking everything we receive exactly. 278 00:13:25.519 --> 00:13:28.279 And the book has some really clear code examples for 279 00:13:28.320 --> 00:13:32.360 different event sources like HTDP requests and S three that 280 00:13:32.399 --> 00:13:34.639 show how to do input validation the right way. 281 00:13:34.840 --> 00:13:38.080 Okay, input validation check. We've covered a lot choosing the 282 00:13:38.120 --> 00:13:42.480 right run time, assessing dependencies, static code analysis, testing, and 283 00:13:42.639 --> 00:13:45.879 input validation. It feels like we've built a pretty solid 284 00:13:45.919 --> 00:13:47.360 foundation for secure code. 285 00:13:47.360 --> 00:13:50.039 What's next Now, let's zom out from the code itself 286 00:13:50.080 --> 00:13:53.159 and look at the broader serverless environment. We need to 287 00:13:53.200 --> 00:13:56.159 talk about how to restrict permissions across your infrastructure. 288 00:13:56.440 --> 00:13:59.039 Okay, I'm ready to start locking things down. The book 289 00:13:59.080 --> 00:14:03.159 talks about least privilege. What does that mean for serverless? 290 00:14:03.399 --> 00:14:06.519 Least privilege means giving your users and services only the 291 00:14:06.559 --> 00:14:09.879 permissions they absolutely need, like giving someone the key to 292 00:14:09.960 --> 00:14:12.720 a specific room instead of a master key to the 293 00:14:12.840 --> 00:14:13.480 entire building. 294 00:14:13.639 --> 00:14:17.879 So compartmentalizing access, limiting the damage if something goes wrong exactly. 295 00:14:18.000 --> 00:14:21.320 In serverleists, this means carefully setting permissions for your functions, 296 00:14:21.440 --> 00:14:25.399 data stores, and other resources, give each component just enough 297 00:14:25.440 --> 00:14:27.440 access to do its job, nothing more. 298 00:14:27.600 --> 00:14:29.440 Okay, that makes sense in theory, but how do we 299 00:14:29.519 --> 00:14:32.519 actually do this? It seems like it could get pretty complicated. 300 00:14:32.799 --> 00:14:35.360 It can be, but the good news is that cloud 301 00:14:35.399 --> 00:14:40.120 providers like AWS, Azure, and Google Cloud offer very fine 302 00:14:40.159 --> 00:14:44.440 grained permission controls. Let's start with AWS. They use a 303 00:14:44.480 --> 00:14:47.559 system of users, groups, roles, and policies. 304 00:14:47.919 --> 00:14:50.000 Okay, break that down for me. I know about users 305 00:14:50.000 --> 00:14:52.000 in groups, but what are roles in policies. 306 00:14:52.200 --> 00:14:55.240 Users are individual accounts like the ones your developers and 307 00:14:55.240 --> 00:14:59.320 admins use. Groups are collections of users who need similar permissions. 308 00:15:00.120 --> 00:15:03.240 Roles are sets of permissions that you can assign to users, groups, 309 00:15:03.360 --> 00:15:05.279 or even AWS services themselves. 310 00:15:05.360 --> 00:15:08.799 So roles are like templates for permissions, predefined sets that 311 00:15:08.799 --> 00:15:10.879 we can apply to different entities exactly. 312 00:15:11.480 --> 00:15:13.799 And policies are the rules that define what's allowed and 313 00:15:13.799 --> 00:15:17.080 what's not. They're written in JSON, which could be a 314 00:15:17.080 --> 00:15:19.600 bit intimidating at first, but it's actually quite logical once 315 00:15:19.639 --> 00:15:20.320 you get used to it. 316 00:15:20.399 --> 00:15:22.360 Okay, I'm willing to give it a try. So how 317 00:15:22.360 --> 00:15:24.279 do we use all of this to put the principle 318 00:15:24.279 --> 00:15:26.000 of least privilege into practice. 319 00:15:26.240 --> 00:15:28.200 Let's say you have a Lambda function that needs to 320 00:15:28.240 --> 00:15:32.039 read data from a Dynamo dB table. You'd create a 321 00:15:32.120 --> 00:15:34.759 role just for that function, give it read access to 322 00:15:34.799 --> 00:15:38.279 only that specific Dynamo dB table, and deny access to 323 00:15:38.279 --> 00:15:38.919 everything else. 324 00:15:39.000 --> 00:15:43.960 So very specific, limited permissions tailored to that function's exact 325 00:15:44.080 --> 00:15:45.159 needs precisely. 326 00:15:45.840 --> 00:15:47.919 The book has a really clear example of how to 327 00:15:47.960 --> 00:15:51.039 create a policy for this scenario. It even shows you 328 00:15:51.080 --> 00:15:53.639 the JSON code and explains how to apply it to 329 00:15:53.679 --> 00:15:54.480 your Lambda function. 330 00:15:54.639 --> 00:15:57.480 That's helpful. What about Azure is their system similar. 331 00:15:57.639 --> 00:16:01.279 Azure also uses users, groups, and roles, but their permission 332 00:16:01.279 --> 00:16:05.120 documents are called role definitions. These role definitions outline what 333 00:16:05.159 --> 00:16:07.519 a user or group can do with a specific resource. 334 00:16:08.039 --> 00:16:11.919 Okay, so the principles are the same, just slightly different terminology. 335 00:16:11.440 --> 00:16:15.320 Right, And Azure also has managed identities for services. This 336 00:16:15.440 --> 00:16:18.360 means you don't have to directly manage credentials for your services. 337 00:16:18.679 --> 00:16:20.399 Azure takes care of that behind the scenes. 338 00:16:20.559 --> 00:16:22.519 That sounds like it could make things a lot easier. 339 00:16:22.679 --> 00:16:25.480 It Can and Google Cloud well, they have their own 340 00:16:25.519 --> 00:16:30.960 flavor of permission management called cloud iam. It's based on roles, members, policies, 341 00:16:31.000 --> 00:16:31.600 and scopes. 342 00:16:31.840 --> 00:16:34.759 Okay, so each provider has its own way of doing things, 343 00:16:35.080 --> 00:16:38.960 but the core idea of least privilege is the same. 344 00:16:38.879 --> 00:16:42.559 Absolutely and regardless of the platform. It's super important to 345 00:16:42.600 --> 00:16:44.840 review and update your permissions regularly. 346 00:16:45.200 --> 00:16:47.840 Why is that so important? I get setting things up 347 00:16:47.840 --> 00:16:50.759 correctly initially, but why revisit them later? 348 00:16:51.039 --> 00:16:54.759 Because things change, your application grows, you add new features, 349 00:16:55.000 --> 00:16:57.399 team members come and go. You need to make sure 350 00:16:57.440 --> 00:16:59.960 your permissions are always up to date and that nobody 351 00:17:00.159 --> 00:17:01.720 has access they don't need anymore. 352 00:17:01.919 --> 00:17:04.319 So permissions are not a one time thing. They need 353 00:17:04.359 --> 00:17:05.960 ongoing attention exactly. 354 00:17:06.000 --> 00:17:09.240 It's an essential part of keeping your serverlist environment secure. 355 00:17:09.359 --> 00:17:13.480 Got it? Okay, so we've tackled rescripting permissions. What's next 356 00:17:13.559 --> 00:17:15.599 on our server list security checklist? 357 00:17:15.799 --> 00:17:18.640 Let's move on to account management. Your first line of 358 00:17:18.640 --> 00:17:19.759 defense makes sense. 359 00:17:19.880 --> 00:17:22.240 Secure the foundation before building on top of it. 360 00:17:22.400 --> 00:17:26.039 Right, every cloud provider has a master account, which is 361 00:17:26.079 --> 00:17:28.759 like having the keys to the kingdom. If that account 362 00:17:28.839 --> 00:17:31.480 is compromised, an attacker can do a lot of damage. 363 00:17:31.559 --> 00:17:34.160 Okay, that's not good. How do we protect this master 364 00:17:34.200 --> 00:17:36.240 account and make sure those keys don't fall into the 365 00:17:36.279 --> 00:17:37.000 wrong hands. 366 00:17:37.279 --> 00:17:40.680 The book has some really good tips. First, don't use 367 00:17:40.720 --> 00:17:43.839 a personal email address for the master account. Use a 368 00:17:43.880 --> 00:17:46.359 dedicated service or group email address instead. 369 00:17:46.480 --> 00:17:48.799 That way, if someone leaves, we don't lose access. 370 00:17:48.960 --> 00:17:53.400 Right. Next, make sure you provide detailed contact information for 371 00:17:53.440 --> 00:17:56.200 the account. This helps the provider reach you quickly if 372 00:17:56.200 --> 00:17:57.680 there's any suspicious activity. 373 00:17:57.839 --> 00:18:00.279 Okay, be reachable just in case something happened. 374 00:18:00.359 --> 00:18:03.880 Right, And obviously, use a strong password for the master account. 375 00:18:03.920 --> 00:18:07.799 That means long, complex, unique, not use anywhere else. 376 00:18:07.920 --> 00:18:10.279 No password one, two three for the master account. 377 00:18:10.319 --> 00:18:14.039 Definitely not and super important. Enable multi factor authentication. 378 00:18:14.119 --> 00:18:16.200 We've talked about MFA a lot. It's like the gold 379 00:18:16.240 --> 00:18:17.559 standard of security, right. 380 00:18:17.440 --> 00:18:19.559 It's pretty close. Yeah. MFA makes it a lot harder 381 00:18:19.559 --> 00:18:21.759 for attackers to gain access even if they get hold 382 00:18:21.759 --> 00:18:24.039 of your password, because they need that second factor. 383 00:18:24.200 --> 00:18:28.039 Okay, MFA. Check any other best practices for securing the 384 00:18:28.079 --> 00:18:28.839 master account. 385 00:18:28.880 --> 00:18:31.079 Yeah. Make it a habit to review and update your 386 00:18:31.079 --> 00:18:35.200 security settings regularly. Don't get lazy and assume everything is fine. 387 00:18:35.519 --> 00:18:36.559 Stay on top of it. 388 00:18:36.799 --> 00:18:39.119 Proactive security hygiene. 389 00:18:38.559 --> 00:18:41.279 Exactly security is a journey, not a destination. 390 00:18:41.599 --> 00:18:45.680 I'm getting that message loud and clear. So we've locked 391 00:18:45.720 --> 00:18:49.039 down the master account. Anything else to consider when it 392 00:18:49.079 --> 00:18:50.359 comes to account management. 393 00:18:50.960 --> 00:18:54.839 Here's a pro tip. Use separate accounts for different environments 394 00:18:55.240 --> 00:18:57.279 like development, testing, and production. 395 00:18:57.519 --> 00:18:58.720 What's the advantage of doing that? 396 00:18:59.400 --> 00:19:02.839 It limits the damage. If one environment is compromised, it 397 00:19:02.880 --> 00:19:06.480 won't necessarily affect the others, like having firewalls between different 398 00:19:06.519 --> 00:19:07.519 sections of a building. 399 00:19:07.640 --> 00:19:12.519 So it's about isolating and containing any potential breaches exactly. 400 00:19:12.759 --> 00:19:15.359 And it can also help you manage permissions more effectively. 401 00:19:15.440 --> 00:19:18.440