PANEL: Securing the Chain: Strategies for Resilient Supply Networks

I'm happy to invite to the stage Tobias Staehle again and André Reichow-Prehn. You need to clap your hands. Just have a seat. Initially it was also planned that we have Watson Munyanyi virtually join, but as I get the information, he's not there yet.

Okay, so this is no problem. Then we have more time to discuss. Maybe we start with a short introduction again.

Tobias, you started this track today, but maybe for the other attendees and also for the recording, a brief introduction again. Yeah, sure. Thank you so much for being here. My name is Tobias Staehle. I'm a Deputy Chief Security Officer at Deutsche Börse AG, Deutsche Börse Group. I'm head of sections of multiple units. One is what we call third-party security risk management. Perfect. André?

Yes, I'm André Reichow-Prehn. I'm the managing partner for Unit 42 at Palo Alto Networks.

Cool, great. Our topic today is securing the chain strategies for resilient supply networks. Earlier this day, we talked more specifically about smart sourcing. I think there are some overlaps from the topic-wise.

I mean, cyber supply chain security nevertheless is a really very important topic, not only regarding Nestora, also in general a thing we need to consider within organizations. Again, to the audience, if you have any kind of question, feel free to raise your hand. I really try to have this very interactive. This also counts for Berthold, for instance, if he has a question again. But this time, we need a microphone.

Otherwise, we don't have it on the recording. So let's jump in.

Tobias, what systemic risks posed by server supply chain cyber threats do you consider most critical? And how can organizations strengthen their resilience against these threats? Okay.

So, André, the panel before, I mentioned only one, and this was what I call the follow the sun challenge, right? So CloudStrike is one thing. Somewhere it starts, and then it spreads across the globe, and it brings us down. Maybe I can add a couple of more of them, actually, especially from a Deutsche Börse perspective is availability, everything which impacts really our availability.

Of course, we are an availability company. We're not dealing much with PI information. Don't have that typical credit cards. But we are talking about half of nanoseconds when we design our systems. So really quick algo trading. And if anything, let's say, limits this, then actually we have a problem, okay? Because we have to be available for our customers in this on a global level. And that could be ransomware. That could be basically even geographical risks, right? So better disasters also where our partners are not there.

And if you would like to say last but not least, and I mentioned that a little bit, it's also cluster risks, right? If you have a cluster risk and we're sitting there in one or the other country, that's also an issue if they go down or not available. André? Yes. So I would say that we have different layers of supply chain risks that we see in regards of cyber risks.

So starting on the hardware level, we have the on one part availability levels that we have learned in the last year, that it can be an issue if I want to secure my environment based on hardware-based systems, that the delivery or lead times can be up to 18 months and above. So covering this for having a more vertical integrated production and security vendors might be a measure as it has helped some. We have the situation that the risks of implemented backdoors, a lot of our hardware technology is coming from Far East.

So there is risk and there has been proven that in example, some years ago in American defense systems, there have been found Chinese hardware backdoors in military helicopters, one example. So this is a latent risk that we have. So availability, because where things are produced, the other thing is it might come with a bonus that we don't want.

Then we have the topics and this was in the presentation before in regards of libraries that we depend on, develop products that are based on different layers of applications, how to handle in regards of security, where they come from, and if they are affected, might affect a bigger part. We have also the situation that I have a complex ecosystem of different companies that are connected with EDI, with different services and API sets. They share that there is kind of an inherent risk that the weakest link is breaking it.

And then we have the top layer in regards of when it comes to securing all this environment. And I have security partners and measures. And in the presentation before, Sergei brought forward the SolarWinds topic, that I have integrated solutions that might become impacted by a targeted attack, that is basically spreading to all the users of those services. So this is kind of the different layers for supply chain risks that I see there.

Tobias, maybe back to your point with the cluster risks. How can you strengthen Deutsche Börse Group in topics like that? Or maybe a more generic phrase? I think the key challenge is to identify the clusters, right? That's the first starting point, which is already a challenge. Why? Because the procurement systems and our downstream systems, they have flat files, so to say, right? So each vendor, each partner is so to say flat, right? That means who knows that Red Hat is a partner of IBM. Is it still there? I think it is, right? But when you look at next sheet thinking, right?

