WEBVTT 1 00:00:00.160 --> 00:00:03.000 Welcome to the deep dive where we extract the crucial 2 00:00:03.040 --> 00:00:07.360 insights you need. Today we're tackling something maybe a bit overlooked, 3 00:00:07.719 --> 00:00:11.359 third party risk. Did you know over half of businesses 4 00:00:11.480 --> 00:00:15.679 don't even do basic third party risk management seriously, and 5 00:00:15.839 --> 00:00:19.120 even fewer have like a really solid cybersecurity program for 6 00:00:19.160 --> 00:00:22.960 their vendors. That number, it's genuinely alarming when you think 7 00:00:23.000 --> 00:00:23.559 about it. 8 00:00:23.399 --> 00:00:26.679 Really is. It's what we call third party cybersecurity risk, 9 00:00:26.760 --> 00:00:29.359 or sometimes you hear supply chain security. You're not talking 10 00:00:29.359 --> 00:00:32.240 about direct hits on your own network necessarily. Often it's 11 00:00:32.280 --> 00:00:34.560 these silent threats kind of sneaking in through partners you 12 00:00:34.560 --> 00:00:38.079 actually trust. It's a fundamental shift really in how we 13 00:00:38.119 --> 00:00:39.719 need to approach digital defense. 14 00:00:39.880 --> 00:00:43.280 Absolutely, so our mission today give you a shortcut help 15 00:00:43.320 --> 00:00:46.840 you understand this pretty complex landscape. We'll cut through the jargon, 16 00:00:47.039 --> 00:00:49.119 shine a light on those hidden dangers, and show you 17 00:00:49.159 --> 00:00:52.880 exactly why looking at your vendors security isn't just nice 18 00:00:52.920 --> 00:00:56.119 to have, it's absolutely essential. Get ready for some insights 19 00:00:56.119 --> 00:00:59.520 that might really change how you think about security. Ok 20 00:01:00.200 --> 00:01:03.320 rte in why have these third parties become while the 21 00:01:03.359 --> 00:01:06.120 new front line? This risk isn't exactly new is it, 22 00:01:06.480 --> 00:01:09.920 But the scale of neglect seems huge. I saw this 23 00:01:10.000 --> 00:01:13.840 twenty eighteen Ponemon study said only forty percent do any 24 00:01:13.840 --> 00:01:18.359 cybersecurity checks on vendors, and sixty percent either nothing or 25 00:01:18.400 --> 00:01:21.200 just random ad hoc stuff. That's basically leaving the back 26 00:01:21.239 --> 00:01:22.159 door unlocked, isn't it. 27 00:01:22.239 --> 00:01:23.640 That's a perfect way to put it. Yeah, And the 28 00:01:23.680 --> 00:01:26.280 result we see them in some really big headline grabbing breaches. 29 00:01:26.319 --> 00:01:28.760 Think about the Solar Winds attack twenty twenty. There wasn't 30 00:01:28.799 --> 00:01:31.840 a direct hit on you know, the thousands of places affected, 31 00:01:31.879 --> 00:01:34.400 including US government agencies. No, it was a state actor 32 00:01:34.439 --> 00:01:39.079 inserting malware, the Sunburst trojan into routine software updates for 33 00:01:39.200 --> 00:01:40.519 Solo Winds Orion product. 34 00:01:40.560 --> 00:01:44.799 The update everyone trusted exactly. Microsoft's president Brad Smith called 35 00:01:44.799 --> 00:01:50.439 it an act of recklessness, classic supply chain attack, exploiting trust. 36 00:01:51.079 --> 00:01:53.840 It showed incredible patients sophistication. 37 00:01:54.480 --> 00:01:57.439 And it's not always these, you know, super sophisticated state 38 00:01:57.480 --> 00:02:00.359 actors either. Sometimes the way in is much simpler, right, 39 00:02:00.680 --> 00:02:03.760 but the damage is just as bad. Like the Target breach, 40 00:02:03.799 --> 00:02:07.040 remember that twenty thirteen, twenty fourteen. They didn't hack target 41 00:02:07.079 --> 00:02:10.639 directly first. Nope, they stole credentials from an HVAC vendor 42 00:02:10.919 --> 00:02:14.159 fazzio mechanical. Such a small thing, seemingly. 43 00:02:13.879 --> 00:02:17.759 But it led to massive financial damage, huge reputational hit 44 00:02:17.840 --> 00:02:20.520 for target. It just shows how a little crack and 45 00:02:20.560 --> 00:02:23.400 a partner security can become a giant problem for you. 46 00:02:23.639 --> 00:02:25.360 Yeah, it really does, and. 47 00:02:25.240 --> 00:02:28.000 It highlights that attackers often take the path of least resistance. 48 00:02:28.159 --> 00:02:30.080 That's frequently through a third party who might not be 49 00:02:30.120 --> 00:02:32.159 as buttoned up, which brings us to a key point. 50 00:02:32.319 --> 00:02:35.039 A lot of existing security programs they're just about checking 51 00:02:35.039 --> 00:02:37.120 a box, meeting some regulation. 52 00:02:37.400 --> 00:02:40.759 Ah, the checkbox trap, So just going through the motions 53 00:02:40.800 --> 00:02:44.360 not actually reducing risk pretty much, it becomes an obligation, 54 00:02:44.520 --> 00:02:48.439 not an active defense strategy. True security, real security has 55 00:02:48.479 --> 00:02:51.680 to be active, ongoing. It's got to go beyond just compliance, 56 00:02:52.080 --> 00:02:54.919 you mean genuine threat hunting, looking not just inside but 57 00:02:54.960 --> 00:02:58.360 outside at your suppliers too. If you're only doing what 58 00:02:58.479 --> 00:03:02.039 regulators mandate, well you're probably gonna get hit faster than 59 00:03:02.039 --> 00:03:04.520 someone who sees regulations as just the starting line. 60 00:03:04.639 --> 00:03:07.159 That's a really powerful point. The starting line, not the 61 00:03:07.159 --> 00:03:09.520 finish line. So if we want to move beyond that 62 00:03:09.680 --> 00:03:12.560 checkbox mentality, who are we actually up against. What do 63 00:03:12.639 --> 00:03:16.280 these adversary these bad actors actually do well. 64 00:03:16.319 --> 00:03:19.400 At its heart, cybercrime is just using tech computers the 65 00:03:19.439 --> 00:03:22.199 Internet for illegal stuff. The who can vary a lot, 66 00:03:22.240 --> 00:03:26.919 though most common cyber criminals think electronic thieves, usually after money, 67 00:03:27.360 --> 00:03:29.199 like in the home depot breach back in twenty fourteen 68 00:03:29.240 --> 00:03:30.360 grabbing payment guard data. 69 00:03:30.560 --> 00:03:32.759 Right, the financial motive, But then there are the others. 70 00:03:33.360 --> 00:03:37.800 The nation state hackers apt's advance persistent threats, those some 71 00:03:37.960 --> 00:03:39.639 more serious they often are. 72 00:03:39.759 --> 00:03:43.719 These are state sponsored groups or sometimes really large organized 73 00:03:43.719 --> 00:03:48.879 cybercrime syndicates. They have serious resources patients. They aim for scalthy, 74 00:03:49.000 --> 00:03:52.759 large scale attacks, often political or economic goals driving them 75 00:03:53.039 --> 00:03:56.000 Solar winds prime example of what they can do. The 76 00:03:56.039 --> 00:03:58.960 big difference is usually their motivation and just how deep 77 00:03:59.000 --> 00:03:59.719 their pockets are. 78 00:04:00.000 --> 00:04:03.000 Okay, so these actors, sophisticated or not, are out there. 79 00:04:03.080 --> 00:04:05.319 How do they typically get in? What are the common 80 00:04:05.360 --> 00:04:06.280 doors they knock on? 81 00:04:06.560 --> 00:04:10.439 Fishing is still massive, huge, those deceptive emails trying to 82 00:04:10.479 --> 00:04:13.280 trick you or your vendors employees into giving up info 83 00:04:13.400 --> 00:04:16.639 or clicking a bad link. And what's really dangerous is spearfishing, 84 00:04:17.000 --> 00:04:20.439 super targeted emails aimed its specific people, often ones with 85 00:04:20.519 --> 00:04:23.800 high level access like system admins exactly, or whale fishing, 86 00:04:23.839 --> 00:04:26.439 which goes after the big fish. The c Suite CEOs 87 00:04:26.680 --> 00:04:29.639 Verizon's twenty nineteen report said something like thirty two percent 88 00:04:29.680 --> 00:04:31.399 of all data breaches started with fishing. 89 00:04:31.439 --> 00:04:34.319 Wow, nearly a third, and once they're potentially in or 90 00:04:34.319 --> 00:04:37.160 even just to cause chaos. We hear so much about ransomware. 91 00:04:37.360 --> 00:04:40.879 Oh yeah, ransomware locks up your data, encrypts it, then 92 00:04:40.879 --> 00:04:43.399 demands money to get it back. Remember want to Cry 93 00:04:43.680 --> 00:04:45.839 hit over two hundred and fifty thousand systems one hundred 94 00:04:45.839 --> 00:04:49.240 and fifty countries. The cost is staggering, expected to hit 95 00:04:49.279 --> 00:04:52.439 twenty billion dollars globally in twenty twenty one. And guess 96 00:04:52.480 --> 00:04:53.600 how it often gets delivered? 97 00:04:53.720 --> 00:04:56.160 I mean guess fishing emails? 98 00:04:56.480 --> 00:05:00.120 Got it often through those very same fishing emails. As 99 00:05:00.120 --> 00:05:02.240 a common tactic is a man in the middle attack 100 00:05:02.519 --> 00:05:05.800 or mid M. That's where an attacker basically ease drops 101 00:05:05.839 --> 00:05:09.560 on communication between two parties, steals data wallets in transit. 102 00:05:09.839 --> 00:05:11.480 Often happens over insecure Wi Fi. 103 00:05:11.720 --> 00:05:13.920 Okay, it sounds like a minefield, but is there a 104 00:05:13.920 --> 00:05:16.800 typical playbook? A general sequence? These attacks tend to follow. 105 00:05:16.879 --> 00:05:20.079 There usually is yeah understanding it helps. Most breaches kind 106 00:05:20.120 --> 00:05:24.560 of follow five general steps. First, research, reconnaissance attacker scope 107 00:05:24.600 --> 00:05:27.360 out the target. This can take months. Then intrusion. They 108 00:05:27.439 --> 00:05:30.160 get that first foothold inside the network, maybe via phishing, 109 00:05:30.319 --> 00:05:33.360 maybe an unattached vulnerability, a foot in the door. Exactly 110 00:05:33.600 --> 00:05:37.040 once they're in, it's lateral movement. They start moving around 111 00:05:37.160 --> 00:05:40.800 exploring a network, looking for valuable stuff, more systems to compromise. 112 00:05:41.279 --> 00:05:45.040 Next comes privileged escalation. They try to get more access rights, 113 00:05:45.519 --> 00:05:49.319 go from a regular user account to something powerful like 114 00:05:49.360 --> 00:05:50.680 a domain admin. 115 00:05:50.399 --> 00:05:52.319 To get the keys to the kingdom right. 116 00:05:52.560 --> 00:05:55.600 And finally, exfiltration. They steal the data they came for 117 00:05:55.680 --> 00:05:57.639 and then try to cover their tracks so you don't 118 00:05:57.639 --> 00:05:59.519 notice immediately. It's methodical. 119 00:06:00.120 --> 00:06:04.399 Target breach fits that perfectly. Research finds the HVAC vendor, 120 00:06:04.800 --> 00:06:08.319 Intrusion uses their credentials. Lateral movement finds the payment systems. 121 00:06:08.360 --> 00:06:11.560 Expiltration steals the card data step by step. 122 00:06:11.680 --> 00:06:13.600 A painful but textbook example. 123 00:06:13.759 --> 00:06:17.079 Okay, so we've seen the dangers, the actors, their methods. 124 00:06:17.560 --> 00:06:20.480 Let's switch gears. How do we build a strong defense? 125 00:06:21.160 --> 00:06:23.439 What are the absolute fundamentals we need to think about? 126 00:06:23.560 --> 00:06:25.240 Especially when evaluating third parties. 127 00:06:25.439 --> 00:06:29.120 It's interesting the core ideas haven't really changed. It always 128 00:06:29.160 --> 00:06:34.399 comes back to the CIA triad. Confidentiality, integrity, availability, not 129 00:06:34.519 --> 00:06:37.519 just jargon. These are the pillars for every security decision. 130 00:06:37.759 --> 00:06:41.160 When you look at a vendor, you have to ask confidentiality, 131 00:06:41.279 --> 00:06:44.759 are they storing our data securely? Integrity? Will they ensure 132 00:06:44.759 --> 00:06:48.920 our data stays accurate unaltered? Availability? Can they guarantee we 133 00:06:48.959 --> 00:06:50.720 can get to our data when we need it? Your 134 00:06:50.800 --> 00:06:53.279 vendor assessment should really hinge on these questions. 135 00:06:53.399 --> 00:06:56.279 That makes sense, and with everyone working remotely. Now I 136 00:06:56.360 --> 00:06:59.480 keep hearing this phrase, identity is the new perimeter. What 137 00:06:59.519 --> 00:07:01.120 does that act mean? In practice? 138 00:07:01.319 --> 00:07:03.399 It's a huge shift. The old model was like a 139 00:07:03.439 --> 00:07:06.959 castle wall protect the network edge, but now people can 140 00:07:06.959 --> 00:07:10.240 act from everywhere use cloud services. That old castle and 141 00:07:10.319 --> 00:07:11.959 mote thing doesn't quite cut it right. 142 00:07:12.000 --> 00:07:13.519 The perimeters blurred. 143 00:07:13.399 --> 00:07:18.240 Totally blurred. So now managing who is accessing what becomes 144 00:07:18.279 --> 00:07:22.560 the main security control identity. This makes multi factor authentication 145 00:07:22.720 --> 00:07:26.800 MFA absolutely critical, that extra layer beyond just a password 146 00:07:26.920 --> 00:07:30.279 and privileged Access Management PM. For those really powerful accounts, 147 00:07:30.399 --> 00:07:33.199 think about it. A domain admin account might sell for 148 00:07:33.360 --> 00:07:36.480 over three thousand dollars on the dark web, a regular 149 00:07:36.600 --> 00:07:38.399 user maybe fifteen. 150 00:07:38.040 --> 00:07:39.439 Dollars, a big difference. 151 00:07:39.720 --> 00:07:43.160 Huge. So MFA and PAM they're your best defense against 152 00:07:43.160 --> 00:07:46.560 stolen credentials getting misused because who is logging in is 153 00:07:46.600 --> 00:07:48.920 often more important now than where they're logging in from. 154 00:07:49.040 --> 00:07:51.759 Okay, so identity and access are key. What other basic 155 00:07:51.759 --> 00:07:53.800 control should we be looking for from our vendors? 156 00:07:54.000 --> 00:07:57.560 Patch management is absolutely vital keeping software and systems updated. 157 00:07:57.720 --> 00:08:00.639 It fixes the holes, the vulnerabilities that attack are constantly 158 00:08:00.680 --> 00:08:02.920 trying to exploit. It's like fixing leaks in your roof. 159 00:08:02.959 --> 00:08:06.360 Regularly basic maintenance, but critical critical. 160 00:08:06.600 --> 00:08:11.240 And things like an intrusion detection system IDs that monitors 161 00:08:11.319 --> 00:08:14.759 network traffic looking for weird behavior or known attack patterns. 162 00:08:15.199 --> 00:08:17.160 Think of it like a security camera with an alarm. 163 00:08:17.519 --> 00:08:20.240 It won't stop the attack itself, maybe, but it gives 164 00:08:20.279 --> 00:08:23.600 you that crucial early warning. Hey, something's wrong, right. 165 00:08:23.480 --> 00:08:25.639 The alarm bell? Now I hear this a lot. Oh 166 00:08:25.639 --> 00:08:28.720 we're fine. We have a firewall. Is that really enough? 167 00:08:28.879 --> 00:08:31.680 Oh? Absolutely not. Firewall is like the moat and the 168 00:08:31.680 --> 00:08:35.480 guard at the castle gate. Essential. Yes, stops unwanted traffic 169 00:08:35.480 --> 00:08:39.039 getting in, but once someone is inside, or if a 170 00:08:39.080 --> 00:08:41.919 threat comes in through email, which a basic firewall won't 171 00:08:41.960 --> 00:08:44.399 inspect deeply. It's not enough. That's why you talk about 172 00:08:44.399 --> 00:08:47.600 defense and depth. Multiple layers, independent layers. If one fails, 173 00:08:47.840 --> 00:08:49.000 hopefully another one catches it. 174 00:08:49.120 --> 00:08:52.799 Multiple layers make sense. So with all this complexity, how 175 00:08:52.840 --> 00:08:56.240 do organizations actually structure their approach? This sounds like where 176 00:08:56.320 --> 00:08:58.279 cybersecurity frameworks come into play. 177 00:08:58.480 --> 00:09:02.080 Exactly. Framework give you a roadmap, a structured way to 178 00:09:02.120 --> 00:09:07.279 manage and reduce risk. The NIST Cybersecurity Framework NIST CSF 179 00:09:07.639 --> 00:09:10.120 is a big one, especially in the US. Came out 180 00:09:10.120 --> 00:09:13.440 of a presidential order. It focuses on five core functions. 181 00:09:13.799 --> 00:09:18.200 Identify your risks, protect your assets, detect incidents, respond when 182 00:09:18.200 --> 00:09:21.279 they happen, and recover afterwards. It's built around the idea 183 00:09:21.320 --> 00:09:23.759 that breaches will happen, so you need to be prepared 184 00:09:23.759 --> 00:09:27.320 to handle them and bounce back quickly. It's a proactive approach. 185 00:09:27.440 --> 00:09:30.320 And they are international ones too, right yes, Like ISO 186 00:09:30.399 --> 00:09:33.000 two seven seven zero one two seven zero zero two 187 00:09:33.559 --> 00:09:36.240 ISO two seven zero zero one sets the standard for 188 00:09:36.279 --> 00:09:39.279 an information security management system and two to seven seven 189 00:09:39.399 --> 00:09:41.279 zero two provides the specific. 190 00:09:40.840 --> 00:09:44.200 Controls if a vendor adheres to one of these frameworks. 191 00:09:44.240 --> 00:09:46.519 It's a good sign of their security maturity. Plus it 192 00:09:46.559 --> 00:09:48.960 gives you a common language to talk about security with them, 193 00:09:48.960 --> 00:09:49.919 which is really valuable. 194 00:09:49.919 --> 00:09:52.240 Okay, let's really unpack this whole vendor life cycle thing. 195 00:09:52.240 --> 00:09:53.960 It's definitely not just a one off check, is it. 196 00:09:53.960 --> 00:09:57.720 It's more like a journey, absolutely a continuous journey, and 197 00:09:57.799 --> 00:09:59.960 it starts right at the beginning in the intake phase. 198 00:10:00.120 --> 00:10:03.039 This is your first impression and maybe the most critical point. 199 00:10:03.320 --> 00:10:05.679 You've got to ask the key questions here. What kind 200 00:10:05.679 --> 00:10:08.799 of datas are we sharing, how sensitive is it, how much, 201 00:10:09.080 --> 00:10:12.799 where's it going to live, country, risk, cloud, location, and 202 00:10:12.840 --> 00:10:15.960 crucially who are their vendors the fourth parties because their 203 00:10:16.000 --> 00:10:17.399 security impacts you too. 204 00:10:17.759 --> 00:10:19.519 And this is where you lay down the law right 205 00:10:19.559 --> 00:10:21.399 your non negotiables exactly. 206 00:10:21.759 --> 00:10:25.679 Your organization needs clear must have security requirements, things like 207 00:10:26.120 --> 00:10:29.320 data must be encrypted at rest and in transit or 208 00:10:29.879 --> 00:10:33.279 MFA is mandatory for any privileged access to our systems, 209 00:10:33.720 --> 00:10:36.919 no exceptions. And those SoC two type two reports you 210 00:10:36.919 --> 00:10:40.159 hear about, they're common for IT vendors. What's really important 211 00:10:40.159 --> 00:10:42.320 isn't just the report existing. It's a Type two means 212 00:10:42.320 --> 00:10:45.639 an auditor has verified that the controls describe not only exist, 213 00:10:45.759 --> 00:10:48.879 but actually worked effectively over a period of time. That 214 00:10:48.919 --> 00:10:51.000 turns it from a claim into real evidence. 215 00:10:51.080 --> 00:10:53.360 Okay, so they're onboarded. The report looks good. How do 216 00:10:53.399 --> 00:10:56.799 you make sure things stay good? How do you keep vigilant. 217 00:10:56.559 --> 00:11:00.240 That's ongoing due diligence. It's about staying engaged. Need a 218 00:11:00.360 --> 00:11:03.399 risk based approach. You can't scrutinize every vendor down to 219 00:11:03.440 --> 00:11:07.000 the last detail. It's not practical. So focus your efforts 220 00:11:07.000 --> 00:11:10.159 where the risk is highest. High risk vendors, they get 221 00:11:10.200 --> 00:11:12.000 the deep dives, the more frequent reviews. 222 00:11:12.120 --> 00:11:15.279 Makes sense. But what about those giants, the too big 223 00:11:15.320 --> 00:11:18.159 to care vendors, the ones you absolutely rely on that 224 00:11:18.200 --> 00:11:20.600 they just won't meet all your specific requirements. 225 00:11:20.960 --> 00:11:24.879 Yeah, that's a tough one. Sometimes, frankly, your only real 226 00:11:24.919 --> 00:11:28.000 option is risk transfer. You require them to have solid 227 00:11:28.039 --> 00:11:31.639 cyberliability insurance. You document the risk, you accept it, and 228 00:11:31.720 --> 00:11:34.279 you have the insurance as of backstop. Not ideal, but 229 00:11:34.360 --> 00:11:35.559 sometimes it's the reality. 230 00:11:35.639 --> 00:11:38.519 And what about the people vendor employees? Their training must 231 00:11:38.559 --> 00:11:41.440 be super important, especially with phishing being so prevalent. 232 00:11:41.519 --> 00:11:44.919 Oh, absolutely critical. A vendor needs strong security awareness and 233 00:11:45.000 --> 00:11:48.320 training for their staff, especially around phishing. We keep coming 234 00:11:48.360 --> 00:11:50.759 back to it because it works. Look at the ge 235 00:11:50.879 --> 00:11:54.600 breach in twenty twenty. It happened because Canon, a ge 236 00:11:54.759 --> 00:11:58.159 vendor had a leak through an employee email account. Compromise 237 00:11:58.840 --> 00:12:01.000 just a simple email ish you at a third party 238 00:12:01.360 --> 00:12:03.200 cause problems for gg Wow. 239 00:12:03.279 --> 00:12:06.080 Okay, so annual reviews are standard, but like you said, 240 00:12:06.120 --> 00:12:08.320 a lot can change in three hundred and sixty four days. 241 00:12:08.919 --> 00:12:10.080 How do you bridge that gap? 242 00:12:10.279 --> 00:12:14.080 That's the role of continuous monitoring CM. There are automated 243 00:12:14.159 --> 00:12:17.279 vendors security rating tools out there now. They can scan 244 00:12:17.440 --> 00:12:21.159 vendor networks externally, look for things like open ports, check 245 00:12:21.159 --> 00:12:25.240 if they're patching pomply, even find exposed credentials online. It 246 00:12:25.279 --> 00:12:28.080 gives you a near real time pulse check between those deeper. 247 00:12:27.840 --> 00:12:30.960 Assessments filling the gaps, and for the really critical vendors, 248 00:12:31.000 --> 00:12:33.440 you can probably go even deeper with monitoring. 249 00:12:33.519 --> 00:12:37.120 Yes, that's enhanced CM. For your most vital partners, you 250 00:12:37.200 --> 00:12:40.840 might monitor more specific things, more often software vulnerabilities. They 251 00:12:40.879 --> 00:12:44.639 might have fourth party connections, data location changes how they're 252 00:12:44.639 --> 00:12:47.159 connected to you, and you need a plan for when 253 00:12:47.200 --> 00:12:51.159 things go wrong. A third Party Incident Management TPIM playbook. 254 00:12:51.360 --> 00:12:52.879 What do you do when a vendor tells you they've 255 00:12:52.919 --> 00:12:56.960 been breached discovery, investigation, reporting, closing the loop. Uber learned 256 00:12:56.960 --> 00:12:59.639 this the hard way. They delayed reporting at twenty sixteen 257 00:12:59.679 --> 00:13:05.000 breach and face serious consequences. Prompt notification is key right now. 258 00:13:05.320 --> 00:13:09.559 The end of the line offboarding, the vendor relationship ends. 259 00:13:10.080 --> 00:13:12.120 This feels like something that could easily get forgotten. 260 00:13:12.399 --> 00:13:15.279 It often does, but it's so important. When a vendor leaves, 261 00:13:15.320 --> 00:13:18.480 you need absolute certainty that any data you shared with 262 00:13:18.559 --> 00:13:23.600 them is gone, you reversibly destroyed. That means proper data sanitization, 263 00:13:24.080 --> 00:13:26.799 not just hitting delete. Depending on the media, hard drives, 264 00:13:26.879 --> 00:13:31.559 flash drives, even paper, it means clearing, purging, or physical destruction. 265 00:13:32.240 --> 00:13:34.320 And you need proof, not just a piece of paper 266 00:13:34.320 --> 00:13:40.039 saying they did it. Get digital certificates of destruction CODs, verifiable. 267 00:13:39.360 --> 00:13:41.559 Proof like what happened with Morgan Stanley. 268 00:13:41.240 --> 00:13:44.200 Exactly find sixty million dollars in twenty twenty. Why they 269 00:13:44.240 --> 00:13:46.720 mess up decomisioning old equipment customer data was still on 270 00:13:46.759 --> 00:13:49.519 there just shows them ass of failure and oversight during offboarding. 271 00:13:49.679 --> 00:13:52.480 Okay, let's pivot slightly. Cloud security. Everyone's moving to the cloud. 272 00:13:52.559 --> 00:13:55.279 Is it inherently riskier for third parties or just different. 273 00:13:55.440 --> 00:13:59.000 I'd say mostly different. Cloud offers huge benefits obviously, but 274 00:13:59.080 --> 00:14:02.200 it does change the calculus for your vendors. The key 275 00:14:02.279 --> 00:14:06.720 is understanding the NYST service models. SAUCE software is the service, 276 00:14:06.840 --> 00:14:11.639 pays platform is infrastructure. They define who's responsible for what. 277 00:14:11.919 --> 00:14:15.159 With SAUCE, for example, the vendor manages almost everything, so 278 00:14:15.200 --> 00:14:20.080 their security practices for the underlying infrastructure are paramount. With IAS, 279 00:14:20.120 --> 00:14:23.159 the customer, your vendor in this case has more control 280 00:14:23.279 --> 00:14:24.840 but also more responsibility. 281 00:14:24.960 --> 00:14:28.480 So it all comes down to that shared responsibility model again, 282 00:14:28.639 --> 00:14:31.200 knowing where their job ends and yours begins or where 283 00:14:31.240 --> 00:14:32.360 your vendor's job. 284 00:14:32.279 --> 00:14:35.240 Ends precisely, and it can get tricky. The Capital One 285 00:14:35.279 --> 00:14:37.360 breach in twenty nineteen was a big wake up call. 286 00:14:37.679 --> 00:14:41.200 AWS provides the secure infrastructure, but they basically said Capital 287 00:14:41.240 --> 00:14:46.039 One misconfigured their own Web application Firewall waf FOUCH. Yeah. 288 00:14:46.480 --> 00:14:49.000 It shows that even with a secure cloud provider, how 289 00:14:49.039 --> 00:14:52.320 your vendor configures and uses the services as critical. You 290 00:14:52.360 --> 00:14:55.720 can use tools like the AWS Trusted Advisor Report TART 291 00:14:55.840 --> 00:14:58.240 or as your Advisor to help assess how well they're 292 00:14:58.279 --> 00:14:59.440 managing their cloud environment. 293 00:14:59.639 --> 00:15:03.639 Okay, let's talk legal shields contracts. How do you actually 294 00:15:03.720 --> 00:15:07.440 bake security into the legal agreement? Sounds like the lawyers 295 00:15:07.440 --> 00:15:09.600 need specific constructions from the security folks. 296 00:15:09.679 --> 00:15:13.039 They absolutely do. Contracts are a crucial tool for managing 297 00:15:13.120 --> 00:15:16.480 vendor risk, but only if the security requirements are clear 298 00:15:16.559 --> 00:15:20.720 and strong. Cybersecurity teams need to tell legal what's essential. 299 00:15:21.120 --> 00:15:24.039 What are the non negotiables? Things like you must encrypt 300 00:15:24.080 --> 00:15:27.360 our data, you must use MFA for privileged accounts connecting 301 00:15:27.360 --> 00:15:29.279 to us. We must have the right to audit or 302 00:15:29.320 --> 00:15:30.399 assess your controls. 303 00:15:30.600 --> 00:15:34.039 Get it in writing upfront and incident notification too. 304 00:15:34.159 --> 00:15:37.639 That seems vital critical. The contract has to spell out 305 00:15:37.639 --> 00:15:40.159 what counts as a brooch that needs reporting and demand 306 00:15:40.159 --> 00:15:43.000 prompt notification. You should aim for twenty four to forty 307 00:15:43.039 --> 00:15:45.759 eight hours, you can't wait weeks. And for offshore vendors 308 00:15:45.840 --> 00:15:49.000 you often meet extra clauses, things like requiring work only 309 00:15:49.039 --> 00:15:53.399 from a specific secure designated workspace or Offshore Development Center ODC, 310 00:15:54.039 --> 00:15:57.799 maybe mandating encrypted connections virtual desktops that can't access the 311 00:15:57.840 --> 00:16:01.840 general Internet or allow copy paste, plus rigorous background checks 312 00:16:01.879 --> 00:16:03.480 on their personnel handling your data. 313 00:16:03.519 --> 00:16:06.679 What about really old contracts? Can they become a liability 314 00:16:06.720 --> 00:16:08.759 if the threat landscape has changed. 315 00:16:08.480 --> 00:16:11.759 A huge liability. Look at the Heritage Valley Held versus 316 00:16:11.879 --> 00:16:15.360 Nuance case from twenty twenty. The core issue was dismissed, 317 00:16:15.639 --> 00:16:18.039 but the court specifically pointed out they were operating under 318 00:16:18.039 --> 00:16:20.639 a contract over ten years old, made with a company 319 00:16:20.720 --> 00:16:24.120 Nuance had bought ages ago. It just screams review and 320 00:16:24.200 --> 00:16:28.399 update your contracts regularly. Security threats evolve constantly. Your contracts 321 00:16:28.440 --> 00:16:31.720 need to keep pace. Old language might not protect you anymore. 322 00:16:31.879 --> 00:16:35.679 Right, last big area the actual software and connections, the 323 00:16:35.720 --> 00:16:39.919 real attack surface. Seems like buyer beware is the mantra 324 00:16:40.120 --> 00:16:41.360 for third party software. 325 00:16:41.480 --> 00:16:43.759 It really has to be. Third party software is a 326 00:16:43.799 --> 00:16:45.960 massive attack vector. We saw it with heart bleed and 327 00:16:46.000 --> 00:16:48.399 open SSL. We saw it with Solar Winds. You need 328 00:16:48.440 --> 00:16:51.639 to push vendors to have a documented secure software development 329 00:16:51.679 --> 00:16:54.679 life cycle as SDLC. Security needs to be built in 330 00:16:54.679 --> 00:16:59.480 from the requirement stage through design, coding, testing, deployment and maintenance. 331 00:17:00.240 --> 00:17:01.919 On at the end, and testing is key. 332 00:17:01.960 --> 00:17:06.200 There absolutely different kinds static analysis looking at the code 333 00:17:06.200 --> 00:17:09.839 itself for flaws before it runs. Dynamic analysis running the 334 00:17:09.880 --> 00:17:13.319 software and watching how it behaves, looking for vulnerabilities in action, 335 00:17:13.839 --> 00:17:17.920 and fuzz testing basically throwing garbage invalid inputs at the 336 00:17:17.960 --> 00:17:21.920 software to see if it breaks in unexpected, potentially exploitable ways. 337 00:17:22.079 --> 00:17:23.039 Get to stress test it. 338 00:17:23.279 --> 00:17:26.799 Good to know and understanding common flaws helps definitely. 339 00:17:27.359 --> 00:17:29.559 The OASPA Top ten is a great resource. It lists 340 00:17:29.559 --> 00:17:32.880 the most critical web applications security risks, things like broken authentication, 341 00:17:33.200 --> 00:17:36.759 security misconfigurations. Your vendor should know it and test against it. 342 00:17:37.079 --> 00:17:40.799 And don't forget open source software OSS. So many products 343 00:17:40.799 --> 00:17:43.480 rely on it. It's great, but needs careful vetting, heart 344 00:17:43.559 --> 00:17:47.200 lead hit open SSL a library used everywhere. Tools called 345 00:17:47.200 --> 00:17:50.519 software composition Analysis or SCA can help find and manage 346 00:17:50.599 --> 00:17:52.720 risks in the open source component's vendors use. 347 00:17:52.799 --> 00:17:56.319 Okay, last piece, how these third parties actually connect to 348 00:17:56.359 --> 00:17:58.920 your network? That seems like a direct line in If 349 00:17:58.960 --> 00:17:59.839 not managed right. 350 00:18:00.119 --> 00:18:02.559 It is and this is where the zero trust ZT 351 00:18:02.720 --> 00:18:06.680 model is so important. The core idea never trust, always verify, 352 00:18:07.000 --> 00:18:10.240 assume nothing is safe by default. Every user, every device, 353 00:18:10.279 --> 00:18:13.400 every application, especially vendor connections needs to be verified before 354 00:18:13.440 --> 00:18:17.240 getting access, and even then only give the minimum access needed. 355 00:18:17.400 --> 00:18:20.559 It drastically limits an attacker's ability to move laterally if 356 00:18:20.599 --> 00:18:24.640 a vendor connection is compromised. Never trust, always verify. Got it? 357 00:18:25.079 --> 00:18:28.640 What about all those connected things IoT devices, smart cameras, sensors. 358 00:18:29.559 --> 00:18:32.839 They seem like a potential nightmare. They can be. IoT 359 00:18:32.960 --> 00:18:36.519 is a huge, growing risk area. Often manufacturers rush them 360 00:18:36.519 --> 00:18:39.720 to market and security is an afterthought. Hard coded passwords, 361 00:18:39.720 --> 00:18:42.279 no way to update them, Basic stuff gets missed, creating 362 00:18:42.359 --> 00:18:45.960 easy targets. Exactly, so, your organization needs minimum standards for 363 00:18:46.039 --> 00:18:49.559 any IoT devices connecting to your network, even through vendors, 364 00:18:50.000 --> 00:18:54.200 no hard coded passwords allowed. Access must be configurable. Ideally 365 00:18:54.240 --> 00:18:57.519 they have a hardware Trusted Platform Module TPM for security, 366 00:18:58.000 --> 00:19:00.680 and critically, they must be patchable. Can update it, you 367 00:19:00.720 --> 00:19:01.400 can't secure it. 368 00:19:01.720 --> 00:19:04.640 Wow. Okay, we have covered a lot of ground from 369 00:19:05.119 --> 00:19:08.200 that shocking statistic about how few companies are even doing 370 00:19:08.240 --> 00:19:10.680 the basics all the way to the nitty gritty of 371 00:19:10.839 --> 00:19:14.440 secure software development and zero trust from Solar Winds to 372 00:19:14.559 --> 00:19:18.599 making sure data gets destroyed properly during off boarding. It's 373 00:19:18.640 --> 00:19:21.319 crystal clear that security isn't just contained within your own 374 00:19:21.319 --> 00:19:23.640 walls anymore. It's a shared responsibility. 375 00:19:23.839 --> 00:19:26.599 It really is. It's a complex web, but understanding the 376 00:19:26.640 --> 00:19:29.759 pieces like we've discussed is absolutely essential. The sources we 377 00:19:29.880 --> 00:19:32.480 drew on really paint a picture of high stakes. This 378 00:19:32.519 --> 00:19:35.400 isn't just about dodging fines. It's about keeping the whole 379 00:19:35.559 --> 00:19:37.039 enterprise running and safe. 380 00:19:37.119 --> 00:19:40.039 So here's something to chew on. Think about solar winds again. 381 00:19:40.240 --> 00:19:43.680 Those attackers, likely in apt, spent months, maybe longer, doing 382 00:19:43.720 --> 00:19:47.559 research planning just to plant malware on one specific server, 383 00:19:47.640 --> 00:19:50.359 a build server at a well known tech company. What 384 00:19:50.400 --> 00:19:53.319 does that level of patients, that sophistication tell us about 385 00:19:53.359 --> 00:19:56.160 the adversaries out there today? And maybe more importantly, what 386 00:19:56.200 --> 00:19:59.920 does it imply about your organization's ability to find something 387 00:20:00.200 --> 00:20:04.599 malicious that might have been hiding dormant inside a trusted 388 00:20:04.599 --> 00:20:07.920 third party system for who knows how long yours may be. 389 00:20:08.000 --> 00:20:10.359 That's the chilling question, isn't it. How deep does your 390 00:20:10.440 --> 00:20:14.279 visibility actually go? Are you equipped to find something that's 391 00:20:14.400 --> 00:20:17.759 deliberately trying to stay hidden, possibly for a very long time, 392 00:20:18.279 --> 00:20:21.519 within your extended ecosystem? Right? This really isn't just about 393 00:20:21.519 --> 00:20:26.279 compliance checkboxes or avoiding bad headlines. It's fundamental to protecting 394 00:20:26.319 --> 00:20:29.559 your entire organization. So the question to ask yourself ask 395 00:20:29.599 --> 00:20:32.559 your team is are we really doing enough? Are we 396 00:20:32.640 --> 00:20:36.000 moving beyond just compliance and truly partnering with our vendors 397 00:20:36.319 --> 00:20:39.240 treating this as an active, ongoing practice of hunting for 398 00:20:39.279 --> 00:20:42.440 threats together, because in this interconnected world, you're only as 399 00:20:42.440 --> 00:20:45.119 strong as your weakest link, and quite often that link 400 00:20:45.200 --> 00:20:47.440 isn't inside your own company, it's with a third party. 401 00:20:47.720 --> 00:20:51.400 Keep learning, keep asking the tough questions, and definitely stay curious.