Ensure Your Supply Chain Continuity – Even Under Pressure

Cybersecurity threats to an institution are no longer limited to the organization themselves, as threat actors launch attacks across the entire supply chain in hopes of disrupting the financial services sector. Managing supply chain risk is top of mind for Ariel Weintraub, Chief Information Security Officer, Aon, who emphasizes that cybersecurity is not a competition, but an opportunity to share best practices and timely information to maintain the resilience of the global financial sector.

Transcription (edited for clarity)

Elizabeth Heathfield, Chief Corporate Affairs Officer, FS-ISAC: Welcome to FS-ISAC's podcast, FinCyber Today. I'm Elizabeth Heathfield, Chief Corporate Affairs Officer at FS-ISAC. Managing supply chain risk is one of the sector's thorniest issues. If our customers can't access our services, it doesn't matter who's to blame. Our reputations and our businesses are on the line. I spoke with Ariel Weintraub, CISO at Aon, about how financial firms and the sector can achieve supply chain resilience to ensure we can keep operating no matter what.

Elizabeth Heathfield: Thanks so much for being here. I know it's a topic that we've talked about before, but how do you define supply chain resilience in today's world?

Ariel Weintraub, Chief Information Security Officer, Aon: Well, I think first it really does mean different things to different people. Resilience is different in the cyber lens than it is in the physical lens. But for us, and I think it probably does apply to physical as well, what are the critical links, both upstream and downstream, that could have a significant business disruption to the entire business or to business processes? And then how do we eliminate those or create more opportunities for switching so that we have less disruption?

Heathfield: Given some of the recent incidents, CrowdStrike comes to mind, but it's not the only one. Where do you think we are as a sector on the journey to supply chain resilience?

Weintraub: I think that the hardest part about it is the cost of switching. The switching cost we've created, both from a security supplier standpoint, from a broader technology standpoint, we've created these really sticky business processes and solutions that make it more difficult in the event of an emergency or even in the longer term to switch out problemsome suppliers.

I think as a sector, we're struggling with more of the agility that we need to be more resilient. So, the stickiness of the way we've implemented a lot of these bits in the upstream and downstream process, I think have been the biggest blocker to what could be more of a resilient process.

Heathfield: How do you think we tackle that problem? Because as you say, we as a sector, we're dependent on quite a few large suppliers. How do you think we get out of the situation that we're in?

Weintraub: I think there's so much customization that we do, and I'm talking specifically about technology suppliers. We do so much customization of, okay, this isn't going to work for us out of the box because every organization thinks they're special, right? That they have their own problems. And so, we create so much custom workflow that, again, back to the switching costs, it would be a big project to switch from one to the other. And maybe I'll use cloud as an example also of where resilience could work better if we were focused on, which is we don't as an industry take advantage of really being cloud native. We aren't containerizing all of our applications. And in a truly cloud-first environment, you actually can switch from one cloud provider to another if everything is in a container. Maybe not instantly, but faster than we would be able to today. But I think especially in financial services where we have older applications and platforms, even when we're moving to the cloud, we're not fully containerizing that they're cloud-native such that we could easily switch from one to the other. But if we use it as kind of like a model, how can we do more of that containerization of our solution so that either in an emergency or in the event of a shorter-term disruption where we need to move from one to the other, it's not, starting from the beginning of moving from one solution to another.

Heathfield: What role do you think AI and automation have in this journey?

Weintraub: I mean, certainly there are some tasks that today maybe humans perform that could be sped up through automation. With agentic AI, for example, maybe we can make faster decisions about how to move from one function to another using the same kind of methodology that a human would use but maybe speed up some of those or using more information, giving that agent more context about how other companies maybe solve that problem. So, I think it's probably early in developing that. I'm thinking about it in the knowledge worker space of how we can speed up some things that are knowledge worker specific. It's not going to be autonomous, but it's giving that a little bit more context to make better decisions and faster.