And I guess many of the procurement systems, they are structured like column A is company names. And there is no connection or family tree. That's the first challenge we currently face is what is the family tree? Who is the mother? Who is the parent? Who is the daughter in our contracted landscape of external partners? That's the first thing. And I think, and what I'm hearing in the market, many companies face the same situation. And so we are working on this at the moment, fair enough. So we are trying to understand that Red Hat is a company of the IBM group. But we are not there yet.

Another challenge which we have, and there is not so much a solution, is that what is the risk exposure for a cluster? What is the risk exposure for a family? How do we determine this? And I guess there is also not so much methodology, community knowledge is available, right? It's at Ember Green. Coming from tons of data points, maybe from risk assessment, which we talked earlier. But how you aggregate. Inherent into Red, then everything is Red, obviously. There's always a Red. And so it's also not working. So I think that's a challenge at the moment. Because it's also DORA.

It's also BIT or regulator relevant. How to identify clusters by services maybe, maybe also by regions, by companies. But then how are you dealing with it? And what are you doing? And I think we are not there yet. We are discussing how we get there. But I think some thoughts need to be spent on this.

André, how can organizations effectively set standards to ensure consistent security practices across the end-to-end supply chain? Yeah, so I think there are established standards that can be used and leveraged.

Like ISO, like a lot of recommendations that are focused on different industries. I think the challenge here is actually implement experienced, sophisticated staff that is exercising on it. Not just focusing on the compliance layer in regards of people that are generating documentations and workflows. But rather in regards of operating and managing those infrastructures. And I think it's also helpful to go in the direction of platformization. So that you reduce complexity, that you don't need 50 departments for 50 different vendors.

And that you basically go to the top creditors, to the top tier vendors. That you reduce the risks of acquisition and consolidation in the market. That you basically talk to vendors and companies that have the highest likelihood to be there for good. And to establish long-term relationships in regards of what they are doing, how things are working. That you have the third-party management right in place without overblowing all the efforts and things you need to do.

Tobias, we discussed this earlier. Is it, for instance, or from your experience, sufficient to trust the typical standards like an ISO for a good level of security in that case? Or is it just a starting point? Or does it depend on maybe the cluster or the topic? I think ISO Certificate or SOC 2 report has been in the past a trustworthy document. A certification where a lot of companies actually hope that it's accepted as the single point of data point. Necessary to support a positive message in terms of we are secure. But I think that has diminished very quickly the last few years or so.

At least for us. And because it was perceived by other regulators that it is just one data point in a set of data points we need to gather. Exactly. And this is when we had these discussions earlier when I had this sharing the insights on our sponsors in terms of contract negotiations. When we are telling them, okay, this is not a contract, cannot compensate a contract. And this is just one data point. We need to go far deeper, far broader. This is the first surprising effect. And there is a reason for it because it's that a certificate is general, okay?

They do their sampling across processes, across topics. And then they get a stamp. But we cannot prove that we as an organization, our controls were part of the sample size in an appropriate sizing. That means we can use it as a good idea, understanding. But we are not allowed to use it as a single data point. And that completely changes the value of an ISO certificate or SOP2 report. It's not becoming more than a single source of truth. It is just another data point of hundreds of them. Which comes back to the smart sourcing topic we had earlier in the discussion.

So basically, I mean, also the automotive industry. I mean, the ISO is not bad. This was not like a statement or didn't expect a statement like, no, it's not sufficient. And ISO 27001 is more like, okay, I handle my risks. Stop. And if the risk is I accept everything, then it's conformed more or less. So for instance, automotive industry, and this goes back to the topic how to really secure some kind of standards. Automotive industry implemented the TYSEX stuff. Assurance level three, something like that. This is more or less concrete what they expect.

