WEBVTT 00:00:00.000 --> 00:00:21.300 Welcome to the KuppingerCole Analysts Chat. I'm Matthias, I'm your host. And today, don't 00:00:21.300 --> 00:00:27.500 go away, we're diving into one of the most critical challenges that CISOs face in 2025 00:00:27.500 --> 00:00:33.800 and beyond, detecting deception. With me is Jonathan Care, our leading expert on security 00:00:33.800 --> 00:00:39.200 leadership and threat detection and telling CISOs what to do. Jonathan, the sophistication 00:00:39.200 --> 00:00:45.200 of deceptive attacks has exploded recently. And what's behind that? What's driving that 00:00:45.200 --> 00:00:46.200 change? 00:00:46.200 --> 00:00:50.500 Hi, well, thanks for having me, Matthias. And you're absolutely right. What we're seeing 00:00:50.500 --> 00:00:54.195 is a perfect storm of AI capabilities, social 00:00:54.195 --> 00:00:58.300 media intelligence, and psychological manipulation 00:00:58.300 --> 00:01:04.100 techniques. And what we're seeing is that threat actors are no longer just sending generic 00:01:04.100 --> 00:01:06.810 phishing emails. We all know how to figure 00:01:06.810 --> 00:01:10.100 those out now. They're crafting highly personalized 00:01:10.100 --> 00:01:13.397 attacks using AI to analyze social media 00:01:13.397 --> 00:01:17.600 profiles in depth and en masse. This allows them to 00:01:17.600 --> 00:01:21.811 generate convincing deepfake videos, emails, 00:01:21.811 --> 00:01:26.500 and even voice synthesis for phone-based attacks. 00:01:26.500 --> 00:01:33.000 So frankly, the traditional security awareness training that we all relied on two years, 00:01:33.000 --> 00:01:35.300 five years ago, is obsolete. 00:01:35.300 --> 00:01:41.100 Well that's sobering reality check, but maybe that can keep me from having to do our next 00:01:41.100 --> 00:01:46.000 awareness training, which is still on my list to do. But before we dive deeper, you're the 00:01:46.000 --> 00:01:48.400 analyst. You're a very structured person. Can 00:01:48.400 --> 00:01:50.800 you give the listeners a kind of a framework, 00:01:50.800 --> 00:01:56.600 a taxonomy for thinking about deception? What's included? What's in there about deception 00:01:56.600 --> 00:01:57.600 and cybersecurity? 00:01:57.600 --> 00:02:01.543 So, absolutely. And I think we can think about 00:02:01.543 --> 00:02:05.400 deception access across four main categories. 00:02:05.400 --> 00:02:11.000 Firstly, there's social engineering and human manipulation. And that's the classic, but 00:02:11.000 --> 00:02:16.700 of course now enhanced by AI approach that we all have plenty of experience with. 00:02:16.700 --> 00:02:18.843 Secondly, we're seeing digital identity 00:02:18.843 --> 00:02:21.700 deception. And this is where our attackers are using 00:02:21.700 --> 00:02:24.600 deepfakes and synthetic personas. 00:02:24.600 --> 00:02:30.700 Thirdly, we're seeing vendor and supply chain impersonation, which means they're attacking 00:02:30.700 --> 00:02:33.567 through our trusted partners. And fourthly, 00:02:33.567 --> 00:02:36.700 of course, technical deception, where attackers 00:02:36.700 --> 00:02:39.460 fool security systems controls using 00:02:39.460 --> 00:02:43.600 adversarial AI. And each of these requires a different 00:02:43.600 --> 00:02:44.600 detection strategies. 00:02:44.600 --> 00:02:50.800 Right. And as I'm taking notes and I understood your four dimensions of how to categorize 00:02:50.800 --> 00:02:55.400 a deception, let's start with the first one that you've mentioned. So, social engineering. 00:02:55.400 --> 00:03:00.400 Let's start with that. And this is the part where most organizations already have some 00:03:00.400 --> 00:03:02.977 existing defense. I just mentioned the awareness 00:03:02.977 --> 00:03:05.500 training that we do. That's mainly about social 00:03:05.500 --> 00:03:09.400 engineering. But how has AI changed the game then? 00:03:09.400 --> 00:03:11.708 Well, I think the change is dramatic. 00:03:11.708 --> 00:03:15.200 Traditional social engineering that we all know and love 00:03:15.200 --> 00:03:18.062 and that you and I did in our younger days 00:03:18.062 --> 00:03:21.400 relied on generic scripts and broad psychological 00:03:21.400 --> 00:03:24.697 triggers. So, we weren't looking to profile 00:03:24.697 --> 00:03:28.300 people. We didn't have the capability, frankly, 00:03:28.300 --> 00:03:34.100 as social engineering testers. Now, of course, attackers are more sophisticated. They can 00:03:34.100 --> 00:03:40.700 and do analyze our LinkedIn posts, Twitter interactions, and other public data that we 00:03:40.700 --> 00:03:44.643 create to make incredibly convincing personas. 00:03:44.643 --> 00:03:48.500 And I've seen cases where attackers generated 00:03:48.500 --> 00:03:56.000 personal emails referencing specific projects, names of colleagues and family and friends, 00:03:56.000 --> 00:04:00.800 and even writing styles that match the supposed sender perfectly. 00:04:00.900 --> 00:04:03.291 This makes detection, especially for the 00:04:03.291 --> 00:04:06.400 layman, even impossible. So, decision makers, CISOs, 00:04:06.400 --> 00:04:10.200 what can they do about that? 00:04:10.200 --> 00:04:15.500 As with so many things nowadays, it comes back to identity. The key is moving beyond 00:04:15.500 --> 00:04:22.100 relying on people to spot deception. And we need to build verification systems instead. 00:04:22.100 --> 00:04:27.800 For example, mandatory callback procedures for any sensitive transaction or system change 00:04:27.800 --> 00:04:32.600 request to bring it out of the IT domain into a business process. If someone claims 00:04:32.600 --> 00:04:39.400 to be your CFO and is asking for an urgent wire transfer, you call back on a known number. 00:04:39.400 --> 00:04:41.379 This sounds simple, but it is incredibly 00:04:41.379 --> 00:04:44.100 effective at stopping attackers. There are other things 00:04:44.100 --> 00:04:49.900 you can do, of course, as well. You can do a micro deposit into your supplier's bank 00:04:49.900 --> 00:04:52.300 account. But we'll talk more about that later on. 00:04:52.300 --> 00:04:56.700 Right. But this requires that people just actually change their behavior, their processes, 00:04:56.700 --> 00:05:01.400 though they have to learn that. It has to be mandatory. Can technology support before 00:05:01.400 --> 00:05:04.700 we make them change their behavior? Are there tools that can help? 00:05:04.700 --> 00:05:09.400 Well, no, it doesn't have to be mandatory. You can live with the increased rate of fraud. 00:05:09.400 --> 00:05:10.400 Sure. 00:05:10.400 --> 00:05:15.900 Fraud is always a matter of business risk. And if you can live with it, then that's up 00:05:15.900 --> 00:05:20.800 to you as an organization. But if you are deciding to do things about it, of course, 00:05:20.800 --> 00:05:24.700 there are technical tools that can help. And one of the things that I think is crucial 00:05:24.800 --> 00:05:32.600 is behavioral analytics. So knowing how your users normally behave, what time they log 00:05:32.600 --> 00:05:39.000 in, what system they access, and how they navigate applications is crucial at detecting 00:05:39.000 --> 00:05:41.640 deception. When someone's account is 00:05:41.640 --> 00:05:45.600 compromised, the behavior patterns change because that 00:05:45.600 --> 00:05:48.000 person has either either the account is being 00:05:48.000 --> 00:05:50.400 operated by a different person or that person 00:05:50.400 --> 00:05:56.400 could be operating under some sort of coercion. And modern behavioral analytics solutions 00:05:56.400 --> 00:05:58.400 can catch those anomalies. 00:05:58.400 --> 00:06:01.231 Of course, we all have already been the victim 00:06:01.231 --> 00:06:04.000 of such attacks, not really victims, but have 00:06:04.000 --> 00:06:09.000 been attacked like this. And I have received messages that claim to be by Berthold, our 00:06:09.000 --> 00:06:15.300 CEO, and they really did not sound like him. And so are there conversation analysis tools 00:06:15.300 --> 00:06:18.700 that can make this step for me already? 00:06:18.700 --> 00:06:25.500 I think so. And we're already seeing tools that can analyze language patterns. As you 00:06:25.500 --> 00:06:28.291 said, you said that didn't sound like Berthold, 00:06:28.291 --> 00:06:31.200 our CEO. But we can analyze the language patterns 00:06:31.200 --> 00:06:33.843 in emails and messages using technology 00:06:33.843 --> 00:06:37.300 tools. We don't have to rely on the human firewall, 00:06:37.300 --> 00:06:39.968 as it's called. We can identify social 00:06:39.968 --> 00:06:43.900 engineering indicators and some obvious triggers. Again, 00:06:44.900 --> 00:06:46.822 I'm still in the realm of general 00:06:46.822 --> 00:06:50.200 psychological triggers here. Artificial urgency, authority 00:06:50.200 --> 00:06:55.100 claims, or emotional manipulation. And as I say, these are still generic psychological 00:06:55.100 --> 00:06:59.400 triggers, and they're obviously ones that are specific to us as individuals, specific 00:06:59.400 --> 00:07:07.900 to you, specific to me. This isn't perfect, but if we can flag an email saying this email 00:07:07.900 --> 00:07:15.500 is suspicious, treat it with care, that helps our humans, our colleagues, to be able to 00:07:15.500 --> 00:07:18.900 say, okay, let me really take a suspicious look at this. 00:07:18.900 --> 00:07:20.989 Right. And in the title of this episode, 00:07:20.989 --> 00:07:23.600 also, we have this notion of advice to leadership. 00:07:23.600 --> 00:07:26.000 So before we close down this first section 00:07:26.000 --> 00:07:28.800 about social engineering, what could be practical 00:07:28.800 --> 00:07:33.800 advice for CISOs who want to start improving towards what you just described immediately 00:07:33.800 --> 00:07:36.200 before buying a tool? What can they do? 00:07:36.300 --> 00:07:40.331 All right. Well, three things you can do this 00:07:40.331 --> 00:07:44.900 week. First, CISOs, implement callback verification 00:07:44.900 --> 00:07:48.186 for any requests involving money, data access, 00:07:48.186 --> 00:07:51.400 or system changes. Those are the three things 00:07:51.400 --> 00:07:54.057 that criminals like and go for. Second, 00:07:54.057 --> 00:07:57.600 establish challenge questions, information that only 00:07:57.600 --> 00:08:04.500 legitimate contacts would know. I'm not a fan of shared secrets as a ongoing verification 00:08:04.500 --> 00:08:11.300 method, but as a firefighting mechanism, until we put more sophisticated tools in, 00:08:11.300 --> 00:08:14.463 they are adequate. Thirdly, create safe 00:08:14.463 --> 00:08:18.600 reporting mechanisms. You have to allow the culture 00:08:18.600 --> 00:08:21.646 to say, hey, I'm reporting this suspicious 00:08:21.646 --> 00:08:25.200 communication, without fear of blame or reprisal. 00:08:25.200 --> 00:08:31.000 Because if people don't feel safe to report suspicious communications, they will not do 00:08:31.000 --> 00:08:32.900 so, and thus the problem continues. 00:08:33.200 --> 00:08:34.978 Yeah, better safe than sorry. That is, I 00:08:34.978 --> 00:08:37.200 think, really also an important part at that point 00:08:37.200 --> 00:08:43.200 to say, okay, maybe one more test rather than one too little. I think that's an issue. 00:08:43.200 --> 00:08:48.200 Okay, that's the first part of the taxonomy that you mentioned. Second, of course, we 00:08:48.200 --> 00:08:54.800 are an identity company, most importantly. So digital identity and deepfake threats. 00:08:54.800 --> 00:08:57.882 I think that's the digital identity deception 00:08:57.882 --> 00:09:01.100 part. And deepfakes are in the news everywhere. 00:09:01.100 --> 00:09:06.100 Everybody's talking about it. We are doing it ourselves. But how real is the threat for 00:09:06.100 --> 00:09:10.100 organizations today? Is this really around the corner or already there? 00:09:10.100 --> 00:09:16.000 It's very real, and it's happening now. We've got many documented cases of attackers using 00:09:16.000 --> 00:09:21.500 AI-generated voices to impersonate executives on phone calls. And again, requesting phone 00:09:21.500 --> 00:09:26.400 transfers, requesting sensitive information. Video deepfakes are still more challenging 00:09:26.400 --> 00:09:32.800 to create in real time, but they're being used in recorded messages and even some video 00:09:32.800 --> 00:09:38.200 calls. And let me give you an example now, which is much in the news, in fact, in the 00:09:38.200 --> 00:09:47.400 UK. The UK government is debating the right to die or assisted dying bill. And as you 00:09:47.400 --> 00:09:57.800 can imagine, things are high on both sides. But of course, this process is exacerbated 00:09:57.800 --> 00:10:00.507 and maybe more challenging if you throw in 00:10:00.507 --> 00:10:03.600 the thought of what happens if you have deepfake 00:10:03.600 --> 00:10:08.400 coming into that scenario, which is already challenging and emotive right now. 00:10:08.400 --> 00:10:10.947 Right. So this is a controversial topic, and 00:10:10.947 --> 00:10:13.900 that can be difficult. But again, from a protection 00:10:13.900 --> 00:10:19.900 perspective, how can organizations detect these synthetic media attacks? How can they 00:10:19.900 --> 00:10:20.900 deal with that? 00:10:20.900 --> 00:10:25.500 Well, there are several layers of defense. And the good news is that technical detection 00:10:25.500 --> 00:10:30.000 tools are improving rapidly. There are now solutions that can analyze video and audio 00:10:30.000 --> 00:10:32.945 in real time to identify synthetic content. 00:10:32.945 --> 00:10:36.300 They look for subtle artifacts that AI generation 00:10:36.300 --> 00:10:39.167 creates, things like inconsistent lighting, 00:10:39.167 --> 00:10:42.900 unnatural eye movements, or audio-visual synchronization 00:10:42.900 --> 00:10:43.900 issues. 00:10:43.900 --> 00:10:52.100 Right. But I think this is just a game of cat and mouse. This technology arms race means 00:10:52.100 --> 00:10:57.600 that these tools will not detect everything. Sometimes the attacker is faster, sometimes 00:10:57.600 --> 00:11:01.500 the technology is faster. What to do when this does not work? 00:11:01.500 --> 00:11:06.400 Well, I've got a very eminent colleague, John Talbot, our eminent colleague John Talbot, 00:11:06.400 --> 00:11:09.274 was recently talking about threat fraud 00:11:09.274 --> 00:11:13.400 detection processes and fraud response and interception. 00:11:13.400 --> 00:11:17.653 And what John and I talked about here is that 00:11:17.653 --> 00:11:22.000 process-based defenses are crucial. Technology 00:11:22.000 --> 00:11:26.447 tools only underpin a robust process. So for 00:11:26.447 --> 00:11:31.400 high-stakes communications, establish out-of-band 00:11:31.400 --> 00:11:37.500 verification. If the CEO suddenly joins a video call asking for something tentative, 00:11:37.500 --> 00:11:43.900 it's okay to send them a text or call their assistant to confirm. This is okay because 00:11:43.900 --> 00:11:46.613 it breaks the attack chain. Even if the 00:11:46.613 --> 00:11:50.300 deepfake is perfect, you're asking for a verification 00:11:50.300 --> 00:11:53.200 that the attacker cannot provide. 00:11:53.200 --> 00:11:56.200 Right. We've talked about the overall tool 00:11:56.200 --> 00:11:59.700 category market segments of identity verification 00:11:59.700 --> 00:12:01.838 in this podcast, together with Annie, 00:12:01.838 --> 00:12:04.900 together with other colleagues. Can that help in that 00:12:04.900 --> 00:12:09.500 case as well? How do you verify on the fly, as you've mentioned, someone just joining 00:12:09.500 --> 00:12:14.300 the call, that they are who they claim to be in our digital world where things take 00:12:14.300 --> 00:12:20.000 just half a second to join a call? 00:12:20.000 --> 00:12:27.100 I'm a fan of what the various vendors have done with digital presence and genuine, what 00:12:27.700 --> 00:12:32.200 do they call it, genuine persona verification. But what we actually need now is to move to 00:12:32.200 --> 00:12:39.900 multi-modal biometrics. Instead of just relying on a password or a face, we need to verify 00:12:39.900 --> 00:12:46.400 everything we can. Typing patterns, voice characteristics, and behavioral traits. And 00:12:46.400 --> 00:12:52.400 the idea is, of course, that attackers might fool one factor. If we ask them to fool a 00:12:52.600 --> 00:12:58.700 number of factors, all working in combination, it's going to be much harder to replicate 00:12:58.700 --> 00:13:05.200 someone's digital behavior. Much harder to fake that complete signature. 00:13:05.200 --> 00:13:07.953 I think most people cannot already imagine 00:13:07.953 --> 00:13:11.100 how that really works. What are the technologies 00:13:11.100 --> 00:13:15.300 that CISOs should be watching to understand? Yes, this is a thing. They understand how 00:13:15.300 --> 00:13:21.200 Matthias moves, how Matthias uses his hands, how he's typing, how he uses his touchpad. 00:13:21.200 --> 00:13:25.000 This is really important, because it can help in identifying what are technologies 00:13:25.000 --> 00:13:26.000 out there. 00:13:26.000 --> 00:13:28.680 Well, you've hit on it. And behavioral 00:13:28.680 --> 00:13:32.700 biometrics is huge and is the key here. Because my belief 00:13:32.700 --> 00:13:35.411 is that these systems, well, my research 00:13:35.411 --> 00:13:38.800 tells me, these systems that learn how we interact 00:13:38.800 --> 00:13:41.657 with our devices are incredibly valuable 00:13:41.657 --> 00:13:45.300 sources of identity information. Your typing rhythm 00:13:45.300 --> 00:13:47.476 is unique to you. You and I type on our 00:13:47.476 --> 00:13:50.600 keyboards in different ways. The way you move your mouse 00:13:50.600 --> 00:13:56.500 is unique to you, as is the way I move my mouse is unique to me. And even how you hold 00:13:56.500 --> 00:14:01.500 your phone, how you brush the glass is all unique. 00:14:01.500 --> 00:14:05.179 And all of this, of course, in the words of 00:14:05.179 --> 00:14:09.200 zero trust, these are continuous authentication 00:14:09.200 --> 00:14:16.300 mechanisms that are very hard to fake. So once you've established an identity at time 00:14:16.300 --> 00:14:23.000 of assertion, at login, then the continuous authentication says the behavior has not 00:14:23.000 --> 00:14:30.400 changed. It is still the same human agent that asserted the identity. And of course, 00:14:30.400 --> 00:14:36.700 the converse of that, if you see a swerve in behavior, say a sudden change, that's an 00:14:36.700 --> 00:14:44.000 indication of some kind of takeover, some kind of coercion. So it's very hard to fake. 00:14:44.100 --> 00:14:50.400 The other thing to look at, and blockchain, for all its faults, is surprisingly useful 00:14:50.400 --> 00:14:53.737 at providing continuous verification or 00:14:53.737 --> 00:14:58.100 providing verification for critical communications. 00:14:58.100 --> 00:15:03.100 We are seeing financial organizations, even some governments, are using blockchains to 00:15:03.100 --> 00:15:06.709 make publicly validatable assertions for 00:15:06.709 --> 00:15:11.400 critical communications. Because, of course, the one 00:15:11.400 --> 00:15:17.400 thing we do know about the blockchain is it does create an immutable proof of the, 00:15:17.400 --> 00:15:19.600 in this case, communication authenticity. 00:15:19.600 --> 00:15:25.600 That would be the thing you compare with. So that would be the normal, the actual, yeah, 00:15:25.600 --> 00:15:30.800 what you compare with. But again, like we did it before, what are practical first steps 00:15:30.800 --> 00:15:35.300 to give guidance to CISOs, to organizations who are worried about deepfakes? 00:15:35.300 --> 00:15:40.200 Well, unusually, because we normally say start with low risk. Actually here, I think you 00:15:40.200 --> 00:15:43.081 should start with your highest risk scenarios, 00:15:43.081 --> 00:15:45.900 the ones that really keep the exec management 00:15:45.900 --> 00:15:51.100 group and the board awake at night. Identify the communications that could cause the most 00:15:51.100 --> 00:15:53.595 damage if compromised, usually involving 00:15:53.595 --> 00:15:56.900 executives, financial transactions, or sensitive data 00:15:56.900 --> 00:16:04.600 access, and then establish verification protocols specifically for those scenarios. 00:16:04.600 --> 00:16:10.000 It's not necessary to verify every email. I don't need to verify an email and say, hey, 00:16:10.100 --> 00:16:14.800 I'm going to be in Wiesbaden. Do you want to come out for lunch? But every request that 00:16:14.800 --> 00:16:18.181 has a significant potential adverse business 00:16:18.181 --> 00:16:22.100 impact that could cost millions should be verified. 00:16:22.100 --> 00:16:27.400 Understood and fully agree. Let's move over to your third category. And if I remember 00:16:27.400 --> 00:16:29.980 correctly, that was vendor and supply chain 00:16:29.980 --> 00:16:32.800 deception. And that is something which I always 00:16:32.800 --> 00:16:38.600 mentioned that in that context is also in the focus of NIST 2, of DORA. So supply chain 00:16:38.600 --> 00:16:43.400 security is important, and obviously for a good reason. This seems like it would be 00:16:43.400 --> 00:16:46.043 harder for attackers to pull off, but 00:16:46.043 --> 00:16:49.900 potentially more damaging. How can that look like? How 00:16:49.900 --> 00:16:53.700 do I pretend to be a supplier or a vendor that I'm not? 00:16:53.700 --> 00:16:58.800 Well, there are simple ways, of course. And we are seeing that in a supply chain, there 00:16:58.800 --> 00:17:07.400 are perhaps some small organizations that are important components of a supply chain, 00:17:07.400 --> 00:17:12.400 which have nevertheless poor security. And so you find that their Office 365 tenant has 00:17:12.400 --> 00:17:15.950 been compromised, something similar. However, 00:17:15.950 --> 00:17:19.500 if we're looking at pure deception, then it's 00:17:19.500 --> 00:17:21.980 true, the barrier to entry is higher. 00:17:21.980 --> 00:17:25.600 Attackers need to do more research and more setup, but 00:17:25.600 --> 00:17:32.400 the payoff is enormous. And I've seen single incident losses of 1.8 million euros is one 00:17:32.400 --> 00:17:38.400 that comes to mind. Threat actors can create entirely fraudulent companies, complete with 00:17:38.400 --> 00:17:44.300 websites, complete with LinkedIn profiles, and even fake references, just to allow them 00:17:44.300 --> 00:17:50.800 to win contracts, gain access into some kind of network. And we need to be on our guard 00:17:50.800 --> 00:17:55.300 against these sophisticated, organized threat actors. 00:17:55.300 --> 00:17:57.170 And the amount of money that you just 00:17:57.170 --> 00:17:59.900 mentioned justifies quite some level of sophistication 00:17:59.900 --> 00:18:05.000 of these attacks. So how sophisticated are these fake vendor operations? 00:18:05.000 --> 00:18:07.714 I think, I admit to a certain grudging 00:18:07.714 --> 00:18:11.500 respect, they are incredibly sophisticated. Attackers 00:18:11.500 --> 00:18:17.800 register a similar domain to a legitimate vendor. Sometimes they use Unicode lookalikes. 00:18:17.800 --> 00:18:20.735 They'll create professional looking websites. 00:18:20.735 --> 00:18:23.800 And even we've had fake employees with detailed 00:18:23.800 --> 00:18:31.300 social media histories. I've seen cases where banks, and the case in mind is a bank in the 00:18:31.300 --> 00:18:34.333 Middle East. So yes, for example, their 00:18:34.333 --> 00:18:38.300 domain name was bankofthemiddleeast.com. And that's 00:18:38.300 --> 00:18:42.500 not the correct domain name, obviously, but it was a very similar one. And when I was 00:18:42.500 --> 00:18:50.000 doing a penetration test, I inadvertently looked at middleeastbank.com, which was an 00:18:50.000 --> 00:18:57.500 incredibly plausible facsimile of the correct website, but actually was a fake. So again, 00:18:57.500 --> 00:19:04.000 these serious and organized organizations will spend months building credibility, will 00:19:04.000 --> 00:19:10.200 spend months creating a fake paper trail. And then of course, they'll make their move. 00:19:10.200 --> 00:19:15.800 But that's mainly for onboarding a new partner, a new vendor, a new member of the supply 00:19:15.800 --> 00:19:21.000 chain. But what you say is the traditional vendor due diligence isn't enough anymore. 00:19:21.000 --> 00:19:22.300 So there needs to be more. 00:19:22.300 --> 00:19:28.000 I think so. And I think you're absolutely spot on. Standard due diligence is just the 00:19:28.000 --> 00:19:33.400 starting point. And I suspect in the same way that we've been talking for years about 00:19:33.400 --> 00:19:39.100 Know Your Customer, KYC, we actually now need Know Your Business Supplier and Know Your 00:19:39.100 --> 00:19:45.300 Business as well. We need enhanced verification protocols, which means verifying business 00:19:45.300 --> 00:19:51.700 registrations and with government databases, checking financial records through multiple 00:19:51.700 --> 00:19:58.400 sources, and most importantly, establishing secure communication channels. And again, 00:19:58.400 --> 00:20:02.200 controlled and protected by strong cryptography. 00:20:02.200 --> 00:20:06.900 And that brings me back to one episode that I just did with our colleague, John Tolbert, 00:20:07.100 --> 00:20:13.600 where I talked about what I think is really essential. Also adding organizational identity 00:20:13.600 --> 00:20:16.439 to our identity management and to understand 00:20:16.439 --> 00:20:19.600 that there's a verifiable organizational identity 00:20:19.600 --> 00:20:24.700 and verifiable means, as you said, through cryptography with certificates that prove 00:20:24.700 --> 00:20:30.800 with a good trust anchor that this organization is the organization that it claims to be. 00:20:30.800 --> 00:20:35.700 How about existing vendor relationships? I already have a contract. How do you protect 00:20:35.700 --> 00:20:40.600 against impersonation there? You won't do the due diligence for every interaction with 00:20:40.600 --> 00:20:41.600 them. 00:20:41.600 --> 00:20:47.100 Well, first of all, monitoring for domain spoofing and lookalike communications, that 00:20:47.100 --> 00:20:51.192 should be part of your vendor supplier monitoring 00:20:51.192 --> 00:20:55.200 process. It is automatable, so we're not putting 00:20:55.200 --> 00:21:00.200 an extra load on our procurement colleagues, but there are tools that they can and should 00:21:00.200 --> 00:21:03.686 deploy to do that. As I said, attackers register 00:21:03.686 --> 00:21:07.100 domains that are one letter off from legitimate 00:21:07.100 --> 00:21:15.000 vendors. They register domains with Unicode. They register domains with all the things 00:21:15.000 --> 00:21:20.700 that we have seen. And of course, they hope that recipients don't notice. Any good email 00:21:20.700 --> 00:21:23.804 solution nowadays will detect these domain 00:21:23.804 --> 00:21:27.500 similarities and then flag them all automatically. 00:21:27.600 --> 00:21:35.300 So there are a host of domain security solutions from Poofpoint, Agari, ValueMail, to name 00:21:35.300 --> 00:21:40.900 but three that will of course sit in front of your email server or indeed your cloud 00:21:40.900 --> 00:21:44.600 email tenant and provide that protection. 00:21:44.600 --> 00:21:49.000 You've mentioned that briefly, but I think we should not let the human element or the 00:21:49.000 --> 00:21:53.700 vendor relationship procurement off the hook. There is a training part for that as well, 00:21:53.700 --> 00:21:54.700 right? 00:21:54.800 --> 00:22:00.500 So, I know how overworked procurement and vendor management teams are, and I'm trying 00:22:00.500 --> 00:22:06.800 not to make their jobs more difficult, but they must, must, must verify changes to payment 00:22:06.800 --> 00:22:09.870 details, contracts or processes through 00:22:09.870 --> 00:22:14.200 independent channels. On the other side, I do tell that 00:22:14.200 --> 00:22:20.200 suppliers, you need to put in big red letters. We will not send you an email saying, hey, 00:22:20.200 --> 00:22:24.700 your payment details have changed. We will contact you. It will be from a person you 00:22:24.700 --> 00:22:29.000 know and recognize in order for a change of that name. It should be on every, something 00:22:29.000 --> 00:22:34.300 like that should be on every invoice. Because if you suddenly get a communication out of 00:22:34.300 --> 00:22:39.100 the blue, hey, it's Bob, I'm your friendly account manager, or hey, I'm the new account 00:22:39.100 --> 00:22:41.642 manager I've taken over from Sue. And I just 00:22:41.642 --> 00:22:44.300 needed to, we need to change the bank details. 00:22:44.400 --> 00:22:46.938 And that needs to trigger a verification 00:22:46.938 --> 00:22:50.300 protocol. And please, not just an email confirmation. 00:22:50.300 --> 00:22:53.035 I saw a case where a large garment 00:22:53.035 --> 00:22:57.700 manufacturer has a supply chain, obviously to supply their 00:22:57.700 --> 00:23:04.600 garments that they make. And they had an email saying, hey, our bank details have changed. 00:23:04.600 --> 00:23:10.100 And they sent an email back saying, are you sure? Are you sure you're not just hacking 00:23:10.100 --> 00:23:15.000 the suppliers? Ha, ha, ha. Came back the email. No, it's okay. Ha, ha, ha. From the 00:23:15.000 --> 00:23:20.200 email address that they were expecting. And of course, what had happened is the attackers 00:23:20.200 --> 00:23:28.000 had compromised in that case, Office 365 email tenant of the supplier. So they were able 00:23:28.000 --> 00:23:35.600 to extract 500,000, I think it was, which in itself was not significant given the size 00:23:35.600 --> 00:23:40.000 of this particular garment manufacturer. However, it did make it onto their financial 00:23:40.000 --> 00:23:45.200 reports because the auditors are saying there was nothing stopping this from being a loss 00:23:45.200 --> 00:23:46.200 in the millions. 00:23:46.200 --> 00:23:48.517 So, but until now, we mainly talked about 00:23:48.517 --> 00:23:51.400 communication, about interacting with an onboarding 00:23:51.400 --> 00:23:54.171 vendor, a partner. How about the technology 00:23:54.171 --> 00:23:57.200 that's already in your organization? Our supply 00:23:57.200 --> 00:23:59.343 chains are much more complex. There are 00:23:59.343 --> 00:24:02.200 systems that we are using provided by others. So how 00:24:02.200 --> 00:24:07.200 about supply chain integrity monitoring? How about understanding what's going on in 00:24:07.200 --> 00:24:08.200 these systems? 00:24:08.200 --> 00:24:13.000 Well, absolutely. Yeah, we are, you know, Matthias, you and I, we are technologists. 00:24:13.000 --> 00:24:15.480 And so this is where our job comes into play. 00:24:15.480 --> 00:24:18.400 This is where technology and our job as technologists 00:24:18.400 --> 00:24:24.600 becomes crucial. We need to deploy tools that monitor for unexpected changes in software 00:24:24.600 --> 00:24:31.200 packages. If part of your software supply chain suddenly updates itself and looks very 00:24:31.200 --> 00:24:38.100 different, then that's a red flag that needs to be investigated. If all of a sudden your 00:24:38.100 --> 00:24:45.200 API gateway is seeing unusual messages from part of your software infrastructure, if your 00:24:45.200 --> 00:24:50.900 microservice starts going macro, let's put it that way, then that's a big red flag that 00:24:50.900 --> 00:24:54.307 needs to be investigated. If your vendor provided 00:24:54.307 --> 00:24:58.200 system suddenly exhibits unusual network communications, 00:24:58.200 --> 00:25:03.500 if it's no longer phoning home, but it's phoning somewhere else on the Internet, that's 00:25:03.500 --> 00:25:10.300 a red flag that should be investigated. Any anomaly in our supply chain, in our software 00:25:10.300 --> 00:25:14.595 supply chain logistics needs to be investigated. 00:25:14.595 --> 00:25:18.800 And SolarWinds taught us that. And Log4j taught 00:25:18.800 --> 00:25:25.400 us that. We need continuous monitoring of everything that enters our environment. 00:25:25.600 --> 00:25:28.831 I loved your approach, what should happen in the 00:25:28.831 --> 00:25:32.600 next two weeks? What should happen in the next two weeks 00:25:32.600 --> 00:25:35.000 for improving vendor deception detection? 00:25:36.100 --> 00:25:38.615 Again, so we can establish secure vendor 00:25:38.615 --> 00:25:42.200 communication channels. We can use mutual authentication. 00:25:42.500 --> 00:25:46.018 We don't need to rely solely upon email for 00:25:46.018 --> 00:25:50.600 sensitive, high impact vendor communications. We can use 00:25:50.600 --> 00:25:53.948 platforms that provide cryptographic verification 00:25:53.948 --> 00:25:57.500 or sender identity and message integrity. Of course, 00:25:57.500 --> 00:26:02.500 this is an investment, but it does pay off when you avoid a major supply chain compromise. 00:26:02.600 --> 00:26:06.250 Really good, good advice. Final category, technical 00:26:06.250 --> 00:26:09.900 deception, where attackers try to fool our security 00:26:09.900 --> 00:26:13.300 systems themselves. Sounds a bit like, yeah, future 00:26:13.300 --> 00:26:16.700 science fiction, but also this is as well happening 00:26:16.700 --> 00:26:17.600 right now, right? 00:26:18.300 --> 00:26:21.009 It's very real. And yes, it does sound like 00:26:21.009 --> 00:26:24.600 something out of a William Gibson novel. I'm a big fan of 00:26:24.600 --> 00:26:28.881 Neuromancer and that whole cyberpunk genre. But 00:26:28.881 --> 00:26:33.800 yeah, this is the world we're living in, folks. We are 00:26:33.800 --> 00:26:37.076 seeing attackers using adversarial machine 00:26:37.076 --> 00:26:41.600 learning to create inputs designed to fool security tools. 00:26:41.700 --> 00:26:45.264 They're crafting emails that bypass fan filters. 00:26:45.264 --> 00:26:49.200 They're creating network traffic that flies under the 00:26:49.200 --> 00:26:53.465 radar and evades intrusion detection or generating 00:26:53.465 --> 00:26:57.900 malware that fools AI-based endpoint protection. And 00:26:57.900 --> 00:27:01.020 in all these cases, it's working out what the normal 00:27:01.020 --> 00:27:04.200 is and working out how you make yourself look normal. 00:27:04.200 --> 00:27:07.684 Right. So when you say it's flying under the radar, 00:27:07.684 --> 00:27:11.100 how can security teams defend against that, adjust 00:27:11.100 --> 00:27:14.026 their radar so that they identify these attacks 00:27:14.026 --> 00:27:17.200 that are actually designed to fool their own tools? 00:27:18.000 --> 00:27:20.501 Just as I talked about multimodal 00:27:20.501 --> 00:27:25.200 identification, here the same key applies. It's ensemble-based 00:27:25.200 --> 00:27:28.468 detection. So instead of a single AI model or a 00:27:28.468 --> 00:27:32.500 single detection method, we need to use multiple different 00:27:32.500 --> 00:27:35.954 approaches. So an adversarial input might fool a 00:27:35.954 --> 00:27:40.200 network-based system, but it's much harder to fool one that 00:27:40.200 --> 00:27:46.900 looks at data repository access or application access or 00:27:46.900 --> 00:27:53.600 looks at the authentication process access. It's hard to 00:27:53.600 --> 00:27:57.959 fool different detection methods simultaneously. 00:27:57.959 --> 00:28:02.500 And again, an aberrance in behavior is a red flag. 00:28:02.600 --> 00:28:06.614 Maybe one additional thought. Before these adversaries 00:28:06.614 --> 00:28:11.000 attack our critical systems or our rescue systems, could we 00:28:11.000 --> 00:28:14.450 not just make them attack something that we just put 00:28:14.450 --> 00:28:18.100 in there for them to attack them? And so honey, tokens, 00:28:18.100 --> 00:28:24.800 deception technology, is this something where we can keep them at arm length away? 00:28:25.700 --> 00:28:29.284 I've always liked deception technology. I think it's a 00:28:29.284 --> 00:28:33.400 very clever idea. It's turning the tables on the attackers. We 00:28:33.400 --> 00:28:36.742 plant fake credentials, decoy files that nobody would 00:28:36.742 --> 00:28:40.400 have any reason to access, and in fact, just dummy systems 00:28:40.400 --> 00:28:43.676 throughout the environment. When someone attacks with 00:28:43.676 --> 00:28:47.200 those, you know, it is by definition unauthorized access, 00:28:47.200 --> 00:28:51.238 whether it's an internal source or an external source. 00:28:51.238 --> 00:28:55.800 There are no false positives. If someone accesses a file or a 00:28:55.800 --> 00:28:59.473 system or user credentials that they have no right to use, 00:28:59.473 --> 00:29:03.400 it's a red flag and you should investigate it. And normally, I 00:29:03.400 --> 00:29:06.779 am cautious about insider risk management tools, because 00:29:06.779 --> 00:29:10.400 of course, we run the risk of damaging corporate culture and 00:29:10.400 --> 00:29:14.043 all the rest of it. And the traditional threat eradication 00:29:14.043 --> 00:29:18.000 procedure, where you corner it and squash it, doesn't work when 00:29:18.000 --> 00:29:21.613 you're talking about fellow employees. It leaves a mess on 00:29:21.613 --> 00:29:25.600 the carpet. So when we're thinking about this kind of thing, the 00:29:25.600 --> 00:29:29.400 fact that we can then use digital methods to identify and 00:29:29.400 --> 00:29:33.400 indeed flag up behavior that is aberrant by definition, it's 00:29:33.400 --> 00:29:34.300 highly valuable. 00:29:34.500 --> 00:29:37.478 Good to hear that. When there's something that I learned as an 00:29:37.478 --> 00:29:40.600 analyst, then it's that technology is not everything, but without 00:29:40.600 --> 00:29:44.184 technology, everything is not enough. Are there specific 00:29:44.184 --> 00:29:48.600 technologies that you would recommend for detecting these adversarial 00:29:48.600 --> 00:29:49.200 attacks? 00:29:49.200 --> 00:29:53.784 Well, absolutely. Monitor for inputs that seem designed to 00:29:53.784 --> 00:29:59.000 test the security boundary. So for example, if Jonathan Kerr sends 00:29:59.000 --> 00:30:03.603 Matthias slightly modified versions of the same file, or 00:30:03.603 --> 00:30:08.700 Jonathan Kerr makes requests of an application with very small 00:30:08.700 --> 00:30:12.569 variations, there might be probing for weaknesses. And this 00:30:12.569 --> 00:30:16.700 can be at the protocol level or at the application and business 00:30:16.700 --> 00:30:20.550 logic level. And so when we see that, again, that's something 00:30:20.550 --> 00:30:24.400 that indicates a cause for investigation. The second thing is 00:30:24.400 --> 00:30:28.727 we need to establish baseline behavior models for critical 00:30:28.727 --> 00:30:33.800 systems. What is normal access for the payroll system? What's normal 00:30:33.800 --> 00:30:37.386 access for the treasury? What's normal access for supplier 00:30:37.386 --> 00:30:41.900 management? What's normal access for production operations? And so on and 00:30:41.900 --> 00:30:44.621 so forth. Whatever the critical system may be for your 00:30:44.621 --> 00:30:48.400 organization. If we establish these baseline behavior models, it means that 00:30:48.400 --> 00:30:52.572 when we see a deviation, we can alert on it. And of course, as I 00:30:52.572 --> 00:30:57.200 said previously, the goal of many sophisticated attackers now is to try 00:30:57.200 --> 00:31:01.423 and fly under the radar. So this is not a panacea, but we are 00:31:01.423 --> 00:31:06.200 raising the bar of the attacker. We're making it harder to attack the 00:31:06.200 --> 00:31:07.000 organization. 00:31:07.100 --> 00:31:10.920 You've mentioned that throughout our discussion, one key factor 00:31:10.920 --> 00:31:14.800 behind that, behind the changes that we're just observing is the 00:31:14.800 --> 00:31:18.472 leveraging of AI for the attacker. On the other hand, you just 00:31:18.472 --> 00:31:22.500 mentioned there is a pattern. I have a normal, I have to identify an 00:31:22.500 --> 00:31:26.950 unexpected behavior. But that, again, is AI on our side. So we have 00:31:26.950 --> 00:31:31.400 AI on the attacker side. We have AI on the cybersecurity protection 00:31:31.400 --> 00:31:35.064 defender side. The broader challenge behind that is that these 00:31:35.064 --> 00:31:39.200 systems are communicating with each other. And on both sides, it's AI. 00:31:39.200 --> 00:31:44.681 Well, like so many defense technologies, it's an arms race. Attackers 00:31:44.681 --> 00:31:50.400 are using AI to generate attacks. Defenders are using AI to detect them, 00:31:50.400 --> 00:31:54.744 respond, and detain them as quickly as possible. And oftentimes, the 00:31:54.744 --> 00:31:59.600 winner is the one that has the better data, more diverse model training, and 00:31:59.600 --> 00:32:04.565 faster adaptation cycles, which is why — come on to another topic here 00:32:04.565 --> 00:32:09.600 — threat intelligence sharing and collaborative defense are becoming so 00:32:09.600 --> 00:32:15.008 important. And I heard one former CEO, someone I respect very much, 00:32:15.008 --> 00:32:20.900 talking about the art of modern defense. We're no longer isolated. And in 00:32:20.900 --> 00:32:24.596 fact, let me give you an example. In my former career, I used to use 00:32:24.596 --> 00:32:28.400 the joke about two people lost in the woods, and they hear a bear roar 00:32:28.400 --> 00:32:31.726 behind them. And one of them starts running, and the other one gets 00:32:31.726 --> 00:32:35.200 their training shoes on. And they say, why did they do that? Well, you 00:32:35.200 --> 00:32:40.490 can't run a bear, no, but I can outrun you. I was so wrong. So, so 00:32:40.490 --> 00:32:45.700 wrong. We only win when we protect ourselves collaboratively, our 00:32:45.700 --> 00:32:50.527 organizations, our supply chains, for that matter, our competitive 00:32:50.527 --> 00:32:55.500 partners. We need to stand together. And this is in fact what modern 00:32:55.500 --> 00:32:59.483 cyber defense is moving towards. Collaborative defense, 00:32:59.483 --> 00:33:03.900 threat intelligence sharing are critical against ETH attacks. 00:33:03.900 --> 00:33:07.331 I fully get that. And I think that is really an important aspect, 00:33:07.331 --> 00:33:11.500 because this is a different thing. I don't think that I should ask the next two 00:33:11.500 --> 00:33:15.533 weeks question at the end of that segment. But nevertheless, what 00:33:15.533 --> 00:33:20.000 should CISOs at least prioritize when they try to build defenses against 00:33:20.100 --> 00:33:21.200 technical deception? 00:33:21.200 --> 00:33:26.212 Yeah, we can't do everything all at once. So where do we start? 00:33:26.212 --> 00:33:32.100 CISOs, start with diversity in your security stack. Don't trust any single 00:33:32.100 --> 00:33:37.057 vendor or single detection method. You need to implement multiple 00:33:37.057 --> 00:33:42.700 layers with different detection approaches, and invest in skilled security 00:33:42.700 --> 00:33:47.687 analysts who can investigate the anomalies that these systems flag. 00:33:47.687 --> 00:33:52.600 Human insight is still crucial to understand sophisticated attacks 00:33:52.600 --> 00:33:57.009 augmented by sophisticated knowledge management, sophisticated 00:33:57.009 --> 00:34:02.200 automated defense and indeed prescriptive action systems, but still human 00:34:02.200 --> 00:34:03.100 insight is crucial. 00:34:03.200 --> 00:34:07.718 So now we went through these four categories, these four dimensions of 00:34:07.718 --> 00:34:12.300 this framework taxonomy that we looked at in the beginning. And that is 00:34:12.300 --> 00:34:17.277 really quite something to chew on. So this is really something where 00:34:17.277 --> 00:34:22.400 people have to think about, me myself as well. So if you combine this, 00:34:22.400 --> 00:34:26.750 usually when you do presentation, there's this final slide with three 00:34:26.750 --> 00:34:31.100 main recommendations as the takeaway. What would be your takeaway for 00:34:31.100 --> 00:34:35.600 CISO's three immediate actions for improving deception detection? 00:34:36.200 --> 00:34:41.078 First, and I stressed it during this web book podcast, implement 00:34:41.078 --> 00:34:47.100 verification protocols for high risk transactions communications. Don't rely on 00:34:47.100 --> 00:34:51.261 people to spot deception. There's considerable evidence now that it is 00:34:51.261 --> 00:34:55.600 impossible for humans to maintain that state of constant vigilance. So we 00:34:55.600 --> 00:35:01.442 need to build systems that require verification. Secondly, behavioral 00:35:01.442 --> 00:35:07.200 analytics will allow you to establish baselines for normal user, and 00:35:07.200 --> 00:35:12.834 for that matter, NHI, non human actors will also give you a behavior 00:35:12.834 --> 00:35:18.800 pattern. Thirdly, you need to create a culture where it's okay to report 00:35:18.800 --> 00:35:24.025 suspicious activity. It's encouraged, it's protected, and it's not 00:35:24.025 --> 00:35:30.200 blank. Hey, oh, why are you flagging this again? You're wrong three times last 00:35:30.200 --> 00:35:32.100 week. Yeah, but they might be right this time. 00:35:32.200 --> 00:35:36.045 Yeah, not very popular topic, but technology investments, where should 00:35:36.045 --> 00:35:40.000 organizations focus their initial budgets when they're starting on their 00:35:40.000 --> 00:35:40.600 journey here? 00:35:41.100 --> 00:35:46.035 Well, not a very popular topic, as you say, because everyone wants to 00:35:46.035 --> 00:35:51.400 invest in the latest and the shiniest. But look at your communication flows 00:35:51.400 --> 00:35:55.489 and your business pathways. Prioritize the technologies that 00:35:55.489 --> 00:36:00.600 integrate well with those existing systems. So advanced email security with 00:36:00.600 --> 00:36:05.197 impersonation detection. Most organizations I know do a lot of high 00:36:05.197 --> 00:36:10.000 value business. They send contracts, they send payments back and forth 00:36:10.300 --> 00:36:15.072 via email. So impersonation detection, behavioral analytics 00:36:15.072 --> 00:36:21.300 platforms that can analyze user behavior across multiple systems. You need to 00:36:21.300 --> 00:36:26.723 have a person centric view of behavior or need a non human actor 00:36:26.723 --> 00:36:32.400 centric personality behavior profile. And then detection protection 00:36:32.400 --> 00:36:37.029 technology. Fairly underutilized, but it does allow you to detect 00:36:37.029 --> 00:36:42.300 unauthorized access. It's possible to solve everything at once. But if you 00:36:42.300 --> 00:36:46.137 can focus on your highest risk scenarios, that's where you'll 00:36:46.137 --> 00:36:50.100 get the biggest wins and therefore the mandate to move forward. 00:36:50.200 --> 00:36:53.370 We've mentioned that before we've mentioned William Gibson, it 00:36:53.370 --> 00:36:57.000 sounds like science fiction already. There's deep fake videos. And if I 00:36:57.000 --> 00:37:01.200 imagine I have 250 episodes of this podcast out there, I think there's 00:37:01.200 --> 00:37:06.000 enough material to train an AI to impersonate me. I think that should be doable. 00:37:06.100 --> 00:37:12.000 But what do you expect coming our way? How do you see the deception landscape evolving? 00:37:12.100 --> 00:37:17.154 We'll see attacks becoming more automated and scalable. We'll see AI 00:37:17.154 --> 00:37:23.100 generated attack campaigns that can adapt in real time based on our responses as 00:37:23.100 --> 00:37:29.020 defenders. Hey, is that really you? Yes, it is really me. Oh, okay. If it's really 00:37:29.020 --> 00:37:35.300 you, Matthias, what do we talk about on the last? And the answer will come back will be 00:37:35.300 --> 00:37:41.125 plausible and correct. We're going to see the volume of attacks increasing 00:37:41.125 --> 00:37:47.500 dramatically, together, unfortunately, with their sophistication. So my advice is 00:37:47.500 --> 00:37:51.800 organizations prepare now for these emerging threats. 00:37:51.800 --> 00:37:57.052 In some recent episodes, which had a very different focus, I talked with 00:37:57.052 --> 00:38:04.200 psychologists about the pressure that CISOs endure by the sheer amount of work they need to do and 00:38:04.200 --> 00:38:10.251 security teams in general. Now we are adding more complexity, more responsibility 00:38:10.251 --> 00:38:16.600 on CISOs. What is your advice for CISOs who are just overwhelmed by the scope of this 00:38:16.700 --> 00:38:18.000 additional challenge? 00:38:18.000 --> 00:38:21.371 The job of a CISO has never been harder. And it's every 00:38:21.371 --> 00:38:24.865 indication that CISO's day is going to be the easiest day 00:38:24.865 --> 00:38:29.400 you've ever had. So it's only going to get more difficult. But what can we 00:38:29.400 --> 00:38:35.711 practically intangibly do? We can start with a deception risk assessment. We can 00:38:35.711 --> 00:38:42.100 map critical business processes and identify where deception could cause the most 00:38:42.200 --> 00:38:46.299 damage. This gives us our hot points. If we build defenses 00:38:46.299 --> 00:38:50.611 around these hot points, these high value targets first, then 00:38:50.611 --> 00:38:55.700 that's where we get the most likelihood of a win. We don't need to solve 00:38:55.700 --> 00:39:00.328 everything immediately. But we do need to build organizational 00:39:00.328 --> 00:39:06.000 resilience systematically, starting with the hot points and working outward. 00:39:06.200 --> 00:39:10.442 So again, we're back to slicing the elephant, really identifying where to 00:39:10.442 --> 00:39:14.393 start and what makes most sense based on a risk assessment. And that 00:39:14.393 --> 00:39:19.100 finally is nice for me because this is my standard reply. Start with a risk-based 00:39:19.100 --> 00:39:23.238 approach and here we are. That again can help cutting down the issue, at 00:39:23.238 --> 00:39:27.490 least allowing that to put it on a timeline and not do everything at once. 00:39:27.490 --> 00:39:31.800 First of all, thank you, Jonathan, for this great insight about the overall 00:39:31.800 --> 00:39:35.505 landscape. Any final thoughts for our listeners? When you 00:39:35.505 --> 00:39:39.405 look back on our conversation on the framework that you just 00:39:39.405 --> 00:39:43.500 created, anything that you would like to add that is important? 00:39:43.700 --> 00:39:47.653 There's a couple of things. First of all, detecting deception is not just a 00:39:47.653 --> 00:39:51.448 technical problem. It's an organizational capability. You need the right 00:39:51.448 --> 00:39:55.613 combination of people, processes and technology working together. Not the first 00:39:55.613 --> 00:40:01.200 time we've given that message, I'm sure. You need to invest in training your team to think like attackers. 00:40:01.800 --> 00:40:07.179 Which is especially key when you are talking about that risk-based approach. Don't 00:40:07.179 --> 00:40:12.624 give in to the temptation of risk management being shutting your eyes and hoping it 00:40:12.624 --> 00:40:18.134 doesn't happen. I've seen that too many times. So instead, you must create processes 00:40:18.134 --> 00:40:24.300 that are resistant to manipulation and deploy technologies that detect what humans might miss. 00:40:24.300 --> 00:40:28.719 Great advice. Thank you very much, Jonathan. And we are at the end of the 00:40:28.719 --> 00:40:33.017 episode. It's a bit longer, but it was so much worth it. I hope you all 00:40:33.017 --> 00:40:37.013 stayed with us until the end because this is so important. For our 00:40:37.013 --> 00:40:41.553 listeners, you'll find more resources on deception detection on our website 00:40:41.553 --> 00:40:46.094 because this is what Jonathan does. So there will be more research on that. 00:40:46.094 --> 00:40:51.300 And I think educating yourself and preparing and actually doing something is key here. 00:40:52.100 --> 00:40:53.800 Absolutely. Thank you very much for having me. 00:40:53.800 --> 00:40:58.767 It has been a great discussion. Thank you very much for our listeners for joining in. 00:40:58.767 --> 00:41:03.558 If you have any questions, as usual, you can leave your comments at our website on 00:41:03.558 --> 00:41:08.349 LinkedIn where we announced this episode and on YouTube in the comment section. We 00:41:08.349 --> 00:41:13.258 are looking at that and we will pick up on that. And Jonathan and I will be happy to 00:41:13.258 --> 00:41:17.991 do another episode just with your questions. Just leave them here. Until that and 00:41:17.991 --> 00:41:23.600 until next time with you, Jonathan, we all have the wish that we stay secure and stay skeptical. 00:41:23.800 --> 00:41:26.199 So this is a business practice. Just do it. 00:41:26.199 --> 00:41:29.100 Thank you again, Jonathan, for being my guest today.