Heathfield: I want to go back to the containerization. Do you think this is standardization? Because you know what you were talking about earlier, right? It's also a standardization, right? This idea that you're not actually that special. Yeah, like you could probably do things in a more standard way, which would enable you to change faster. Do you differentiate between containerization versus standardization?

Weintraub: Well, first I just made it up. I think maybe. I do think that they're slightly different, which is, and I started to go down probably the standardization path, which was, yes, we've customized too many things, and that's why when we say we're just GRC platform A, we want to put in B, it's not just about taking this one out and implementing this one. It's walking back all of the things that we've integrated it with. So that's probably more in the standardization category.

Containerization, if we try to apply that more broadly than what is really intended, might be above and beyond that, which is leveraging some of the more modern-day technology, like APIs, where maybe the better word is orchestration, creating more orchestration layers so that the things that sit between are less sticky. If you're connecting A to B and there's a thing in the middle, the thing in the middle doesn't necessarily need to know what's on either side. And as long as the thing in the middle stays the same, then it makes the switching a little easier. Now, of course, now the thing in the middle becomes the roadblock or the bit in the supply chain that's now critical. So how do you think about that? I think that that's kind of the model that I'm thinking about of creating less stickiness in the workflow to create more opportunities down the road for resilience.

Heathfield: Yeah, it’s more flexibility. Yes. So, let's talk about the A and the B. What percentage of services that, you know, let's say large financial institutions have that you also have a B for. Are you being required to have more backup suppliers?

Weintraub: It depends on the size, scale, and importance of the organization and how it fits into the sector. From a regulatory standpoint, companies that have an impact on the sector itself, they're more the backbone of the financial transactions. Those, I think, are given more direction to have those multiple suppliers.

Other companies, mine included, aren't necessarily viewed in that type of perspective. We're not necessarily upstream in supply chain resilience. We may not directly be given that sort of pressure and therefore we're more potentially vulnerable to not having those backup options. But it all comes down to cost, right? We don't have unlimited resources. So, we have to decide which are the ones that are necessary to have that backup solution. But maybe where we need to be headed to is more partnerships. Maybe vendor A and vendor B, and certainly this has sales implications that need to be sorted out, but maybe they need to have more partnerships. To that need then that something happens to one, there's another one to come save them. In reality, I don't know how that works. And I have a long history of working on this side, not on the supplier side. But I think that's the key to unlocking like solving for the whole sector versus just solving for individual organizations.

Heathfield: Say you're required to have a backup supplier for a critical function. Besides the pure cost, there's also just like the overhead of managing that risk as well, right? So how do you think CISOs and security teams need to think about that when they're looking across? Thinking about what makes sense for us to have backups for, that also means it's just yet another supplier that we have to manage the risk for.

Weintraub: I think there's one argument to say that fewer suppliers is better because it's a numbers game. At any given point, any company, any supplier could have a significant incident, whether it's a cyber incident or an IT outage or whatever it is. It is a numbers game. There is math there that if you have a smaller number of total suppliers, the likelihood of one of your suppliers being impacted is certainly smaller. But on the other hand, then you don't have that optionality in the event that the one that you do have gets hit. I don't think there's a perfect in the middle, but I think you have to balance both of those. Yes, you don't want your total population of vendors to be higher than it absolutely has to be. On the other hand, you don't want it to be so small that you have no optionality.

Heathfield: Let's talk about disconnection and reconnection because I also think that that's obviously a conversation that's happening a lot. How did those considerations play into the concept of supply chain resilience?

Weintraub: I think we've broadened this topic such that there's too much of a scare tactic because the reality of how we directly connect from one company to another is often quite small. And the likelihood of certain types of, for example, ransomware spreading from one to another, is very dependent upon where that incident actually occurs. And I think sometimes we're a little quick to jump to conclusions. We hear about this company facing a ransomware incident and we have to cut all ties with them. That means email. That means any connectivity that they have with us. Maybe we're afraid to even pick up the phone. And I think there's like a reality of we really need to understand what their incident is and what it does impact to make that decision. And the reality is there's probably a very small percent of incidents that actually have likelihood of spreading.