For sure, it's also not sufficient in many cases, but it's a good starting point. You laughed a bit. So feel free to challenge. Yes. So first of all, looking from an internal perspective, if I want to set up and operate a good security operations, I think going to the standards and taking it and not reinventing the wheel is a good measure. But having a third party issuing or showing me that it has different certifications, I think is not trustworthy. So I have had incident responses led at clients that had a TYSEX certification, that had ISO 27K certification in place.

And it was basically just an Excel spreadsheet that was answering the controls. And they found the right companies that did the audit based on this and issued the certificate. So it's not warrantying that's ineffective and in place. And TYSEX is basically answering 120 questions. And if the auditor behind this is not sophisticated or has not the efforts to put into making sure that what's on the document is implemented in reality, I have challenges. So I would recommend to look at who has issued that certification, so who has been the entity in charge.

I would try, if possible, always get a second opinion either by myself to go there and ask and show evidence and figure out whether there's a document and the ZOAR is matching what I find there. Because there's a whole certification, be it different ISO certifications and so on. There has been a blooming business in China. You could get any certifications for 400 bucks without that somebody is coming to you. And from TÜV Rheinland and others. So that's kind of a business model there.

So I would not go down that road and say, okay, every SOC 2 or every ISO certification that is shown to me is representing the truth. So I would also implement their goals, see for yourself and verify or at least have an eye on who has done the assessment and is this a trustworthy actor. This is more or less the topic we discussed earlier, right? So really considering more than that. So coming back, we cannot rely on that. It's just one bullet point on the checklist I need to verify for my supply chain. In respect to the time, six minutes left. That's crazy.

But we have a bit more time, I guess, today. Any question from the audience to the two experts here on stage? No? Otherwise? Yeah. This all sounds to me like the regulator has a set of requirements and has basically put all the loads to solve this problem. Would it be conceivable that the regulator itself establishes some – they want to have the transparency because they want to protect the infrastructure at the states and so on. That the regulator solves this and asks all the defined points they want to have to make all the supply chain end-to-end transparent by themselves.

That the big picture is present at the state level or at the regulator level. And not to put this load onto your shoulder and then somehow that you have the loads to solve this. I don't understand this approach that that's a set of requirements and now solve it. It would make more sense to have it centralized at the state level. You could actually say yes, but the thing is they have a different mandate. They have a different role to fulfill. Very simple.

Okay, so their oversight, they're setting the rules to protect the ecosystem. The state, the companies, the people, right, from bank perspective. And that means the companies who are in scope, they need to fix it. And let's take DORA or let's also take NISQS. I think it goes far beyond as ever we have done it before, right? So you have – as a regulator you only can oversee those companies which are in your scope. This is banks, generally speaking, okay? But now it's going far beyond.

So basically you are as a company in scope, you are now asked to oversee the world on behalf of the regulation. It means we need to make sure that our partners across the globe, sitting wherever they sit, are complying with European law.

Okay, that means we are mandated tasks to ensure that all the companies we are working with in this chaining perspective fulfill our own requirements which are perceived as valid maybe, which is a big, big extension of the oversight rule. And the local European regulators, they do oversee it. They get their regular notifications. They fully understand our partners. They collect it. They do the M2M relationship, the mapping, and then identify hotspots. So I think that will not go away. It is with regulated entities, yeah. It is not working like this, unfortunately, yeah.

But it's also the quantity. So yesterday I was at a client, large German logistics company. They have more than 480 applications that they need for their daily business. So it's not 480 vendors, but it's a lot of vendors that needs to be audited, checked. The products need to be tested. So this is a huge effort. And looking in Deutsche Börse or Deutsche Bank or others, everybody is probably having a part of this using by themselves. And everybody is approaching the vendors in regards of checking. And sometimes the vendor is a three-people company or something.

And then a lot of companies are going and want to have audits and want to have protocols. So I would see that there would be an advantage in joining those efforts. So basically have one doing it for all. But I think the initiatives, and this is struggling for years, is kind of having a software liability certification. So that we basically have the liability at the vendors, that they need to take care that their products are working, that the standards are fulfilled, availability and security. And giving kind of like for the cars. But I think this has been hesitant for quite a time.

