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:13.040 --> 00:00:18.960
Music.
00:00:19.877 --> 00:00:23.717
Hello and welcome everybody. This is Joe from StartupRad.io,
00:00:23.957 --> 00:00:27.837
your startup podcast, YouTube blog and internet radio station from Germany,
00:00:27.957 --> 00:00:28.937
Austria and Switzerland.
00:00:28.937 --> 00:00:35.177
Today, I do have another expert interview with you, talking about Dora again.
00:00:35.597 --> 00:00:41.457
We have been in the past hearing one guest who was talking about third-party
00:00:41.457 --> 00:00:44.457
assets on your website that you need to take care of.
00:00:44.797 --> 00:00:49.417
This time, I do have Giles here as a guest. Hey, how are you doing?
00:00:50.437 --> 00:00:54.857
Hi, nice to see you. Thanks for having me on. Totally my pleasure.
00:00:54.857 --> 00:01:00.337
You are Director of Services EMEA at NetSpy, and we will be talking a little
00:01:00.337 --> 00:01:03.957
bit broader about DORA and what you should do.
00:01:04.117 --> 00:01:07.937
I do have a few questions to guide you through this interview,
00:01:07.997 --> 00:01:10.957
and hopefully it will be very useful for everybody of us.
00:01:11.077 --> 00:01:16.217
But before we get started, can you introduce yourself a little bit to our audience?
00:01:16.357 --> 00:01:19.917
Keep in mind, most people will just listen to us. Of course.
00:01:20.237 --> 00:01:26.517
So I'm Giles, and I look after a number of different testing services.
00:01:26.697 --> 00:01:29.337
So I am a security tester. And
00:01:29.337 --> 00:01:33.837
before that, involved in IT infrastructure for a long time in my career.
00:01:34.317 --> 00:01:39.157
So in terms of my profession now, what I do is something called red teaming.
00:01:39.357 --> 00:01:42.617
And that is an expression of
00:01:42.617 --> 00:01:47.157
security testing. it's essentially organization-wide resiliency testing.
00:01:47.357 --> 00:01:54.657
And it's the type of testing that sort of DORA asks us to undertake and Tiber2
00:01:54.657 --> 00:01:57.237
and other frameworks, things like CBEST, for instance, in the UK,
00:01:57.517 --> 00:01:59.177
and other frameworks globally.
00:02:00.057 --> 00:02:06.177
It is essentially, for want of a better way of putting it, I'm a hacker, but in a good way. Yeah.
00:02:08.094 --> 00:02:13.994
You are, can you say, an ethical hacker? Correct. Yes, absolutely. An ethical hacker.
00:02:15.354 --> 00:02:18.774
I see. So today we're talking about DORA.
00:02:18.974 --> 00:02:23.914
No, it's not a first name of a lady. It's the Digital Operational Resilience
00:02:23.914 --> 00:02:26.034
Act from the European Union.
00:02:27.774 --> 00:02:35.234
And before we do get started, right now, it's already in force.
00:02:35.234 --> 00:02:39.554
But we do know the way bureaucracy work.
00:02:41.414 --> 00:02:44.994
Likely next year, the first checks will be done by authorities,
00:02:45.194 --> 00:02:46.774
by auditors, and so on and so forth.
00:02:46.914 --> 00:02:52.554
So this is the time to really get your stuff done, to really get down to business.
00:02:52.934 --> 00:02:56.774
If you appear or think you have some holes in there.
00:02:56.774 --> 00:03:02.774
And for this reason, we go a little bit broadly over the whole regulation and
00:03:02.774 --> 00:03:08.574
tell you potential places where you may have to work on before you get audited.
00:03:09.574 --> 00:03:13.194
Should we start with government and risk management?
00:03:14.234 --> 00:03:19.874
Please. Governance structure. Have I established a clear governance framework
00:03:19.874 --> 00:03:25.794
for digital operational resilience and are roles and responsibilities well defined?
00:03:25.794 --> 00:03:28.394
And that is a pretty interesting question.
00:03:28.414 --> 00:03:33.534
And what kind of answer should an entrepreneur have except for yes, of course?
00:03:36.634 --> 00:03:42.894
Yeah, that's a really interesting one. I think it's about the evidence base
00:03:42.894 --> 00:03:44.514
and the rationale behind it.
00:03:44.574 --> 00:03:48.814
And I think that's the kind of some of the core aspect to this.
00:03:48.814 --> 00:03:54.914
So if you can prove the rationale of that structure and sort of why you've made
00:03:54.914 --> 00:03:57.294
the choices that you have, I think that's a key component of it.
00:03:58.974 --> 00:04:02.774
Reasoning behind things, if that makes sense. It's not just the process,
00:04:02.774 --> 00:04:05.954
and I think that's one of the things that is critical to this.
00:04:06.134 --> 00:04:09.674
It's about the reasoning for the process and sort of the evaluation,
00:04:09.914 --> 00:04:11.374
the showing you're working, if you will.
00:04:11.674 --> 00:04:14.534
But I think this is really trying to prize out, if that makes sense.
00:04:14.534 --> 00:04:18.414
So that means if an auditor asks you, why did you do that?
00:04:18.554 --> 00:04:23.474
You should have a pretty good reason. But I do believe most will have thought
00:04:23.474 --> 00:04:26.034
it through at this point.
00:04:26.374 --> 00:04:33.294
Then we're talking about risk management strategy, having a comprehensive risk
00:04:33.294 --> 00:04:38.714
management framework to address all potential ICT risks.
00:04:38.714 --> 00:04:44.334
Can you first tell us a little bit what ICT risks are and then what you would
00:04:44.334 --> 00:04:51.354
expect from such a risk management strategy if you would look at it from an outside perspective?
00:04:51.714 --> 00:04:53.834
So I think there is a...
00:04:54.917 --> 00:04:58.677
A significant amount of this that is kind of understanding your organization
00:04:58.677 --> 00:05:03.777
and sort of where you sit within the market, where you intend to be in sort
00:05:03.777 --> 00:05:05.657
of three, five, ten years time, for instance,
00:05:05.977 --> 00:05:10.737
and sort of where you need to integrate to be able to understand what those risks might be.
00:05:11.777 --> 00:05:15.377
The component parts of your business and what keeps you operational is really important.
00:05:15.557 --> 00:05:19.177
You know, what are the cogs that keep the business turning from an IT perspective,
00:05:19.177 --> 00:05:23.157
the critical, important functions, to use the sort of the terminology there?
00:05:23.157 --> 00:05:29.637
These are the component parts of the business that you absolutely must keep
00:05:29.637 --> 00:05:30.857
running and operational.
00:05:31.117 --> 00:05:37.197
And that's why operational resiliency is a big part of this risk management approach, if you will.
00:05:38.877 --> 00:05:42.897
Actually, funny thing in German, it's called information and communications
00:05:42.897 --> 00:05:48.157
technology, information and communications technology, IKT-risiko.
00:05:48.377 --> 00:05:53.257
So that should give a little bit more hint about that. but please go on.
00:05:53.417 --> 00:05:59.877
The approach in terms of the strategy and the vision is you have to understand
00:05:59.877 --> 00:06:05.037
all of your assets that form part of that ICT estate and the processes and components
00:06:05.037 --> 00:06:06.717
and the human element as well, if you will,
00:06:06.777 --> 00:06:09.777
that go into that to be able to drive the business.
00:06:10.717 --> 00:06:15.177
And that accurate mapping of it is essentially the most fundamental component
00:06:15.177 --> 00:06:18.477
of that strategy, if you will. Yes, sure.
00:06:20.097 --> 00:06:22.197
Risk-venture framework, when
00:06:22.197 --> 00:06:28.397
would it be comprehensive to address all potential ICT risk? Thank you.
00:06:31.016 --> 00:06:35.216
Without understanding your entire estate and all of your ICT systems and the
00:06:35.216 --> 00:06:37.796
usage of them and sort of how they integrate to the business,
00:06:37.836 --> 00:06:42.196
it's an incredible challenge to be able to make it complete.
00:06:42.696 --> 00:06:48.056
So a strong asset inventory or a strong understanding of your own ICT systems
00:06:48.056 --> 00:06:52.676
is critical to be able to understand the risk to them or the potential risk to them.
00:06:53.316 --> 00:06:59.536
I have one question. You said it's important to have like overall overview.
00:06:59.536 --> 00:07:04.936
I do believe a lot of people tend to forget one or two tools.
00:07:05.376 --> 00:07:12.456
Do you have any experience where people usually forget some ICT assets,
00:07:12.656 --> 00:07:16.436
meaning physical or digital tools, software, IT?
00:07:17.736 --> 00:07:24.156
Yeah. So I think shadow IT as a concept is something that people talk often
00:07:24.156 --> 00:07:29.176
about, which is parts of the infrastructure that have been sort of created dynamically
00:07:29.176 --> 00:07:31.296
or by individuals or users that are unknown.
00:07:31.476 --> 00:07:36.516
And I think that's one of the key missing elements from a lot of people's asset inventories.
00:07:36.676 --> 00:07:40.256
So you have to have an element that is through known mechanisms,
00:07:40.436 --> 00:07:44.436
things like sort of databases that you might have of assets that exist already.
00:07:44.536 --> 00:07:47.696
But you also need to have the ability to dynamically map them and to be able
00:07:47.696 --> 00:07:53.716
to dynamically understand the component technology assets of your business on a continuous basis.
00:07:53.716 --> 00:07:59.696
So there are a number of sort of platforms and sources and tools that aim to
00:07:59.696 --> 00:08:04.416
do that dynamically and to varying degrees of success in the market.
00:08:04.656 --> 00:08:09.336
But doing an evaluation of those as part of your component infrastructure and
00:08:09.336 --> 00:08:14.216
looking at the efficacy of those is is a really important task as part of this
00:08:14.216 --> 00:08:18.476
kind of this overall framework development is you need to be able to assess the tools you use.
00:08:18.656 --> 00:08:22.116
In fact, it kind of almost the next level, if you will, that assess how you
00:08:22.116 --> 00:08:29.316
work. It's a bit of a non-answer almost sometimes, but the approach...
00:08:33.105 --> 00:08:36.865
You need to be able to know what you don't know and how do you quantify that?
00:08:36.985 --> 00:08:40.785
And I think that's the tricky question here is how do you map the unknown and
00:08:40.785 --> 00:08:43.785
how do you rate a tool that allows you to do that?
00:08:44.225 --> 00:08:48.465
Often people lean into things like SaaS platforms that sort of offer a,
00:08:48.545 --> 00:08:51.285
for want of a better way, a magical solution to these problems.
00:08:51.505 --> 00:08:56.745
I think validation and checking and due diligence, again, another core concept
00:08:56.745 --> 00:09:00.385
of this act and what it tries to instill, key components of that.
00:09:00.385 --> 00:09:06.025
So you need to make sure that you are checking and validating the software that
00:09:06.025 --> 00:09:11.345
you use, even that you use to understand your business and evaluate itself, if that makes sense.
00:09:12.245 --> 00:09:15.705
So you shouldn't have any freelancers who
00:09:15.705 --> 00:09:19.005
do have developed proprietary tool they transfer
00:09:19.005 --> 00:09:22.025
data and then put it back into your system that that's the
00:09:22.025 --> 00:09:28.085
kind of risk we're talking about plus getting your data into a third-party software
00:09:28.085 --> 00:09:36.145
and not be aware of that do you have because this shadow it is always a pretty
00:09:36.145 --> 00:09:39.945
difficult topic especially to figure out Oh,
00:09:40.525 --> 00:09:44.725
if you have something like that, I once talked to a guest and they say,
00:09:44.825 --> 00:09:48.345
yeah, look at the company credit card bills.
00:09:48.805 --> 00:09:52.525
If there's software charge, that could be a good hint.
00:09:53.005 --> 00:09:59.385
Do you have any other ideas, suggestions how somebody may find,
00:09:59.665 --> 00:10:07.965
may learn more about potential shadow software where they could find hints about it?
00:10:08.655 --> 00:10:13.395
Yeah, there are elements. So some of this might be externally facing,
00:10:13.535 --> 00:10:15.875
for instance, so internet facing and available to the public,
00:10:15.895 --> 00:10:17.175
and you may not be aware of it.
00:10:17.295 --> 00:10:20.935
So there are tools and techniques and processes that you can do to dynamically
00:10:20.935 --> 00:10:27.075
scan and to sort of search for assets that might be linked to your business in some way.
00:10:27.775 --> 00:10:30.775
You know products like this are often called things like attack surface mapping for
00:10:30.775 --> 00:10:33.495
instance these are what they aim
00:10:33.495 --> 00:10:37.755
to do is look for traces of your organization externally so then that you can
00:10:37.755 --> 00:10:42.255
take sort of reparatory action or some form of action to investigate where they
00:10:42.255 --> 00:10:45.875
may have come from what the background might be credit card data is in fact
00:10:45.875 --> 00:10:50.015
quite an interesting one because company assets company finance are tracked
00:10:50.015 --> 00:10:52.955
already in a lot of organizations so that gives you that audit trail.
00:10:53.615 --> 00:10:59.695
Other sources of data, things like in the sort of the computer sort of identity
00:10:59.695 --> 00:11:03.695
sense, for instance, things like cloud services will hold databases of users.
00:11:03.855 --> 00:11:06.975
Perhaps you can track what those users, what resources they're creating.
00:11:07.195 --> 00:11:10.855
The same for sort of on-premise systems like Active Directory, for instance.
00:11:11.415 --> 00:11:14.955
Those are means by which you can have a look at what resources are being spun
00:11:14.955 --> 00:11:17.135
up, but that's not dynamic. That's fairly static.
00:11:23.035 --> 00:11:26.315
The regulation talks about ICT risk
00:11:26.315 --> 00:11:30.215
assessment how frequently should
00:11:30.215 --> 00:11:35.655
you do that and how I mean there are of course different methodologies but how
00:11:35.655 --> 00:11:43.675
would you go about figuring out what methodology one should use that's an interesting
00:11:43.675 --> 00:11:49.315
uh an interesting topic um you have to assess it Again, I think that's a really important thing.
00:11:49.415 --> 00:11:52.555
And I think this is kind of, again, this is the territory of non-answer again,
00:11:52.715 --> 00:11:54.815
where you're expected to do
00:11:54.815 --> 00:11:57.215
the due diligence, but often there's not a great deal of guidance on it.
00:11:57.335 --> 00:12:00.335
And to be able to prove and validate that and argue the case for it,
00:12:00.335 --> 00:12:03.955
again, is one of the key things. But in terms of the.
00:12:04.793 --> 00:12:08.113
In terms of the sort of the way that you manage that due diligence on third
00:12:08.113 --> 00:12:11.253
party suppliers, existing and new ones, a lot of organizations.
00:12:11.473 --> 00:12:17.653
For instance, that I've spoken to are re-evaluating contracts as a result of this act.
00:12:17.793 --> 00:12:22.193
So that's kind of a one-time monolithic sort of evaluation of those organizations
00:12:22.193 --> 00:12:25.333
and how they treat their own security as part of that supply chain risk piece.
00:12:25.333 --> 00:12:30.573
But also when you are updating or changing contracts or when you are refreshing
00:12:30.573 --> 00:12:35.733
service contracts with those organizations, that's when you should be doing this assessment,
00:12:35.893 --> 00:12:40.273
for instance, or at least on a yearly basis or an annual basis to make sure
00:12:40.273 --> 00:12:42.873
that you are regularly reviewing and revisiting them.
00:12:42.993 --> 00:12:48.133
And I think the review and revisit is another core component to this is you
00:12:48.133 --> 00:12:53.593
can't treat something as trusted if you've done this forever, if you know what I mean.
00:12:53.593 --> 00:12:56.893
So if you've done your due diligence once, that doesn't mean that that due diligence
00:12:56.893 --> 00:13:00.253
continues year after year, year after year.
00:13:00.393 --> 00:13:03.313
Organizations can become insecure that you deal with as a supplier,
00:13:03.413 --> 00:13:05.193
for instance, over the course of their lifetime.
00:13:05.393 --> 00:13:08.513
So what you need to be doing is making sure that you're continuously checking
00:13:08.513 --> 00:13:13.533
those, understanding their downstream processes for sort of how they manage
00:13:13.533 --> 00:13:17.653
their own vulnerabilities, their own risk management approaches, their own processes.
00:13:17.653 --> 00:13:21.333
And that's one of the big challenges around this
00:13:21.333 --> 00:13:27.053
act is organizations are now presented with how do they present information
00:13:27.053 --> 00:13:33.633
about how and where they are vulnerable to their clients without giving away
00:13:33.633 --> 00:13:36.433
data that is sensitive or controlled under other legislation,
00:13:36.593 --> 00:13:37.913
things like GDPR, for instance.
00:13:38.173 --> 00:13:43.673
And that's a very tricky question to get an accurate and clear answer on.
00:13:43.753 --> 00:13:46.513
And I think that's been one of the challenges for organizations trying to solve this.
00:13:47.833 --> 00:13:53.533
When we're talking about DORA here we're talking about incident reporting and
00:13:53.533 --> 00:14:00.793
management can you help us to understand this field first step how do you,
00:14:01.660 --> 00:14:05.160
identify an incident. What is the level?
00:14:06.060 --> 00:14:09.820
Again, it's a little bit subjective here. When is it an incident?
00:14:11.020 --> 00:14:14.460
Yeah, absolutely. So you have to need to have a reasonable level of confidence
00:14:14.460 --> 00:14:19.460
that this is a operationally affecting incident, cyber security or otherwise.
00:14:19.700 --> 00:14:23.800
So, you know, for instance, the one that a lot of people lean towards is cyber
00:14:23.800 --> 00:14:26.140
security incident or a breach, for instance.
00:14:26.740 --> 00:14:31.980
You need to have a good degree of confidence of that is a genuine breach,
00:14:32.120 --> 00:14:34.400
for instance, and be able to report that as soon as possible,
00:14:34.640 --> 00:14:36.020
ideally within 24 hours.
00:14:36.220 --> 00:14:42.000
So you need to have a strong ability to respond to these types of events and
00:14:42.000 --> 00:14:47.120
identify them, triage them, and treat them as quickly as possible, i.e.
00:14:47.240 --> 00:14:50.060
Identify them as quickly as possible. And then you've got a responsibility at
00:14:50.060 --> 00:14:54.240
that point to do the notification process and follow through the rest of your
00:14:54.240 --> 00:14:55.880
incident response plan.
00:14:56.140 --> 00:14:59.180
And that can vary depending on what type of incident you face.
00:14:59.600 --> 00:15:05.560
So in a lot of breaches, for instance, you see things like ransomware affecting organizations.
00:15:06.300 --> 00:15:12.380
That type of breach is very, very fast moving, typically, in the market for a lot of organizations.
00:15:12.980 --> 00:15:17.800
So there's a real challenge with the timing of being able to identify something
00:15:17.800 --> 00:15:21.480
like this, respond to it, and sort of recover from it, as well as going through
00:15:21.480 --> 00:15:23.240
the notification process at the same time.
00:15:23.240 --> 00:15:27.380
And I think that's where we'll see a real stretch for organizations to meet
00:15:27.380 --> 00:15:28.360
that compliance standard.
00:15:28.600 --> 00:15:34.900
How do you show that you can do the identification process and adapt and prevent
00:15:34.900 --> 00:15:36.220
and recover from a threat at
00:15:36.220 --> 00:15:39.540
the same time, for instance? So it's a really tricky thing to get right.
00:15:40.480 --> 00:15:44.200
It needs to be documented. You need to be able to, again, justify it.
00:15:44.260 --> 00:15:49.400
You need to be able to talk about why you believe that the method and approach
00:15:49.400 --> 00:15:50.640
that you're using is appropriate.
00:15:50.640 --> 00:15:54.920
Because when you come to audit, you will need to go through that process.
00:15:54.920 --> 00:15:58.360
You will need to meet the challenge of, you know, these questions being asked
00:15:58.360 --> 00:16:00.600
of your organizations and why you've chosen that.
00:16:00.780 --> 00:16:06.300
If you don't have a robust set of evidence behind it, about behind why you've
00:16:06.300 --> 00:16:09.580
made the choices, then there is a high likelihood that, you know,
00:16:09.660 --> 00:16:11.380
you'll need to take some measure afterwards.
00:16:11.540 --> 00:16:16.980
So if you've got good justification, you may well have to take less action to
00:16:16.980 --> 00:16:20.660
sort of get up to the right standard for next year and years after that.
00:16:20.780 --> 00:16:23.580
So the improvement plan will be much reduced, if you will.
00:16:24.419 --> 00:16:32.899
I see. We've been talking about communicate, communication, reporting of incidents,
00:16:33.199 --> 00:16:36.119
of course, to the relevant authorities and the stakeholders.
00:16:36.219 --> 00:16:39.579
But what kind of channels would you use?
00:16:39.659 --> 00:16:44.819
Because I do believe it's not secure enough and not sufficient to just send
00:16:44.819 --> 00:16:47.119
an email. Hey, guys, look at this. Something happened.
00:16:48.459 --> 00:16:52.979
Yeah, absolutely. So in these types of incidents, especially in a cybersecurity
00:16:52.979 --> 00:16:55.579
incident where the systems you
00:16:55.579 --> 00:16:58.639
use to actually send those emails may be compromised in and of themselves,
00:16:58.999 --> 00:17:05.939
there is a balance between sort of using the systems that are breached and some
00:17:05.939 --> 00:17:07.799
other out-of-band method, like
00:17:07.799 --> 00:17:11.879
a telephone call or an SMS or a reporting platform or something similar.
00:17:11.879 --> 00:17:17.699
So some nations, for instance, will have direct report that you can do through
00:17:17.699 --> 00:17:18.659
a website, for instance.
00:17:18.979 --> 00:17:24.299
Those are methods that are often used. If you are in a market that is heavily
00:17:24.299 --> 00:17:31.679
regulated already, you will often have a contact or a representative or an agency, if you will,
00:17:31.699 --> 00:17:38.959
or a TCT in the sort of the Tiber terms that you would make contact with.
00:17:39.019 --> 00:17:40.779
So you would have a familiar contact normally.
00:17:41.879 --> 00:17:46.179
Typically, they would be a first point or a local law enforcement agency if it's relevant as well.
00:17:47.719 --> 00:17:55.759
That's a tricky one with the balance of sort of when and where you are allowed
00:17:55.759 --> 00:17:56.639
to do that in some regions.
00:17:56.799 --> 00:17:59.519
But I won't go too far into that because there be dragons.
00:18:02.579 --> 00:18:06.739
Plus, we're just trying to provide here a high-level summary for the audience
00:18:06.739 --> 00:18:12.579
that they can start thinking about. But where may they be a weakness not to
00:18:12.579 --> 00:18:14.619
be found in your first audit?
00:18:14.799 --> 00:18:19.519
Because that's what everybody wants to avoid. And that's why we are here and talking today.
00:18:20.979 --> 00:18:25.559
I would like to go a little bit over to the topic of third-party risk management.
00:18:25.779 --> 00:18:32.339
You've been already talking about adjusting the contract with vendors here.
00:18:35.679 --> 00:18:41.819
I'm pretty confident everybody now has already the class, the, the, the, the, um,
00:18:42.864 --> 00:18:49.104
the required criteria in their evaluation,
00:18:49.584 --> 00:18:57.884
third-party ICT providers, and so on and so forth, how would you proceed with existing vendors,
00:18:58.904 --> 00:19:05.484
that may be a little bit late to come by or promise something and didn't deliver
00:19:05.484 --> 00:19:11.184
yet because that's a problem for you and not necessarily for them? Absolutely.
00:19:12.504 --> 00:19:16.764
So there is guidance to say that you need to have good termination procedures
00:19:16.764 --> 00:19:18.044
in place as well, for instance.
00:19:18.284 --> 00:19:23.904
So the ability to terminate contracts with the sort of supply chain or with
00:19:23.904 --> 00:19:28.004
third parties when they are shown to not be complying.
00:19:28.204 --> 00:19:31.284
And I think that's a you need to be able to pull that plug and have a process
00:19:31.284 --> 00:19:34.324
for it and be resilient against the impact that that might have.
00:19:34.324 --> 00:19:39.404
And I think that's especially seen for managed service providers or managed
00:19:39.404 --> 00:19:43.784
security service providers, especially in the ICT realm, which is a common practice.
00:19:44.204 --> 00:19:49.324
Outsourced IT, outsourced security operations center or outsourced endpoint
00:19:49.324 --> 00:19:54.864
detection and response are all things that you may have to terminate them and
00:19:54.864 --> 00:19:58.284
the agreement with them if they're unable to provide sufficient improvement
00:19:58.284 --> 00:19:59.524
or documentation or evidence.
00:20:01.304 --> 00:20:06.304
Of course, you should have by now at least looked and adjusted the contract
00:20:06.304 --> 00:20:08.264
and service level agreements.
00:20:08.884 --> 00:20:14.344
Do you think there is a minimum of clauses you must put in this contract with
00:20:14.344 --> 00:20:18.104
third parties to align with DORA? Absolutely.
00:20:18.684 --> 00:20:23.584
So their ability to share their own security process with you, i.e.
00:20:23.624 --> 00:20:28.044
Their vulnerability management, their own sort of incident response procedures,
00:20:28.384 --> 00:20:31.704
and sort of what the expected SLAs around those are, so that they are communicating
00:20:31.704 --> 00:20:36.024
to you if they present a risk to you. And I think that's one of the core elements.
00:20:36.704 --> 00:20:42.464
In terms of the other pieces, so contractually speaking, you mentioned that
00:20:42.464 --> 00:20:47.084
they've, sorry, contractually speaking, you know, these things are negotiated already.
00:20:49.515 --> 00:20:53.615
At that point, it's data management, I think, and it's handling of your data
00:20:53.615 --> 00:20:56.795
and segregation of your data and evidence of that would be another key component as well.
00:20:56.935 --> 00:21:00.735
How do they deal with your data in relation and how do they protect that data?
00:21:01.155 --> 00:21:05.875
So I've seen in a number of examples, for instance, large service providers
00:21:05.875 --> 00:21:08.895
are now providing that level of attestation to their clients,
00:21:08.975 --> 00:21:11.955
for instance, and that's part of the negotiations that are ongoing for them.
00:21:14.155 --> 00:21:25.015
Let us go a little bit into the ICT tools and systems, the integrity, system integrity.
00:21:25.375 --> 00:21:30.635
Everybody needs to ask themselves, are my current systems resilient enough to
00:21:30.635 --> 00:21:34.935
withstand operational disruptions as outlined in DORA?
00:21:34.935 --> 00:21:43.275
But what would that mean for me as a maybe smaller startup fintech here?
00:21:44.575 --> 00:21:53.235
Yeah, absolutely. So I think as a smaller organization, the cost overhead of
00:21:53.235 --> 00:21:56.015
compliance and being able to show compliance,
00:21:56.135 --> 00:22:00.095
build the process is a big consideration for them.
00:22:00.095 --> 00:22:05.855
Equally, the nature of a startup or a scale-up is that they are dynamic organizations.
00:22:05.895 --> 00:22:10.755
They need to be able to adapt and respond, and they are the guerrilla fighters,
00:22:10.875 --> 00:22:15.235
if you will, of the business world.
00:22:15.395 --> 00:22:18.175
And that's one of the things that makes this quite tricky is because you're
00:22:18.175 --> 00:22:24.795
asking them to build a rigid structure and to do things that may prevent some
00:22:24.795 --> 00:22:30.175
level of innovation. And I think that's part of the pushback that some organizations have said.
00:22:31.235 --> 00:22:35.695
Cost is kind of probably going to come first for a lot and then complexity afterward,
00:22:35.695 --> 00:22:39.555
I would say, for the implementation and the challenges for them.
00:22:42.355 --> 00:22:46.955
You're talking about rigid systems, dynamic startups here.
00:22:47.155 --> 00:22:54.895
I was wondering, do you have seen any good solutions, any good systems?
00:22:54.895 --> 00:22:58.915
How do startups do work with backup and recovery?
00:22:59.115 --> 00:23:04.675
Because they tend to change a lot of what they're doing and how they're doing this.
00:23:04.835 --> 00:23:10.975
And their backup and recovery needs to adjust. So how do they keep pace with
00:23:10.975 --> 00:23:13.555
their current development in terms of backup and recovery?
00:23:14.215 --> 00:23:22.395
That's a really interesting question. And one that I think the hard part is
00:23:22.395 --> 00:23:27.355
to design a system when you are a small organization and have the scale that
00:23:27.355 --> 00:23:29.955
you will reach in mind and understand how to build for that scale.
00:23:30.435 --> 00:23:36.175
And for backup and recovery, the system that applies to a smaller company with
00:23:36.175 --> 00:23:40.095
five people, for instance, to one that has a thousand people or anywhere in
00:23:40.095 --> 00:23:42.095
between, it's tricky to get that scaling right.
00:23:43.295 --> 00:23:45.835
What you need to be able to do is build the.
00:23:47.465 --> 00:23:50.205
Build the backup scalability and the
00:23:50.205 --> 00:23:53.085
recovery scalability into every machine in
00:23:53.085 --> 00:23:55.825
a granular way so this is where a lot of organizations are turning
00:23:55.825 --> 00:23:59.965
to things like SaaS platforms that offer that backup and retention dynamically
00:23:59.965 --> 00:24:03.125
without them really doing any sort of thought there are
00:24:03.125 --> 00:24:06.965
some pitfalls to that approach you're outsourcing the risk to another vendor
00:24:06.965 --> 00:24:15.605
rather than sort of doing the full process yourself for instance if you so finding
00:24:15.605 --> 00:24:21.265
a good place to retain the original backups is a good start.
00:24:21.805 --> 00:24:26.705
Looking at how you can backport new iterations of systems or new generations
00:24:26.705 --> 00:24:29.025
of architecture into that is a key component.
00:24:29.545 --> 00:24:32.525
Things like immutability, for instance, are another element that people often
00:24:32.525 --> 00:24:35.905
think about and talk about is whether or not those backups can be changed.
00:24:37.985 --> 00:24:43.825
The regular review of what you are doing as part of that backup and generational
00:24:43.825 --> 00:24:50.805
changes and the transformation journey are – it's very difficult.
00:24:50.965 --> 00:24:53.225
You have to track it over its lifespan, if that makes sense.
00:24:53.305 --> 00:24:57.305
So you have to kind of understand those systems as they evolve and start to plan forward.
00:24:58.585 --> 00:25:04.165
Spelled out in every aspect. And I do believe after the first audits,
00:25:04.165 --> 00:25:06.545
there will be some issues coming up.
00:25:06.665 --> 00:25:13.385
People will discuss it on events. And over time, it will be an established enforcement.
00:25:13.825 --> 00:25:18.385
As well as rules and guidance people can adhere to.
00:25:18.525 --> 00:25:22.445
But right now we do have a little bit of wiggle room in some areas.
00:25:22.445 --> 00:25:26.425
And that's why we try to cover as much space as we're doing here.
00:25:28.085 --> 00:25:32.885
Talking about monitoring and testing, especially penetration testing,
00:25:32.885 --> 00:25:34.005
you've been talking about.
00:25:34.165 --> 00:25:41.185
I do know there is some guidance here in Germany, especially from BSI and other associations.
00:25:42.165 --> 00:25:48.585
What kind of standards and certifications would you use and recommend for your clients to do that?
00:25:49.385 --> 00:25:57.245
Yeah, it's an interesting one. So under the Tiber standard that's been across
00:25:57.245 --> 00:25:59.025
EU for some time now for a number of years,
00:25:59.325 --> 00:26:03.965
there were originally some guidelines around qualifications that organizations
00:26:03.965 --> 00:26:09.965
and the team members within them would have to have to conduct tests under the Tiber framework.
00:26:09.965 --> 00:26:14.245
But actually those are not enforced anymore.
00:26:14.565 --> 00:26:18.545
And there's a bit of a gap there. Although a lot of the organizations will still
00:26:18.545 --> 00:26:23.225
refer to them as the kind of the standard that is expected.
00:26:24.996 --> 00:26:30.376
What i would tend to advise is look for organizations that have individuals tested,
00:26:31.476 --> 00:26:37.016
tested and accredited as well as the organization itself to a recognized industry standard level,
00:26:37.636 --> 00:26:45.536
so for instance for the tlpt or the similar standards threat-led pen test under
00:26:45.536 --> 00:26:50.736
dora or essentially advanced testing or advanced red teaming intelligence-led red teaming.
00:26:52.716 --> 00:26:56.076
The typical standard is something like a sort
00:26:56.076 --> 00:27:00.396
of a crest certification like a cc sam or a cc sas for operators and managers
00:27:00.396 --> 00:27:03.836
you're looking at something that has a bit of a history and a legacy for instance
00:27:03.836 --> 00:27:09.136
other other similar standards exist as well and there's a lot of emergent organizations
00:27:09.136 --> 00:27:15.236
now that are bringing really good forward thinking standards to the to the fore,
00:27:16.216 --> 00:27:19.996
um i would also expect organizations to
00:27:19.996 --> 00:27:23.116
perform due diligence tech and so would so would uh so and
00:27:23.116 --> 00:27:25.936
that's what the standard advise is so looking at the
00:27:25.936 --> 00:27:28.876
individuals who are conducting testing whether it's advanced or
00:27:28.876 --> 00:27:34.636
basic if you will um and their experience and capability so sort of five years
00:27:34.636 --> 00:27:39.156
of experience testing against financial services organizations for a uh an experienced
00:27:39.156 --> 00:27:43.296
red team operator is considered uh to be the appropriate amount to amount to
00:27:43.296 --> 00:27:46.536
conduct tlpt or timer in these instances.
00:27:48.357 --> 00:27:53.317
Need to validate those and sort of do those checks.
00:27:53.517 --> 00:27:58.837
Again, understand the justification for it, and the best approach and the approach
00:27:58.837 --> 00:28:03.277
that I've seen most welcomed is to talk to your authority, your regulator, if you will,
00:28:03.737 --> 00:28:06.877
and sort of run your approach past and say, we've checked these,
00:28:07.077 --> 00:28:10.717
do these meet your standard, are there any other standards that you would like us to meet?
00:28:12.257 --> 00:28:18.577
So again, no fixed qualifications at this moment in time, but look for accredited, credible,
00:28:18.877 --> 00:28:22.737
longstanding institutions, if you're in any doubt, and do the due diligence
00:28:22.737 --> 00:28:27.257
on the individual testers themselves that will be performing work on your ICT
00:28:27.257 --> 00:28:28.977
systems, critical, important functions.
00:28:29.637 --> 00:28:31.357
And that's kind of the right approach.
00:28:34.537 --> 00:28:40.157
I do believe something very similar would be required for the resilient testing,
00:28:40.337 --> 00:28:44.717
except level of testing to demonstrate digital operation resilience.
00:28:46.057 --> 00:28:50.937
I would be a little bit more interested in threat intelligence.
00:28:50.937 --> 00:28:56.257
You already talked about real time threat intelligence. How is the best practice
00:28:56.257 --> 00:28:59.837
to integrate that as far as you've seen?
00:29:00.857 --> 00:29:05.717
It's a really interesting um concept so
00:29:05.717 --> 00:29:08.777
the threat intelligence plays
00:29:08.777 --> 00:29:13.857
an important part in understanding how to design against threats to your resiliency
00:29:13.857 --> 00:29:19.277
so having a constant feed and knowing the types of organizations that or or
00:29:19.277 --> 00:29:24.017
threat actors or groups that might be targeting your your organization or one
00:29:24.017 --> 00:29:27.837
similar to you on a continuous basis is really really important,
00:29:28.377 --> 00:29:32.017
That helps you design against them, if you will. The.
00:29:35.772 --> 00:29:39.112
There is a difference between sort of continuous threat intelligence and that
00:29:39.112 --> 00:29:45.292
element, as well as something that might be a standalone report or a point in time assessment.
00:29:46.432 --> 00:29:52.032
You need to have continuous feeds of what's directly interacting with your systems.
00:29:52.132 --> 00:29:55.652
For instance, that's what a lot of threat intelligence providers will now do.
00:29:55.812 --> 00:29:58.932
So they'll be looking at who's actually actively scanning your networks.
00:29:59.112 --> 00:30:00.392
What can that be attributed to?
00:30:01.752 --> 00:30:04.672
Likewise organizations that are able to sort of
00:30:04.672 --> 00:30:07.552
get into the sort of the dark recesses of
00:30:07.552 --> 00:30:10.532
the internet deep web dark web those types of things and
00:30:10.532 --> 00:30:13.512
look for evidence of threat actors
00:30:13.512 --> 00:30:17.872
targeting your organization and then there's also things like sort of nation
00:30:17.872 --> 00:30:21.972
state or nation state linked groups that might be targeting you for strategic
00:30:21.972 --> 00:30:27.632
advantage for instance a lot of financial sector organizations will be targeted
00:30:27.632 --> 00:30:30.892
because they're prime targets for nation state level groups.
00:30:31.572 --> 00:30:35.912
So having the feed and the understanding of what's going on on that side of
00:30:35.912 --> 00:30:39.432
things, who they might be, what they might be targeting, have they made some
00:30:39.432 --> 00:30:43.352
kind of public announcement, or have they affected similar organizations is
00:30:43.352 --> 00:30:44.052
really, really important.
00:30:45.432 --> 00:30:48.332
Equally, that information source, that threat intelligence source could be a
00:30:48.332 --> 00:30:52.872
platform or a vendor or a threat intelligence team you have yourself or threat
00:30:52.872 --> 00:30:56.532
intelligence capability you have of your own or it could be your peers in the
00:30:56.532 --> 00:31:01.452
market it could be the other financial institutions or similar types of institutions
00:31:01.452 --> 00:31:04.232
or the ICT institutions that provide services into them,
00:31:05.092 --> 00:31:09.332
is sharing information. And that's another core core tenet of this is actually
00:31:09.332 --> 00:31:15.092
sharing that information about near misses, incidents, events between the different
00:31:15.092 --> 00:31:18.712
parts of the ecosystem is another source of really valuable threat intelligence.
00:31:18.952 --> 00:31:23.072
And there needs to be a good way to share that in a private way and not expose
00:31:23.072 --> 00:31:27.272
each other's vulnerabilities and issues for competitive advantage, for instance.
00:31:27.832 --> 00:31:31.032
That sounds like a lot of lunch appointments you're recommending
00:31:31.032 --> 00:31:34.132
here yeah i
00:31:34.132 --> 00:31:36.852
think uh i think uh everyone's waistlines would have increased i think
00:31:36.852 --> 00:31:40.772
that's the side effect of uh of this i see
00:31:40.772 --> 00:31:44.012
we'll be back with policies and procedures after
00:31:44.012 --> 00:31:52.992
a little break for our sponsor okay
00:31:52.992 --> 00:31:59.072
we are back here with giles um we are still talking about dora giving you a
00:31:59.072 --> 00:32:04.272
high-level overview here of steps you should and could have taken.
00:32:05.012 --> 00:32:10.392
As we said, it's not really yet enforced. It's not yet audited.
00:32:10.592 --> 00:32:15.972
That's why we give you a very broad, very high-level overview of the steps.
00:32:16.172 --> 00:32:21.752
We would take questions we would ask. Therefore, you could go through and start
00:32:21.752 --> 00:32:24.592
thinking, hmm, did I miss something? Is everything in there?
00:32:24.592 --> 00:32:29.172
I will also link for the German authorities here.
00:32:29.332 --> 00:32:38.652
They have some guidelines for the enforcement of, have some guidelines for DORA.
00:32:38.972 --> 00:32:45.872
I'll link it here in the show notes. Unfortunately, it is not in English.
00:32:46.112 --> 00:32:50.572
Nonetheless, let's talk a little bit about policy and staff training because
00:32:50.572 --> 00:32:53.472
one kind of reinforces the others.
00:32:55.132 --> 00:33:02.632
We assume you currently have policies for operational resilience reviewed,
00:33:02.912 --> 00:33:11.252
but how often, how frequently do you need to adopt them to evolve in order to keep current?
00:33:11.572 --> 00:33:16.472
The world changes rapidly. So all the time is the optimal answer,
00:33:16.632 --> 00:33:20.812
but possibly also equally not the realistic one. So as a minimum,
00:33:21.032 --> 00:33:24.572
you'd need to be sort of annually reviewing as an absolute minimum.
00:33:24.792 --> 00:33:29.732
But if you're undergoing major change as a business, you're taking on new initiatives
00:33:29.732 --> 00:33:33.592
or you've acquired, say, for instance, mergers and acquisitions are a thing
00:33:33.592 --> 00:33:34.752
that happens all the time.
00:33:35.292 --> 00:33:39.612
Perhaps you've got an influx of new people in the team.
00:33:40.692 --> 00:33:43.832
When there's a major event like that, then you need to start building that in.
00:33:43.832 --> 00:33:47.492
Much like if you were building a new product or developing something new,
00:33:47.592 --> 00:33:49.852
you'd want to test that when there's a major update to it.
00:33:50.652 --> 00:33:54.452
You'd do the same for your business and its people and your culture to make
00:33:54.452 --> 00:34:00.272
sure that that is well understood, adopted, part of the onboarding process, if you will.
00:34:00.732 --> 00:34:02.932
So, yeah, major changes and at least annually.
00:34:03.697 --> 00:34:07.517
Yeah, and staff training should take place on a regular basis.
00:34:07.957 --> 00:34:13.917
I vividly remember that I had a few years ago a company here in the interview
00:34:13.917 --> 00:34:16.197
that offered this kind of testing.
00:34:16.377 --> 00:34:19.397
They just sent out mails and looked who clicked on the links.
00:34:19.517 --> 00:34:24.497
And I remember the answer, most clicks came from top management,
00:34:24.737 --> 00:34:26.737
but they are also the fastest ones to learn.
00:34:30.277 --> 00:34:36.837
I think there'll be a lot of required trainings and don't make it like a boring
00:34:36.837 --> 00:34:39.617
online presentation, a YouTube video or something like that.
00:34:40.037 --> 00:34:45.137
Make it interactive. That usually helps a lot more, especially I can tell from
00:34:45.137 --> 00:34:51.417
my past, especially if you get your staff, a group of people together,
00:34:51.657 --> 00:34:56.477
try to do the penetration testing themselves or at least give some ideas.
00:34:56.737 --> 00:35:03.117
It's really interesting how dark some people's thoughts can get here.
00:35:07.217 --> 00:35:10.897
Talking a little bit about cross-border compliance.
00:35:14.717 --> 00:35:19.377
Assuming you're a little bit bigger company, but even in financial services,
00:35:19.437 --> 00:35:23.657
if you have a few hundred employees, you're not really necessarily that big,
00:35:23.837 --> 00:35:30.997
but you can have operations in multiple EU countries or outside of EU countries.
00:35:31.217 --> 00:35:33.437
How does DORA apply there?
00:35:34.877 --> 00:35:38.157
That's a it's an interesting um dilemma for
00:35:38.157 --> 00:35:40.957
a lot of organizations so we uh have had the privilege
00:35:40.957 --> 00:35:44.597
of working with global organizations that are facing this same challenge so
00:35:44.597 --> 00:35:47.957
it may be that for instance um you
00:35:47.957 --> 00:35:51.897
face the challenge of multiple regulatory compliance
00:35:51.897 --> 00:35:56.217
so it could be different regions you have to comply to and a common practice
00:35:56.217 --> 00:35:58.777
for a lot of organizations when they start to get a bit larger or a bit more
00:35:58.777 --> 00:36:03.157
global in this side uh is to look at the most stringent requirement and try
00:36:03.157 --> 00:36:07.197
and comply to that or try and go for the kind of the path of most resistance
00:36:07.197 --> 00:36:10.677
where it comes to the compliance journey. And that's a typical approach.
00:36:11.917 --> 00:36:12.817
If you are.
00:36:15.157 --> 00:36:19.797
Sort of taking kind of taking this as a fairly sweeping legislation as it is
00:36:19.797 --> 00:36:24.757
and with lots of lots of kind of enforcement power, it's likely that this legislation
00:36:24.757 --> 00:36:27.257
will probably be the most stringent standard that you face.
00:36:29.297 --> 00:36:34.837
Targeting DORA and the ACT and the various articles underneath as the primary
00:36:34.837 --> 00:36:36.677
component is probably the most sensible approach.
00:36:38.357 --> 00:36:42.197
There are other standards of a similar nature, but I would suggest that this
00:36:42.197 --> 00:36:46.857
is probably the most complex for a lot of organizations to undertake and target
00:36:46.857 --> 00:36:48.117
this first in this instance.
00:36:50.057 --> 00:36:55.777
Data localization. Of course, Because it's always preferable to have the data
00:36:55.777 --> 00:37:00.537
within the country where you're regulated, where you're located.
00:37:01.797 --> 00:37:05.157
Are there specific requirements to store the data, for example,
00:37:05.317 --> 00:37:08.217
within the European Union to ensure compliance?
00:37:09.252 --> 00:37:14.972
Absolutely. So the data itself, much like some of the kind of the elements around
00:37:14.972 --> 00:37:19.152
sort of GDPR and what that brought in for a lot of global sort of companies, if you will,
00:37:19.572 --> 00:37:24.792
having that data where it is relevant stored in the European Union is the right
00:37:24.792 --> 00:37:25.652
approach in this instance.
00:37:25.652 --> 00:37:30.452
And so it should be residing there and you should be able to sort of see,
00:37:30.612 --> 00:37:33.172
as we say in the UK, farm to plate.
00:37:33.392 --> 00:37:38.772
So when you have a meal and maybe you have meat or whatever it might be,
00:37:38.972 --> 00:37:42.452
you know where that data has been held throughout its lifecycle.
00:37:43.032 --> 00:37:48.132
So being able to trace that back and make sure that you understand its location
00:37:48.132 --> 00:37:52.152
in full and that your suppliers are able to give you that information as a key component to that.
00:37:52.292 --> 00:37:55.072
So that goes downstream as well as for yourself, if you see what I mean.
00:37:55.072 --> 00:37:59.852
So cloud providers, for instance, often will allow you to put your data in specific
00:37:59.852 --> 00:38:01.652
regions if that's the way that you operate.
00:38:01.852 --> 00:38:04.292
So that's the right approach in this instance.
00:38:04.512 --> 00:38:12.392
If you are consuming services, SaaS services, or web-based products, by the way of putting it,
00:38:13.112 --> 00:38:17.712
that are based in other regions, that's a good reason and a good time to do
00:38:17.712 --> 00:38:21.572
a review and understand whether or not they're compliant to this legislation.
00:38:22.872 --> 00:38:30.452
I see. The last topic that I have here is pretty funny because it's areas of uncertainty.
00:38:30.832 --> 00:38:35.972
We've learned throughout this interview, which we're now asking you questions
00:38:35.972 --> 00:38:37.072
for more than 40 minutes,
00:38:37.232 --> 00:38:44.012
that we do have a big area of uncertainty, which kind of is all around Dora
00:38:44.012 --> 00:38:46.932
because it's not enforced yet. There are some guidelines.
00:38:47.132 --> 00:38:50.432
There will be some incidents. There will be some learnings. There will be a
00:38:50.432 --> 00:38:57.712
lot of lunches we've learned. And over time, this will disappear.
00:38:57.712 --> 00:39:01.312
But right now, we're trying to help you a little bit here.
00:39:01.612 --> 00:39:07.632
Where would you say the implementation guidelines are still ambiguous?
00:39:10.932 --> 00:39:15.732
How or where are they for you? And how would you seek clarification?
00:39:17.212 --> 00:39:21.032
That's a really interesting topic for a lot of organizations at the moment.
00:39:21.032 --> 00:39:26.592
So, for instance, things like the RTSs themselves are due to be published fairly soon.
00:39:26.692 --> 00:39:29.092
I think that's around March time that we're looking to see those.
00:39:30.752 --> 00:39:34.952
And there are still quite a few big question marks around things like a lot
00:39:34.952 --> 00:39:37.432
of organizations are interested in pooled testing, for instance,
00:39:37.672 --> 00:39:42.732
and the kind of the role of service providers that a lot of organizations will use for.
00:39:44.046 --> 00:39:49.646
There are still, dare I say it, quite a few question marks, lacks of answers,
00:39:49.826 --> 00:39:54.266
even from sort of the kind of the top down, the authorities themselves about
00:39:54.266 --> 00:39:55.386
sort of how that will play out.
00:39:55.666 --> 00:40:00.806
And that shows the complexity of this and what's trying to be achieved.
00:40:01.046 --> 00:40:05.766
So it's trying to tie organizations together to get them to communicate and
00:40:05.766 --> 00:40:10.006
to be able to share that data in a collaborative way. But the reality of that
00:40:10.006 --> 00:40:11.066
is very difficult to implement.
00:40:11.906 --> 00:40:15.446
Sorry, could you remind me of the question again? Yeah, sure.
00:40:18.006 --> 00:40:23.466
We've been talking about unclear guidelines and how you would seek clarification for them.
00:40:23.986 --> 00:40:29.186
Yeah, absolutely. So in terms of the way that you would be able to seek guidance for such a thing,
00:40:29.406 --> 00:40:36.306
speaking to the authority that you have in your region or when that's assigned
00:40:36.306 --> 00:40:40.326
and sort of getting the guidance directly from them is definitely a good thing to do.
00:40:40.326 --> 00:40:42.426
So being communicative, almost
00:40:42.426 --> 00:40:46.526
over-communicative, and asking those questions is the right approach.
00:40:46.626 --> 00:40:50.746
And it's been something that's worked for sort of organizations trying to get
00:40:50.746 --> 00:40:53.506
themselves ready for Tiber testing in years past, for instance.
00:40:54.666 --> 00:40:58.526
Talking, asking the question of your authority once they've been enshrined,
00:40:58.686 --> 00:41:03.026
hopefully in March, will be the right way to make sure that you've got the right
00:41:03.026 --> 00:41:06.006
information and the right point of contact, if that makes sense,
00:41:06.086 --> 00:41:09.006
or the right structure and the right approach.
00:41:10.566 --> 00:41:19.826
For what level of compliance would you aim usually you should aim for good enough to pass,
00:41:20.846 --> 00:41:29.566
an audit you should also take the opportunity to look a little bit through the
00:41:29.566 --> 00:41:31.746
cyber security of your organization,
00:41:32.086 --> 00:41:40.346
what kind of level would you recommend for your clients to implement in order
00:41:40.346 --> 00:41:44.346
to not really get in any big trouble?
00:41:44.566 --> 00:41:48.086
Do everything as best as you can, ask as many questions as you can,
00:41:48.226 --> 00:41:50.806
and then you should be at least okay?
00:41:51.186 --> 00:41:55.766
Well, it is possible to ask too many questions and to force yourself down a
00:41:55.766 --> 00:42:00.226
path that's too complex. So I would start with the questions to understand the
00:42:00.226 --> 00:42:03.726
size of that delta to start with.
00:42:05.206 --> 00:42:06.406
In terms of the.
00:42:08.343 --> 00:42:11.383
Do the best that you can approach um i think
00:42:11.383 --> 00:42:14.163
it's difficult to go wrong but that you
00:42:14.163 --> 00:42:17.483
know the reality the commercial reality of that can be can be quite challenging
00:42:17.483 --> 00:42:20.243
um it could cost quite a lot to be
00:42:20.243 --> 00:42:23.123
able to do the best you can and you may not get business support for it or investment
00:42:23.123 --> 00:42:28.963
or funding whatever it might be so the minimum level is probably the realistic
00:42:28.963 --> 00:42:33.683
level for a lot of organizations in this instance um but have a plan a plan
00:42:33.683 --> 00:42:39.023
rather to improve beyond that point and a structured set of goals that you want to exceed that.
00:42:39.243 --> 00:42:42.703
Start with that minimal and work your way up. And in continuous improvement
00:42:42.703 --> 00:42:46.003
and showing that continuous improvement in your approach, your thinking,
00:42:46.323 --> 00:42:50.463
your documentation and the process and building that out over time is the right
00:42:50.463 --> 00:42:52.263
way to stay ahead of that curve.
00:42:52.423 --> 00:42:55.443
If you treat this as point in time, I'm good for now.
00:42:56.003 --> 00:42:59.683
Nothing changes, that the world changes around you. You will find that there
00:42:59.683 --> 00:43:02.063
is a compliance gap 12 months, 18 months,
00:43:02.383 --> 00:43:06.403
24 months away so make sure that you are hitting
00:43:06.403 --> 00:43:09.163
that minimum at least to start with as much as possible and then
00:43:09.163 --> 00:43:11.783
planning forward to try and get better over time and i
00:43:11.783 --> 00:43:14.603
think that's what this is trying to encourage i was aiming for
00:43:14.603 --> 00:43:19.203
the continuous improvement as well as i've seen a lot of consulting projects
00:43:19.203 --> 00:43:24.323
in the past they they really blow up they they became much much bigger than
00:43:24.323 --> 00:43:32.763
you would expect and that's what you've been referring to with the exploding costs so um Basically,
00:43:33.043 --> 00:43:38.343
you should aim at a level where you feel secure that you've done enough.
00:43:38.503 --> 00:43:41.743
And as you said, you can ask too many questions.
00:43:43.463 --> 00:43:49.663
And guys, keep in mind, this is not a regulatory or legal advice here.
00:43:49.943 --> 00:43:54.263
That is just a place to start doing your own homework.
00:43:56.403 --> 00:44:01.043
Josh, I do believe I bothered you with a lot of questions here.
00:44:01.823 --> 00:44:07.623
We talked a lot of high-level stuff, and I do believe some people listening
00:44:07.623 --> 00:44:12.863
to this really got some value added out of it because they have now some areas
00:44:12.863 --> 00:44:18.643
where they can think and rethink their approach to DORA. Thank you very much. Thank you.
00:44:24.523 --> 00:44:34.143
That's all folks. Find more news, streams, events, and interviews at www.startuprad.io.
00:44:34.563 --> 00:44:36.643
Remember, sharing is caring.
00:44:37.360 --> 00:44:50.175
Music.
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:13.040 --> 00:00:18.960
Music.
00:00:19.877 --> 00:00:23.717
Hello and welcome everybody. This is Joe from StartupRad.io,
00:00:23.957 --> 00:00:27.837
your startup podcast, YouTube blog and internet radio station from Germany,
00:00:27.957 --> 00:00:28.937
Austria and Switzerland.
00:00:28.937 --> 00:00:35.177
Today, I do have another expert interview with you, talking about Dora again.
00:00:35.597 --> 00:00:41.457
We have been in the past hearing one guest who was talking about third-party
00:00:41.457 --> 00:00:44.457
assets on your website that you need to take care of.
00:00:44.797 --> 00:00:49.417
This time, I do have Giles here as a guest. Hey, how are you doing?
00:00:50.437 --> 00:00:54.857
Hi, nice to see you. Thanks for having me on. Totally my pleasure.
00:00:54.857 --> 00:01:00.337
You are Director of Services EMEA at NetSpy, and we will be talking a little
00:01:00.337 --> 00:01:03.957
bit broader about DORA and what you should do.
00:01:04.117 --> 00:01:07.937
I do have a few questions to guide you through this interview,
00:01:07.997 --> 00:01:10.957
and hopefully it will be very useful for everybody of us.
00:01:11.077 --> 00:01:16.217
But before we get started, can you introduce yourself a little bit to our audience?
00:01:16.357 --> 00:01:19.917
Keep in mind, most people will just listen to us. Of course.
00:01:20.237 --> 00:01:26.517
So I'm Giles, and I look after a number of different testing services.
00:01:26.697 --> 00:01:29.337
So I am a security tester. And
00:01:29.337 --> 00:01:33.837
before that, involved in IT infrastructure for a long time in my career.
00:01:34.317 --> 00:01:39.157
So in terms of my profession now, what I do is something called red teaming.
00:01:39.357 --> 00:01:42.617
And that is an expression of
00:01:42.617 --> 00:01:47.157
security testing. it's essentially organization-wide resiliency testing.
00:01:47.357 --> 00:01:54.657
And it's the type of testing that sort of DORA asks us to undertake and Tiber2
00:01:54.657 --> 00:01:57.237
and other frameworks, things like CBEST, for instance, in the UK,
00:01:57.517 --> 00:01:59.177
and other frameworks globally.
00:02:00.057 --> 00:02:06.177
It is essentially, for want of a better way of putting it, I'm a hacker, but in a good way. Yeah.
00:02:08.094 --> 00:02:13.994
You are, can you say, an ethical hacker? Correct. Yes, absolutely. An ethical hacker.
00:02:15.354 --> 00:02:18.774
I see. So today we're talking about DORA.
00:02:18.974 --> 00:02:23.914
No, it's not a first name of a lady. It's the Digital Operational Resilience
00:02:23.914 --> 00:02:26.034
Act from the European Union.
00:02:27.774 --> 00:02:35.234
And before we do get started, right now, it's already in force.
00:02:35.234 --> 00:02:39.554
But we do know the way bureaucracy work.
00:02:41.414 --> 00:02:44.994
Likely next year, the first checks will be done by authorities,
00:02:45.194 --> 00:02:46.774
by auditors, and so on and so forth.
00:02:46.914 --> 00:02:52.554
So this is the time to really get your stuff done, to really get down to business.
00:02:52.934 --> 00:02:56.774
If you appear or think you have some holes in there.
00:02:56.774 --> 00:03:02.774
And for this reason, we go a little bit broadly over the whole regulation and
00:03:02.774 --> 00:03:08.574
tell you potential places where you may have to work on before you get audited.
00:03:09.574 --> 00:03:13.194
Should we start with government and risk management?
00:03:14.234 --> 00:03:19.874
Please. Governance structure. Have I established a clear governance framework
00:03:19.874 --> 00:03:25.794
for digital operational resilience and are roles and responsibilities well defined?
00:03:25.794 --> 00:03:28.394
And that is a pretty interesting question.
00:03:28.414 --> 00:03:33.534
And what kind of answer should an entrepreneur have except for yes, of course?
00:03:36.634 --> 00:03:42.894
Yeah, that's a really interesting one. I think it's about the evidence base
00:03:42.894 --> 00:03:44.514
and the rationale behind it.
00:03:44.574 --> 00:03:48.814
And I think that's the kind of some of the core aspect to this.
00:03:48.814 --> 00:03:54.914
So if you can prove the rationale of that structure and sort of why you've made
00:03:54.914 --> 00:03:57.294
the choices that you have, I think that's a key component of it.
00:03:58.974 --> 00:04:02.774
Reasoning behind things, if that makes sense. It's not just the process,
00:04:02.774 --> 00:04:05.954
and I think that's one of the things that is critical to this.
00:04:06.134 --> 00:04:09.674
It's about the reasoning for the process and sort of the evaluation,
00:04:09.914 --> 00:04:11.374
the showing you're working, if you will.
00:04:11.674 --> 00:04:14.534
But I think this is really trying to prize out, if that makes sense.
00:04:14.534 --> 00:04:18.414
So that means if an auditor asks you, why did you do that?
00:04:18.554 --> 00:04:23.474
You should have a pretty good reason. But I do believe most will have thought
00:04:23.474 --> 00:04:26.034
it through at this point.
00:04:26.374 --> 00:04:33.294
Then we're talking about risk management strategy, having a comprehensive risk
00:04:33.294 --> 00:04:38.714
management framework to address all potential ICT risks.
00:04:38.714 --> 00:04:44.334
Can you first tell us a little bit what ICT risks are and then what you would
00:04:44.334 --> 00:04:51.354
expect from such a risk management strategy if you would look at it from an outside perspective?
00:04:51.714 --> 00:04:53.834
So I think there is a...
00:04:54.917 --> 00:04:58.677
A significant amount of this that is kind of understanding your organization
00:04:58.677 --> 00:05:03.777
and sort of where you sit within the market, where you intend to be in sort
00:05:03.777 --> 00:05:05.657
of three, five, ten years time, for instance,
00:05:05.977 --> 00:05:10.737
and sort of where you need to integrate to be able to understand what those risks might be.
00:05:11.777 --> 00:05:15.377
The component parts of your business and what keeps you operational is really important.
00:05:15.557 --> 00:05:19.177
You know, what are the cogs that keep the business turning from an IT perspective,
00:05:19.177 --> 00:05:23.157
the critical, important functions, to use the sort of the terminology there?
00:05:23.157 --> 00:05:29.637
These are the component parts of the business that you absolutely must keep
00:05:29.637 --> 00:05:30.857
running and operational.
00:05:31.117 --> 00:05:37.197
And that's why operational resiliency is a big part of this risk management approach, if you will.
00:05:38.877 --> 00:05:42.897
Actually, funny thing in German, it's called information and communications
00:05:42.897 --> 00:05:48.157
technology, information and communications technology, IKT-risiko.
00:05:48.377 --> 00:05:53.257
So that should give a little bit more hint about that. but please go on.
00:05:53.417 --> 00:05:59.877
The approach in terms of the strategy and the vision is you have to understand
00:05:59.877 --> 00:06:05.037
all of your assets that form part of that ICT estate and the processes and components
00:06:05.037 --> 00:06:06.717
and the human element as well, if you will,
00:06:06.777 --> 00:06:09.777
that go into that to be able to drive the business.
00:06:10.717 --> 00:06:15.177
And that accurate mapping of it is essentially the most fundamental component
00:06:15.177 --> 00:06:18.477
of that strategy, if you will. Yes, sure.
00:06:20.097 --> 00:06:22.197
Risk-venture framework, when
00:06:22.197 --> 00:06:28.397
would it be comprehensive to address all potential ICT risk? Thank you.
00:06:31.016 --> 00:06:35.216
Without understanding your entire estate and all of your ICT systems and the
00:06:35.216 --> 00:06:37.796
usage of them and sort of how they integrate to the business,
00:06:37.836 --> 00:06:42.196
it's an incredible challenge to be able to make it complete.
00:06:42.696 --> 00:06:48.056
So a strong asset inventory or a strong understanding of your own ICT systems
00:06:48.056 --> 00:06:52.676
is critical to be able to understand the risk to them or the potential risk to them.
00:06:53.316 --> 00:06:59.536
I have one question. You said it's important to have like overall overview.
00:06:59.536 --> 00:07:04.936
I do believe a lot of people tend to forget one or two tools.
00:07:05.376 --> 00:07:12.456
Do you have any experience where people usually forget some ICT assets,
00:07:12.656 --> 00:07:16.436
meaning physical or digital tools, software, IT?
00:07:17.736 --> 00:07:24.156
Yeah. So I think shadow IT as a concept is something that people talk often
00:07:24.156 --> 00:07:29.176
about, which is parts of the infrastructure that have been sort of created dynamically
00:07:29.176 --> 00:07:31.296
or by individuals or users that are unknown.
00:07:31.476 --> 00:07:36.516
And I think that's one of the key missing elements from a lot of people's asset inventories.
00:07:36.676 --> 00:07:40.256
So you have to have an element that is through known mechanisms,
00:07:40.436 --> 00:07:44.436
things like sort of databases that you might have of assets that exist already.
00:07:44.536 --> 00:07:47.696
But you also need to have the ability to dynamically map them and to be able
00:07:47.696 --> 00:07:53.716
to dynamically understand the component technology assets of your business on a continuous basis.
00:07:53.716 --> 00:07:59.696
So there are a number of sort of platforms and sources and tools that aim to
00:07:59.696 --> 00:08:04.416
do that dynamically and to varying degrees of success in the market.
00:08:04.656 --> 00:08:09.336
But doing an evaluation of those as part of your component infrastructure and
00:08:09.336 --> 00:08:14.216
looking at the efficacy of those is is a really important task as part of this
00:08:14.216 --> 00:08:18.476
kind of this overall framework development is you need to be able to assess the tools you use.
00:08:18.656 --> 00:08:22.116
In fact, it kind of almost the next level, if you will, that assess how you
00:08:22.116 --> 00:08:29.316
work. It's a bit of a non-answer almost sometimes, but the approach...
00:08:33.105 --> 00:08:36.865
You need to be able to know what you don't know and how do you quantify that?
00:08:36.985 --> 00:08:40.785
And I think that's the tricky question here is how do you map the unknown and
00:08:40.785 --> 00:08:43.785
how do you rate a tool that allows you to do that?
00:08:44.225 --> 00:08:48.465
Often people lean into things like SaaS platforms that sort of offer a,
00:08:48.545 --> 00:08:51.285
for want of a better way, a magical solution to these problems.
00:08:51.505 --> 00:08:56.745
I think validation and checking and due diligence, again, another core concept
00:08:56.745 --> 00:09:00.385
of this act and what it tries to instill, key components of that.
00:09:00.385 --> 00:09:06.025
So you need to make sure that you are checking and validating the software that
00:09:06.025 --> 00:09:11.345
you use, even that you use to understand your business and evaluate itself, if that makes sense.
00:09:12.245 --> 00:09:15.705
So you shouldn't have any freelancers who
00:09:15.705 --> 00:09:19.005
do have developed proprietary tool they transfer
00:09:19.005 --> 00:09:22.025
data and then put it back into your system that that's the
00:09:22.025 --> 00:09:28.085
kind of risk we're talking about plus getting your data into a third-party software
00:09:28.085 --> 00:09:36.145
and not be aware of that do you have because this shadow it is always a pretty
00:09:36.145 --> 00:09:39.945
difficult topic especially to figure out Oh,
00:09:40.525 --> 00:09:44.725
if you have something like that, I once talked to a guest and they say,
00:09:44.825 --> 00:09:48.345
yeah, look at the company credit card bills.
00:09:48.805 --> 00:09:52.525
If there's software charge, that could be a good hint.
00:09:53.005 --> 00:09:59.385
Do you have any other ideas, suggestions how somebody may find,
00:09:59.665 --> 00:10:07.965
may learn more about potential shadow software where they could find hints about it?
00:10:08.655 --> 00:10:13.395
Yeah, there are elements. So some of this might be externally facing,
00:10:13.535 --> 00:10:15.875
for instance, so internet facing and available to the public,
00:10:15.895 --> 00:10:17.175
and you may not be aware of it.
00:10:17.295 --> 00:10:20.935
So there are tools and techniques and processes that you can do to dynamically
00:10:20.935 --> 00:10:27.075
scan and to sort of search for assets that might be linked to your business in some way.
00:10:27.775 --> 00:10:30.775
You know products like this are often called things like attack surface mapping for
00:10:30.775 --> 00:10:33.495
instance these are what they aim
00:10:33.495 --> 00:10:37.755
to do is look for traces of your organization externally so then that you can
00:10:37.755 --> 00:10:42.255
take sort of reparatory action or some form of action to investigate where they
00:10:42.255 --> 00:10:45.875
may have come from what the background might be credit card data is in fact
00:10:45.875 --> 00:10:50.015
quite an interesting one because company assets company finance are tracked
00:10:50.015 --> 00:10:52.955
already in a lot of organizations so that gives you that audit trail.
00:10:53.615 --> 00:10:59.695
Other sources of data, things like in the sort of the computer sort of identity
00:10:59.695 --> 00:11:03.695
sense, for instance, things like cloud services will hold databases of users.
00:11:03.855 --> 00:11:06.975
Perhaps you can track what those users, what resources they're creating.
00:11:07.195 --> 00:11:10.855
The same for sort of on-premise systems like Active Directory, for instance.
00:11:11.415 --> 00:11:14.955
Those are means by which you can have a look at what resources are being spun
00:11:14.955 --> 00:11:17.135
up, but that's not dynamic. That's fairly static.
00:11:23.035 --> 00:11:26.315
The regulation talks about ICT risk
00:11:26.315 --> 00:11:30.215
assessment how frequently should
00:11:30.215 --> 00:11:35.655
you do that and how I mean there are of course different methodologies but how
00:11:35.655 --> 00:11:43.675
would you go about figuring out what methodology one should use that's an interesting
00:11:43.675 --> 00:11:49.315
uh an interesting topic um you have to assess it Again, I think that's a really important thing.
00:11:49.415 --> 00:11:52.555
And I think this is kind of, again, this is the territory of non-answer again,
00:11:52.715 --> 00:11:54.815
where you're expected to do
00:11:54.815 --> 00:11:57.215
the due diligence, but often there's not a great deal of guidance on it.
00:11:57.335 --> 00:12:00.335
And to be able to prove and validate that and argue the case for it,
00:12:00.335 --> 00:12:03.955
again, is one of the key things. But in terms of the.
00:12:04.793 --> 00:12:08.113
In terms of the sort of the way that you manage that due diligence on third
00:12:08.113 --> 00:12:11.253
party suppliers, existing and new ones, a lot of organizations.
00:12:11.473 --> 00:12:17.653
For instance, that I've spoken to are re-evaluating contracts as a result of this act.
00:12:17.793 --> 00:12:22.193
So that's kind of a one-time monolithic sort of evaluation of those organizations
00:12:22.193 --> 00:12:25.333
and how they treat their own security as part of that supply chain risk piece.
00:12:25.333 --> 00:12:30.573
But also when you are updating or changing contracts or when you are refreshing
00:12:30.573 --> 00:12:35.733
service contracts with those organizations, that's when you should be doing this assessment,
00:12:35.893 --> 00:12:40.273
for instance, or at least on a yearly basis or an annual basis to make sure
00:12:40.273 --> 00:12:42.873
that you are regularly reviewing and revisiting them.
00:12:42.993 --> 00:12:48.133
And I think the review and revisit is another core component to this is you
00:12:48.133 --> 00:12:53.593
can't treat something as trusted if you've done this forever, if you know what I mean.
00:12:53.593 --> 00:12:56.893
So if you've done your due diligence once, that doesn't mean that that due diligence
00:12:56.893 --> 00:13:00.253
continues year after year, year after year.
00:13:00.393 --> 00:13:03.313
Organizations can become insecure that you deal with as a supplier,
00:13:03.413 --> 00:13:05.193
for instance, over the course of their lifetime.
00:13:05.393 --> 00:13:08.513
So what you need to be doing is making sure that you're continuously checking
00:13:08.513 --> 00:13:13.533
those, understanding their downstream processes for sort of how they manage
00:13:13.533 --> 00:13:17.653
their own vulnerabilities, their own risk management approaches, their own processes.
00:13:17.653 --> 00:13:21.333
And that's one of the big challenges around this
00:13:21.333 --> 00:13:27.053
act is organizations are now presented with how do they present information
00:13:27.053 --> 00:13:33.633
about how and where they are vulnerable to their clients without giving away
00:13:33.633 --> 00:13:36.433
data that is sensitive or controlled under other legislation,
00:13:36.593 --> 00:13:37.913
things like GDPR, for instance.
00:13:38.173 --> 00:13:43.673
And that's a very tricky question to get an accurate and clear answer on.
00:13:43.753 --> 00:13:46.513
And I think that's been one of the challenges for organizations trying to solve this.
00:13:47.833 --> 00:13:53.533
When we're talking about DORA here we're talking about incident reporting and
00:13:53.533 --> 00:14:00.793
management can you help us to understand this field first step how do you,
00:14:01.660 --> 00:14:05.160
identify an incident. What is the level?
00:14:06.060 --> 00:14:09.820
Again, it's a little bit subjective here. When is it an incident?
00:14:11.020 --> 00:14:14.460
Yeah, absolutely. So you have to need to have a reasonable level of confidence
00:14:14.460 --> 00:14:19.460
that this is a operationally affecting incident, cyber security or otherwise.
00:14:19.700 --> 00:14:23.800
So, you know, for instance, the one that a lot of people lean towards is cyber
00:14:23.800 --> 00:14:26.140
security incident or a breach, for instance.
00:14:26.740 --> 00:14:31.980
You need to have a good degree of confidence of that is a genuine breach,
00:14:32.120 --> 00:14:34.400
for instance, and be able to report that as soon as possible,
00:14:34.640 --> 00:14:36.020
ideally within 24 hours.
00:14:36.220 --> 00:14:42.000
So you need to have a strong ability to respond to these types of events and
00:14:42.000 --> 00:14:47.120
identify them, triage them, and treat them as quickly as possible, i.e.
00:14:47.240 --> 00:14:50.060
Identify them as quickly as possible. And then you've got a responsibility at
00:14:50.060 --> 00:14:54.240
that point to do the notification process and follow through the rest of your
00:14:54.240 --> 00:14:55.880
incident response plan.
00:14:56.140 --> 00:14:59.180
And that can vary depending on what type of incident you face.
00:14:59.600 --> 00:15:05.560
So in a lot of breaches, for instance, you see things like ransomware affecting organizations.
00:15:06.300 --> 00:15:12.380
That type of breach is very, very fast moving, typically, in the market for a lot of organizations.
00:15:12.980 --> 00:15:17.800
So there's a real challenge with the timing of being able to identify something
00:15:17.800 --> 00:15:21.480
like this, respond to it, and sort of recover from it, as well as going through
00:15:21.480 --> 00:15:23.240
the notification process at the same time.
00:15:23.240 --> 00:15:27.380
And I think that's where we'll see a real stretch for organizations to meet
00:15:27.380 --> 00:15:28.360
that compliance standard.
00:15:28.600 --> 00:15:34.900
How do you show that you can do the identification process and adapt and prevent
00:15:34.900 --> 00:15:36.220
and recover from a threat at
00:15:36.220 --> 00:15:39.540
the same time, for instance? So it's a really tricky thing to get right.
00:15:40.480 --> 00:15:44.200
It needs to be documented. You need to be able to, again, justify it.
00:15:44.260 --> 00:15:49.400
You need to be able to talk about why you believe that the method and approach
00:15:49.400 --> 00:15:50.640
that you're using is appropriate.
00:15:50.640 --> 00:15:54.920
Because when you come to audit, you will need to go through that process.
00:15:54.920 --> 00:15:58.360
You will need to meet the challenge of, you know, these questions being asked
00:15:58.360 --> 00:16:00.600
of your organizations and why you've chosen that.
00:16:00.780 --> 00:16:06.300
If you don't have a robust set of evidence behind it, about behind why you've
00:16:06.300 --> 00:16:09.580
made the choices, then there is a high likelihood that, you know,
00:16:09.660 --> 00:16:11.380
you'll need to take some measure afterwards.
00:16:11.540 --> 00:16:16.980
So if you've got good justification, you may well have to take less action to
00:16:16.980 --> 00:16:20.660
sort of get up to the right standard for next year and years after that.
00:16:20.780 --> 00:16:23.580
So the improvement plan will be much reduced, if you will.
00:16:24.419 --> 00:16:32.899
I see. We've been talking about communicate, communication, reporting of incidents,
00:16:33.199 --> 00:16:36.119
of course, to the relevant authorities and the stakeholders.
00:16:36.219 --> 00:16:39.579
But what kind of channels would you use?
00:16:39.659 --> 00:16:44.819
Because I do believe it's not secure enough and not sufficient to just send
00:16:44.819 --> 00:16:47.119
an email. Hey, guys, look at this. Something happened.
00:16:48.459 --> 00:16:52.979
Yeah, absolutely. So in these types of incidents, especially in a cybersecurity
00:16:52.979 --> 00:16:55.579
incident where the systems you
00:16:55.579 --> 00:16:58.639
use to actually send those emails may be compromised in and of themselves,
00:16:58.999 --> 00:17:05.939
there is a balance between sort of using the systems that are breached and some
00:17:05.939 --> 00:17:07.799
other out-of-band method, like
00:17:07.799 --> 00:17:11.879
a telephone call or an SMS or a reporting platform or something similar.
00:17:11.879 --> 00:17:17.699
So some nations, for instance, will have direct report that you can do through
00:17:17.699 --> 00:17:18.659
a website, for instance.
00:17:18.979 --> 00:17:24.299
Those are methods that are often used. If you are in a market that is heavily
00:17:24.299 --> 00:17:31.679
regulated already, you will often have a contact or a representative or an agency, if you will,
00:17:31.699 --> 00:17:38.959
or a TCT in the sort of the Tiber terms that you would make contact with.
00:17:39.019 --> 00:17:40.779
So you would have a familiar contact normally.
00:17:41.879 --> 00:17:46.179
Typically, they would be a first point or a local law enforcement agency if it's relevant as well.
00:17:47.719 --> 00:17:55.759
That's a tricky one with the balance of sort of when and where you are allowed
00:17:55.759 --> 00:17:56.639
to do that in some regions.
00:17:56.799 --> 00:17:59.519
But I won't go too far into that because there be dragons.
00:18:02.579 --> 00:18:06.739
Plus, we're just trying to provide here a high-level summary for the audience
00:18:06.739 --> 00:18:12.579
that they can start thinking about. But where may they be a weakness not to
00:18:12.579 --> 00:18:14.619
be found in your first audit?
00:18:14.799 --> 00:18:19.519
Because that's what everybody wants to avoid. And that's why we are here and talking today.
00:18:20.979 --> 00:18:25.559
I would like to go a little bit over to the topic of third-party risk management.
00:18:25.779 --> 00:18:32.339
You've been already talking about adjusting the contract with vendors here.
00:18:35.679 --> 00:18:41.819
I'm pretty confident everybody now has already the class, the, the, the, the, um,
00:18:42.864 --> 00:18:49.104
the required criteria in their evaluation,
00:18:49.584 --> 00:18:57.884
third-party ICT providers, and so on and so forth, how would you proceed with existing vendors,
00:18:58.904 --> 00:19:05.484
that may be a little bit late to come by or promise something and didn't deliver
00:19:05.484 --> 00:19:11.184
yet because that's a problem for you and not necessarily for them? Absolutely.
00:19:12.504 --> 00:19:16.764
So there is guidance to say that you need to have good termination procedures
00:19:16.764 --> 00:19:18.044
in place as well, for instance.
00:19:18.284 --> 00:19:23.904
So the ability to terminate contracts with the sort of supply chain or with
00:19:23.904 --> 00:19:28.004
third parties when they are shown to not be complying.
00:19:28.204 --> 00:19:31.284
And I think that's a you need to be able to pull that plug and have a process
00:19:31.284 --> 00:19:34.324
for it and be resilient against the impact that that might have.
00:19:34.324 --> 00:19:39.404
And I think that's especially seen for managed service providers or managed
00:19:39.404 --> 00:19:43.784
security service providers, especially in the ICT realm, which is a common practice.
00:19:44.204 --> 00:19:49.324
Outsourced IT, outsourced security operations center or outsourced endpoint
00:19:49.324 --> 00:19:54.864
detection and response are all things that you may have to terminate them and
00:19:54.864 --> 00:19:58.284
the agreement with them if they're unable to provide sufficient improvement
00:19:58.284 --> 00:19:59.524
or documentation or evidence.
00:20:01.304 --> 00:20:06.304
Of course, you should have by now at least looked and adjusted the contract
00:20:06.304 --> 00:20:08.264
and service level agreements.
00:20:08.884 --> 00:20:14.344
Do you think there is a minimum of clauses you must put in this contract with
00:20:14.344 --> 00:20:18.104
third parties to align with DORA? Absolutely.
00:20:18.684 --> 00:20:23.584
So their ability to share their own security process with you, i.e.
00:20:23.624 --> 00:20:28.044
Their vulnerability management, their own sort of incident response procedures,
00:20:28.384 --> 00:20:31.704
and sort of what the expected SLAs around those are, so that they are communicating
00:20:31.704 --> 00:20:36.024
to you if they present a risk to you. And I think that's one of the core elements.
00:20:36.704 --> 00:20:42.464
In terms of the other pieces, so contractually speaking, you mentioned that
00:20:42.464 --> 00:20:47.084
they've, sorry, contractually speaking, you know, these things are negotiated already.
00:20:49.515 --> 00:20:53.615
At that point, it's data management, I think, and it's handling of your data
00:20:53.615 --> 00:20:56.795
and segregation of your data and evidence of that would be another key component as well.
00:20:56.935 --> 00:21:00.735
How do they deal with your data in relation and how do they protect that data?
00:21:01.155 --> 00:21:05.875
So I've seen in a number of examples, for instance, large service providers
00:21:05.875 --> 00:21:08.895
are now providing that level of attestation to their clients,
00:21:08.975 --> 00:21:11.955
for instance, and that's part of the negotiations that are ongoing for them.
00:21:14.155 --> 00:21:25.015
Let us go a little bit into the ICT tools and systems, the integrity, system integrity.
00:21:25.375 --> 00:21:30.635
Everybody needs to ask themselves, are my current systems resilient enough to
00:21:30.635 --> 00:21:34.935
withstand operational disruptions as outlined in DORA?
00:21:34.935 --> 00:21:43.275
But what would that mean for me as a maybe smaller startup fintech here?
00:21:44.575 --> 00:21:53.235
Yeah, absolutely. So I think as a smaller organization, the cost overhead of
00:21:53.235 --> 00:21:56.015
compliance and being able to show compliance,
00:21:56.135 --> 00:22:00.095
build the process is a big consideration for them.
00:22:00.095 --> 00:22:05.855
Equally, the nature of a startup or a scale-up is that they are dynamic organizations.
00:22:05.895 --> 00:22:10.755
They need to be able to adapt and respond, and they are the guerrilla fighters,
00:22:10.875 --> 00:22:15.235
if you will, of the business world.
00:22:15.395 --> 00:22:18.175
And that's one of the things that makes this quite tricky is because you're
00:22:18.175 --> 00:22:24.795
asking them to build a rigid structure and to do things that may prevent some
00:22:24.795 --> 00:22:30.175
level of innovation. And I think that's part of the pushback that some organizations have said.
00:22:31.235 --> 00:22:35.695
Cost is kind of probably going to come first for a lot and then complexity afterward,
00:22:35.695 --> 00:22:39.555
I would say, for the implementation and the challenges for them.
00:22:42.355 --> 00:22:46.955
You're talking about rigid systems, dynamic startups here.
00:22:47.155 --> 00:22:54.895
I was wondering, do you have seen any good solutions, any good systems?
00:22:54.895 --> 00:22:58.915
How do startups do work with backup and recovery?
00:22:59.115 --> 00:23:04.675
Because they tend to change a lot of what they're doing and how they're doing this.
00:23:04.835 --> 00:23:10.975
And their backup and recovery needs to adjust. So how do they keep pace with
00:23:10.975 --> 00:23:13.555
their current development in terms of backup and recovery?
00:23:14.215 --> 00:23:22.395
That's a really interesting question. And one that I think the hard part is
00:23:22.395 --> 00:23:27.355
to design a system when you are a small organization and have the scale that
00:23:27.355 --> 00:23:29.955
you will reach in mind and understand how to build for that scale.
00:23:30.435 --> 00:23:36.175
And for backup and recovery, the system that applies to a smaller company with
00:23:36.175 --> 00:23:40.095
five people, for instance, to one that has a thousand people or anywhere in
00:23:40.095 --> 00:23:42.095
between, it's tricky to get that scaling right.
00:23:43.295 --> 00:23:45.835
What you need to be able to do is build the.
00:23:47.465 --> 00:23:50.205
Build the backup scalability and the
00:23:50.205 --> 00:23:53.085
recovery scalability into every machine in
00:23:53.085 --> 00:23:55.825
a granular way so this is where a lot of organizations are turning
00:23:55.825 --> 00:23:59.965
to things like SaaS platforms that offer that backup and retention dynamically
00:23:59.965 --> 00:24:03.125
without them really doing any sort of thought there are
00:24:03.125 --> 00:24:06.965
some pitfalls to that approach you're outsourcing the risk to another vendor
00:24:06.965 --> 00:24:15.605
rather than sort of doing the full process yourself for instance if you so finding
00:24:15.605 --> 00:24:21.265
a good place to retain the original backups is a good start.
00:24:21.805 --> 00:24:26.705
Looking at how you can backport new iterations of systems or new generations
00:24:26.705 --> 00:24:29.025
of architecture into that is a key component.
00:24:29.545 --> 00:24:32.525
Things like immutability, for instance, are another element that people often
00:24:32.525 --> 00:24:35.905
think about and talk about is whether or not those backups can be changed.
00:24:37.985 --> 00:24:43.825
The regular review of what you are doing as part of that backup and generational
00:24:43.825 --> 00:24:50.805
changes and the transformation journey are – it's very difficult.
00:24:50.965 --> 00:24:53.225
You have to track it over its lifespan, if that makes sense.
00:24:53.305 --> 00:24:57.305
So you have to kind of understand those systems as they evolve and start to plan forward.
00:24:58.585 --> 00:25:04.165
Spelled out in every aspect. And I do believe after the first audits,
00:25:04.165 --> 00:25:06.545
there will be some issues coming up.
00:25:06.665 --> 00:25:13.385
People will discuss it on events. And over time, it will be an established enforcement.
00:25:13.825 --> 00:25:18.385
As well as rules and guidance people can adhere to.
00:25:18.525 --> 00:25:22.445
But right now we do have a little bit of wiggle room in some areas.
00:25:22.445 --> 00:25:26.425
And that's why we try to cover as much space as we're doing here.
00:25:28.085 --> 00:25:32.885
Talking about monitoring and testing, especially penetration testing,
00:25:32.885 --> 00:25:34.005
you've been talking about.
00:25:34.165 --> 00:25:41.185
I do know there is some guidance here in Germany, especially from BSI and other associations.
00:25:42.165 --> 00:25:48.585
What kind of standards and certifications would you use and recommend for your clients to do that?
00:25:49.385 --> 00:25:57.245
Yeah, it's an interesting one. So under the Tiber standard that's been across
00:25:57.245 --> 00:25:59.025
EU for some time now for a number of years,
00:25:59.325 --> 00:26:03.965
there were originally some guidelines around qualifications that organizations
00:26:03.965 --> 00:26:09.965
and the team members within them would have to have to conduct tests under the Tiber framework.
00:26:09.965 --> 00:26:14.245
But actually those are not enforced anymore.
00:26:14.565 --> 00:26:18.545
And there's a bit of a gap there. Although a lot of the organizations will still
00:26:18.545 --> 00:26:23.225
refer to them as the kind of the standard that is expected.
00:26:24.996 --> 00:26:30.376
What i would tend to advise is look for organizations that have individuals tested,
00:26:31.476 --> 00:26:37.016
tested and accredited as well as the organization itself to a recognized industry standard level,
00:26:37.636 --> 00:26:45.536
so for instance for the tlpt or the similar standards threat-led pen test under
00:26:45.536 --> 00:26:50.736
dora or essentially advanced testing or advanced red teaming intelligence-led red teaming.
00:26:52.716 --> 00:26:56.076
The typical standard is something like a sort
00:26:56.076 --> 00:27:00.396
of a crest certification like a cc sam or a cc sas for operators and managers
00:27:00.396 --> 00:27:03.836
you're looking at something that has a bit of a history and a legacy for instance
00:27:03.836 --> 00:27:09.136
other other similar standards exist as well and there's a lot of emergent organizations
00:27:09.136 --> 00:27:15.236
now that are bringing really good forward thinking standards to the to the fore,
00:27:16.216 --> 00:27:19.996
um i would also expect organizations to
00:27:19.996 --> 00:27:23.116
perform due diligence tech and so would so would uh so and
00:27:23.116 --> 00:27:25.936
that's what the standard advise is so looking at the
00:27:25.936 --> 00:27:28.876
individuals who are conducting testing whether it's advanced or
00:27:28.876 --> 00:27:34.636
basic if you will um and their experience and capability so sort of five years
00:27:34.636 --> 00:27:39.156
of experience testing against financial services organizations for a uh an experienced
00:27:39.156 --> 00:27:43.296
red team operator is considered uh to be the appropriate amount to amount to
00:27:43.296 --> 00:27:46.536
conduct tlpt or timer in these instances.
00:27:48.357 --> 00:27:53.317
Need to validate those and sort of do those checks.
00:27:53.517 --> 00:27:58.837
Again, understand the justification for it, and the best approach and the approach
00:27:58.837 --> 00:28:03.277
that I've seen most welcomed is to talk to your authority, your regulator, if you will,
00:28:03.737 --> 00:28:06.877
and sort of run your approach past and say, we've checked these,
00:28:07.077 --> 00:28:10.717
do these meet your standard, are there any other standards that you would like us to meet?
00:28:12.257 --> 00:28:18.577
So again, no fixed qualifications at this moment in time, but look for accredited, credible,
00:28:18.877 --> 00:28:22.737
longstanding institutions, if you're in any doubt, and do the due diligence
00:28:22.737 --> 00:28:27.257
on the individual testers themselves that will be performing work on your ICT
00:28:27.257 --> 00:28:28.977
systems, critical, important functions.
00:28:29.637 --> 00:28:31.357
And that's kind of the right approach.
00:28:34.537 --> 00:28:40.157
I do believe something very similar would be required for the resilient testing,
00:28:40.337 --> 00:28:44.717
except level of testing to demonstrate digital operation resilience.
00:28:46.057 --> 00:28:50.937
I would be a little bit more interested in threat intelligence.
00:28:50.937 --> 00:28:56.257
You already talked about real time threat intelligence. How is the best practice
00:28:56.257 --> 00:28:59.837
to integrate that as far as you've seen?
00:29:00.857 --> 00:29:05.717
It's a really interesting um concept so
00:29:05.717 --> 00:29:08.777
the threat intelligence plays
00:29:08.777 --> 00:29:13.857
an important part in understanding how to design against threats to your resiliency
00:29:13.857 --> 00:29:19.277
so having a constant feed and knowing the types of organizations that or or
00:29:19.277 --> 00:29:24.017
threat actors or groups that might be targeting your your organization or one
00:29:24.017 --> 00:29:27.837
similar to you on a continuous basis is really really important,
00:29:28.377 --> 00:29:32.017
That helps you design against them, if you will. The.
00:29:35.772 --> 00:29:39.112
There is a difference between sort of continuous threat intelligence and that
00:29:39.112 --> 00:29:45.292
element, as well as something that might be a standalone report or a point in time assessment.
00:29:46.432 --> 00:29:52.032
You need to have continuous feeds of what's directly interacting with your systems.
00:29:52.132 --> 00:29:55.652
For instance, that's what a lot of threat intelligence providers will now do.
00:29:55.812 --> 00:29:58.932
So they'll be looking at who's actually actively scanning your networks.
00:29:59.112 --> 00:30:00.392
What can that be attributed to?
00:30:01.752 --> 00:30:04.672
Likewise organizations that are able to sort of
00:30:04.672 --> 00:30:07.552
get into the sort of the dark recesses of
00:30:07.552 --> 00:30:10.532
the internet deep web dark web those types of things and
00:30:10.532 --> 00:30:13.512
look for evidence of threat actors
00:30:13.512 --> 00:30:17.872
targeting your organization and then there's also things like sort of nation
00:30:17.872 --> 00:30:21.972
state or nation state linked groups that might be targeting you for strategic
00:30:21.972 --> 00:30:27.632
advantage for instance a lot of financial sector organizations will be targeted
00:30:27.632 --> 00:30:30.892
because they're prime targets for nation state level groups.
00:30:31.572 --> 00:30:35.912
So having the feed and the understanding of what's going on on that side of
00:30:35.912 --> 00:30:39.432
things, who they might be, what they might be targeting, have they made some
00:30:39.432 --> 00:30:43.352
kind of public announcement, or have they affected similar organizations is
00:30:43.352 --> 00:30:44.052
really, really important.
00:30:45.432 --> 00:30:48.332
Equally, that information source, that threat intelligence source could be a
00:30:48.332 --> 00:30:52.872
platform or a vendor or a threat intelligence team you have yourself or threat
00:30:52.872 --> 00:30:56.532
intelligence capability you have of your own or it could be your peers in the
00:30:56.532 --> 00:31:01.452
market it could be the other financial institutions or similar types of institutions
00:31:01.452 --> 00:31:04.232
or the ICT institutions that provide services into them,
00:31:05.092 --> 00:31:09.332
is sharing information. And that's another core core tenet of this is actually
00:31:09.332 --> 00:31:15.092
sharing that information about near misses, incidents, events between the different
00:31:15.092 --> 00:31:18.712
parts of the ecosystem is another source of really valuable threat intelligence.
00:31:18.952 --> 00:31:23.072
And there needs to be a good way to share that in a private way and not expose
00:31:23.072 --> 00:31:27.272
each other's vulnerabilities and issues for competitive advantage, for instance.
00:31:27.832 --> 00:31:31.032
That sounds like a lot of lunch appointments you're recommending
00:31:31.032 --> 00:31:34.132
here yeah i
00:31:34.132 --> 00:31:36.852
think uh i think uh everyone's waistlines would have increased i think
00:31:36.852 --> 00:31:40.772
that's the side effect of uh of this i see
00:31:40.772 --> 00:31:44.012
we'll be back with policies and procedures after
00:31:44.012 --> 00:31:52.992
a little break for our sponsor okay
00:31:52.992 --> 00:31:59.072
we are back here with giles um we are still talking about dora giving you a
00:31:59.072 --> 00:32:04.272
high-level overview here of steps you should and could have taken.
00:32:05.012 --> 00:32:10.392
As we said, it's not really yet enforced. It's not yet audited.
00:32:10.592 --> 00:32:15.972
That's why we give you a very broad, very high-level overview of the steps.
00:32:16.172 --> 00:32:21.752
We would take questions we would ask. Therefore, you could go through and start
00:32:21.752 --> 00:32:24.592
thinking, hmm, did I miss something? Is everything in there?
00:32:24.592 --> 00:32:29.172
I will also link for the German authorities here.
00:32:29.332 --> 00:32:38.652
They have some guidelines for the enforcement of, have some guidelines for DORA.
00:32:38.972 --> 00:32:45.872
I'll link it here in the show notes. Unfortunately, it is not in English.
00:32:46.112 --> 00:32:50.572
Nonetheless, let's talk a little bit about policy and staff training because
00:32:50.572 --> 00:32:53.472
one kind of reinforces the others.
00:32:55.132 --> 00:33:02.632
We assume you currently have policies for operational resilience reviewed,
00:33:02.912 --> 00:33:11.252
but how often, how frequently do you need to adopt them to evolve in order to keep current?
00:33:11.572 --> 00:33:16.472
The world changes rapidly. So all the time is the optimal answer,
00:33:16.632 --> 00:33:20.812
but possibly also equally not the realistic one. So as a minimum,
00:33:21.032 --> 00:33:24.572
you'd need to be sort of annually reviewing as an absolute minimum.
00:33:24.792 --> 00:33:29.732
But if you're undergoing major change as a business, you're taking on new initiatives
00:33:29.732 --> 00:33:33.592
or you've acquired, say, for instance, mergers and acquisitions are a thing
00:33:33.592 --> 00:33:34.752
that happens all the time.
00:33:35.292 --> 00:33:39.612
Perhaps you've got an influx of new people in the team.
00:33:40.692 --> 00:33:43.832
When there's a major event like that, then you need to start building that in.
00:33:43.832 --> 00:33:47.492
Much like if you were building a new product or developing something new,
00:33:47.592 --> 00:33:49.852
you'd want to test that when there's a major update to it.
00:33:50.652 --> 00:33:54.452
You'd do the same for your business and its people and your culture to make
00:33:54.452 --> 00:34:00.272
sure that that is well understood, adopted, part of the onboarding process, if you will.
00:34:00.732 --> 00:34:02.932
So, yeah, major changes and at least annually.
00:34:03.697 --> 00:34:07.517
Yeah, and staff training should take place on a regular basis.
00:34:07.957 --> 00:34:13.917
I vividly remember that I had a few years ago a company here in the interview
00:34:13.917 --> 00:34:16.197
that offered this kind of testing.
00:34:16.377 --> 00:34:19.397
They just sent out mails and looked who clicked on the links.
00:34:19.517 --> 00:34:24.497
And I remember the answer, most clicks came from top management,
00:34:24.737 --> 00:34:26.737
but they are also the fastest ones to learn.
00:34:30.277 --> 00:34:36.837
I think there'll be a lot of required trainings and don't make it like a boring
00:34:36.837 --> 00:34:39.617
online presentation, a YouTube video or something like that.
00:34:40.037 --> 00:34:45.137
Make it interactive. That usually helps a lot more, especially I can tell from
00:34:45.137 --> 00:34:51.417
my past, especially if you get your staff, a group of people together,
00:34:51.657 --> 00:34:56.477
try to do the penetration testing themselves or at least give some ideas.
00:34:56.737 --> 00:35:03.117
It's really interesting how dark some people's thoughts can get here.
00:35:07.217 --> 00:35:10.897
Talking a little bit about cross-border compliance.
00:35:14.717 --> 00:35:19.377
Assuming you're a little bit bigger company, but even in financial services,
00:35:19.437 --> 00:35:23.657
if you have a few hundred employees, you're not really necessarily that big,
00:35:23.837 --> 00:35:30.997
but you can have operations in multiple EU countries or outside of EU countries.
00:35:31.217 --> 00:35:33.437
How does DORA apply there?
00:35:34.877 --> 00:35:38.157
That's a it's an interesting um dilemma for
00:35:38.157 --> 00:35:40.957
a lot of organizations so we uh have had the privilege
00:35:40.957 --> 00:35:44.597
of working with global organizations that are facing this same challenge so
00:35:44.597 --> 00:35:47.957
it may be that for instance um you
00:35:47.957 --> 00:35:51.897
face the challenge of multiple regulatory compliance
00:35:51.897 --> 00:35:56.217
so it could be different regions you have to comply to and a common practice
00:35:56.217 --> 00:35:58.777
for a lot of organizations when they start to get a bit larger or a bit more
00:35:58.777 --> 00:36:03.157
global in this side uh is to look at the most stringent requirement and try
00:36:03.157 --> 00:36:07.197
and comply to that or try and go for the kind of the path of most resistance
00:36:07.197 --> 00:36:10.677
where it comes to the compliance journey. And that's a typical approach.
00:36:11.917 --> 00:36:12.817
If you are.
00:36:15.157 --> 00:36:19.797
Sort of taking kind of taking this as a fairly sweeping legislation as it is
00:36:19.797 --> 00:36:24.757
and with lots of lots of kind of enforcement power, it's likely that this legislation
00:36:24.757 --> 00:36:27.257
will probably be the most stringent standard that you face.
00:36:29.297 --> 00:36:34.837
Targeting DORA and the ACT and the various articles underneath as the primary
00:36:34.837 --> 00:36:36.677
component is probably the most sensible approach.
00:36:38.357 --> 00:36:42.197
There are other standards of a similar nature, but I would suggest that this
00:36:42.197 --> 00:36:46.857
is probably the most complex for a lot of organizations to undertake and target
00:36:46.857 --> 00:36:48.117
this first in this instance.
00:36:50.057 --> 00:36:55.777
Data localization. Of course, Because it's always preferable to have the data
00:36:55.777 --> 00:37:00.537
within the country where you're regulated, where you're located.
00:37:01.797 --> 00:37:05.157
Are there specific requirements to store the data, for example,
00:37:05.317 --> 00:37:08.217
within the European Union to ensure compliance?
00:37:09.252 --> 00:37:14.972
Absolutely. So the data itself, much like some of the kind of the elements around
00:37:14.972 --> 00:37:19.152
sort of GDPR and what that brought in for a lot of global sort of companies, if you will,
00:37:19.572 --> 00:37:24.792
having that data where it is relevant stored in the European Union is the right
00:37:24.792 --> 00:37:25.652
approach in this instance.
00:37:25.652 --> 00:37:30.452
And so it should be residing there and you should be able to sort of see,
00:37:30.612 --> 00:37:33.172
as we say in the UK, farm to plate.
00:37:33.392 --> 00:37:38.772
So when you have a meal and maybe you have meat or whatever it might be,
00:37:38.972 --> 00:37:42.452
you know where that data has been held throughout its lifecycle.
00:37:43.032 --> 00:37:48.132
So being able to trace that back and make sure that you understand its location
00:37:48.132 --> 00:37:52.152
in full and that your suppliers are able to give you that information as a key component to that.
00:37:52.292 --> 00:37:55.072
So that goes downstream as well as for yourself, if you see what I mean.
00:37:55.072 --> 00:37:59.852
So cloud providers, for instance, often will allow you to put your data in specific
00:37:59.852 --> 00:38:01.652
regions if that's the way that you operate.
00:38:01.852 --> 00:38:04.292
So that's the right approach in this instance.
00:38:04.512 --> 00:38:12.392
If you are consuming services, SaaS services, or web-based products, by the way of putting it,
00:38:13.112 --> 00:38:17.712
that are based in other regions, that's a good reason and a good time to do
00:38:17.712 --> 00:38:21.572
a review and understand whether or not they're compliant to this legislation.
00:38:22.872 --> 00:38:30.452
I see. The last topic that I have here is pretty funny because it's areas of uncertainty.
00:38:30.832 --> 00:38:35.972
We've learned throughout this interview, which we're now asking you questions
00:38:35.972 --> 00:38:37.072
for more than 40 minutes,
00:38:37.232 --> 00:38:44.012
that we do have a big area of uncertainty, which kind of is all around Dora
00:38:44.012 --> 00:38:46.932
because it's not enforced yet. There are some guidelines.
00:38:47.132 --> 00:38:50.432
There will be some incidents. There will be some learnings. There will be a
00:38:50.432 --> 00:38:57.712
lot of lunches we've learned. And over time, this will disappear.
00:38:57.712 --> 00:39:01.312
But right now, we're trying to help you a little bit here.
00:39:01.612 --> 00:39:07.632
Where would you say the implementation guidelines are still ambiguous?
00:39:10.932 --> 00:39:15.732
How or where are they for you? And how would you seek clarification?
00:39:17.212 --> 00:39:21.032
That's a really interesting topic for a lot of organizations at the moment.
00:39:21.032 --> 00:39:26.592
So, for instance, things like the RTSs themselves are due to be published fairly soon.
00:39:26.692 --> 00:39:29.092
I think that's around March time that we're looking to see those.
00:39:30.752 --> 00:39:34.952
And there are still quite a few big question marks around things like a lot
00:39:34.952 --> 00:39:37.432
of organizations are interested in pooled testing, for instance,
00:39:37.672 --> 00:39:42.732
and the kind of the role of service providers that a lot of organizations will use for.
00:39:44.046 --> 00:39:49.646
There are still, dare I say it, quite a few question marks, lacks of answers,
00:39:49.826 --> 00:39:54.266
even from sort of the kind of the top down, the authorities themselves about
00:39:54.266 --> 00:39:55.386
sort of how that will play out.
00:39:55.666 --> 00:40:00.806
And that shows the complexity of this and what's trying to be achieved.
00:40:01.046 --> 00:40:05.766
So it's trying to tie organizations together to get them to communicate and
00:40:05.766 --> 00:40:10.006
to be able to share that data in a collaborative way. But the reality of that
00:40:10.006 --> 00:40:11.066
is very difficult to implement.
00:40:11.906 --> 00:40:15.446
Sorry, could you remind me of the question again? Yeah, sure.
00:40:18.006 --> 00:40:23.466
We've been talking about unclear guidelines and how you would seek clarification for them.
00:40:23.986 --> 00:40:29.186
Yeah, absolutely. So in terms of the way that you would be able to seek guidance for such a thing,
00:40:29.406 --> 00:40:36.306
speaking to the authority that you have in your region or when that's assigned
00:40:36.306 --> 00:40:40.326
and sort of getting the guidance directly from them is definitely a good thing to do.
00:40:40.326 --> 00:40:42.426
So being communicative, almost
00:40:42.426 --> 00:40:46.526
over-communicative, and asking those questions is the right approach.
00:40:46.626 --> 00:40:50.746
And it's been something that's worked for sort of organizations trying to get
00:40:50.746 --> 00:40:53.506
themselves ready for Tiber testing in years past, for instance.
00:40:54.666 --> 00:40:58.526
Talking, asking the question of your authority once they've been enshrined,
00:40:58.686 --> 00:41:03.026
hopefully in March, will be the right way to make sure that you've got the right
00:41:03.026 --> 00:41:06.006
information and the right point of contact, if that makes sense,
00:41:06.086 --> 00:41:09.006
or the right structure and the right approach.
00:41:10.566 --> 00:41:19.826
For what level of compliance would you aim usually you should aim for good enough to pass,
00:41:20.846 --> 00:41:29.566
an audit you should also take the opportunity to look a little bit through the
00:41:29.566 --> 00:41:31.746
cyber security of your organization,
00:41:32.086 --> 00:41:40.346
what kind of level would you recommend for your clients to implement in order
00:41:40.346 --> 00:41:44.346
to not really get in any big trouble?
00:41:44.566 --> 00:41:48.086
Do everything as best as you can, ask as many questions as you can,
00:41:48.226 --> 00:41:50.806
and then you should be at least okay?
00:41:51.186 --> 00:41:55.766
Well, it is possible to ask too many questions and to force yourself down a
00:41:55.766 --> 00:42:00.226
path that's too complex. So I would start with the questions to understand the
00:42:00.226 --> 00:42:03.726
size of that delta to start with.
00:42:05.206 --> 00:42:06.406
In terms of the.
00:42:08.343 --> 00:42:11.383
Do the best that you can approach um i think
00:42:11.383 --> 00:42:14.163
it's difficult to go wrong but that you
00:42:14.163 --> 00:42:17.483
know the reality the commercial reality of that can be can be quite challenging
00:42:17.483 --> 00:42:20.243
um it could cost quite a lot to be
00:42:20.243 --> 00:42:23.123
able to do the best you can and you may not get business support for it or investment
00:42:23.123 --> 00:42:28.963
or funding whatever it might be so the minimum level is probably the realistic
00:42:28.963 --> 00:42:33.683
level for a lot of organizations in this instance um but have a plan a plan
00:42:33.683 --> 00:42:39.023
rather to improve beyond that point and a structured set of goals that you want to exceed that.
00:42:39.243 --> 00:42:42.703
Start with that minimal and work your way up. And in continuous improvement
00:42:42.703 --> 00:42:46.003
and showing that continuous improvement in your approach, your thinking,
00:42:46.323 --> 00:42:50.463
your documentation and the process and building that out over time is the right
00:42:50.463 --> 00:42:52.263
way to stay ahead of that curve.
00:42:52.423 --> 00:42:55.443
If you treat this as point in time, I'm good for now.
00:42:56.003 --> 00:42:59.683
Nothing changes, that the world changes around you. You will find that there
00:42:59.683 --> 00:43:02.063
is a compliance gap 12 months, 18 months,
00:43:02.383 --> 00:43:06.403
24 months away so make sure that you are hitting
00:43:06.403 --> 00:43:09.163
that minimum at least to start with as much as possible and then
00:43:09.163 --> 00:43:11.783
planning forward to try and get better over time and i
00:43:11.783 --> 00:43:14.603
think that's what this is trying to encourage i was aiming for
00:43:14.603 --> 00:43:19.203
the continuous improvement as well as i've seen a lot of consulting projects
00:43:19.203 --> 00:43:24.323
in the past they they really blow up they they became much much bigger than
00:43:24.323 --> 00:43:32.763
you would expect and that's what you've been referring to with the exploding costs so um Basically,
00:43:33.043 --> 00:43:38.343
you should aim at a level where you feel secure that you've done enough.
00:43:38.503 --> 00:43:41.743
And as you said, you can ask too many questions.
00:43:43.463 --> 00:43:49.663
And guys, keep in mind, this is not a regulatory or legal advice here.
00:43:49.943 --> 00:43:54.263
That is just a place to start doing your own homework.
00:43:56.403 --> 00:44:01.043
Josh, I do believe I bothered you with a lot of questions here.
00:44:01.823 --> 00:44:07.623
We talked a lot of high-level stuff, and I do believe some people listening
00:44:07.623 --> 00:44:12.863
to this really got some value added out of it because they have now some areas
00:44:12.863 --> 00:44:18.643
where they can think and rethink their approach to DORA. Thank you very much. Thank you.
00:44:24.523 --> 00:44:34.143
That's all folks. Find more news, streams, events, and interviews at www.startuprad.io.
00:44:34.563 --> 00:44:36.643
Remember, sharing is caring.
00:44:37.360 --> 00:44:50.175
Music.
