Welcome to StartupRad.io, your podcast and YouTube blog covering the German
startup scene with news, interviews and live events.
Hello and welcome everybody. This is Joe from StartupRad.io,
your startup podcast, YouTube blog and internet radio station from Germany,
Austria. What's the line bringing you the most news and important content from the region.
This time, I do have somebody as an expert, Simon here with me. Hey, how are you doing?
Hi. Simon here with me, who will be talking about some aspects of Dora.
Dora is important enough that we decided to have two episodes on it.
But don't worry, we're not going to pack them back to back. But we'll have two
episodes here on different areas of the DORA regulation.
Simon, before we get started, there is a little disclaimer.
This is no legal advice. The content of this interview is provided for informational
purposes only and does not constitute legal advice.
Neither the interviewer nor the guest are licensed attorneys.
The discussion is intended to offer our audience a framework to think about.
Some of the more technical aspects of the EU regulation called DORA,
Digital Operation Resilience Act.
We strongly encourage you to consult with qualified legal and compliance professionals
to address your specific requirements
and implementations of DORA as they pertain to your organizations.
Realize solely on information provided in this discussion could result in non-compliance
or other legal and regulatory risk.
Always seek professional guidance tailored to your unique circumstances.
Now that we have that out of the way, DORA is at the time of recording in force.
But as we talked before, the real enforcement, the real audit will only come next year.
And the people are really getting started how to handle this,
how to comply with the DORA Act.
Can you tell us a little bit about you, a little bit about the DORA Act before
we get into the subject where you are, the subject matter expert?
Sure. Then first of all, thanks for having me. Yeah. So my background,
I started my career at Microsoft at a young age.
I was 16 at the time, built my career, worked at Cloudflare for a while,
became a product manager there for more client-side related problems.
As I grew, like I was solution architect first, I was spending a lot of time
with customers and then I made it into my role, but more on the product side of things.
Then I worked at Vercel, built their security products for a while,
and then a small database company and came back to it.
So I recognized that as we spent a lot of money and time on protecting our infrastructure
by buying firewalls to protect the perimeter around our most critical assets.
Protecting and detecting network flows within our own virtual networks, et cetera,
and that we also monitor our open source dependencies through static registries
like Node Package Manager, we have totally forgot about a very big part of the
attack surface, and that's what's happening in the browser of the user when
they visit your website.
So I run a company called Seasite. We do client-side security.
So basically making sure that whatever happens in the browser of the user as
a result of your dependencies, your marketing tools, but also your own code
is safe and is not going to add
to a major compliance risk or potential downtime or issues in the future.
So I already see we will be talking about the browser here.
Is that what we've been talking about?
Well, so I think that the scope for why Dora is relevant in our field is more
because Dora talks about third-party services in a more broad concept.
And it also talks about actively monitoring things.
And so there's a lot of things happening currently in this space.
PCI DSS is requiring to monitor client-side dependencies.
And you may be wondering why. Well, because there were so many incidents for
the last 10 years where credit card skimming originated from the browser, right?
So thinking at the British Airways attack in 2018, a polyfill attack last year,
there's a lot of attacks that execute in the browser.
And the PCI, so the Payment Card Industry Digital Safety Standards,
the organization behind that PCI-SSE has recognized that the majority of credit
card skimming nowadays happens in the browser of a user.
So when we talk about, like, finally financial organizations and institutions
being pushed to have a more standardized security process, the client side is
really very actively in scope.
And even though the DORA Act is very broad, it is still actively saying things
like actively monitoring,
third-party dependency management, regardless of the attack surface,
whether it's server side or client side, this is your, like,
part of DORA. You need to monitor it.
So that's the scope here. We are not a browser company.
We don't build a secure browser. We're not a Zscaler or an island or anything like that.
We sell to companies who need to protect their online asset,
their website, and prevent it from performing attacks in browsers of users or
things like crypto mining or credit card skimming or login credential theft
or anything like that by any of the tools that they use.
The way you're here today is because, of course, it applies to the usual banks,
the usual insurance companies, but also the fintechs, all companies that are
related to payment and so on and so forth.
Therefore, I thought it was very interesting to have you here.
And as you said, I've been a consultant on capital markets for more than a decade.
And a lot of the cybersecurity, a lot of all the efforts were around the core systems.
Barely anybody talked about the website in terms of cybersecurity.
Here is something I do believe because we're also, as you said,
most of the theft of private information actually takes place.
And so I do believe it's an important piece here in the puzzle.
As we said, we'll be a little bit more specific here.
But my first question would be compliance readiness. what key steps need companies
to take to ensure compliance with DORA,
particularly when monitoring dynamic assets like a chatbot, like a capture system
to satisfy the authorities,
the auditors, and also, of course, your investors.
Because if you do have DORA trouble, your investors won't be happy.
Yeah, exactly. So, I mean, there's a lot of controls in DORA that overlap with
other frameworks people should already be familiar with.
So if you're ISO or you're SOC2 or your GDPR or PCI DSS, you're going to probably
already have a really significant chunk of it ticked. So that's a good thing.
I really looked at that DORA Act as an umbrella act that is just revisiting
the things we should already be doing.
When we talk specifically about third-party dependencies and their dynamic,
unfortunately, those have kind of faded into the background.
So a lot of these frameworks didn't call those out explicitly,
and you can also tell that therefore the majority of security solutions out
there that are targeting supply chain security, they don't actively monitor client-side scripts.
We, however, do, and we do it in a way that is difficult, but it's the only
right way to do it because this is a unique problem.
When you go to a website, you will get a response from a third-party server
that is outside of the control of that actual website that you visit.
So in the case of a chatbot, let's say you're going to a website and they're
using the intercom chatbot.
Well, your browser is making a request to the intercom server.
Well, God forbid, Intercom gets hacked, right? But there are so many of these
chatbot companies out there, some with more senior security people than others,
some with better protections than others.
The result is that there could very easily be an attack that target only a small
subset of people and therefore fly below the radar and make it very hard to detect.
To put that into a real-life example, what you could pull off with a third-party
JavaScript is an attack that targets 1% of users in France and then after office
hours, right, only, and then the week after move to 1% of visitors in North America.
Also after office hours, and then move to another area in the world and just fly below the radar.
Because if a security analyst were to use a tool that does static analysis,
that's not going to catch that dynamicness, right?
So the way that Seaside does this, and that's fundamentally different from what
we saw in the market, and that's also the reason why we started this as a business,
is we actually put ourselves in the middle.
So instead of you actually talking directly to these third-party services,
we put ourselves in the middle and we offer you complete observability.
So if somebody on an old Android phone goes to your website or somebody on a
modern MacBook goes to the website and they get different versions of that script,
which is often the case, we have all of that data.
We analyze it through an LLM. We analyze it through an attributes engine that we built in the house.
So we look for outliers in the behavior and how it has changed.
So if any of these scripts become malicious and things start behaving weirdly,
exfiltrating sensitive information, trying to get access to things it shouldn't
have, like session tokens, for instance.
That type of behavior we would very quickly flag. And this is directly a thing.
When you talk about active monitoring of third-party dependencies,
well, these third-party scripts you add to a website are third-party dependency.
Because they are dynamic, active monitoring is required.
Connect the dots, and there you go. That is a door requirement.
And this is already a requirement, I think, under many other frameworks,
but sometimes not as explicitly put forward.
So if you look at PCI DSS, it's an explicit requirement.
But under HIPAA, you can also expect the clauses regarding third-party security
to be in scope there. But yes.
We've been already getting a little bit ahead of ourselves. I want to talk about
monitoring of those, what you call, dynamic assets.
That's what I – the most advanced stuff I ever did was to write a little bit
in Tuber Pascal. So please excuse me here.
I'm not the technical guy, but this is also not the audience we're targeting
here. How do you monitor all this external stuff that you have,
for example, analytics, capture, newsletter, pop-up.
Chatbot, podcast player, radio player, something like this? How do you actively monitor?
Monitor those tools and what should the non-technical founders that are listening
to us right now or how should they think about it in terms of cyber security because,
I find it fascinating what you do here because that's also something that has
not popped up in all the discussions that I had around the topic.
It was more like the usual cyber attacks, really big things.
For example, University Clinic here in Frankfurt was almost digitally shut down due to cybertech.
That's the kind of stuff people are thinking about, not, for example, their website.
Yeah, I mean, the thing is we interact with most online things through a website.
Even if we don't realize it, a lot of mobile apps are actually websites under the hood.
Progressive web apps, PWA is a technical term for that, or web views.
It's essentially just a way for a developer to be able to build a thing in a
language they're confident with, right?
To build a website and it basically becomes a mobile app, right?
So more things have become browsers. We already interact with most things through
what is basically a browser.
And at the same time, we have not protected the browser. So the way that it
works, and this should be easy to do for people that are non-technical even,
if you can add that button or you can add that like podcast or that A-B testing
thing or that chatbot to your website,
It's exactly the same thing you would do to install our solution.
So we've got a couple of ways you can onboard, but the easiest is you just add
our script to the website as the first one to load and you go through those
other scripts you added and you put proxy.ccital.dev slash in front of them.
That's it. And now it flows through us.
So that code now comes through our systems.
There's another way that you can onboard and that's using basically a plugin
that you install, an NPM package.
It's basically just to put it more technically a CLI that would automatically
rewrite these scripts for you.
You don't have to do anything more than just installing a thing, that would be it.
In our dashboard you then see all of these scripts passing through us,
but autonomously we review those.
So the biggest clue that there is something going wrong is when notice these
scripts change and there's changes that are not consistent with the behavior
we'd expect from that script.
It is normal for scripts to change and they are very dynamic.
So as I explained earlier, if you have an old Android device,
you're probably going to get
a different version of a certain script than you will on a modern laptop.
That dynamicness of a third-party script is actually a big part of the feature
because it allows for those packages to be consistently working across very
different environments,
sometimes still even including Internet Explorer, right, which has been phased
out for so many people, but it's still a very small percentage of the internet.
I want to interrupt you, but do people actually still use Netscape?
Netscape, I have not come across in significant enough numbers,
but yeah, I mean, whatever device you currently have in front of you,
unless you keep it in your house forever, will eventually end up somewhere being
used by someone who's not as fortunate as us.
So recycling of devices, especially in corporate environments,
it has an incredibly long lifeline.
Old compact computers from 20 years ago are probably in use somewhere in the world, right?
Or either they get recycled or they make it all the way to Kenya, right?
So the result is that old legacy things that we in the Western world can't even
think about anymore, there's still a small percentage of the internet that use them.
Of course, then the attack surface is different, right? but still very relevant
to understand that backwards compatibility is something that with any modern
web application is not something to neglect.
And actually, this is a completely different thing to point out here,
but as I noticed my grandparents aging, we also have to understand that users
are also something that you shouldn't neglect backwards compatibility to.
That's not something that Dorak talks about at all, but as we all get older...
It's a very challenging way to say that. Yeah, I mean, if we all get older,
we have to also think about how our older people are going to understand this.
And this is the thing, like with these third party scripts, they are incredibly good at accessibility.
They are incredibly good at backwards compatibility. And that is because of
the dynamicness of them.
But that's also very problem-based. So like really the only way that you can
do proper client-side security is by having that stuff coming through you.
By our system analyzing it 100% of the time.
We, of course, hash it, right? So if the script is the same as it was before,
we will not do the very painful and heavy lifting of reanalyzing it.
If the hash is the same, we won't do it again.
If the hash is different, though, that's when we reanalyze it in its entirety.
And that then allows us to be quite confident in detections that we do.
Of course, as every security solution out there, we're always looking for things
we need to improve and detections that need to be added.
But we at least have all the data. We don't think any of our competitors have
the amount of data that we have.
And that's also partly to thank the fact that we have a free tier.
People can just sign up, use our products for free, and get a whole lot of visibility.
And that would then help everybody to be safer, right? Because a lot of these
scripts, they can even act differently depending on the website they are on.
So if there's an analytic script on a bank's website, where that same analytic
script is also on the local Baker's website, They can very easily make that
script behave differently on a bank website as it does on the local baker's website.
This is actually a very relevant thing to call out still.
Any website out there, how weird you may think it is, will probably have some
type of analytics tooling on it, including hospital websites.
And so Kaiser Permanente, a large American insurance company last year,
leaked all of their customers' healthcare information, all 13 million people's
healthcare data, to a third party through their client-side script.
And this was an honest mistake. They added the TikTok script to their website,
thinking this was just TikTok's normal US-use script.
It turned out to be the Chinese version, so the data was being sent to China.
That's obviously a big HIPAA no-no, and that then caused a big trouble there.
The problem is there's not enough governance around adding analytics tools to
websites or these types of third-party scripts.
And that's what these frameworks are trying to enforce.
And that's a good thing because it basically protects the end user.
Would you, again, for the non-technical entrepreneur,
help us to think a little bit what steps an entrepreneur should take,
thinking about vendor risk, third-party contracts, and really mapping the dependencies here?
Yes. So honestly, as a non-technical person, this is a very hard assessment
to make because they will not tell you whether the script is dynamic or not,
or whether there's other methods you can use yourself to install it that are safer.
So fortunately, there's a lot of trust you need to have there.
But I think if a non-technical person, the best thing you can do is make sure
that the tools you add to your website are being used by a significant portion of the internet.
And that those tools are built by companies with a staff that looks confident
and have a good security team.
There's a few ways you can go ahead and figure that out. So first of all,
if these scripts are being used on all of websites, there's this platform called public www.com.
I think it's .net or whatever.
You can type in the script in there and it will tell you how many websites also have that script.
If that script is on another 100,000 websites, you're probably going to be okay,
right? Because these companies, they have something to lose.
Then if you have a look at the website of that script and you have a look at
that tool and you see that they have a security center or a trust center,
go have a look at their certifications, see what certifications they have.
That probably will be a good indicator of them having good security compliance on their site.
So then that particular vendor, you're probably okay adding to your website.
However, the best thing you can do, and this is just because you don't know
what those people then trust, there's third-party dependencies on their side,
one script calls, another script calls, another script.
Honestly, the best thing you can do, and I hate to sound like a marketing guy, but it's.
Use our free tier because there's no other way to get the visibility because
it's happening outside of your field of vision in the browser of your visitor.
And that visitor can get a different thing than you get on your site.
So there really is only that. That's the real reason why I wanted to build this
thing. I didn't find any other way to do it.
I'm thinking now about mapping those dependencies in terms of one connection as a lag.
How many of those connections, how many degrees, how many of those lags have you found?
Or do you usually find how many dependency, codependency, and so on and so forth
do you usually see there? It really depends.
So if you have, for instance, let's say you're, and this is a bit outside of
the scope of Dora, right? Well, actually, we can make this about Dora.
Let's say you're an insurance broker and you have an iframe on your webpage to book an appointment.
And that tool that you added, that iframe, or I don't know, it could be a widget,
right? Does third-party fetches to other things?
It could very easily end up with a long list.
So we saw this with, for instance, a little hotel booking widget that people
add to their hotel's website so that when you're a hotel owner,
you add this thing and they can book it through that.
Well, that thing was calling like 50 other dependencies, right?
So it was calling jQuery through a CDN, this thing through a CDN,
that thing through a CDN, calling third-party assets here, there,
and everywhere, adding analytics to it, even adding A-B testing to that widget
because, of course, they're also looking to improve their product.
And then those A-B testing things, they called up other stuff,
it can become a very significant tree.
So I've seen personally more than 50 of these dependencies on some scripts.
Many of them are nice to themselves and only have one JavaScript file and no sub-dependencies.
It really could be anything, right? And the problem is you will only really
know when you start analyzing these things yourself, either manually or using a tool like us.
And even when you're using a tool like us, you will see that it will largely
differ, especially with A-B testing.
If they then fetch a version and that version has more things to it,
then it's going to be different across different browsers.
There's a lot of noise here. So it's very hard. I can't just say normally it's 40.
That's not how it works. It could be a very broad spectrum.
I see. We will be back with you guys shortly after the break for our sponsor.
Okay. Welcome back. I have Simon here still with me talking about the more technical aspects,
especially in the browser of your company client-facing that falls under the DORA Act.
When I was thinking about this,
what is the average number of third-party dependencies you usually see?
Because when you've been talking about a booking, a little booking app,
a chatbot, a player, and I think I have at least 20 of them on my website and
I don't even want to think about mapping them out.
Yeah. So, I mean, the average I have seen from the websites that we crawl and
that we have as our customer base is 53.
You will find varying numbers about this, But it's very common for a commercial
business with all types of pages and projects, et cetera, on their website to
have a very broad scope of these, right?
So you've got the analytics tools and a chatbot for support and the testing
for legal and that pixel for engineering and A-B testing for that.
And the marketing team has a podcast widget and all that stuff, right?
Before you know it, you've got 53. And I think that that number will not really
go down because it's funny when people tell me, oh, aren't third-party scripts
on the way out? Well, no, because there will always be a reason for client-side dynamicness.
And that will never be replaced by just an NPM package because they're still
going to fetch it in the browser anyway.
And that's another thing. If you install a dependency through something like
Node Package Manager, which if you're an engineer, you definitely know,
but as a non-technical person, it's just a marketplace of open source stuff you can add to a website.
And now all of a sudden you have access to this big library of cool stuff.
Well, those can do client-side fetches.
That's not really solving anything because the client-side fetch is still there.
In fact, actually, the thing that I find interesting about this attack factor
is that even people that are non-technical, that are putting their faith in
tools like WordPress, etc., well, we see a significant amount of client-side
attacks coming through WordPress,
especially through old themes.
So those old dashboard themes that people use to build a pretty website.
Yeah, if those people don't maintain those and some bad actor manages to get
a hold of them, they will add malicious JavaScript to them.
Before you know it, you've got an attack happening that way.
Just like early in January, we spotted 5,000 websites were impacted through that.
That's an, of course, significant amount of websites, but for WordPress,
well, there's many millions of WordPress websites, but still 5,000 websites
is quite a big deal. You could do a lot of very, very...
Dumb stuff with all the data you get there. We've been talking about incidents
here and there, talking about incident management and reporting here.
How should they design the incident response process to address the issues that
are stemming from the browser-based user interactions and ensure that they are
doing Dura-compliant reporting here?
Yeah, so my advice is regarding any type of client-side dependency that you
add to keep track of when you added it and what state it was at the time, right?
And then also makes it easier to understand, okay, at that date,
we added that script, and then we saw a jump in sub-dependencies that were also
added to the website as a result of that script.
It makes it easier to trace back if there's an incident.
The unfortunate thing about client-side security is if we see an attack at scale
on a whole bunch of websites, it's sometimes not clear to us where it originated
from because, I mean, the client-side code made it into the code,
and that's usually through some server-side action originally.
So it could be that a bad actor worked their way into your website through a backdoor somewhere.
But that could be anywhere. It could be an open-source thing that you use.
It could be that your credentials as an admin were stolen, that they got into
your GitHub, or whatever. It could be anything.
They could have hijacked an S3 bucket of another dependency that you added.
It's very hard to trace back. So my advice is when there is a client-side script
on your website that you do not recognize.
Unfortunately, if you're not using a tool like ours and actively monitoring
it, it's probably not a bad idea to be very quick in removing a whole bunch of dependencies.
It's a bit like when your breaker, your fuse in your house, like the main one
turns off and you then have to go figure out on which cycle in your house there is a problem.
You turn all of them off and then you turn them back on one by one by one by
one and see when the problem gets back.
That's an unfortunate truth about client-side security as well,
because you don't really know where it's coming from. You're probably going
to have to do big cleanup.
And that could be anything from starting over again to turning it off and turning
it on one by one by one and then getting rid of it.
It actually gets worse with people using third-party marketing firms.
We have seen this a lot where people add a Google Tag Manager script to their
website to then give to their marketing people,
and then those marketing people add a bunch of scripts. And then a year later,
you switch to another marketing company and those scripts are still on your
website and you don't have control over the Google Tag Manager.
So the only thing you can do is remove the entire Google Tag Manager and then
see what breaks and then add those back one by one.
That's a very sad thing that happens a lot, right?
Those types of things that is unfortunately part of the incident response.
You have to sometimes just go all the way back to then add it one by one.
Could you also, when we already talked about incident response here,
the regulatory reporting, because in the event of a breach or issue involving
the dynamic assets we talked about here,
what timers and protocols should you be following to meet DORA?
Yeah, that's sort of part of the reporting there I found very vague,
right? Because they have all types of requirements regarding reporting and different things.
Look, my perspective on any type of reporting here is act on the side of caution.
As soon as you've noticed there's some type of incident, put out a public note,
send out an email to every customer, tell them, hey, we're investigating an
issue regarding a client-side script on our website or something like that, right?
We'll be back with more information in the next 24 hours, 48 hours, whatever.
You do your thing. You do your research, you explain what happened,
and you just err on the side of caution by being incredibly transparent about it.
I worked at Cloudsphere. Cloudsphere was great at that. If there was any type
of downtime incident, which luckily during my time there, there weren't major
security incidents, but a downtime incident, it's better to be very open about
everything and put out your learnings and what you're going to fix in the future.
That's just a good thing because as those blog posts exist, the shame also goes
away and people can actually become more comfortable in improving their systems
over time and being open about it. it.
Unfortunately, that's not how most companies do things.
And then, of course, these rules come into play to try and push people to work
that way, but they probably will not either anyway.
But yeah, I think the reporting side of things, especially when I read the Dora
Act, I found it a little bit all over the place and very broad umbrella.
And especially with a client side security incident, the investigation timeframe
of it can be very long because it doesn't, it could be that that script just
doesn't do the thing anymore that it did during the attack time.
So it's very difficult to investigate. I see.
You were talking about confidence, transparency here.
My last question is, how can entrepreneurs effectively communicate their Dora compliance strategy?
Particularly, would you talk about dynamic asset, third-party dependencies to
build trust with either their existing or new investors?
Because I do believe If you're going through a large funding round at one point,
there'll be legal compliance and it'll also take a look into DORA.
So my experience with these things is that you should not be trying to do these things manually.
We personally use Vanta. There are solutions like Vanta or Drata or Sprinto,
et cetera, that allow you to document your controls and frameworks that you apply those to.
And then how you provide evidence to those. And then there's trust pages specifically for them.
It's better to have those things documented and cleanly put out there.
So that if you ever have to report on those because either a specific customer
asks for it or because you need to do it for an investor's round or because
of an insurance quotation or anything like that,
it's just there. You shouldn't be treating this as a one-off.
The old-fashioned method of using a spreadsheet probably works.
I don't like it. And I'll tell you why.
Even if the spreadsheet is collaborative, your customers are going to look at
you weirdly if you provide them with an ugly, manually maintained spreadsheets.
People have gotten quite used to going to trust.thecompany.com, right?
And then just seeing all of the security reports there. It's a cleaner way to do it.
Yeah, and then one of the things that I think is interesting for people to realize,
and especially as a product person, this is really what the entire career is
about. You have to understand there's different personas you talk to.
When you talk to a security engineer or a security analyst or a CISO,
So they're probably going to go to trusttaughtyourcompany.com, right?
They will also notice that there's a security webpage on your website, right?
That webpage is more to talk about your generalistic view, your non-technical,
non-specific security compliance strategy.
That's also a good thing to have. And so there's even in SOC 2, I think,
I'm not sure if it's a requirement or a best practice, but having a page like
that is very helpful just so that multiple people with some that are more comfortable
or less comfortable with technology have the ability to go there.
That was a really good interview. Thank you very much.
Actually, we scheduled our interview to be just shy of 30 minutes to attach
you to another interview.
And now you've talked for more than 30 minutes.
Great. Thank you very much. We link everything down here in the show notes,
a YouTube talk that you did on Slush, your LinkedIn profile,
your website, where there's also free to you, and of course,
the Vintalink. Thank you very much for having me.
My pleasure. Have a good day. Bye-bye.
That's all, folks. Find more news, streams, events, and interviews at www.startuprad.io.
Remember, sharing is caring.
Music.