But also if you look at the industry in regards of DORA and needs to make all these checks and compliance, it's a tremendous effort to do all this. So the wish behind it, I think, is valid and good. But I think the implementation will just become a paper tiger, so to say. That is generating a lot of documentation. And I have checked and I have checked. And it will nothing be implemented. So it will not reach the end, unfortunately. But I think it's understood that, as you mentioned, right? That there's maybe the option to have one contract, right?

We have issued all different contracts, I bet, on the same thing. Yeah, on the DORA perspective. We all issue assessments, all on the same thing, based on ISO, but they all look different. And what you also mentioned is that certifications may or may not be reliable. That means we have no trustful partner, which is like when you get a test for a year end. I think that company is somehow in the liability when they write it, at least for one year. And that actually is not so much existing.

I mean, there is no trustworthy data points. And that means the whole thing doesn't fly.

And, Tobias, maybe that's a good point for the next question. How can companies leverage innovative technologies or approaches to really identify and address such security challenges or processes to improve supply chain security? Is there a fantastic tool by vendor ABC that I can just install and it makes me more or less happy?

Look, I think I don't have here the silver bullet or the plated bullet. I think in my speech before I mentioned that the things which we are currently doing, and this is a little bit hands-on, but it's definitely state-of-the-art.

Obviously, in the future you could think about all the crypto, we talk blockchain, we talk fancy things, which magically tell me the ratings of the exposure and all these kind of things of my chain and blah, blah, blah. Okay, but I think this is really future. And I think there is not that tool available. There is not the process there, whatever algorithm available. Data points are not available. So we are working against a significantly higher uncertainty. And partnership is good, as Petal asked earlier, but the question is how you can go with the trust, right?

It's an economical discussion as well. It's a business discussion. It is always somebody hides shit. It means you hardly can trust, okay? And if it blows up, you get to follow the sun. It's really difficult. That means we are trying to do our best at the moment in a kind of economical way, which I believe is really hard to achieve the economical part. And we are trying to get something meaningful out of it, okay? Because we are checking compliance, we are not checking risk. We try to make something out of compliance data points, a risk exposure, which is not a tough question.

So really difficult at the moment. So afraid to say there is the magic. I don't think there is a magic. Maybe VeChain, I don't know. It's probably the magic in the crypto space, but I think there is nothing available. And we are all sitting in the boat that we try to find the answer for the one billion question.

André, your thoughts? Yes, I agree with you. I think there are some solutions in regards of supply chain risk. So there used to be a tool by the Pentagon that was built exactly to manage third-party supply chain risk. So basically observing globally the attack surface of its many vendors and providers. We have acquired this tool five years ago. This is a part to what can be done. But I would say in regards of emerging technologies, I was just thinking, remembering 1,400 pages of regulation.

If you have a team of 20 people and maybe use some large language model to make five relevant pages out of it, that's not 20 people are reading 1,400 pages each. But besides, I would agree that that's a joint effort of different technologies, people, and processes to handle all those, unfortunately. No silver bullet. Perfect. Any questions from the audience? Yep. Two additional checks. So what I think the current practice is a long-term model.

Yeah, I would say the challenge there is that if you look into products that are certified, as an example for Pharma, for confidential infrastructures, it contributes to that you have legacy systems because you basically waive the certification with updates and patches. And for Pharma industry, for defense industries, this can become a challenge because if my recertification process takes three years, but just considering Microsoft, every month there is Patch Tuesday, then this becomes more of a challenge.

So we need to figure a solution that is flexible enough but still maintains the trust level of there is kind of a stamp on it that says you're good, but still be flexible enough to be able to patch and update systems. Okay, perfect. If there are no further questions, I would say thank you again, André and Tobias, for participating in this panel and giving your insights from Palo Alto Networks and Deutsche Börse as well. This was really valuable for us, I think. Thank you. Thank you. Thank you.