WEBVTT 1 00:00:00.080 --> 00:00:03.720 Welcome to the deep dive. We're jumping straight into a 2 00:00:03.799 --> 00:00:06.519 massive topic today, application security. 3 00:00:06.799 --> 00:00:07.080 Huge. 4 00:00:07.320 --> 00:00:08.919 Yeah, it can feel like trying to drink from a 5 00:00:08.919 --> 00:00:10.960 fire hose, right, I mean it's just a quick look 6 00:00:10.960 --> 00:00:14.800 on Amazon you see something like forty thousand books listed 7 00:00:14.880 --> 00:00:16.239 under computer security. 8 00:00:16.359 --> 00:00:19.760 It's staggering. Yeah, and you know that sheer volume can 9 00:00:19.839 --> 00:00:23.120 leave developers feeling a bit overwhelmed, sort of wondering, Okay, 10 00:00:23.120 --> 00:00:25.719 where do I even start, especially when you just want 11 00:00:25.719 --> 00:00:27.079 to build secure applications? 12 00:00:27.120 --> 00:00:31.120 Exactly what are the absolute must knows? So our mission 13 00:00:31.160 --> 00:00:33.399 today really is to cut through some of that noise. 14 00:00:33.799 --> 00:00:36.640 We're diving deep into the foundational security tech that well 15 00:00:36.640 --> 00:00:39.840 every developer should probably have in their toolkit. We're basing 16 00:00:39.880 --> 00:00:44.039 this on some great material focused on securing cloud applications. Okay, 17 00:00:44.119 --> 00:00:47.240 think of this as maybe your shortcut getting to grips 18 00:00:47.240 --> 00:00:50.119 with what's truly critical, you know, without getting totally lost 19 00:00:50.119 --> 00:00:50.640 in the weeds. 20 00:00:50.719 --> 00:00:53.679 Right. The goal is for you, the listener, to finish 21 00:00:53.679 --> 00:00:58.520 this feeling knowledgeable, feeling confident, not just buried under like 22 00:00:59.000 --> 00:00:59.920 a mountain of jargon. 23 00:01:00.200 --> 00:01:03.399 Yeah, exactly, we want to build a strong foundation. What 24 00:01:03.439 --> 00:01:06.159 are the core challenges, what are the essential tools, the 25 00:01:06.239 --> 00:01:10.040 ideas the basics of secure development, and we're going to. 26 00:01:10.040 --> 00:01:14.760 Kick things off by looking at two really fundamental security problems. 27 00:01:14.760 --> 00:01:17.799 They're key starting points. Making sure our applications talk to 28 00:01:17.840 --> 00:01:23.000 each other, securing those communication channels, and second, making sure 29 00:01:23.040 --> 00:01:26.959 all the other software we rely on our dependencies don't 30 00:01:27.040 --> 00:01:28.760 end up introducing weaknesses. 31 00:01:29.000 --> 00:01:32.959 Got it. Communication and dependencies good starting points, definitely. 32 00:01:33.319 --> 00:01:37.120 So let's begin with maybe how our view of security 33 00:01:37.159 --> 00:01:39.040 responsibility has shifted over time. 34 00:01:39.200 --> 00:01:41.799 Okay, let's unpack that because security, well, it used to 35 00:01:41.879 --> 00:01:43.879 feel like it was purely a software thing, didn't you 36 00:01:44.000 --> 00:01:45.120 worried about bugs in your. 37 00:01:45.040 --> 00:01:49.079 Code pretty much? But things have really really changed. Our 38 00:01:49.079 --> 00:01:52.480 sources point out how even the hardware itself, the silicon, 39 00:01:52.879 --> 00:01:54.239 can have serious flaws. 40 00:01:54.640 --> 00:01:57.120 Ah, you mean like Specter and meltdown exactly. 41 00:01:57.120 --> 00:02:00.400 Those were vulnerabilities right down at the chip level, allowed 42 00:02:01.000 --> 00:02:03.640 one user in a cloud environment to potentially peek into 43 00:02:03.719 --> 00:02:04.920 another user's memory. 44 00:02:05.159 --> 00:02:08.080 Wow, that's not a bug in my application code. That's 45 00:02:08.680 --> 00:02:10.719 that's the foundation it's running on, precisely. 46 00:02:10.919 --> 00:02:12.960 And what those hardware issues really drove home is that 47 00:02:13.039 --> 00:02:17.199 security isn't just an app developer problem anymore. It's it's 48 00:02:17.199 --> 00:02:18.360 a shared responsibility. 49 00:02:18.520 --> 00:02:21.719 Right, it goes across the entire IT world, from the 50 00:02:21.800 --> 00:02:24.560 hardware engineers designing chips all the way up to US 51 00:02:24.639 --> 00:02:26.120 developers writing the app code. 52 00:02:27.039 --> 00:02:29.360 The material we looked at nails. This calls it a 53 00:02:29.400 --> 00:02:32.479 mindset shift. It says, regardless of your role in the 54 00:02:32.479 --> 00:02:36.719 IT world, security is your responsibility. That's a fundamental change. 55 00:02:36.879 --> 00:02:39.039 Yeah, it really is. And this isn't just some abstract 56 00:02:39.080 --> 00:02:42.759 concept either. The financial hit from security failures it's enormous. 57 00:02:42.800 --> 00:02:43.560 Oh, absolutely. 58 00:02:43.599 --> 00:02:46.000 Our sources mentioned the average cost of a data breach 59 00:02:46.039 --> 00:02:48.120 back in twenty twenty was nearly four. 60 00:02:47.960 --> 00:02:50.199 Million dollars four million average. 61 00:02:49.759 --> 00:02:52.919 And then you see these massive cases like Marriott getting 62 00:02:53.000 --> 00:02:55.680 hit with one hundred and twenty six million dollar charge 63 00:02:56.039 --> 00:03:00.280 or ecofax their cleanup cost was reportedly over one point 64 00:03:00.280 --> 00:03:01.800 four billion billion. 65 00:03:02.080 --> 00:03:05.719 Yeah, these numbers really show why it's a CEO level 66 00:03:05.759 --> 00:03:09.639 problem now and why CISOs, the chief information security officers 67 00:03:10.039 --> 00:03:13.039 have well increasingly high expectations for developers. 68 00:03:13.280 --> 00:03:15.159 Makes sense, what kind of expectations. 69 00:03:15.439 --> 00:03:17.680 They're not just looking for code that works anymore. They 70 00:03:17.719 --> 00:03:20.680 expect you to use all the security features in the 71 00:03:20.680 --> 00:03:25.280 products you adopt, follow the company's security standards, and crucially 72 00:03:25.960 --> 00:03:29.159 design and build secure applications right from the start, so. 73 00:03:29.159 --> 00:03:32.039 Thinking about security from day one, not just bolting. 74 00:03:31.639 --> 00:03:33.759 It on at the end exactly. And they also want 75 00:03:33.800 --> 00:03:38.439 developers to be active players in what's called DevSecOps. 76 00:03:38.479 --> 00:03:41.120 Okay, dev scops, we'll circle back to that one, but 77 00:03:41.240 --> 00:03:46.039 first let's tackle one of those initial problems, securing communication channels. 78 00:03:46.199 --> 00:03:46.400 Right. 79 00:03:46.800 --> 00:03:49.960 Think about a typical app structure. Right, You've got your website, 80 00:03:50.080 --> 00:03:54.159 maybe mobile apps for Android iOS. That's the front end, 81 00:03:54.919 --> 00:03:57.520 and then there's a back end, often arrest API over 82 00:03:57.719 --> 00:03:59.240 HTTP doing all the work. 83 00:03:59.280 --> 00:04:01.280 That's pretty calm, very common setup. 84 00:04:01.400 --> 00:04:04.159 Now that communication, it often happens over networks we just 85 00:04:04.280 --> 00:04:07.400 can't trust implicitly, like public Wi Fi at a coffee 86 00:04:07.400 --> 00:04:09.400 shop or just the general. 87 00:04:09.000 --> 00:04:13.280 Internet, absolutely prime territory for attackers. And that's exactly where 88 00:04:13.360 --> 00:04:16.040 transport layer security or TLS comes into play. 89 00:04:16.519 --> 00:04:19.519 TLS the lock icon in the browser. 90 00:04:19.480 --> 00:04:22.959 That's the one. It's the industry standard protocol for encrypting 91 00:04:23.040 --> 00:04:26.399 data while it's moving between systems. Okay, and the material 92 00:04:26.439 --> 00:04:30.519 we have hammers this home as a bus practice, place 93 00:04:30.680 --> 00:04:34.519 zero trust in all networks, including internal secure networks. Use 94 00:04:34.600 --> 00:04:35.839 TLS everywhere. 95 00:04:35.959 --> 00:04:39.360 Zero trust, So even inside your own company. 96 00:04:38.959 --> 00:04:43.000 Network, especially inside. Just because it's labeled internal doesn't make 97 00:04:43.040 --> 00:04:45.879 it safe. Remember that target breach a while back, Vague 98 00:04:46.000 --> 00:04:49.279 attackers got in through credentials for the HVAC system, the 99 00:04:49.279 --> 00:04:52.240 air conditioning. Once inside, they could move around. 100 00:04:52.399 --> 00:04:55.560 Wow. So TLS isn't just for the outside world. It's 101 00:04:55.680 --> 00:04:58.040 defense in depth, even internally. 102 00:04:57.720 --> 00:05:01.920 Exactly, and mastering TLS understanding it is a kim skill 103 00:05:02.000 --> 00:05:05.879 for developers. Our source mentions will dig deeper into it later. Good. 104 00:05:05.959 --> 00:05:09.519 Okay, so that's communication. What about the other big starting 105 00:05:09.560 --> 00:05:11.000 point securing dependencies? 106 00:05:11.199 --> 00:05:14.360 Right, making sure the software components we didn't write but 107 00:05:14.399 --> 00:05:18.240 that our applications rely on are secure. This has become 108 00:05:18.240 --> 00:05:19.480 a huge attack vector. 109 00:05:19.639 --> 00:05:22.120 Yeah, the whole software supply chain thing. It sounds kind 110 00:05:22.120 --> 00:05:26.720 of abstract, but the impact, well, we mentioned Equifax earlier exactly. 111 00:05:26.920 --> 00:05:30.879 That massive breach happened because they didn't patch a known 112 00:05:31.079 --> 00:05:33.079 vulnerability into patchy struts. 113 00:05:32.800 --> 00:05:35.519 Which is like a super common Java framework right. 114 00:05:35.639 --> 00:05:39.720 Very widely used, and that one unpatched library costs them 115 00:05:39.839 --> 00:05:42.759 potentially over one point four billion dollars. 116 00:05:42.800 --> 00:05:43.560 Incredible. 117 00:05:43.839 --> 00:05:46.120 And it's not just about known flaws and old software. 118 00:05:46.279 --> 00:05:49.079 There was that events stream incident too. What was that 119 00:05:49.839 --> 00:05:53.079 a malicious back door was deliberately added to a popular 120 00:05:53.199 --> 00:05:57.240 JavaScript library. It was designed to steal bitcoin from developers 121 00:05:57.279 --> 00:05:59.040 applications using that library. 122 00:05:59.079 --> 00:06:02.279 Whoa, so someone actatively poison the well so to speak. 123 00:06:02.319 --> 00:06:05.399 Correct. It shows even widely trusted open source components can 124 00:06:05.439 --> 00:06:08.920 be compromised. These supply chain attacks work because modern apps 125 00:06:08.959 --> 00:06:10.959 is pull in so many external pieces. 126 00:06:10.680 --> 00:06:12.680 It's kind of mind boggling when you look under the hood. 127 00:06:12.720 --> 00:06:15.560 The source gives an example. Spring boots starter data JPO 128 00:06:15.759 --> 00:06:17.160 sound specific with that. 129 00:06:17.079 --> 00:06:20.560 One dependency pulls in forty five other jar files from 130 00:06:20.680 --> 00:06:22.680 fifteen different open source projects. 131 00:06:22.800 --> 00:06:27.160 Forty five each one needing validation, each a potential entry 132 00:06:27.160 --> 00:06:28.199 point exactly. 133 00:06:28.279 --> 00:06:30.240 Each one needs to be checked kept up to date, 134 00:06:30.439 --> 00:06:32.600 which is why staying on top of patches is just 135 00:06:33.079 --> 00:06:33.920 non negotiable. 136 00:06:34.040 --> 00:06:36.800 So how does that work in practice? A vulnerability gets. 137 00:06:36.560 --> 00:06:41.040 Found right a cve a common vulnerability and exposure gets published. 138 00:06:41.279 --> 00:06:45.639 Then the companies making vulnerability scanning tools update their databases. Okay, 139 00:06:45.800 --> 00:06:49.040 your company's scanner picks it up, maybe alerts the development team. 140 00:06:49.319 --> 00:06:52.680 Ideally you have automated systems that can test and apply 141 00:06:52.800 --> 00:06:53.720 the patch quickly. 142 00:06:54.040 --> 00:06:55.279 How quickly are we talking? 143 00:06:55.560 --> 00:06:59.959 The goal should be honestly, ours, especially for critical vulnerability, 144 00:07:00.079 --> 00:07:02.879 is you want to close that window of opportunity fast, 145 00:07:03.399 --> 00:07:06.839 and importantly, don't just scan fix the issues, prioritize the 146 00:07:06.839 --> 00:07:10.040 ones that are easily exploitable or would have the biggest impact. 147 00:07:10.199 --> 00:07:13.720 Right. Not all vulnerabilities are created equal, definitely not. But 148 00:07:13.920 --> 00:07:16.720 you know, patching quickly only works if your application can 149 00:07:16.759 --> 00:07:19.560 be updated easily. Our source had a cautionary tale about that. 150 00:07:19.800 --> 00:07:22.040 Ah. Yes, the twelve year old Java library. 151 00:07:22.120 --> 00:07:25.079 That's the one A mission critical app got stuck on 152 00:07:25.160 --> 00:07:29.279 this ancient library. Why because the original developers had written 153 00:07:29.279 --> 00:07:32.480 over one hundred thousand lines of code directly against the 154 00:07:32.519 --> 00:07:36.800 library's internal private APIs things not meant for public. 155 00:07:36.600 --> 00:07:40.079 Use, oh, digging into the internals exactly. 156 00:07:40.480 --> 00:07:43.720 So when the library maintainers changed or removed those internals 157 00:07:43.759 --> 00:07:46.040 in later versions, which they have every right to do, 158 00:07:46.839 --> 00:07:50.079 upgrading became this monumental, practically impossible task. 159 00:07:50.439 --> 00:07:53.680 So they were just stuck on an insecure, outdated version. 160 00:07:54.079 --> 00:07:57.879 Precisely, it's a huge lesson. Stick to the public documented 161 00:07:57.920 --> 00:08:01.439 interfaces of libraries. It's not just good coding, it's fundamental 162 00:08:01.480 --> 00:08:02.879 for security maintainability. 163 00:08:03.040 --> 00:08:05.959 Makes perfect sense. Let the library manage its own internals. 164 00:08:06.720 --> 00:08:10.360 And the source offers a clear best practice here, use 165 00:08:10.399 --> 00:08:14.920 a dependency vulnerability scanner, rapidly fix issues, stay up to date, 166 00:08:15.319 --> 00:08:16.399 champion these tools. 167 00:08:16.519 --> 00:08:18.319 It also mentions githubs depended. 168 00:08:18.079 --> 00:08:20.920 On Yeah, as a good often free tool that can 169 00:08:20.959 --> 00:08:23.920 help automate standing and even create pull requests for updates. 170 00:08:24.240 --> 00:08:24.839 Very useful. 171 00:08:24.920 --> 00:08:28.319 Okay, so securecom secure dependencies. Now let's touch on that 172 00:08:28.399 --> 00:08:30.480 term you mentioned earlier, dev secops. 173 00:08:30.680 --> 00:08:33.320 Right, dev secops. It sounds a bit like a buzzword, 174 00:08:33.360 --> 00:08:34.360 maybe a little bit. 175 00:08:34.240 --> 00:08:37.480 Yeah, but there's a really important shift happening underneath it. 176 00:08:38.039 --> 00:08:43.080 Traditionally you had these separate silos, right div build stuff, ops, 177 00:08:43.159 --> 00:08:46.360 run stuff, security, review stuff often late in the game. 178 00:08:46.480 --> 00:08:48.679 Yeah, the security gate at the end that often says 179 00:08:48.759 --> 00:08:50.080 no right when you want to. 180 00:08:50.080 --> 00:08:54.360 Ship exactly, and that whole handoff process. Yeah, it leads 181 00:08:54.360 --> 00:08:58.320 to delays, cost overruns, frustration, and frankly, often less secure 182 00:08:58.360 --> 00:09:01.600 applications because security becomes an afterthought or a bottleneck. 183 00:09:01.840 --> 00:09:04.879 It sounds like a recipe for friction. Devs feel blocked, 184 00:09:04.919 --> 00:09:07.840 ops get stressed. Security feels like the bad guy totally. 185 00:09:07.879 --> 00:09:11.799 So devsekops is basically a movement to break down those walls, 186 00:09:12.519 --> 00:09:15.679 integrate security into the development life cycle from the very 187 00:09:15.720 --> 00:09:18.480 beginning all the way through deployment and operations. 188 00:09:18.519 --> 00:09:21.480 Shifting security left they call it sometimes that's the idea. 189 00:09:21.679 --> 00:09:26.600 It's about collaboration, shared responsibility, automating security checks within the 190 00:09:26.639 --> 00:09:30.720 developer workflow. The goal is faster, more efficient delivery, and 191 00:09:30.759 --> 00:09:32.639 better security, not one or the other. 192 00:09:32.720 --> 00:09:34.480 And companies are actually investing in this. 193 00:09:34.559 --> 00:09:38.440 Heavily, both in tools and in transforming their processes in culture. 194 00:09:38.720 --> 00:09:41.440 Okay. And part of this is developers understanding the rules 195 00:09:41.440 --> 00:09:42.879 of the road, the security standards. 196 00:09:42.879 --> 00:09:45.919 Absolutely. That's where the corporate information security team usually comes in. 197 00:09:46.120 --> 00:09:49.679 They set the standards, the policies. Developers need to understand 198 00:09:49.720 --> 00:09:53.120 why those standards exist and work with security teams, not 199 00:09:53.240 --> 00:09:53.799 against them. 200 00:09:53.919 --> 00:09:55.600 Collaboration not conflict. 201 00:09:55.639 --> 00:09:59.840 That's the ideal. So with that collaborative spirit, what are 202 00:10:00.000 --> 00:10:03.039 some of the core security technologies that dev and offs 203 00:10:03.080 --> 00:10:04.879 teams really need to get comfortable with? 204 00:10:05.039 --> 00:10:07.679 Okay? The essential toolkit? What's number one? 205 00:10:07.799 --> 00:10:10.240 Well, given our chat about networks, it has to be 206 00:10:10.279 --> 00:10:13.720 transport layer security TLS. You just have to encrypt data 207 00:10:13.759 --> 00:10:14.679 in transit. 208 00:10:14.399 --> 00:10:16.279 Non negotiable basically pretty much. 209 00:10:16.440 --> 00:10:20.440 And closely related is the Advanced Encryption Standard AES. 210 00:10:20.320 --> 00:10:23.559 AES for encrypting the data itself exactly. 211 00:10:24.039 --> 00:10:27.279 Our source rightly calls it the most widely deployed algorithm 212 00:10:27.279 --> 00:10:30.759 for encrypting data, whether it's moving or just sitting stored somewhere. 213 00:10:30.840 --> 00:10:33.240 You find it everywhere, including inside TLS. 214 00:10:33.360 --> 00:10:35.960 Got it, TLS for the pipe, AES often for the 215 00:10:35.960 --> 00:10:37.200 stuff inside. What else? 216 00:10:37.360 --> 00:10:40.679 You really can't talk TLS without talking x point five 217 00:10:40.799 --> 00:10:42.559 zero nine digital certificates. 218 00:10:43.159 --> 00:10:46.440 Certificates Those seem complicated, They can. 219 00:10:46.279 --> 00:10:49.120 Be, but think of them as digital ID cards. They're 220 00:10:49.240 --> 00:10:52.559 essential for TLS to work, verifying the identity of servers 221 00:10:52.840 --> 00:10:55.960 sometimes clients too. They pop up in lots of security protocols. 222 00:10:56.039 --> 00:10:57.759 So that's how my browser knows it's really talking to 223 00:10:57.759 --> 00:10:58.639 my bank's website. 224 00:10:58.679 --> 00:11:02.000 That's a big part of it. Yeah, these three TLS 225 00:11:02.039 --> 00:11:05.679 AES x point five zero nine, they're built on deeper 226 00:11:05.679 --> 00:11:09.240 crypto algorithms, but understanding these is crucial for developers. 227 00:11:09.320 --> 00:11:12.720 Okay, foundational tech. Now let's switch to users. How do 228 00:11:12.759 --> 00:11:14.840 they get into our apps? Authentication? 229 00:11:15.679 --> 00:11:19.000 Logging in right and for ages that meant usernames and passwords. 230 00:11:19.399 --> 00:11:22.000 But as our source points out, that model is well, 231 00:11:22.000 --> 00:11:22.759 it's pretty. 232 00:11:22.519 --> 00:11:25.039 Broken, broken how security wise? 233 00:11:25.360 --> 00:11:29.039 User wise, both really security wise. People use weak passwords. 234 00:11:29.039 --> 00:11:32.080 They reuse passwords across sites. Yeah it's a nightmare. Yeah, 235 00:11:32.120 --> 00:11:34.000 I know I shouldn't, but we all do it. And 236 00:11:34.039 --> 00:11:37.159 for users it's just a massive headache remembering dozens of 237 00:11:37.200 --> 00:11:40.879 complex passwords constantly doing resets. It's bad ux. 238 00:11:40.799 --> 00:11:42.960 Okay, so passwords are bad. What's the alternative? 239 00:11:43.240 --> 00:11:46.279 Single sign on or SSO is a major improvement, and 240 00:11:46.360 --> 00:11:49.039 it's about more than just not storing passwords in your app. 241 00:11:49.200 --> 00:11:50.399 How does SSO work? 242 00:11:50.440 --> 00:11:54.960 Basically, it centralizes authentication. Users log in once to a 243 00:11:55.000 --> 00:11:58.679 trusted identity provider and then they can access multiple applications 244 00:11:58.679 --> 00:12:00.159 without logging in again each time time. 245 00:12:00.360 --> 00:12:03.399 Ah, like using your Google account to log into other services. 246 00:12:03.440 --> 00:12:06.720 That's one common example. Yeah, think about the ACME shoe 247 00:12:06.720 --> 00:12:11.000 company example. In our source, they have customers, employees, partners, 248 00:12:11.279 --> 00:12:14.600 all needing access. SSO streamlines that for everyone. 249 00:12:14.639 --> 00:12:17.360 Okay, so let's take Acme's groups. How do they handle 250 00:12:17.399 --> 00:12:19.279 customers buying shoes online? 251 00:12:19.360 --> 00:12:22.519 For customers, the source highlights two main approaches. One is 252 00:12:22.559 --> 00:12:25.360 exactly what you said, letting them use existing third party 253 00:12:25.360 --> 00:12:29.759 accounts via protocols like OOF two or open id connect. 254 00:12:29.559 --> 00:12:34.840 Google, Microsoft, Facebook, Apple, Those buttons you see everywhere exactly. 255 00:12:34.960 --> 00:12:37.919 It's convenient for users, no new password to create, and 256 00:12:37.960 --> 00:12:40.720 it shifts the burden of storing credentials securely to those 257 00:12:40.720 --> 00:12:42.279 big providers who specialize in it. 258 00:12:42.360 --> 00:12:44.759 What's the difference between OF two and open id connect 259 00:12:44.759 --> 00:12:45.919 They often seem used together. 260 00:12:46.559 --> 00:12:51.440 Good question of two is primarily about authorization, granting permission 261 00:12:51.480 --> 00:12:54.600 for one app to access some data in another. Open 262 00:12:54.639 --> 00:12:56.759 id connect builds on top of o F two to 263 00:12:56.799 --> 00:13:00.000 add the authentication layer verifying who the user actually is. 264 00:13:00.399 --> 00:13:04.799 Okay, subtle but important distinction. What's the other customer approach mentioned? 265 00:13:04.840 --> 00:13:10.240 The other really interesting one is passwordless biometric login using webothen. 266 00:13:10.559 --> 00:13:14.200 Passwordless using like fingerprints or face. 267 00:13:14.000 --> 00:13:17.879 ID, precisely your phone or laptop hardware. Weboten is a 268 00:13:17.879 --> 00:13:21.000 web standard that lets websites use those biometrics for login, 269 00:13:21.360 --> 00:13:23.519 completely ditching the password in many cases. 270 00:13:23.600 --> 00:13:24.919 Is that widely supported now? 271 00:13:25.000 --> 00:13:28.120 Yeah, Support is pretty broad across modern browsers and platforms. 272 00:13:28.279 --> 00:13:30.440 You can even try a demo at webothon dot io. 273 00:13:30.559 --> 00:13:31.240 It's quite slick. 274 00:13:31.320 --> 00:13:35.759 A passwordless future sounds nice. Okay, what about acme's employees? 275 00:13:36.320 --> 00:13:37.159 Different needs there? 276 00:13:37.240 --> 00:13:40.960 Definitely for employees, especially in larger companies. Microsoft Active Directory 277 00:13:41.000 --> 00:13:44.039 or AD is super common. It's the system managing their 278 00:13:44.039 --> 00:13:45.360 work logins. 279 00:13:44.960 --> 00:13:47.320 Right for their laptops internal sites exactly. 280 00:13:47.360 --> 00:13:50.240 But employees also need access to external cloud apps sauce 281 00:13:50.279 --> 00:13:54.080 tools right like Salesforce or Slack or whatever. Sure, the 282 00:13:54.120 --> 00:13:57.879 goal with SSO here is for employees to use their 283 00:13:57.919 --> 00:14:01.440 familiar AD username and password to get into those external 284 00:14:01.480 --> 00:14:07.320 apps too, and critically, for ACME to centrally manage access, 285 00:14:07.559 --> 00:14:10.440 disable an account once when someone leaves. 286 00:14:10.679 --> 00:14:13.639 One identity to rule them all from the employee's perspective, 287 00:14:14.200 --> 00:14:16.720 and easier management for ACME. 288 00:14:16.440 --> 00:14:17.159 That's the idea. 289 00:14:17.240 --> 00:14:21.080 What about the third group? Acme's partners, like suppliers. 290 00:14:20.600 --> 00:14:23.519 Partners are interesting. One way is just creating accounts for 291 00:14:23.600 --> 00:14:27.639 partner employees in Acme's own system, like pseudo employees. 292 00:14:27.240 --> 00:14:29.559 But that sounds like a management headache when people leave 293 00:14:29.600 --> 00:14:30.519 the partner company. 294 00:14:30.679 --> 00:14:33.399 It absolutely is. A much better and more secure way 295 00:14:33.559 --> 00:14:37.320 is to delegate, use something called federated identity delegate. How 296 00:14:37.559 --> 00:14:42.279 Acme's ssosystem trusts the partner's ssosystem. When a partner employee 297 00:14:42.279 --> 00:14:45.440 tries to log into an ACME resource, they get redirected 298 00:14:45.440 --> 00:14:47.679 to their own company's login page. To authenticate. 299 00:14:47.879 --> 00:14:51.080 Huh, so the partner manages their own people's access exactly. 300 00:14:51.200 --> 00:14:53.720 If someone leaves the partner, the partner disables their account 301 00:14:53.960 --> 00:14:57.320 and their access to ACME systems is automatically revoked. Too 302 00:14:57.639 --> 00:14:59.039 much cleaner, much more secure. 303 00:14:59.200 --> 00:15:02.080 That makes a lot more sense now. The source also 304 00:15:02.120 --> 00:15:04.759 brought up phishing attacks a huge. 305 00:15:04.440 --> 00:15:08.559 Problem, massive and getting more sophisticated. The example they gave 306 00:15:08.639 --> 00:15:09.720 was chilling the. 307 00:15:09.679 --> 00:15:12.720 One targeting Joe Smith, the DevOps engineer at ACME. 308 00:15:13.240 --> 00:15:16.759 Yeah, he gets an email looks totally legit, supposedly from 309 00:15:16.840 --> 00:15:18.679 Google Cloud warning about an issue. 310 00:15:19.080 --> 00:15:22.000 Urges him to click a link, standard fishing tactic. 311 00:15:21.840 --> 00:15:25.679 Right, but Joe's tired, maybe rushing, clicks the link, gets 312 00:15:25.679 --> 00:15:28.480 a perfect imitation of the Google login page. Oh dear, 313 00:15:29.240 --> 00:15:32.879 enters his username password, even enters the code from his 314 00:15:32.919 --> 00:15:36.039 authenticator app, gives the attackers everything. Wow. 315 00:15:36.120 --> 00:15:40.360 So even multi factor authentication isn't foolproof against a good fish, 316 00:15:40.519 --> 00:15:40.960 not if. 317 00:15:40.840 --> 00:15:43.360 The user is tricked into giving the credentials, including the 318 00:15:43.440 --> 00:15:46.879 MFA code, to the fake site. That's why phishing resistant 319 00:15:46.919 --> 00:15:50.200 authentication is so vital. Like what technologies like web often 320 00:15:50.240 --> 00:15:53.039 which we mentioned, and physical security keys like UBI keys. 321 00:15:53.320 --> 00:15:57.360 These methods cryptographically bind the log into the legitimate site, 322 00:15:57.600 --> 00:16:01.320 making it incredibly hard for phishing sites to intercept useful credentials. 323 00:16:01.360 --> 00:16:05.320 So the takeaway for developers is externalize authentication, use a 324 00:16:05.360 --> 00:16:10.080 dedicated SSO service, rely on modern secure protocols like OOF 325 00:16:10.159 --> 00:16:14.519 to open idconnect, and especially push towards phishing resistant methods 326 00:16:14.559 --> 00:16:17.080 like web Often. Don't try to build all this yourself. 327 00:16:17.200 --> 00:16:20.279 Okay, that's user login covered. What about the secrets? Are 328 00:16:20.320 --> 00:16:24.159 applications need apikeys, database passwords, that kind of thing. Where 329 00:16:24.159 --> 00:16:24.759 should they. 330 00:16:24.600 --> 00:16:29.399 Live application secrets? This is critical. The absolute worst place 331 00:16:29.720 --> 00:16:33.000 is directly in configuration files checked into source control. 332 00:16:33.120 --> 00:16:35.639 Yeah seems obvious, but I bet it still happens. 333 00:16:35.320 --> 00:16:38.919 All the time. The huge risk secrets get exposed. They're 334 00:16:38.919 --> 00:16:42.200 hard to rotate regularly, which you absolutely should do, and 335 00:16:42.240 --> 00:16:44.519 there's no audit trail of who accessed them. 336 00:16:44.559 --> 00:16:45.720 So what's the right way. 337 00:16:46.000 --> 00:16:49.279 Centralized credential storage. Think of it as a secure vault 338 00:16:49.320 --> 00:16:50.879 just for your application secrets, like. 339 00:16:50.799 --> 00:16:52.000 A password manager, but. 340 00:16:51.960 --> 00:16:55.440 For apps kind of Yeah, the source mentions different types. 341 00:16:55.720 --> 00:16:58.799 You've got services from the big cloud providers as your keyvault, 342 00:16:59.080 --> 00:17:04.640 awskey Management Service, CAMS, Google Cloud, KMS, very convenient. If 343 00:17:04.720 --> 00:17:07.640 you're already in that cloud, then there are options tied 344 00:17:07.640 --> 00:17:11.640 to container platforms like credhub for cloud Foundry or Kubernety. 345 00:17:11.680 --> 00:17:14.240 Secrets makes sense if you're using containers. 346 00:17:14.079 --> 00:17:17.119 And finally self hosted options like Hashi corp vault, which 347 00:17:17.160 --> 00:17:18.079 you run yourself. 348 00:17:18.240 --> 00:17:20.759 Lots of choices, but the core idea is the same, 349 00:17:21.160 --> 00:17:24.119 get secrets out of the code and configure precisely. 350 00:17:24.480 --> 00:17:28.839 The best practice is crystal clear. Always store application credentials 351 00:17:28.839 --> 00:17:32.480 in a centralized credential store, use a managed service or 352 00:17:32.480 --> 00:17:34.119 a well maintained open source one. 353 00:17:34.319 --> 00:17:36.680 Is there a standard way for apps to talk to 354 00:17:36.720 --> 00:17:37.720 these different vaults? 355 00:17:38.359 --> 00:17:41.000 Unfortunately, No, that's a bit of a pain point. The 356 00:17:41.000 --> 00:17:44.880 source mentions there isn't one universal protocol. You generally have 357 00:17:44.960 --> 00:17:48.759 to use the specific API or client library for whichever 358 00:17:48.799 --> 00:17:49.599 service you choose. 359 00:17:50.000 --> 00:17:52.759 Okay, something to be aware of. Now, let's shift gears 360 00:17:52.799 --> 00:17:57.799 to something potentially more complex, securing communication between different services 361 00:17:57.839 --> 00:18:00.440 in our own application services. 362 00:18:00.440 --> 00:18:03.359 Basically, yeah, this gets intricate fast, especially as apps become 363 00:18:03.359 --> 00:18:06.279 more distributed. The Amazon product page example, and the source 364 00:18:06.319 --> 00:18:09.759 is perfect. You load one page, but behind the scenes, 365 00:18:09.799 --> 00:18:12.960 that single request might trigger calls to dozens of other 366 00:18:13.000 --> 00:18:16.480 internal micro services, one for price, one for inventory, one 367 00:18:16.519 --> 00:18:18.799 for reviews, one for recommendations. 368 00:18:18.160 --> 00:18:21.480 Well, whole cascade of internal calls exactly, and this fan 369 00:18:21.559 --> 00:18:23.799 out introduces new security headaches. 370 00:18:24.240 --> 00:18:27.599 The Source highlights to big ones, which are, first, how 371 00:18:27.599 --> 00:18:30.920 do you propagate the original user's identity securely through that 372 00:18:31.000 --> 00:18:34.960 whole chain of service calls? The inventory service might need 373 00:18:35.000 --> 00:18:37.519 to know who was asking, not just that the request 374 00:18:37.559 --> 00:18:39.160 came from the product page service. 375 00:18:39.000 --> 00:18:42.200 Right for auditing or maybe fine grain permissions. 376 00:18:41.720 --> 00:18:45.720 Exactly, But doing that consistently across service is written in 377 00:18:45.920 --> 00:18:51.200 potentially different languages, using different communication protocols HGTPGRPC message queues 378 00:18:51.240 --> 00:18:52.240 is really challenging. 379 00:18:52.440 --> 00:18:53.519 Is there a standard way? 380 00:18:54.039 --> 00:18:56.480 Not really a single simple standard. You typically have to 381 00:18:56.480 --> 00:19:00.319 piece together a solution using various patterns and technologies. Open 382 00:19:00.319 --> 00:19:04.559 any connect tokens, maybe mutual TLS, JWTs, jason web tokens. 383 00:19:04.799 --> 00:19:09.079 Perhaps the service mesh helps. It's complex requires understanding lots 384 00:19:09.079 --> 00:19:09.480 of pieces. 385 00:19:09.519 --> 00:19:13.359 Okay, that's user identity propagation. What's the second big problem? 386 00:19:13.480 --> 00:19:18.440 Service identity? How does one microservice securely identify which other 387 00:19:18.480 --> 00:19:21.480 service is calling it? Why does that matter for authorization 388 00:19:21.599 --> 00:19:24.880 between services? Maybe the product detail service can be called 389 00:19:24.880 --> 00:19:28.480 by almost any other service, but the update price service 390 00:19:28.559 --> 00:19:32.720 should only accept calls from, say, the pricing management service. 391 00:19:33.000 --> 00:19:35.119 You need to authenticate the calling service itself. 392 00:19:35.319 --> 00:19:39.319 Ah inter service authorization. Got it? How does services prove 393 00:19:39.359 --> 00:19:40.519 their identity to each other? 394 00:19:40.799 --> 00:19:44.119 Two common ways mentioned are API keys, where the calling 395 00:19:44.160 --> 00:19:45.599 service includes a secret token. 396 00:19:46.039 --> 00:19:48.640 Simple, but you have to manage those keys securely right. 397 00:19:48.960 --> 00:19:52.400 The other is mutual TLS or MTLs. This is stronger. 398 00:19:52.799 --> 00:19:55.720 Both the calling service and the called service use digital 399 00:19:55.720 --> 00:19:58.920 certificates to authenticate each other before any data is. 400 00:19:58.880 --> 00:20:02.720 Even exchanged, but for both sides of the connection essentially yes, 401 00:20:03.000 --> 00:20:06.759