Now this requires more talking to each other, which is of course, you know, where FS-ISAC comes in as an opportunity because with the information sharing, I think together we can make better decisions versus making a knee jerk reaction and to say, well, I don't have all the facts and therefore I'm going to take the most restrictive stance and say, I don't, don't trust them anymore. I'm going to have to just disconnect.

Heathfield: Is there a tension between how individual firms need to think about managing their supply chain risk and resilience and how the sector at large thinks about it? Or are they aligned? Or can it be that they sort of go into opposite directions in given cases?

Weintraub: I think it's the latter, I think the information sharing part of that's what's most important. Then optionality, those two things together. Of course, in the event where one leading supplier is broadly used, for example, the one you shared before, and that it has a disproportionate impact on the sector. On the other hand, you have a network of other companies that are dealing with the same thing. So solving the problem and the response is actually faster because you're able to leverage the insights from your peers and it's not just solving this problem by yourself. So yes, would the broader impacts have been smaller if not as high of a percent of companies used to that particular product? Sure. But I do think we also really banded quickly of like here's some tips and techniques. Have you this? Have you tried that? It probably would have been worse and recovery times would have taken even longer if we didn't have those information sharing practices.

Heathfield: So obviously resilience is a key focus of ours, it's a key focus of regulators, it's a key focus all around. Beyond exercises and incident response playbooks, is there anything that we should be doing that we're not yet doing to prepare for a really big systemic incident?

Weintraub: I think the regulatory pressure will continue to push against, in some ways, some of the information sharing opportunities. I think just continuing to focus on the fact that we're not competing based on cybersecurity. We're not competing even based on technology availability. We're competing on the businesses that we're providing. Viewing it in that way, I think, just makes people feel better about sharing with each other the best practices.

So yes, formal things like tabletops and playbooks and all of that. But the reality is when the thing happens, beyond just taking out your playbook, you're calling the other person that may have either previously experienced something or just may be an expert in a particular area. I think it's really just continuing on the connectivity between firms and creating that opportunity for sharing best practices.

Heathfield: Anything else that we should be talking about that we haven't really touched on? Because I mean, it's obviously the North Star. We want to keep operating no matter what. No matter how far we've gone individually as a firm, if we continue to experience these outages, we're going to continue to have to be responsible for it. So is there anything more that we can be doing?

Weintraub: I think it's just over emphasizing that response is equally important as detection and prevention. We will never prevent all of the incidents from happening, either within our own company or within a supplier that we use. Yes, practicing, but you know, I'm not talking about practicing via tabletop because that just doesn't look the same. But how do we flex our muscles and get better at the actual response part?

Are there ways that we can truly simulate what it looks like to have a full availability outage? It doesn't even matter if it's caused by a cyber incident or an IT outage. How do we create more of those non-paper-based exercises so that the stress associated with it too is something that's really real? mean, even just the human impacts of how do you coordinate people's personal lives that things like childcare and other responsibilities that people have. You don't plan that really into your playbooks. I mean, some of these incidents, if large enough, this is an all hands on deck 24/7 situation until it's resolved. You know, you can't really simulate that no matter how hard you try, you're not going to simulate some of the stress associated with that. But maybe how do we focus on that more and have options for recovery solutions? And maybe it's, leaning on other teams and other companies to assist to come in and be part of an incident in support of another. 

This was a problem when we first talked about this, the first time, and it is now because it is so complex. As technology becomes more complex, the problem becomes more complex. AI, I'm sure, will create additional things that we're not even thinking about in the supply chain problem. So, I look forward to that podcast in two years.

Heathfield: I'll see you then, probably before as well. All right. Thanks so much Ariel.

Weintraub: Thank you.