WEBVTT 1 00:00:00.160 --> 00:00:03.680 Welcome to the deep dive. Today, we're tackling zero trust. 2 00:00:04.280 --> 00:00:06.719 You've probably heard the term, maybe seen it as a 3 00:00:06.719 --> 00:00:11.759 bit of a cybersecurity buzzword, but honestly, it's actually changing everything. 4 00:00:11.800 --> 00:00:16.039 It's gaining immense traction. But you know, it can often 5 00:00:16.079 --> 00:00:19.039 feel like this riddle wrapped in complex terms. So our 6 00:00:19.079 --> 00:00:21.079 goal for this deep diet is to really pull back 7 00:00:21.120 --> 00:00:24.079 the curtain. We want to unpack where this idea came from, 8 00:00:24.399 --> 00:00:27.480 what really makes it tick, and how it's well fundamentally 9 00:00:27.519 --> 00:00:31.640 shaking up digital security in our crazy evolving world. We've 10 00:00:31.640 --> 00:00:35.719 pulled from some truly comprehensive and frankly expert driven sources 11 00:00:35.960 --> 00:00:37.520 to get right to the heart of what you need 12 00:00:37.560 --> 00:00:39.759 to know. All right, so let's start by digging into 13 00:00:39.799 --> 00:00:43.280 this What exactly is zero trust and maybe how did 14 00:00:43.280 --> 00:00:45.640 this pretty radical idea even come about? 15 00:00:45.719 --> 00:00:48.119 Okay, yeah, good place to start. So at its core, 16 00:00:48.359 --> 00:00:52.200 zero trust is a cybersecurity framework, and it completely flips 17 00:00:52.200 --> 00:00:55.920 the script on traditional network security. For decades, we operated 18 00:00:55.920 --> 00:00:58.159 on a model that was basically trustpit. 19 00:00:57.840 --> 00:01:01.000 Verify right the old way. Once you're inside the castle walls, 20 00:01:01.000 --> 00:01:01.399 you're good. 21 00:01:01.799 --> 00:01:04.959 Exactly, once you were inside that network perimeter, you were 22 00:01:05.239 --> 00:01:09.120 well largely trusted. Zero trust is nope, never trust always 23 00:01:09.200 --> 00:01:10.560 verifying never trust never. 24 00:01:10.680 --> 00:01:10.760 No. 25 00:01:10.959 --> 00:01:14.120 Entity doesn't matter if it's a user, a device, an application, 26 00:01:14.640 --> 00:01:16.760 It doesn't matter if it's inside or outside your network. 27 00:01:17.319 --> 00:01:21.760 Nothing is trusted by default. So every single access request 28 00:01:21.799 --> 00:01:27.599 has to be rigorously authenticated, authorized, and crucially continuously validated. 29 00:01:27.719 --> 00:01:32.280 Continuously yes, based on context, things like who is the user, 30 00:01:32.439 --> 00:01:35.359 what's the health of their device, where are they connecting from, 31 00:01:35.840 --> 00:01:39.439 even their typical behavior patterns. The core tenets they sound simple, 32 00:01:39.439 --> 00:01:44.439 but they're profound. Verify identity, grant only the least privilege necessary, 33 00:01:44.480 --> 00:01:46.319 and continuously monitor everything. 34 00:01:46.719 --> 00:01:49.840 That's a huge shift from that old castle and mode idea. 35 00:01:49.959 --> 00:01:52.359 This sounds like a complete overhaul really of how we've 36 00:01:52.400 --> 00:01:55.519 thought about security for decades. So why now, Why is 37 00:01:55.560 --> 00:01:58.560 this shift so critical right now? What's driving this urgency? 38 00:01:58.719 --> 00:02:01.959 Yeah, it's critical because that additional parameter based security model 39 00:02:02.480 --> 00:02:05.640 it's just not adequate anymore, not for today's digital landscape. 40 00:02:05.640 --> 00:02:07.480 I mean, think about it, our tax services. It just 41 00:02:07.519 --> 00:02:09.680 exploded everywhere, right everywhere. 42 00:02:09.719 --> 00:02:12.520 We're talking about the massive shift to cloud computing, a 43 00:02:12.599 --> 00:02:16.879 truly mobile workforce. Now, the proliferation of Internet of Things 44 00:02:16.960 --> 00:02:23.199 or IoT devices and even integrating artificial intelligence AI into 45 00:02:23.240 --> 00:02:27.759 our systems. All of these just dramatically increase the potential 46 00:02:27.879 --> 00:02:30.960 entry points for cyber criminals. Okay, and the attackers themselves, 47 00:02:31.120 --> 00:02:34.639 they're evolving rapidly too. They're leveraging really advanced techniques, things 48 00:02:34.680 --> 00:02:39.599 like AI powered malware, highly targeted ransomware, and increasingly elaborate 49 00:02:39.639 --> 00:02:43.319 social engineering and deep fix scams. 50 00:02:43.599 --> 00:02:44.439 Oh, the deep fis. 51 00:02:44.560 --> 00:02:47.000 Yeah, we saw that shocking example with the British design 52 00:02:47.080 --> 00:02:49.360 firm or Up, didn't we. They unfortunately lost what twenty. 53 00:02:49.199 --> 00:02:51.159 Five million dollars twenty five million, yeah, all. 54 00:02:51.120 --> 00:02:53.599 Due to a deep fake imposter pretending to be their CFO. 55 00:02:53.759 --> 00:02:55.039 Just incredible. 56 00:02:55.240 --> 00:02:55.639 Wow. 57 00:02:55.680 --> 00:02:57.879 And on top of all that, you've got these emerging 58 00:02:57.960 --> 00:03:02.520 risks like quantum computing, which you know, could potentially render 59 00:03:02.560 --> 00:03:04.879 our current cryptographic standards ineffective down the road. 60 00:03:05.120 --> 00:03:08.080 That's a scary thought, it is. And then they're insider risks. 61 00:03:08.360 --> 00:03:11.800 Traditional measures often overlook those, whether they're malicious or even 62 00:03:11.840 --> 00:03:16.039 just accidental. Plus, modern IT environments are just incredibly complex now, 63 00:03:16.479 --> 00:03:20.759 highly interconnected, multiple vendors, third party services. It all demands 64 00:03:20.800 --> 00:03:24.159 a much more granular, much more dynamic approach to security. 65 00:03:24.280 --> 00:03:27.240 Makes sense, and it's interesting. This concept actually originated from 66 00:03:27.280 --> 00:03:30.360 John kindervag Hees it forced to research back in twenty ten, 67 00:03:30.840 --> 00:03:33.000 and you can see its importance growing right with the 68 00:03:33.039 --> 00:03:37.120 development of industry standards like NISK Special Publication eight hundred 69 00:03:37.199 --> 00:03:40.360 two oh seven and the CSAs Zero Trust Maturity Model. 70 00:03:40.879 --> 00:03:42.680 These give clear guidance. 71 00:03:42.599 --> 00:03:45.439 That air up example is just staggering. It really highlights 72 00:03:45.479 --> 00:03:48.840 these aren't just like theoretical threats anymore. But it sounds 73 00:03:48.879 --> 00:03:51.680 like technology is maybe just one piece of this puzzle. 74 00:03:51.719 --> 00:03:55.039 Though we often hear that phrase people, processes, and technology 75 00:03:55.479 --> 00:03:58.879 as core pillars and security. What does that really mean 76 00:03:58.960 --> 00:04:01.919 for zero trust, especially when, let's face it, the human 77 00:04:01.960 --> 00:04:04.240 element often feels like the weakest link. 78 00:04:04.520 --> 00:04:07.280 You've absolutely hit on a crucial point. There a successful 79 00:04:07.400 --> 00:04:11.199 zero trust implementation. It isn't just about throwing new tech 80 00:04:11.240 --> 00:04:17.160 at the problem. It fundamentally aligns those three elements, people, processes, 81 00:04:17.680 --> 00:04:21.399 and technology. Let's start with people, because you're right, social 82 00:04:21.439 --> 00:04:25.160 engineering is still a primary attack factor. Why because malicious 83 00:04:25.160 --> 00:04:29.879 messages can look almost indistinguishable from legitimate communications scary stuff. 84 00:04:29.920 --> 00:04:33.600 It is so zero trust demands clear roles and responsibilities. 85 00:04:33.720 --> 00:04:36.279 This ensures the right security rules get applied to the 86 00:04:36.360 --> 00:04:39.480 right people. It forces you to ask those questions like, 87 00:04:40.120 --> 00:04:43.560 should someone who works at reception really have access to, say, 88 00:04:43.879 --> 00:04:48.040 the public financial forecasting information. Probably not exactly. The answer 89 00:04:48.040 --> 00:04:51.199 is usually know and zero trust helps enforce that. It's 90 00:04:51.240 --> 00:04:54.079 about empowering people with the right level of access and 91 00:04:54.160 --> 00:04:58.279 absolutely no more to minimize those accidental or malicious missteps. 92 00:04:58.319 --> 00:04:59.920 Okay, that's people. What about processes? 93 00:05:00.439 --> 00:05:05.839 Right processes. You absolutely need redust incident response and recovery processes. 94 00:05:06.040 --> 00:05:08.399 And this isn't just about reacting after the fact. It's 95 00:05:08.399 --> 00:05:12.720 about rapid identification and detection of security incidents, followed by 96 00:05:12.720 --> 00:05:16.920 swift containment and system remediation get things back online safely. 97 00:05:17.319 --> 00:05:21.560 Organizations must have well defined action plans disaster recovery strategies, 98 00:05:21.720 --> 00:05:25.480 especially in these complex multi cloud environments, because even with 99 00:05:25.519 --> 00:05:28.839 the best laid plans, unexpected things can still happen. Always, 100 00:05:29.040 --> 00:05:32.000 So if a breach occurs, how quickly can you isolate it? 101 00:05:32.319 --> 00:05:34.759 How fast can you restore affected systems without letting the 102 00:05:34.800 --> 00:05:39.040 threat spread further. These processes ensure resilience even when you 103 00:05:39.079 --> 00:05:40.279 assume a breach will happen. 104 00:05:40.399 --> 00:05:41.120 Assume breach. 105 00:05:41.240 --> 00:05:44.680 That's key, it is And finally, that brings us to technology. 106 00:05:45.160 --> 00:05:48.720 This really forms the core of the practical implementation, giving 107 00:05:48.800 --> 00:05:51.839 us the tools to enforce these principles, these people and 108 00:05:51.879 --> 00:05:53.040 process decisions. 109 00:05:53.079 --> 00:05:55.560 That's a perfect setup. Okay, Now let's really dive into 110 00:05:55.600 --> 00:05:58.759 that technological backbone. What are the core components, what actually 111 00:05:58.759 --> 00:06:01.360 brings zero trust to life and enforces those decisions we 112 00:06:01.439 --> 00:06:02.079 just talked about. 113 00:06:02.319 --> 00:06:05.759 Right, the tech foundation, it's robust and it's all interconnected. 114 00:06:06.560 --> 00:06:10.560 First up, you have Identity and Access Management or IAM. Now, 115 00:06:10.600 --> 00:06:12.800 this isn't just about verifying who you are once when 116 00:06:12.800 --> 00:06:15.759 you log in. It's the whole framework of policies and 117 00:06:15.800 --> 00:06:18.879 technologies ensuring appropriate continuous. 118 00:06:18.360 --> 00:06:20.759 Access continuous again, yes, and. 119 00:06:20.720 --> 00:06:25.480 It involves several key things. First, multi factor authentication MFA 120 00:06:25.680 --> 00:06:31.319 and continuous MFA CMFA. You're likely familiar with MFA proving 121 00:06:31.360 --> 00:06:34.120 your identity to say, a password and a code. 122 00:06:33.839 --> 00:06:35.759 From your phone, right, yep, use it all the time. 123 00:06:35.839 --> 00:06:40.800 Continuous MFA takes that concept further. It continuously reverifies identity 124 00:06:40.839 --> 00:06:44.240 throughout a session, adapting if your behavior or context changes. 125 00:06:44.720 --> 00:06:48.560 Then there's role based access control our BAC. This ensures 126 00:06:48.639 --> 00:06:51.199 users only get the minimum resources they need based on 127 00:06:51.240 --> 00:06:55.120 their specific job role least privilege precisely so a marketing 128 00:06:55.199 --> 00:06:57.519 team member, for example, should absolutely not have access to 129 00:06:57.560 --> 00:07:00.839 financial systems. Our BAC enforces that, and tied into that 130 00:07:01.000 --> 00:07:04.160 is just in time GIIT and just enough access. This 131 00:07:04.199 --> 00:07:07.360 is a really crucial zero trust principle. Access is granted 132 00:07:07.399 --> 00:07:10.920 only when it's specifically needed and only for the exact duration. 133 00:07:10.680 --> 00:07:13.920 Required, like for a specific task, exactly. 134 00:07:13.759 --> 00:07:17.079 Like during a defined maintenance window. For apps. A practical 135 00:07:17.120 --> 00:07:20.160 example might be, should users be able to print documents 136 00:07:20.160 --> 00:07:23.600 to an office printer outside of normal business hours when 137 00:07:23.600 --> 00:07:27.360 the building isn't even open. Probably not GIT access would 138 00:07:27.399 --> 00:07:31.639 likely say no. It limits the window of opportunity for misuse. 139 00:07:32.279 --> 00:07:35.160 Okay, so it's not just authenticating who you are, but 140 00:07:35.360 --> 00:07:39.040 very specifically what you're allowed to touch and when at 141 00:07:39.079 --> 00:07:41.120 any given moment. That's a powerful distinction. 142 00:07:41.279 --> 00:07:44.920 Exactly and intrinsically linked to that is segmentation. This is 143 00:07:44.959 --> 00:07:48.160 all about isolating security threats to prevent them from spreading. 144 00:07:48.680 --> 00:07:52.399 Think of it like creating watertight compartments on a ship. 145 00:07:52.959 --> 00:07:55.879 If one area of floods, it doesn't sink the whole vessel. 146 00:07:55.920 --> 00:07:59.360 Good analogy. We have two main types macro segmentation. This 147 00:07:59.480 --> 00:08:03.800 is broader network separation typically done with traditional firewalls or 148 00:08:03.839 --> 00:08:08.040 maybe virtual routing and forwarding VRF, which essentially creates separate 149 00:08:08.120 --> 00:08:11.600 virtual networks on the same physical infrastructure. But then there's 150 00:08:11.639 --> 00:08:15.439 micro segmentation. This is where zero trust gets really granular. 151 00:08:15.600 --> 00:08:18.639 It provides control within those macro segments. It allows you 152 00:08:18.720 --> 00:08:23.240 to separate individual devices, applications, even identities, without needing everything 153 00:08:23.279 --> 00:08:25.319 to funnel back through a central firewall. 154 00:08:25.680 --> 00:08:26.480 How does that work? 155 00:08:26.519 --> 00:08:30.319 Technically, it's often achieved through identity to tag mapping, things 156 00:08:30.399 --> 00:08:35.440 like security group tags sgts or endpoint groups EPGs. These 157 00:08:35.519 --> 00:08:39.679 tags act almost like well, an individual's driver's license or passport. 158 00:08:39.919 --> 00:08:42.240 They travel with the user or device and define what 159 00:08:42.279 --> 00:08:44.919 they can access anywhere on the network based on policy. 160 00:08:45.039 --> 00:08:47.120 Very cool, think a digital passport. 161 00:08:46.720 --> 00:08:49.799 Kind of Yeah, then we have endpoint security. This focus 162 00:08:49.840 --> 00:08:52.799 is on securing all those client devices, your laptops, phones, 163 00:08:52.879 --> 00:08:54.480 IoT gadgets. 164 00:08:54.000 --> 00:08:56.639 The things people actually use exactly, which. 165 00:08:56.519 --> 00:09:01.039 Are essentially everywhere and constantly on the move, all them supplicants, 166 00:09:01.879 --> 00:09:04.559 and because they're always moving and connecting from different places, 167 00:09:04.679 --> 00:09:07.159 they're like pervasive moving targets for attackers. 168 00:09:07.360 --> 00:09:07.879 Makes sense. 169 00:09:08.360 --> 00:09:12.200 So this involves things like endpoint detection and response EDER systems. 170 00:09:12.480 --> 00:09:15.879 These constantly monitored devices for threats, not just waiting for 171 00:09:15.919 --> 00:09:19.240 something to hit the network edge, Network access control and 172 00:09:19.320 --> 00:09:22.759 AC which verifies devices and users before they even get 173 00:09:22.799 --> 00:09:27.039 onto the network, and Mobile Device Management MDM for securing 174 00:09:27.080 --> 00:09:30.200 and managing mobile devices specifically. All these work together to 175 00:09:30.279 --> 00:09:33.919 validate device health and make sure it adheres to security policy. 176 00:09:34.200 --> 00:09:37.840 Okay, so we've got identity segmentation endpoints. 177 00:09:37.639 --> 00:09:41.519 What else network visibility and analytics. These are absolutely crucial. 178 00:09:41.600 --> 00:09:44.120 You need to understand what a normal and healthy baseline 179 00:09:44.120 --> 00:09:47.159 looks like in your network. Tools like security information and 180 00:09:47.200 --> 00:09:52.080 Event Management or SEAM systems aggregate and assess security information 181 00:09:52.120 --> 00:09:56.000 from all over. They identify anomalies or potentially malicious behavior 182 00:09:56.360 --> 00:09:59.000 by comparing the current state to those benchmarked good. 183 00:09:58.840 --> 00:10:01.559 States, like spot unusual activity. 184 00:10:01.399 --> 00:10:05.440 Exactly, for instance, detecting a sudden unusual increase in data 185 00:10:05.440 --> 00:10:09.120 transfers from a particular users machine that deviates from their 186 00:10:09.120 --> 00:10:13.399 normal pattern that would raise a flag, and finally, policy enforcement. 187 00:10:14.080 --> 00:10:16.879 This isn't static, It's about the dynamic nature of these 188 00:10:16.919 --> 00:10:21.440 security policies. They need to adapt constantly to evolving security 189 00:10:21.440 --> 00:10:26.159 standards based on real time factors like user roles, endpoint 190 00:10:26.159 --> 00:10:27.960 types and even usage patterns. 191 00:10:28.120 --> 00:10:32.679 Wow. Okay, so if we connect all these pieces identity, segmentation, endpoints, visibility, 192 00:10:32.759 --> 00:10:35.840 dynamic policies, back to the bigger picture, it really sounds 193 00:10:35.840 --> 00:10:39.360 like managing all these intricate security layers dynamically and especially 194 00:10:39.360 --> 00:10:43.279 at scale, is where automation and orchestration become absolutely critical. 195 00:10:43.360 --> 00:10:44.720 You can't do this manually, can you? 196 00:10:44.879 --> 00:10:47.200 Absolutely not? You're spot on. If you had to manually 197 00:10:47.240 --> 00:10:51.279 configure every policy for every user, every device across all 198 00:10:51.320 --> 00:10:55.320 these systems, it would just become unmanageable instantly. 199 00:10:55.480 --> 00:10:58.480 So what does this actually mean for daily operations? Then 200 00:10:58.480 --> 00:11:00.840 we're talking about something much more so sophisticated than just 201 00:11:00.919 --> 00:11:02.120 simple scripting, right. 202 00:11:02.279 --> 00:11:06.360 Oh, much more exactly. We're talking about network automation and orchestration. 203 00:11:07.159 --> 00:11:11.120 This basically involves using specialized software and tools to manage, configure, 204 00:11:11.240 --> 00:11:16.480 monitor and optimized network operations, ideally with minimal human invention. 205 00:11:16.799 --> 00:11:19.879 Right. Let the machines handle the complexity. 206 00:11:19.360 --> 00:11:23.480 Precisely, and the benefits are huge faster deployments of services 207 00:11:23.480 --> 00:11:27.840 and policies, dramatically improved security consistency across the board, and 208 00:11:27.919 --> 00:11:30.960 a significant reduction in human error, which is often a 209 00:11:31.000 --> 00:11:35.480 major vulnerability. A major evolution here is something called net DevOps. 210 00:11:35.840 --> 00:11:37.840 Net DevOps like DevOps. 211 00:11:37.320 --> 00:11:41.120 But for networking exactly that it applies those rapid iterative 212 00:11:41.120 --> 00:11:45.440 principles of DevOps collaboration, automation, integration directly to networking. A 213 00:11:45.519 --> 00:11:48.679 key part of this is treating network configuration as code. 214 00:11:48.840 --> 00:11:50.960 This is often called infrastructure's code or. 215 00:11:50.919 --> 00:11:53.440 IAC infrastructure's code okay. 216 00:11:53.320 --> 00:11:56.799 And crucially, net DevOps integrate security much earlier in the 217 00:11:56.840 --> 00:11:58.960 development and deployment cycle as an. 218 00:11:58.919 --> 00:12:01.879 Afterthought, shifting security left, as they say, that's the. 219 00:12:01.879 --> 00:12:05.919 Term, yes, shifting left. The benefits are pretty clear. It 220 00:12:06.000 --> 00:12:10.080 enables smaller, more frequent changes, which are less risky than massive, 221 00:12:10.360 --> 00:12:15.120 infrequent updates. It offers reliable updates with automated rollback capabilities 222 00:12:15.159 --> 00:12:18.600 if something goes wrong. It helps avoid network disruption through 223 00:12:18.679 --> 00:12:23.080 rigorous validation testing at multiple phases of the process. And critically, 224 00:12:23.320 --> 00:12:27.840 it integrates security practices directly into the continuous integration, continuous 225 00:12:27.960 --> 00:12:32.080 delivery continuous testing pipeline the CICDCT pipeline. 226 00:12:31.600 --> 00:12:33.519 So catching problems early exactly. 227 00:12:33.840 --> 00:12:37.559 This means you can detect vulnerabilities, configuration errors, or compliance 228 00:12:37.600 --> 00:12:41.039 issues early in the pre production stage, rather than finding 229 00:12:41.039 --> 00:12:43.799 them after a breach or when something breaks in production. 230 00:12:44.480 --> 00:12:48.000 With infrastructure as code, you're literally defining your enterprise security 231 00:12:48.039 --> 00:12:51.600 policies as these automated playbooks, maybe using tools like ansable 232 00:12:51.759 --> 00:12:55.519 or Terraform, and the CICDCT pipeline ensures automated checks along 233 00:12:55.519 --> 00:12:58.919 the way for syntax errors, compliance adherence, security best practices, 234 00:12:58.960 --> 00:12:59.399 and so on. 235 00:12:59.559 --> 00:13:03.519 That sounds incredibly powerful for maintaining consistency and security posture. 236 00:13:03.720 --> 00:13:06.679 It is, and one more critical point here, it's vital 237 00:13:06.720 --> 00:13:10.720 to apply these same zero trust principles to API security. 238 00:13:10.799 --> 00:13:13.120 APIs, right, application programming interfaces. 239 00:13:13.120 --> 00:13:16.519 They're everywhere now, absolutely everywhere. They're how different software systems 240 00:13:16.559 --> 00:13:20.679 talk to each other, and unsecured APIs pose really significant risks. 241 00:13:21.279 --> 00:13:23.799 Gartner identified them way back in twenty nineteen as a 242 00:13:23.879 --> 00:13:28.360 critical new attack factor. So every single API call also 243 00:13:28.399 --> 00:13:33.799 needs to be treated with that never trust, always verify, mindset, authentication, authorization, 244 00:13:34.039 --> 00:13:35.360 monitoring the whole package. 245 00:13:35.559 --> 00:13:38.600 That's fascinating how security is being woven into the very 246 00:13:38.639 --> 00:13:42.320 fabric of network operations through automation and code. Now, zero 247 00:13:42.360 --> 00:13:45.320 trust clearly isn't just for traditional on premises networks anymore, 248 00:13:45.360 --> 00:13:47.679 is it. How does it extend to the really dynamic 249 00:13:47.720 --> 00:13:51.679 world of cloud computing. And also what about those emerging 250 00:13:51.720 --> 00:13:54.200 maybe more futuristic threats like quantum computing. 251 00:13:54.440 --> 00:13:58.679 You're absolutely right. Zero trust is incredibly relevant, maybe even 252 00:13:58.759 --> 00:14:04.080 more relevant in modern cloud native environments. These architectures, with 253 00:14:04.120 --> 00:14:08.320 their micro services, containerization, and ephemeral workloads meaning things that 254 00:14:08.360 --> 00:14:11.919 spin up and down quickly, they present unique security challenges. 255 00:14:12.080 --> 00:14:14.240 Right, it's not a static environment, not at all. 256 00:14:14.919 --> 00:14:17.360 First, you have the shared responsibility model in the cloud. 257 00:14:17.879 --> 00:14:20.799 This means security dutis are divided between the cloud provider 258 00:14:21.320 --> 00:14:26.240 like Aws, Azure, Google Cloud and the customer. The provider 259 00:14:26.279 --> 00:14:29.799 secures the underlying infrastructure, but the customer must implement strong 260 00:14:29.879 --> 00:14:34.519 security for their own applications, data and configurations. Zero trust 261 00:14:34.600 --> 00:14:36.159 is key for the customer's part. 262 00:14:36.200 --> 00:14:37.960 So you can't just rely on the cloud provider. 263 00:14:38.200 --> 00:14:41.879 Definitely not. And the way services communicate changes too. We 264 00:14:41.960 --> 00:14:46.159 shift from relying solely on traditional centralized firewalls at the 265 00:14:46.279 --> 00:14:51.519 edge to needing more dynamic, fine grained security policies between 266 00:14:51.519 --> 00:14:56.360 individual microservices. This often involves unique encryption and authentication for 267 00:14:56.559 --> 00:15:00.679 every single service to service communication path. So like service 268 00:15:00.720 --> 00:15:03.759 mesh technologies, SDO is a popular example, can offer an 269 00:15:03.759 --> 00:15:07.000 additional layer of security specifically for these interactions okay. 270 00:15:07.120 --> 00:15:09.840 Securing the communication between services. 271 00:15:09.320 --> 00:15:12.399 Exactly and managing the keys for all that encryption is vital. 272 00:15:12.799 --> 00:15:15.960 That's where key management systems CAMS come in. They're crucial 273 00:15:16.000 --> 00:15:19.080 for managing cryptographic keys, often with features like automated key 274 00:15:19.159 --> 00:15:23.039 rotation to reduce risk and simplified interfaces. Hechey Corp Vault, 275 00:15:23.120 --> 00:15:25.519 for instance, is known for its ability to generate dynamic 276 00:15:25.720 --> 00:15:29.279 short lived secrets, which fits the zero trust model perfectly 277 00:15:29.399 --> 00:15:33.039 short lived secrets okay. And to protect the entire application 278 00:15:33.120 --> 00:15:36.360 life cycle in the cloud from development to production. We 279 00:15:36.480 --> 00:15:39.919 now have these integrated platforms called Cloud Native Application Protection 280 00:15:40.000 --> 00:15:45.240 platforms or cnapps. These provide holistic security, covering things like 281 00:15:45.279 --> 00:15:49.799 API security, compliance management, and even securing container images before 282 00:15:49.840 --> 00:15:50.440 they're deployed. 283 00:15:50.600 --> 00:15:52.360 It sounds like a lot to manage. 284 00:15:52.039 --> 00:15:55.840 It can be, which leads to another important concept, Continuous 285 00:15:55.879 --> 00:16:00.919 threat exposure management CETEM. Gartner unveiled this in twenty twenty two. 286 00:16:01.399 --> 00:16:05.200 It's a proactive cybersecurity approach. Instead of just scanning for 287 00:16:05.279 --> 00:16:10.320 known vulnerabilities, CTEM continuously simulates attacks to identify both known 288 00:16:10.440 --> 00:16:14.519 and unknown vulnerabilities and exposures. Across your environment. It goes 289 00:16:14.559 --> 00:16:16.879 beyond traditional vulnerability scanning, so it's. 290 00:16:16.759 --> 00:16:20.080 Not just about building walls, but actively constantly looking for 291 00:16:20.159 --> 00:16:22.720 weaknesses even in the cloud. That makes a lot of sense. 292 00:16:22.840 --> 00:16:25.039 What about the role of AI and machine learning and 293 00:16:25.080 --> 00:16:27.960 all this. Are they friend or foe in this zero 294 00:16:28.000 --> 00:16:28.799 trust landscape? 295 00:16:28.840 --> 00:16:31.919 Oh, they're definitely a powerful friend. AI and machine learning 296 00:16:32.159 --> 00:16:36.120 mL are really transforming cloud native security, especially with real 297 00:16:36.159 --> 00:16:40.440 time detection and response capabilities. Well. Techniques like unsupervised learning, 298 00:16:40.759 --> 00:16:44.799 often using methods like clustering, can detect anomalous traffic patterns 299 00:16:44.840 --> 00:16:48.759 by spotting deviations from established norms, even without knowing what 300 00:16:48.799 --> 00:16:52.519 a specific attack looks like beforehand. In neural networks can 301 00:16:52.559 --> 00:16:56.159 be trained to classify network traffic as malicious or benign 302 00:16:56.559 --> 00:17:00.000 with impressive accuracy, helping sift through massive amounts of dats. 303 00:17:00.759 --> 00:17:02.279 Is that related to generative AI? 304 00:17:02.679 --> 00:17:06.119 Generative AI or GENAI is actually a broader field focused 305 00:17:06.160 --> 00:17:09.000 more on creating new content like text or images, but 306 00:17:09.039 --> 00:17:12.759 the underlying AI and mL technologies are being heavily leveraged 307 00:17:12.799 --> 00:17:17.920 for these kinds of security applications. Detection, classification, anomaly spotting. 308 00:17:17.640 --> 00:17:20.400 Got it? Okay? Now for that more futuristic but potentially 309 00:17:20.400 --> 00:17:23.880 disruptive threat quantum computing. What's the concern there? From a 310 00:17:23.960 --> 00:17:26.039 zero trust and security perspective. 311 00:17:25.799 --> 00:17:29.400 Right quantum computing. Our sources highlight a key point. Quantum 312 00:17:29.440 --> 00:17:33.799 computers can perform certain types of calculations, specifically probabilistic work, 313 00:17:34.160 --> 00:17:35.720 in a fraction of the time compared to. 314 00:17:35.680 --> 00:17:38.480 Classical computers faster calculations. 315 00:17:37.960 --> 00:17:42.119 Much faster for specific problems, and this capability poses a 316 00:17:42.160 --> 00:17:46.519 significant existential threat to many of our current cryptographic algorithms, 317 00:17:47.079 --> 00:17:51.119 especially asymmetric encryption. Think about things like the Diffie Hellman 318 00:17:51.200 --> 00:17:57.079 key exchange, or the digital certificates underpinning secure websites HTTPS. 319 00:17:56.279 --> 00:17:57.799 The ones we rely on every day. 320 00:17:58.000 --> 00:18:01.400 Exactly, these rely on the mathematic difficulty of factoring very 321 00:18:01.480 --> 00:18:05.119 large numbers. It's easy to multiply two large primes, but 322 00:18:05.240 --> 00:18:08.200 incredibly hard for classical computers to find those primes if 323 00:18:08.240 --> 00:18:12.039 you only have the product. Quantum computers using algorithms like 324 00:18:12.079 --> 00:18:16.200 shores algorithm could theoretically crack this kind of encryption relatively easily, 325 00:18:16.480 --> 00:18:18.759 breaking much of today's public key cryptography. 326 00:18:18.920 --> 00:18:20.440 Yikes, So what's safe? 327 00:18:20.559 --> 00:18:25.839 Well, symmetric key encryption like AES Advanced Encryption Standard, which 328 00:18:25.960 --> 00:18:29.400 uses the same key for encryption and decryption is generally 329 00:18:29.400 --> 00:18:33.680 considered more resilient against known quantum attacks. It would require 330 00:18:33.759 --> 00:18:36.880 larger key sizes, but the fundamental approach holds up better. 331 00:18:37.599 --> 00:18:40.720 The good news is there's a huge global effort underway 332 00:18:40.720 --> 00:18:46.279 by cryptographers to develop and standardize new quantum safe cryptographic algorithms, 333 00:18:46.440 --> 00:18:49.960 sometimes called post quantum cryptography. It's a very active area 334 00:18:49.960 --> 00:18:50.920 of research and development. 335 00:18:51.079 --> 00:18:52.799 Okay, good to know people are working on it. 336 00:18:53.319 --> 00:18:53.519 Now. 337 00:18:53.680 --> 00:18:56.960 This all sounds incredibly complex to actually implement across an 338 00:18:57.119 --> 00:19:00.240 entire organization, especially if you're not starting fresh. How do 339 00:19:00.279 --> 00:19:02.680 companies actually do this? Do they have to rip everything 340 00:19:02.720 --> 00:19:05.279 out and start from scratch or can they adapt their 341 00:19:05.319 --> 00:19:08.079 existing systems? What does that look like in practice? 342 00:19:08.359 --> 00:19:10.720 That's a great question, and it's usually a mix. Really. 343 00:19:10.759 --> 00:19:13.720 Each path has its own set of challenges and advantages. 344 00:19:14.200 --> 00:19:17.880 Organizations might face a greenfield deployment, meaning they're building something 345 00:19:18.000 --> 00:19:20.279 entirely new, maybe a new cloud environment or a new 346 00:19:20.319 --> 00:19:24.279 facility that allows for a more streamlined zero trust implementation 347 00:19:24.799 --> 00:19:26.839 right from day one. Designing it in. 348 00:19:26.839 --> 00:19:27.880 That sounds ideal. 349 00:19:28.119 --> 00:19:30.960 It often is, but it's less common. More often companies 350 00:19:31.000 --> 00:19:34.799 are dealing with brownfield deployments. This means integrating zero trust 351 00:19:34.799 --> 00:19:40.279 principles and technologies into their existing, often very complex, legacy infrastructures. 352 00:19:41.039 --> 00:19:44.880 This requires really careful planning and feezing to avoid disrupting 353 00:19:44.960 --> 00:19:46.079 ongoing operations. 354 00:19:46.160 --> 00:19:49.920 Okay, Brownfield is probably the reality for most. 355 00:19:49.720 --> 00:19:52.880 For many, Yes, and a huge enabler in practice for 356 00:19:52.920 --> 00:19:57.240 both Greenfield and Brownfield to some extent is automated network deployment. 357 00:19:57.559 --> 00:19:59.440 This is often called plug and play or P and 358 00:19:59.519 --> 00:20:04.240 P technology solutions like Cisco Catalyst Centers, Land Automation, or 359 00:20:04.480 --> 00:20:09.519 Maraki Zero Touch PROVISIONINGZTP. They really revolutionize how networks are deployed, 360 00:20:09.559 --> 00:20:10.359 especially at scale. 361 00:20:10.480 --> 00:20:11.119 How did they work? 362 00:20:11.200 --> 00:20:14.759 Essentially, they allow new network devices, switches, routers, access points 363 00:20:14.960 --> 00:20:18.440 to automatically register with a central controller and configure themselves 364 00:20:18.480 --> 00:20:21.920 correctly upon first boot up. This significantly reduces or even 365 00:20:21.920 --> 00:20:25.200 eliminates the need for highly skilled IT technicians to be 366 00:20:25.240 --> 00:20:27.599 physically on site for basic setup ah. 367 00:20:27.599 --> 00:20:29.359 That saves time and money. 368 00:20:29.359 --> 00:20:33.319 And addresses skills gaps. Think about a large banking customer 369 00:20:33.359 --> 00:20:36.680 we heard about doing a Pan African deployment. They had 370 00:20:36.720 --> 00:20:41.079 branches across many countries. PNP solutions were absolutely critical for them, 371 00:20:41.160 --> 00:20:45.119 especially in remote locations. Some perhaps unsafe, where finding skilled 372 00:20:45.119 --> 00:20:48.799 personnel locally was a major challenge. It allowed their st 373 00:20:48.920 --> 00:20:51.319 one devices, these are network devices at the edge, to 374 00:20:51.440 --> 00:20:54.559 just connect to the Internet, find the controller, download their configure, 375 00:20:54.720 --> 00:20:59.000 and establish necessary connections like BGP peerings for routing, all 376 00:20:59.000 --> 00:21:01.559 without complex annual intervention on site. 377 00:21:01.640 --> 00:21:04.799 That's a massive operational win. Solves a real world problem 378 00:21:04.880 --> 00:21:06.599 with scale and personnel availability. 379 00:21:06.680 --> 00:21:10.920 Absolutely. Another example is a global enterprise software company. They 380 00:21:11.039 --> 00:21:14.079 demployed something like four hundred sites using a sophisticated network 381 00:21:14.160 --> 00:21:18.599 architecture LAESPE based sd access. This allowed them to maintain 382 00:21:18.640 --> 00:21:22.920 consistent end to end micro segmentation and macro segmentation applying 383 00:21:22.920 --> 00:21:26.079 those zero trust principles even when parts of their network 384 00:21:26.079 --> 00:21:29.319 connected through third party SD one solutions that didn't natively 385 00:21:29.359 --> 00:21:32.720 support their specific security tagging technology called. 386 00:21:32.559 --> 00:21:37.400 Trustsec, so they could extend zero trust across different vendors exactly. 387 00:21:37.680 --> 00:21:41.720 It shows how advanced technical solutions can enable that granular 388 00:21:41.759 --> 00:21:46.759 segmentation across complex multi vendor environments, which is common today. 389 00:21:46.920 --> 00:21:50.240 Okay, those are great examples of deployment and segmentation. What 390 00:21:50.319 --> 00:21:53.559 about applying those dynamic policies you mentioned earlier? Any examples 391 00:21:53.559 --> 00:21:54.240 of that in action? 392 00:21:54.480 --> 00:21:57.960 Yes, definitely. We see dynamic policy enforcement used in some 393 00:21:58.079 --> 00:22:03.480 really interesting ways, sometimes beyond typical enterprise security. Take a library, 394 00:22:03.519 --> 00:22:05.880 for instance, in a small beach town on the northeast 395 00:22:05.880 --> 00:22:09.640 coast of Australia. A library, Yeah, they used time based 396 00:22:09.680 --> 00:22:14.039 network authorization policies to restrict guest Wi Fi access strictly 397 00:22:14.039 --> 00:22:18.079 to their operating hours. This specific problem, they had tourists 398 00:22:18.160 --> 00:22:21.519 and backpackers hanging around the building perimeter after hours using 399 00:22:21.519 --> 00:22:24.640 the free Wi Fi and well leaving a mess. 400 00:22:24.799 --> 00:22:26.799 Huh practical application. 401 00:22:26.559 --> 00:22:30.759