WEBVTT 00:00:05.217 --> 00:00:12.737 Welcome to StartupRad.io, your podcast and YouTube blog covering the German 00:00:12.737 --> 00:00:17.657 startup scene with news, interviews and live events. 00:00:19.677 --> 00:00:23.277 Hello and welcome everybody. This is Joe from StartupRad.io, 00:00:23.437 --> 00:00:27.657 your startup podcast, YouTube blog and internet radio station from Germany, 00:00:27.737 --> 00:00:33.917 Austria. What's the line bringing you the most news and important content from the region. 00:00:34.357 --> 00:00:39.417 This time, I do have somebody as an expert, Simon here with me. Hey, how are you doing? 00:00:40.657 --> 00:00:47.357 Hi. Simon here with me, who will be talking about some aspects of Dora. 00:00:47.557 --> 00:00:51.817 Dora is important enough that we decided to have two episodes on it. 00:00:51.937 --> 00:00:56.657 But don't worry, we're not going to pack them back to back. But we'll have two 00:00:56.657 --> 00:01:01.517 episodes here on different areas of the DORA regulation. 00:01:01.937 --> 00:01:05.597 Simon, before we get started, there is a little disclaimer. 00:01:05.837 --> 00:01:09.917 This is no legal advice. The content of this interview is provided for informational 00:01:09.917 --> 00:01:13.837 purposes only and does not constitute legal advice. 00:01:14.357 --> 00:01:17.877 Neither the interviewer nor the guest are licensed attorneys. 00:01:17.957 --> 00:01:22.897 The discussion is intended to offer our audience a framework to think about. 00:01:22.897 --> 00:01:27.697 Some of the more technical aspects of the EU regulation called DORA, 00:01:27.857 --> 00:01:29.817 Digital Operation Resilience Act. 00:01:30.077 --> 00:01:34.677 We strongly encourage you to consult with qualified legal and compliance professionals 00:01:34.677 --> 00:01:37.597 to address your specific requirements 00:01:37.597 --> 00:01:43.017 and implementations of DORA as they pertain to your organizations. 00:01:43.277 --> 00:01:48.217 Realize solely on information provided in this discussion could result in non-compliance 00:01:48.217 --> 00:01:51.157 or other legal and regulatory risk. 00:01:51.377 --> 00:01:55.317 Always seek professional guidance tailored to your unique circumstances. 00:01:56.237 --> 00:02:02.997 Now that we have that out of the way, DORA is at the time of recording in force. 00:02:03.117 --> 00:02:09.937 But as we talked before, the real enforcement, the real audit will only come next year. 00:02:10.037 --> 00:02:13.877 And the people are really getting started how to handle this, 00:02:14.057 --> 00:02:16.217 how to comply with the DORA Act. 00:02:16.217 --> 00:02:20.697 Can you tell us a little bit about you, a little bit about the DORA Act before 00:02:20.697 --> 00:02:25.517 we get into the subject where you are, the subject matter expert? 00:02:26.307 --> 00:02:30.007 Sure. Then first of all, thanks for having me. Yeah. So my background, 00:02:30.107 --> 00:02:31.967 I started my career at Microsoft at a young age. 00:02:32.067 --> 00:02:35.967 I was 16 at the time, built my career, worked at Cloudflare for a while, 00:02:36.607 --> 00:02:39.887 became a product manager there for more client-side related problems. 00:02:40.307 --> 00:02:43.567 As I grew, like I was solution architect first, I was spending a lot of time 00:02:43.567 --> 00:02:47.447 with customers and then I made it into my role, but more on the product side of things. 00:02:48.207 --> 00:02:51.107 Then I worked at Vercel, built their security products for a while, 00:02:51.227 --> 00:02:54.087 and then a small database company and came back to it. 00:02:54.187 --> 00:02:58.227 So I recognized that as we spent a lot of money and time on protecting our infrastructure 00:02:58.227 --> 00:03:03.087 by buying firewalls to protect the perimeter around our most critical assets. 00:03:04.067 --> 00:03:07.927 Protecting and detecting network flows within our own virtual networks, et cetera, 00:03:08.167 --> 00:03:11.927 and that we also monitor our open source dependencies through static registries 00:03:11.927 --> 00:03:15.667 like Node Package Manager, we have totally forgot about a very big part of the 00:03:15.667 --> 00:03:18.567 attack surface, and that's what's happening in the browser of the user when 00:03:18.567 --> 00:03:19.307 they visit your website. 00:03:19.507 --> 00:03:22.707 So I run a company called Seasite. We do client-side security. 00:03:22.867 --> 00:03:26.027 So basically making sure that whatever happens in the browser of the user as 00:03:26.027 --> 00:03:29.947 a result of your dependencies, your marketing tools, but also your own code 00:03:29.947 --> 00:03:32.427 is safe and is not going to add 00:03:32.427 --> 00:03:37.247 to a major compliance risk or potential downtime or issues in the future. 00:03:37.787 --> 00:03:42.567 So I already see we will be talking about the browser here. 00:03:43.327 --> 00:03:46.367 Is that what we've been talking about? 00:03:46.827 --> 00:03:53.167 Well, so I think that the scope for why Dora is relevant in our field is more 00:03:53.167 --> 00:03:57.627 because Dora talks about third-party services in a more broad concept. 00:03:57.887 --> 00:04:00.487 And it also talks about actively monitoring things. 00:04:00.787 --> 00:04:03.687 And so there's a lot of things happening currently in this space. 00:04:03.847 --> 00:04:07.807 PCI DSS is requiring to monitor client-side dependencies. 00:04:08.227 --> 00:04:11.847 And you may be wondering why. Well, because there were so many incidents for 00:04:11.847 --> 00:04:15.667 the last 10 years where credit card skimming originated from the browser, right? 00:04:15.827 --> 00:04:20.147 So thinking at the British Airways attack in 2018, a polyfill attack last year, 00:04:20.367 --> 00:04:22.547 there's a lot of attacks that execute in the browser. 00:04:23.287 --> 00:04:27.107 And the PCI, so the Payment Card Industry Digital Safety Standards, 00:04:27.367 --> 00:04:31.067 the organization behind that PCI-SSE has recognized that the majority of credit 00:04:31.067 --> 00:04:33.227 card skimming nowadays happens in the browser of a user. 00:04:33.967 --> 00:04:38.507 So when we talk about, like, finally financial organizations and institutions 00:04:38.507 --> 00:04:43.187 being pushed to have a more standardized security process, the client side is 00:04:43.187 --> 00:04:44.947 really very actively in scope. 00:04:45.167 --> 00:04:50.267 And even though the DORA Act is very broad, it is still actively saying things 00:04:50.267 --> 00:04:51.967 like actively monitoring, 00:04:52.387 --> 00:04:56.127 third-party dependency management, regardless of the attack surface, 00:04:56.227 --> 00:04:58.907 whether it's server side or client side, this is your, like, 00:04:58.987 --> 00:05:00.627 part of DORA. You need to monitor it. 00:05:01.047 --> 00:05:04.147 So that's the scope here. We are not a browser company. 00:05:04.307 --> 00:05:09.307 We don't build a secure browser. We're not a Zscaler or an island or anything like that. 00:05:09.767 --> 00:05:13.287 We sell to companies who need to protect their online asset, 00:05:13.407 --> 00:05:17.347 their website, and prevent it from performing attacks in browsers of users or 00:05:17.347 --> 00:05:21.687 things like crypto mining or credit card skimming or login credential theft 00:05:21.687 --> 00:05:23.827 or anything like that by any of the tools that they use. 00:05:25.317 --> 00:05:32.197 The way you're here today is because, of course, it applies to the usual banks, 00:05:32.377 --> 00:05:37.997 the usual insurance companies, but also the fintechs, all companies that are 00:05:37.997 --> 00:05:40.217 related to payment and so on and so forth. 00:05:40.877 --> 00:05:44.757 Therefore, I thought it was very interesting to have you here. 00:05:44.757 --> 00:05:51.497 And as you said, I've been a consultant on capital markets for more than a decade. 00:05:51.737 --> 00:05:57.277 And a lot of the cybersecurity, a lot of all the efforts were around the core systems. 00:05:57.557 --> 00:06:01.917 Barely anybody talked about the website in terms of cybersecurity. 00:06:04.917 --> 00:06:09.397 Here is something I do believe because we're also, as you said, 00:06:09.637 --> 00:06:16.757 most of the theft of private information actually takes place. 00:06:16.757 --> 00:06:20.477 And so I do believe it's an important piece here in the puzzle. 00:06:22.597 --> 00:06:26.017 As we said, we'll be a little bit more specific here. 00:06:26.617 --> 00:06:32.317 But my first question would be compliance readiness. what key steps need companies 00:06:32.317 --> 00:06:35.057 to take to ensure compliance with DORA, 00:06:35.237 --> 00:06:41.617 particularly when monitoring dynamic assets like a chatbot, like a capture system 00:06:41.617 --> 00:06:44.957 to satisfy the authorities, 00:06:45.237 --> 00:06:47.777 the auditors, and also, of course, your investors. 00:06:47.777 --> 00:06:51.617 Because if you do have DORA trouble, your investors won't be happy. 00:06:53.057 --> 00:06:58.057 Yeah, exactly. So, I mean, there's a lot of controls in DORA that overlap with 00:06:58.057 --> 00:07:00.697 other frameworks people should already be familiar with. 00:07:00.897 --> 00:07:06.857 So if you're ISO or you're SOC2 or your GDPR or PCI DSS, you're going to probably 00:07:06.857 --> 00:07:10.237 already have a really significant chunk of it ticked. So that's a good thing. 00:07:10.697 --> 00:07:16.877 I really looked at that DORA Act as an umbrella act that is just revisiting 00:07:16.877 --> 00:07:18.177 the things we should already be doing. 00:07:19.077 --> 00:07:23.277 When we talk specifically about third-party dependencies and their dynamic, 00:07:23.917 --> 00:07:26.257 unfortunately, those have kind of faded into the background. 00:07:26.257 --> 00:07:28.657 So a lot of these frameworks didn't call those out explicitly, 00:07:28.657 --> 00:07:32.397 and you can also tell that therefore the majority of security solutions out 00:07:32.397 --> 00:07:37.297 there that are targeting supply chain security, they don't actively monitor client-side scripts. 00:07:37.657 --> 00:07:41.897 We, however, do, and we do it in a way that is difficult, but it's the only 00:07:41.897 --> 00:07:43.817 right way to do it because this is a unique problem. 00:07:44.137 --> 00:07:48.497 When you go to a website, you will get a response from a third-party server 00:07:48.497 --> 00:07:51.377 that is outside of the control of that actual website that you visit. 00:07:51.377 --> 00:07:55.097 So in the case of a chatbot, let's say you're going to a website and they're 00:07:55.097 --> 00:07:56.437 using the intercom chatbot. 00:07:56.637 --> 00:07:59.597 Well, your browser is making a request to the intercom server. 00:08:00.400 --> 00:08:03.220 Well, God forbid, Intercom gets hacked, right? But there are so many of these 00:08:03.220 --> 00:08:07.700 chatbot companies out there, some with more senior security people than others, 00:08:07.840 --> 00:08:08.980 some with better protections than others. 00:08:09.380 --> 00:08:13.180 The result is that there could very easily be an attack that target only a small 00:08:13.180 --> 00:08:17.740 subset of people and therefore fly below the radar and make it very hard to detect. 00:08:18.200 --> 00:08:22.520 To put that into a real-life example, what you could pull off with a third-party 00:08:22.520 --> 00:08:28.440 JavaScript is an attack that targets 1% of users in France and then after office 00:08:28.440 --> 00:08:32.780 hours, right, only, and then the week after move to 1% of visitors in North America. 00:08:33.700 --> 00:08:38.880 Also after office hours, and then move to another area in the world and just fly below the radar. 00:08:39.040 --> 00:08:42.080 Because if a security analyst were to use a tool that does static analysis, 00:08:42.660 --> 00:08:45.400 that's not going to catch that dynamicness, right? 00:08:45.920 --> 00:08:49.580 So the way that Seaside does this, and that's fundamentally different from what 00:08:49.580 --> 00:08:52.740 we saw in the market, and that's also the reason why we started this as a business, 00:08:52.960 --> 00:08:54.440 is we actually put ourselves in the middle. 00:08:54.620 --> 00:08:57.940 So instead of you actually talking directly to these third-party services, 00:08:58.520 --> 00:09:01.260 we put ourselves in the middle and we offer you complete observability. 00:09:01.560 --> 00:09:05.840 So if somebody on an old Android phone goes to your website or somebody on a 00:09:05.840 --> 00:09:08.960 modern MacBook goes to the website and they get different versions of that script, 00:09:09.100 --> 00:09:11.540 which is often the case, we have all of that data. 00:09:11.680 --> 00:09:15.920 We analyze it through an LLM. We analyze it through an attributes engine that we built in the house. 00:09:16.120 --> 00:09:19.080 So we look for outliers in the behavior and how it has changed. 00:09:19.220 --> 00:09:23.840 So if any of these scripts become malicious and things start behaving weirdly, 00:09:24.480 --> 00:09:28.980 exfiltrating sensitive information, trying to get access to things it shouldn't 00:09:28.980 --> 00:09:30.720 have, like session tokens, for instance. 00:09:31.200 --> 00:09:35.180 That type of behavior we would very quickly flag. And this is directly a thing. 00:09:35.380 --> 00:09:38.160 When you talk about active monitoring of third-party dependencies, 00:09:38.460 --> 00:09:42.080 well, these third-party scripts you add to a website are third-party dependency. 00:09:42.340 --> 00:09:44.800 Because they are dynamic, active monitoring is required. 00:09:45.480 --> 00:09:48.060 Connect the dots, and there you go. That is a door requirement. 00:09:48.320 --> 00:09:51.080 And this is already a requirement, I think, under many other frameworks, 00:09:51.080 --> 00:09:56.060 but sometimes not as explicitly put forward. 00:09:56.220 --> 00:09:58.520 So if you look at PCI DSS, it's an explicit requirement. 00:09:58.760 --> 00:10:04.040 But under HIPAA, you can also expect the clauses regarding third-party security 00:10:04.040 --> 00:10:06.500 to be in scope there. But yes. 00:10:07.160 --> 00:10:12.000 We've been already getting a little bit ahead of ourselves. I want to talk about 00:10:12.000 --> 00:10:16.520 monitoring of those, what you call, dynamic assets. 00:10:16.520 --> 00:10:24.060 That's what I – the most advanced stuff I ever did was to write a little bit 00:10:24.060 --> 00:10:26.700 in Tuber Pascal. So please excuse me here. 00:10:26.800 --> 00:10:30.960 I'm not the technical guy, but this is also not the audience we're targeting 00:10:30.960 --> 00:10:36.560 here. How do you monitor all this external stuff that you have, 00:10:36.700 --> 00:10:41.260 for example, analytics, capture, newsletter, pop-up. 00:10:43.440 --> 00:10:49.900 Chatbot, podcast player, radio player, something like this? How do you actively monitor? 00:10:51.218 --> 00:10:59.678 Monitor those tools and what should the non-technical founders that are listening 00:10:59.678 --> 00:11:04.978 to us right now or how should they think about it in terms of cyber security because, 00:11:05.798 --> 00:11:10.918 I find it fascinating what you do here because that's also something that has 00:11:10.918 --> 00:11:13.938 not popped up in all the discussions that I had around the topic. 00:11:14.138 --> 00:11:19.458 It was more like the usual cyber attacks, really big things. 00:11:19.538 --> 00:11:25.418 For example, University Clinic here in Frankfurt was almost digitally shut down due to cybertech. 00:11:25.598 --> 00:11:29.718 That's the kind of stuff people are thinking about, not, for example, their website. 00:11:30.178 --> 00:11:34.938 Yeah, I mean, the thing is we interact with most online things through a website. 00:11:35.138 --> 00:11:39.658 Even if we don't realize it, a lot of mobile apps are actually websites under the hood. 00:11:40.738 --> 00:11:44.238 Progressive web apps, PWA is a technical term for that, or web views. 00:11:44.258 --> 00:11:47.998 It's essentially just a way for a developer to be able to build a thing in a 00:11:47.998 --> 00:11:49.778 language they're confident with, right? 00:11:49.918 --> 00:11:53.938 To build a website and it basically becomes a mobile app, right? 00:11:54.118 --> 00:11:58.078 So more things have become browsers. We already interact with most things through 00:11:58.078 --> 00:11:59.258 what is basically a browser. 00:11:59.658 --> 00:12:03.198 And at the same time, we have not protected the browser. So the way that it 00:12:03.198 --> 00:12:07.278 works, and this should be easy to do for people that are non-technical even, 00:12:07.518 --> 00:12:13.078 if you can add that button or you can add that like podcast or that A-B testing 00:12:13.078 --> 00:12:14.778 thing or that chatbot to your website, 00:12:15.258 --> 00:12:18.218 It's exactly the same thing you would do to install our solution. 00:12:18.778 --> 00:12:22.498 So we've got a couple of ways you can onboard, but the easiest is you just add 00:12:22.498 --> 00:12:25.818 our script to the website as the first one to load and you go through those 00:12:25.818 --> 00:12:29.718 other scripts you added and you put proxy.ccital.dev slash in front of them. 00:12:29.958 --> 00:12:31.598 That's it. And now it flows through us. 00:12:31.998 --> 00:12:34.458 So that code now comes through our systems. 00:12:36.040 --> 00:12:38.980 There's another way that you can onboard and that's using basically a plugin 00:12:38.980 --> 00:12:40.880 that you install, an NPM package. 00:12:41.280 --> 00:12:45.060 It's basically just to put it more technically a CLI that would automatically 00:12:45.060 --> 00:12:46.980 rewrite these scripts for you. 00:12:47.140 --> 00:12:49.780 You don't have to do anything more than just installing a thing, that would be it. 00:12:50.280 --> 00:12:53.200 In our dashboard you then see all of these scripts passing through us, 00:12:53.900 --> 00:12:55.540 but autonomously we review those. 00:12:55.840 --> 00:13:01.580 So the biggest clue that there is something going wrong is when notice these 00:13:01.580 --> 00:13:06.740 scripts change and there's changes that are not consistent with the behavior 00:13:06.740 --> 00:13:07.760 we'd expect from that script. 00:13:08.360 --> 00:13:11.620 It is normal for scripts to change and they are very dynamic. 00:13:11.840 --> 00:13:15.500 So as I explained earlier, if you have an old Android device, 00:13:15.540 --> 00:13:16.380 you're probably going to get 00:13:16.380 --> 00:13:20.260 a different version of a certain script than you will on a modern laptop. 00:13:20.640 --> 00:13:24.860 That dynamicness of a third-party script is actually a big part of the feature 00:13:24.860 --> 00:13:29.700 because it allows for those packages to be consistently working across very 00:13:29.700 --> 00:13:30.860 different environments, 00:13:31.400 --> 00:13:34.680 sometimes still even including Internet Explorer, right, which has been phased 00:13:34.680 --> 00:13:37.640 out for so many people, but it's still a very small percentage of the internet. 00:13:38.220 --> 00:13:41.760 I want to interrupt you, but do people actually still use Netscape? 00:13:43.100 --> 00:13:46.040 Netscape, I have not come across in significant enough numbers, 00:13:46.220 --> 00:13:49.960 but yeah, I mean, whatever device you currently have in front of you, 00:13:50.120 --> 00:13:53.860 unless you keep it in your house forever, will eventually end up somewhere being 00:13:53.860 --> 00:13:55.900 used by someone who's not as fortunate as us. 00:13:55.900 --> 00:13:59.120 So recycling of devices, especially in corporate environments, 00:13:59.460 --> 00:14:01.780 it has an incredibly long lifeline. 00:14:02.940 --> 00:14:07.680 Old compact computers from 20 years ago are probably in use somewhere in the world, right? 00:14:07.800 --> 00:14:11.140 Or either they get recycled or they make it all the way to Kenya, right? 00:14:11.320 --> 00:14:15.880 So the result is that old legacy things that we in the Western world can't even 00:14:15.880 --> 00:14:19.340 think about anymore, there's still a small percentage of the internet that use them. 00:14:19.940 --> 00:14:23.780 Of course, then the attack surface is different, right? but still very relevant 00:14:23.780 --> 00:14:27.460 to understand that backwards compatibility is something that with any modern 00:14:27.460 --> 00:14:29.800 web application is not something to neglect. 00:14:30.860 --> 00:14:33.840 And actually, this is a completely different thing to point out here, 00:14:33.960 --> 00:14:39.000 but as I noticed my grandparents aging, we also have to understand that users 00:14:39.000 --> 00:14:42.480 are also something that you shouldn't neglect backwards compatibility to. 00:14:43.040 --> 00:14:47.140 That's not something that Dorak talks about at all, but as we all get older... 00:14:47.980 --> 00:14:52.940 It's a very challenging way to say that. Yeah, I mean, if we all get older, 00:14:53.080 --> 00:14:56.280 we have to also think about how our older people are going to understand this. 00:14:56.520 --> 00:15:00.840 And this is the thing, like with these third party scripts, they are incredibly good at accessibility. 00:15:01.180 --> 00:15:04.840 They are incredibly good at backwards compatibility. And that is because of 00:15:04.840 --> 00:15:05.740 the dynamicness of them. 00:15:06.420 --> 00:15:09.840 But that's also very problem-based. So like really the only way that you can 00:15:09.840 --> 00:15:13.140 do proper client-side security is by having that stuff coming through you. 00:15:13.778 --> 00:15:16.918 By our system analyzing it 100% of the time. 00:15:17.298 --> 00:15:20.778 We, of course, hash it, right? So if the script is the same as it was before, 00:15:21.038 --> 00:15:24.838 we will not do the very painful and heavy lifting of reanalyzing it. 00:15:24.898 --> 00:15:26.178 If the hash is the same, we won't do it again. 00:15:26.538 --> 00:15:29.918 If the hash is different, though, that's when we reanalyze it in its entirety. 00:15:31.558 --> 00:15:34.838 And that then allows us to be quite confident in detections that we do. 00:15:34.978 --> 00:15:38.738 Of course, as every security solution out there, we're always looking for things 00:15:38.738 --> 00:15:40.838 we need to improve and detections that need to be added. 00:15:41.278 --> 00:15:44.478 But we at least have all the data. We don't think any of our competitors have 00:15:44.478 --> 00:15:45.638 the amount of data that we have. 00:15:46.038 --> 00:15:48.778 And that's also partly to thank the fact that we have a free tier. 00:15:48.958 --> 00:15:53.378 People can just sign up, use our products for free, and get a whole lot of visibility. 00:15:53.738 --> 00:15:57.058 And that would then help everybody to be safer, right? Because a lot of these 00:15:57.058 --> 00:16:00.618 scripts, they can even act differently depending on the website they are on. 00:16:00.778 --> 00:16:05.198 So if there's an analytic script on a bank's website, where that same analytic 00:16:05.198 --> 00:16:10.898 script is also on the local Baker's website, They can very easily make that 00:16:10.898 --> 00:16:14.738 script behave differently on a bank website as it does on the local baker's website. 00:16:14.918 --> 00:16:17.338 This is actually a very relevant thing to call out still. 00:16:18.598 --> 00:16:22.978 Any website out there, how weird you may think it is, will probably have some 00:16:22.978 --> 00:16:26.338 type of analytics tooling on it, including hospital websites. 00:16:26.338 --> 00:16:30.358 And so Kaiser Permanente, a large American insurance company last year, 00:16:30.758 --> 00:16:33.998 leaked all of their customers' healthcare information, all 13 million people's 00:16:33.998 --> 00:16:39.118 healthcare data, to a third party through their client-side script. 00:16:39.718 --> 00:16:43.778 And this was an honest mistake. They added the TikTok script to their website, 00:16:43.778 --> 00:16:46.958 thinking this was just TikTok's normal US-use script. 00:16:47.298 --> 00:16:50.518 It turned out to be the Chinese version, so the data was being sent to China. 00:16:51.078 --> 00:16:55.078 That's obviously a big HIPAA no-no, and that then caused a big trouble there. 00:16:55.078 --> 00:16:59.378 The problem is there's not enough governance around adding analytics tools to 00:16:59.378 --> 00:17:01.418 websites or these types of third-party scripts. 00:17:01.618 --> 00:17:03.958 And that's what these frameworks are trying to enforce. 00:17:04.218 --> 00:17:07.818 And that's a good thing because it basically protects the end user. 00:17:07.818 --> 00:17:12.558 Would you, again, for the non-technical entrepreneur, 00:17:12.918 --> 00:17:20.398 help us to think a little bit what steps an entrepreneur should take, 00:17:20.518 --> 00:17:26.758 thinking about vendor risk, third-party contracts, and really mapping the dependencies here? 00:17:28.344 --> 00:17:33.284 Yes. So honestly, as a non-technical person, this is a very hard assessment 00:17:33.284 --> 00:17:38.304 to make because they will not tell you whether the script is dynamic or not, 00:17:38.304 --> 00:17:43.284 or whether there's other methods you can use yourself to install it that are safer. 00:17:43.764 --> 00:17:45.784 So fortunately, there's a lot of trust you need to have there. 00:17:45.864 --> 00:17:49.064 But I think if a non-technical person, the best thing you can do is make sure 00:17:49.064 --> 00:17:54.984 that the tools you add to your website are being used by a significant portion of the internet. 00:17:55.824 --> 00:18:01.124 And that those tools are built by companies with a staff that looks confident 00:18:01.124 --> 00:18:02.664 and have a good security team. 00:18:03.004 --> 00:18:05.804 There's a few ways you can go ahead and figure that out. So first of all, 00:18:05.964 --> 00:18:11.284 if these scripts are being used on all of websites, there's this platform called public www.com. 00:18:11.484 --> 00:18:12.784 I think it's .net or whatever. 00:18:13.284 --> 00:18:17.104 You can type in the script in there and it will tell you how many websites also have that script. 00:18:17.304 --> 00:18:20.784 If that script is on another 100,000 websites, you're probably going to be okay, 00:18:21.104 --> 00:18:23.044 right? Because these companies, they have something to lose. 00:18:23.824 --> 00:18:27.024 Then if you have a look at the website of that script and you have a look at 00:18:27.024 --> 00:18:29.864 that tool and you see that they have a security center or a trust center, 00:18:30.204 --> 00:18:33.144 go have a look at their certifications, see what certifications they have. 00:18:33.684 --> 00:18:38.144 That probably will be a good indicator of them having good security compliance on their site. 00:18:38.284 --> 00:18:41.704 So then that particular vendor, you're probably okay adding to your website. 00:18:42.164 --> 00:18:46.164 However, the best thing you can do, and this is just because you don't know 00:18:46.164 --> 00:18:49.524 what those people then trust, there's third-party dependencies on their side, 00:18:50.044 --> 00:18:52.024 one script calls, another script calls, another script. 00:18:52.624 --> 00:18:55.624 Honestly, the best thing you can do, and I hate to sound like a marketing guy, but it's. 00:18:56.458 --> 00:18:59.958 Use our free tier because there's no other way to get the visibility because 00:18:59.958 --> 00:19:02.878 it's happening outside of your field of vision in the browser of your visitor. 00:19:03.138 --> 00:19:06.278 And that visitor can get a different thing than you get on your site. 00:19:06.638 --> 00:19:10.198 So there really is only that. That's the real reason why I wanted to build this 00:19:10.198 --> 00:19:11.958 thing. I didn't find any other way to do it. 00:19:12.118 --> 00:19:18.858 I'm thinking now about mapping those dependencies in terms of one connection as a lag. 00:19:19.018 --> 00:19:24.698 How many of those connections, how many degrees, how many of those lags have you found? 00:19:24.698 --> 00:19:30.758 Or do you usually find how many dependency, codependency, and so on and so forth 00:19:30.758 --> 00:19:34.698 do you usually see there? It really depends. 00:19:35.118 --> 00:19:39.998 So if you have, for instance, let's say you're, and this is a bit outside of 00:19:39.998 --> 00:19:42.798 the scope of Dora, right? Well, actually, we can make this about Dora. 00:19:43.098 --> 00:19:48.718 Let's say you're an insurance broker and you have an iframe on your webpage to book an appointment. 00:19:49.198 --> 00:19:54.058 And that tool that you added, that iframe, or I don't know, it could be a widget, 00:19:54.238 --> 00:19:56.518 right? Does third-party fetches to other things? 00:19:56.698 --> 00:19:58.658 It could very easily end up with a long list. 00:19:58.958 --> 00:20:03.398 So we saw this with, for instance, a little hotel booking widget that people 00:20:03.398 --> 00:20:06.578 add to their hotel's website so that when you're a hotel owner, 00:20:06.658 --> 00:20:08.258 you add this thing and they can book it through that. 00:20:08.718 --> 00:20:11.458 Well, that thing was calling like 50 other dependencies, right? 00:20:11.538 --> 00:20:15.898 So it was calling jQuery through a CDN, this thing through a CDN, 00:20:15.938 --> 00:20:18.818 that thing through a CDN, calling third-party assets here, there, 00:20:18.818 --> 00:20:22.338 and everywhere, adding analytics to it, even adding A-B testing to that widget 00:20:22.338 --> 00:20:24.458 because, of course, they're also looking to improve their product. 00:20:24.738 --> 00:20:27.178 And then those A-B testing things, they called up other stuff, 00:20:27.378 --> 00:20:30.258 it can become a very significant tree. 00:20:30.818 --> 00:20:35.778 So I've seen personally more than 50 of these dependencies on some scripts. 00:20:36.198 --> 00:20:41.038 Many of them are nice to themselves and only have one JavaScript file and no sub-dependencies. 00:20:41.878 --> 00:20:45.358 It really could be anything, right? And the problem is you will only really 00:20:45.358 --> 00:20:50.458 know when you start analyzing these things yourself, either manually or using a tool like us. 00:20:51.178 --> 00:20:54.138 And even when you're using a tool like us, you will see that it will largely 00:20:54.138 --> 00:20:56.038 differ, especially with A-B testing. 00:20:56.778 --> 00:21:00.538 If they then fetch a version and that version has more things to it, 00:21:00.598 --> 00:21:02.118 then it's going to be different across different browsers. 00:21:02.638 --> 00:21:06.898 There's a lot of noise here. So it's very hard. I can't just say normally it's 40. 00:21:07.158 --> 00:21:11.278 That's not how it works. It could be a very broad spectrum. 00:21:12.838 --> 00:21:19.378 I see. We will be back with you guys shortly after the break for our sponsor. 00:21:28.425 --> 00:21:35.085 Okay. Welcome back. I have Simon here still with me talking about the more technical aspects, 00:21:35.245 --> 00:21:43.605 especially in the browser of your company client-facing that falls under the DORA Act. 00:21:44.305 --> 00:21:47.045 When I was thinking about this, 00:21:47.225 --> 00:21:54.665 what is the average number of third-party dependencies you usually see? 00:21:54.845 --> 00:21:59.425 Because when you've been talking about a booking, a little booking app, 00:21:59.565 --> 00:22:06.005 a chatbot, a player, and I think I have at least 20 of them on my website and 00:22:06.005 --> 00:22:09.365 I don't even want to think about mapping them out. 00:22:11.185 --> 00:22:16.025 Yeah. So, I mean, the average I have seen from the websites that we crawl and 00:22:16.025 --> 00:22:18.165 that we have as our customer base is 53. 00:22:19.325 --> 00:22:24.705 You will find varying numbers about this, But it's very common for a commercial 00:22:24.705 --> 00:22:29.905 business with all types of pages and projects, et cetera, on their website to 00:22:29.905 --> 00:22:31.365 have a very broad scope of these, right? 00:22:31.465 --> 00:22:34.225 So you've got the analytics tools and a chatbot for support and the testing 00:22:34.225 --> 00:22:37.565 for legal and that pixel for engineering and A-B testing for that. 00:22:37.765 --> 00:22:41.125 And the marketing team has a podcast widget and all that stuff, right? 00:22:41.565 --> 00:22:46.185 Before you know it, you've got 53. And I think that that number will not really 00:22:46.185 --> 00:22:50.105 go down because it's funny when people tell me, oh, aren't third-party scripts 00:22:50.105 --> 00:22:55.345 on the way out? Well, no, because there will always be a reason for client-side dynamicness. 00:22:55.865 --> 00:22:59.445 And that will never be replaced by just an NPM package because they're still 00:22:59.445 --> 00:23:00.705 going to fetch it in the browser anyway. 00:23:01.085 --> 00:23:04.865 And that's another thing. If you install a dependency through something like 00:23:04.865 --> 00:23:08.145 Node Package Manager, which if you're an engineer, you definitely know, 00:23:08.205 --> 00:23:13.225 but as a non-technical person, it's just a marketplace of open source stuff you can add to a website. 00:23:13.225 --> 00:23:16.285 And now all of a sudden you have access to this big library of cool stuff. 00:23:16.605 --> 00:23:18.585 Well, those can do client-side fetches. 00:23:19.685 --> 00:23:23.185 That's not really solving anything because the client-side fetch is still there. 00:23:25.045 --> 00:23:29.005 In fact, actually, the thing that I find interesting about this attack factor 00:23:29.005 --> 00:23:33.205 is that even people that are non-technical, that are putting their faith in 00:23:33.205 --> 00:23:37.885 tools like WordPress, etc., well, we see a significant amount of client-side 00:23:37.885 --> 00:23:39.185 attacks coming through WordPress, 00:23:39.845 --> 00:23:41.565 especially through old themes. 00:23:41.985 --> 00:23:46.685 So those old dashboard themes that people use to build a pretty website. 00:23:48.065 --> 00:23:52.025 Yeah, if those people don't maintain those and some bad actor manages to get 00:23:52.025 --> 00:23:54.145 a hold of them, they will add malicious JavaScript to them. 00:23:54.645 --> 00:23:56.785 Before you know it, you've got an attack happening that way. 00:23:56.885 --> 00:24:02.405 Just like early in January, we spotted 5,000 websites were impacted through that. 00:24:02.585 --> 00:24:06.425 That's an, of course, significant amount of websites, but for WordPress, 00:24:06.625 --> 00:24:09.445 well, there's many millions of WordPress websites, but still 5,000 websites 00:24:09.445 --> 00:24:15.505 is quite a big deal. You could do a lot of very, very... 00:24:17.623 --> 00:24:23.023 Dumb stuff with all the data you get there. We've been talking about incidents 00:24:23.023 --> 00:24:28.183 here and there, talking about incident management and reporting here. 00:24:28.723 --> 00:24:35.683 How should they design the incident response process to address the issues that 00:24:35.683 --> 00:24:40.623 are stemming from the browser-based user interactions and ensure that they are 00:24:40.623 --> 00:24:43.203 doing Dura-compliant reporting here? 00:24:43.783 --> 00:24:48.683 Yeah, so my advice is regarding any type of client-side dependency that you 00:24:48.683 --> 00:24:52.823 add to keep track of when you added it and what state it was at the time, right? 00:24:53.863 --> 00:24:58.143 And then also makes it easier to understand, okay, at that date, 00:24:58.163 --> 00:25:01.943 we added that script, and then we saw a jump in sub-dependencies that were also 00:25:01.943 --> 00:25:03.783 added to the website as a result of that script. 00:25:03.963 --> 00:25:06.083 It makes it easier to trace back if there's an incident. 00:25:06.283 --> 00:25:11.623 The unfortunate thing about client-side security is if we see an attack at scale 00:25:11.623 --> 00:25:15.903 on a whole bunch of websites, it's sometimes not clear to us where it originated 00:25:15.903 --> 00:25:18.723 from because, I mean, the client-side code made it into the code, 00:25:18.823 --> 00:25:21.023 and that's usually through some server-side action originally. 00:25:21.563 --> 00:25:27.623 So it could be that a bad actor worked their way into your website through a backdoor somewhere. 00:25:28.203 --> 00:25:31.883 But that could be anywhere. It could be an open-source thing that you use. 00:25:31.903 --> 00:25:36.503 It could be that your credentials as an admin were stolen, that they got into 00:25:36.503 --> 00:25:38.803 your GitHub, or whatever. It could be anything. 00:25:38.963 --> 00:25:42.463 They could have hijacked an S3 bucket of another dependency that you added. 00:25:43.203 --> 00:25:47.723 It's very hard to trace back. So my advice is when there is a client-side script 00:25:47.723 --> 00:25:49.583 on your website that you do not recognize. 00:25:51.843 --> 00:25:55.163 Unfortunately, if you're not using a tool like ours and actively monitoring 00:25:55.163 --> 00:25:59.483 it, it's probably not a bad idea to be very quick in removing a whole bunch of dependencies. 00:26:00.583 --> 00:26:06.083 It's a bit like when your breaker, your fuse in your house, like the main one 00:26:06.083 --> 00:26:11.083 turns off and you then have to go figure out on which cycle in your house there is a problem. 00:26:11.083 --> 00:26:14.503 You turn all of them off and then you turn them back on one by one by one by 00:26:14.503 --> 00:26:15.923 one and see when the problem gets back. 00:26:16.143 --> 00:26:18.983 That's an unfortunate truth about client-side security as well, 00:26:19.063 --> 00:26:21.743 because you don't really know where it's coming from. You're probably going 00:26:21.743 --> 00:26:22.643 to have to do big cleanup. 00:26:22.843 --> 00:26:27.763 And that could be anything from starting over again to turning it off and turning 00:26:27.763 --> 00:26:29.663 it on one by one by one and then getting rid of it. 00:26:29.943 --> 00:26:33.883 It actually gets worse with people using third-party marketing firms. 00:26:34.723 --> 00:26:38.923 We have seen this a lot where people add a Google Tag Manager script to their 00:26:38.923 --> 00:26:41.563 website to then give to their marketing people, 00:26:42.379 --> 00:26:45.759 and then those marketing people add a bunch of scripts. And then a year later, 00:26:46.119 --> 00:26:48.859 you switch to another marketing company and those scripts are still on your 00:26:48.859 --> 00:26:51.639 website and you don't have control over the Google Tag Manager. 00:26:51.899 --> 00:26:55.079 So the only thing you can do is remove the entire Google Tag Manager and then 00:26:55.079 --> 00:26:57.659 see what breaks and then add those back one by one. 00:26:58.039 --> 00:27:00.499 That's a very sad thing that happens a lot, right? 00:27:01.039 --> 00:27:04.139 Those types of things that is unfortunately part of the incident response. 00:27:04.279 --> 00:27:07.199 You have to sometimes just go all the way back to then add it one by one. 00:27:07.199 --> 00:27:12.059 Could you also, when we already talked about incident response here, 00:27:12.439 --> 00:27:17.259 the regulatory reporting, because in the event of a breach or issue involving 00:27:17.259 --> 00:27:20.279 the dynamic assets we talked about here, 00:27:20.779 --> 00:27:25.519 what timers and protocols should you be following to meet DORA? 00:27:26.319 --> 00:27:29.819 Yeah, that's sort of part of the reporting there I found very vague, 00:27:29.959 --> 00:27:33.619 right? Because they have all types of requirements regarding reporting and different things. 00:27:33.719 --> 00:27:38.399 Look, my perspective on any type of reporting here is act on the side of caution. 00:27:38.559 --> 00:27:41.499 As soon as you've noticed there's some type of incident, put out a public note, 00:27:41.979 --> 00:27:46.199 send out an email to every customer, tell them, hey, we're investigating an 00:27:46.199 --> 00:27:49.699 issue regarding a client-side script on our website or something like that, right? 00:27:50.419 --> 00:27:53.559 We'll be back with more information in the next 24 hours, 48 hours, whatever. 00:27:54.179 --> 00:27:57.279 You do your thing. You do your research, you explain what happened, 00:27:57.439 --> 00:28:01.039 and you just err on the side of caution by being incredibly transparent about it. 00:28:01.859 --> 00:28:04.919 I worked at Cloudsphere. Cloudsphere was great at that. If there was any type 00:28:04.919 --> 00:28:08.659 of downtime incident, which luckily during my time there, there weren't major 00:28:08.659 --> 00:28:12.419 security incidents, but a downtime incident, it's better to be very open about 00:28:12.419 --> 00:28:16.299 everything and put out your learnings and what you're going to fix in the future. 00:28:16.499 --> 00:28:20.559 That's just a good thing because as those blog posts exist, the shame also goes 00:28:20.559 --> 00:28:23.819 away and people can actually become more comfortable in improving their systems 00:28:23.819 --> 00:28:25.259 over time and being open about it. it. 00:28:25.959 --> 00:28:28.139 Unfortunately, that's not how most companies do things. 00:28:28.859 --> 00:28:32.019 And then, of course, these rules come into play to try and push people to work 00:28:32.019 --> 00:28:34.499 that way, but they probably will not either anyway. 00:28:35.359 --> 00:28:38.439 But yeah, I think the reporting side of things, especially when I read the Dora 00:28:38.439 --> 00:28:43.299 Act, I found it a little bit all over the place and very broad umbrella. 00:28:43.679 --> 00:28:47.699 And especially with a client side security incident, the investigation timeframe 00:28:47.699 --> 00:28:52.279 of it can be very long because it doesn't, it could be that that script just 00:28:52.279 --> 00:28:54.919 doesn't do the thing anymore that it did during the attack time. 00:28:55.959 --> 00:28:59.419 So it's very difficult to investigate. I see. 00:29:00.799 --> 00:29:04.699 You were talking about confidence, transparency here. 00:29:05.339 --> 00:29:12.399 My last question is, how can entrepreneurs effectively communicate their Dora compliance strategy? 00:29:12.619 --> 00:29:17.979 Particularly, would you talk about dynamic asset, third-party dependencies to 00:29:17.979 --> 00:29:20.899 build trust with either their existing or new investors? 00:29:20.899 --> 00:29:27.179 Because I do believe If you're going through a large funding round at one point, 00:29:27.319 --> 00:29:30.719 there'll be legal compliance and it'll also take a look into DORA. 00:29:31.685 --> 00:29:35.765 So my experience with these things is that you should not be trying to do these things manually. 00:29:36.585 --> 00:29:41.465 We personally use Vanta. There are solutions like Vanta or Drata or Sprinto, 00:29:41.585 --> 00:29:45.645 et cetera, that allow you to document your controls and frameworks that you apply those to. 00:29:45.885 --> 00:29:50.225 And then how you provide evidence to those. And then there's trust pages specifically for them. 00:29:50.645 --> 00:29:55.405 It's better to have those things documented and cleanly put out there. 00:29:55.405 --> 00:29:59.545 So that if you ever have to report on those because either a specific customer 00:29:59.545 --> 00:30:04.505 asks for it or because you need to do it for an investor's round or because 00:30:04.505 --> 00:30:07.225 of an insurance quotation or anything like that, 00:30:07.445 --> 00:30:10.485 it's just there. You shouldn't be treating this as a one-off. 00:30:11.465 --> 00:30:14.565 The old-fashioned method of using a spreadsheet probably works. 00:30:14.685 --> 00:30:17.405 I don't like it. And I'll tell you why. 00:30:17.945 --> 00:30:21.765 Even if the spreadsheet is collaborative, your customers are going to look at 00:30:21.765 --> 00:30:26.125 you weirdly if you provide them with an ugly, manually maintained spreadsheets. 00:30:27.025 --> 00:30:30.725 People have gotten quite used to going to trust.thecompany.com, right? 00:30:31.325 --> 00:30:35.045 And then just seeing all of the security reports there. It's a cleaner way to do it. 00:30:36.085 --> 00:30:40.765 Yeah, and then one of the things that I think is interesting for people to realize, 00:30:40.945 --> 00:30:45.305 and especially as a product person, this is really what the entire career is 00:30:45.305 --> 00:30:47.665 about. You have to understand there's different personas you talk to. 00:30:47.945 --> 00:30:51.665 When you talk to a security engineer or a security analyst or a CISO, 00:30:51.665 --> 00:30:54.385 So they're probably going to go to trusttaughtyourcompany.com, right? 00:30:55.625 --> 00:31:00.085 They will also notice that there's a security webpage on your website, right? 00:31:00.265 --> 00:31:04.425 That webpage is more to talk about your generalistic view, your non-technical, 00:31:04.565 --> 00:31:06.645 non-specific security compliance strategy. 00:31:07.185 --> 00:31:10.965 That's also a good thing to have. And so there's even in SOC 2, I think, 00:31:11.685 --> 00:31:15.425 I'm not sure if it's a requirement or a best practice, but having a page like 00:31:15.425 --> 00:31:20.365 that is very helpful just so that multiple people with some that are more comfortable 00:31:20.365 --> 00:31:23.645 or less comfortable with technology have the ability to go there. 00:31:24.105 --> 00:31:27.845 That was a really good interview. Thank you very much. 00:31:28.285 --> 00:31:35.045 Actually, we scheduled our interview to be just shy of 30 minutes to attach 00:31:35.045 --> 00:31:36.445 you to another interview. 00:31:36.625 --> 00:31:39.405 And now you've talked for more than 30 minutes. 00:31:39.925 --> 00:31:44.505 Great. Thank you very much. We link everything down here in the show notes, 00:31:44.665 --> 00:31:48.285 a YouTube talk that you did on Slush, your LinkedIn profile, 00:31:48.285 --> 00:31:51.745 your website, where there's also free to you, and of course, 00:31:51.945 --> 00:31:54.365 the Vintalink. Thank you very much for having me. 00:31:55.185 --> 00:31:57.005 My pleasure. Have a good day. Bye-bye. 00:32:01.905 --> 00:32:11.145 That's all, folks. Find more news, streams, events, and interviews at www.startuprad.io. 00:32:11.485 --> 00:32:13.665 Remember, sharing is caring. 00:32:14.320 --> 00:32:27.178 Music.