Patchmageddon

MICHAEL CEMBALEST: All right. Good morning, everybody. This is the July Eye on the Market podcast. This one's called The Summer I Turned Pretty, which I'll explain. And earlier this year, on my TikTok feed, I was bombarded with all sorts of clips from a TV show called The Summer I Turned Pretty-- which I never saw. But I used it for a tagline here because this is the summer that I turned pretty cautious on two pretty important topics. And that's what we're going to talk about on today's podcast. 

Cautious about zero-day cyber attacks resulting from the latest frontier AI models, and that's going to be the bulk of the discussion on today's podcast, and, also, cautious about some market technicals and some growing challenges to the frontier labs from both new open and closed weight models. And let's start with some of the market technical issues. 

And there's a bunch of people that have been writing similar things. This is some work a colleague in the investment bank, Jason Hunter, has done. If you look back to the late 1990s, there was a point at which the communications stocks flatlined, even though the infrastructure stocks kept on rising. And as a proxy for that, think about Juniper Networks and Verizon and things like that. 

So you had this period on the market where the front end, which was the communication services stocks, started to flatline, but the infrastructure stocks kept going, and it was a bit of a head fake to the market. We're having a little bit of a parallel right now because the hyperscalers, which are the front end of this AI boom, are seeing their stock prices stagnate and their free cash flow fall, even as the semiconductor and other infrastructure providers and optical networking companies are continuing to go up. So there are some parallels here that I think we need to think about because you always want the caboose going slower than the front of the engine, and that's not what's happening. 

There are also some serious challenges to the frontier labs-- and by that, I'm obviously referring to Anthropic and OpenAI-- coming from a whole bunch of new models. And for those of you consuming this in video form, you can see this really colorful chart that's become somewhat standard in discussions about these different models. On the y-axis, you have some kind of measure of their productivity and performance. In this case, it's a benchmark focused on math and reasoning and coding tasks from this group, Artificial Analysis. And the x-axis is typically in log scale. And importantly, it's not cost per token, it's cost per task, because models can differ on the intensity of how many tokens they use and need. 

So it's better to just look at net of that efficiency, what's the overall cost of a task. And this curve used to be such that OpenAI and Anthropic frontier models were way better than everything else. Now, you can slide to the left on this chart. And Meta has a new model. SpaceXAI has a new Grok model. There's a new Chinese model where, all of a sudden, you're looking at models whose performance isn't that different from the best OpenAI and Anthropic models at either a third or a tenth of the cost. 

And so, I can imagine there's a lot of CFOs-- and I've spoken to some of them already-- that are starting to think about, hey, maybe these models can work for us on certain tasks. Not all of them, but some of them are having a bit of a sticker shock on the token bills that they've been paying. So there's two pieces to the Eye on the Market that are coming out today. One of them is on the cyber issue, and the other one is on these market technical and frontier lab challenges. And all that information is in the email. 

Just two quick things-- Thinking Machines, which was launched by some people that used to work at OpenAI, finally released their model. And as expected, it looks pretty good. And it's a mixture of experts' model, and I wouldn't be surprised if they were a serious challenger as well. And you're probably hearing a lot about Kimi K3 from a company called Moonshot. It's Chinese. And just to give you a sense, it costs about 30% as much in terms of input and output tokens as some of the other best models with similar performance. So, again, take a look at the Eye on the Market today for that. 

OK, so today is a first. So I'm having a co-host on the podcast, which I haven't done before. I should probably do that more often because some of our listeners probably are tired of hearing me drone on and on. But Pat Opet is here, and Pat is the Global Chief Information Security Officer at JP Morgan. And you've been at JP Morgan for more than a decade? 

PAT OPET: Yeah, 12 years. 

MICHAEL CEMBALEST: 12 years. And Pat and his various teams have worked and helped me write a piece called, "Patchmageddon, the race to patch software vulnerabilities before zero-day cyber exploitations proliferate." So a lot of jargon involved, but Pat's here to make sure that everybody understands in layman's terms as much as we can what's going on. Thank you. And welcome to the podcast. 

PAT OPET: Well, thanks for having me. I'm excited to be here. 

MICHAEL CEMBALEST: I know. I might do this again. So, even before Mythos came along, right-- because Mythos was a bit of a shock to the system earlier this year. Even before Mythos came along, the data that your team shared with me shows that the pace at which vulnerabilities in the systems that big companies use were being found and disclosed at a much faster rate than they're patched. 

PAT OPET: That's right. 

MICHAEL CEMBALEST: And what's it like to be inside a large organization where it's raining vulnerabilities, and you have to patch them? 

PAT OPET: Look, it's very difficult. And obviously, a lot of automation and tooling has been built over many years to help find vulnerabilities in software. But there isn't so much automation and tooling that helps organizations fix vulnerabilities. Fixing vulnerabilities requires putting new software in production. That often means that you have to do thorough testing to ensure that the new software you're putting in production doesn't break any other features. And for companies like ours, where continuity of operation is very important for our customers, that's a very careful process. 

Multiply that by the various industries and the difficulty in, perhaps, reaching the software that has to be put in production. Think like industrial control systems that aren't easily accessible or teams that don't have sufficiently sized technical teams. It becomes really onerous to keep up with the rate by which vulnerabilities are being found. 

MICHAEL CEMBALEST: So analyses differ here, right? But this chart is a proxy for, how long does it take for organizations to remediate things that need to be fixed? That's the gold line. And then the falling blue line is Time To Exploit, right? 

PAT OPET: That's right. 

MICHAEL CEMBALEST: TTE-- why is that such an important concept for people to understand? Because I've been seeing it everywhere. 

PAT OPET: Yeah, so when a vulnerability is found, it is a flaw in a piece of software that could be abused by an attacker. The exploitation process is the attacker actually abusing that software. And so, typically, if you look back several years, teams had time, days, between a vulnerability being discovered and an attacker weaponizing that vulnerability. 

But through, again, new tooling, and in particular, various AI systems, attackers can now exploit vulnerabilities much more quickly to the point where attackers are actually both discovering the vulnerabilities and exploiting the vulnerabilities before the defenders even know they exist. That is colloquially called a zero-day, which is now dominating the headlines. 

MICHAEL CEMBALEST: Yes, and in this chart, in 2020, there was 30 days in between the disclosure of eligibility and its first exploitation. And those numbers have fallen basically to zero. And obviously, what industries are at risk? A lot of them and across a lot of different parts of the economy. And so it's not like one particular industry is more at risk than others. 

The ECB put out this financial stability review, and I thought it was kind of spooky that the largest component of who's doing this fell into a category called unknown. Why is it so hard to know who's doing it? Is it just the nature of-- 

PAT OPET: Just, what's called attribution in cybersecurity, associating an activity with an attacker depends on tradecraft and tooling and patterns. And over time, state actors or criminal actors have either diversified their supply chain, so it's not just them or their team doing an action, and they depend on many different parts of the community. Or they've intentionally obfuscated their actions by hiding them to make it much more difficult to attribute the action. 

MICHAEL CEMBALEST: OK, so a real attribution of this might find the state-sponsored sector much higher than what's in the chart? 

PAT OPET: Yeah, or criminals. 

MICHAEL CEMBALEST: Or criminals, gotcha. OK, so in April, Mary sent me an email saying, hey, you better look into this Mythos thing. And I didn't what Mythos was. I thought it had something to do with the new Odyssey movie, like it was some Greek thing that was coming out. And obviously, I spent time looking into it. Your team was helpful to me at the time. And I came across this chart. And this chart spooked me, which is why I included it in the Eye on the Market at the time. And it's from this AI Security Institute in the UK. 

And the purpose of this analysis was, with 32 steps across lots of different points of a system, you can execute a full-system takeover, OK? At the time, the existing frontier models can only get about a third or a halfway there. And then Mythos came out, and they published a big uh-oh. Mythos just went all the way up the food chain and completed the 32 steps. And then a couple weeks after that, it was disclosed that GPT, I think it was 5.5, did the same. 

PAT OPET: That's right. 

MICHAEL CEMBALEST: What are these different barriers that it has to get through? 

PAT OPET: Yeah, so I think there's two important things to take away from this chart. One, cyber attacks occur in various stages, oftentimes called a kill chain. And so, what's being described here is a model autonomously working through that kill chain, end to end, being able to exploit-- 

MICHAEL CEMBALEST: Autonomous? 

PAT OPET: --an organization without hands on keyboard, without an operator. And so, what this is really meant to measure is the autonomy of a model being able to execute end-to-end and attack through each of those stages. But I think it's a little bit misleading, because if one just takes away the fact that models will be able to autonomously attack corporations, it misses the point that what they're also doing is accelerating and augmenting skilled attackers. 

So, let's take criminal attackers versus states. State attackers have exceptional capability that's very well-funded, and they are by far the most dangerous attackers when we talk about cyber actors. Criminals are very dangerous, but they may be less skilled, less well-funded, or less resourced. All of a sudden, when you take these capabilities provided by the frontier models that, in one sense, can autonomously execute attack, but with a skilled operator, you boost the capabilities of that skilled operator pretty precipitously. 

MICHAEL CEMBALEST: It's interesting because a lot of the AI research coming out of Stanford and Harvard is, within an organization, it makes your lower employees better-- 

PAT OPET: That's right. 

MICHAEL CEMBALEST: --more than it makes the great employees better. So, similarly, it's doing the same here. 

PAT OPET: Same thing applies. 

MICHAEL CEMBALEST: Oh, wonderful. And I thought this chart was interesting, too, because here, you can really see the impact of the new models on the pace of critical and high-severity vulnerabilities that get reported. The CVE is a critical vulnerability. There's some kind of a central repository for this kind of thing? 

PAT OPET: Yeah, there's a mechanism to disclose these-- reserve a number associated with the vulnerability and then inform the market, all the consumers of the software, that they need to fix something. Obviously, criticals and highs are the most important because they're the easiest to exploit, and they can create the most damage. They're often hard to find. 

The really interesting part of these models is that they can compute on software in ways that allow them to either chain various flaws together, or to recognize that there are much more severe flaws in the software that we knew to exist at a scale that is significantly more than we typically deal with on an annual basis. 

MICHAEL CEMBALEST: I mean, look at this thing. I mean, the number of criticals were running less than 10 consistently and now hit 400, right? 

PAT OPET: Yeah. 

MICHAEL CEMBALEST: This is pretty asymptotic. So I don't want to go through too much detail here, but we have some stuff in the piece that talks about-- and when Mythos first came out, this first bullet point got a lot of focus, which is, oh, my god, Mozilla had all of these vulnerabilities in Firefox that nobody knew about until they started using Mythos to try to figure them out. 

And the third bullet point I thought was interesting. 95% of the Mythos vulnerability disclosures had no public advisory at the time they were found. Does that mean what it sounds like? 

PAT OPET: Yeah, they're novel. 

MICHAEL CEMBALEST: OK. So-- 

PAT OPET: The model is finding new flaws in software that security researchers, in some cases, over decades, were unable to find in some of the most well-trodden pieces of software, like the Linux operating system. And the way in which the models are able to compute on software allows them to find these exquisite or novel weaknesses. 

MICHAEL CEMBALEST: The other parallel here is, last year, I talked to a group at Stanford in biotech. And there's this thing called antibiotic-resistant bacteria, MRSA, and it kills, like, 10,000 people a year. And they used some of the same models to go through 30 million possible compounds, and they found two that might work in mice trials. So there are a lot of parallels here with the way that people are using these for good things in terms of-- as opposed to the bad things. 

This chart was also kind of unnerving. It's the share of exploitations occurring before or on the day of disclosure. So it's like you come into the office, and you sit down at your desk, and all of a sudden, there are these-- 

PAT OPET: There's a problem. 

MICHAEL CEMBALEST: It may not be you, but there are other companies that have suffered an exploitation. 

PAT OPET: That's right. 

MICHAEL CEMBALEST: And you have to deal with it. 

PAT OPET: Yeah, and I think this just lends to the same point, is that as tooling has gotten better, it's enabled attackers to find vulnerabilities at a broader scale. When attackers find the vulnerabilities and not defenders, they can weaponize them right away. And so, you prefer the other side. Defenders are finding the vulnerabilities first. They're then fixing those vulnerabilities and pushing disclosures. Companies are consuming it and fixing that software before attackers weaponize it. We've essentially inverted the process. 

MICHAEL CEMBALEST: Right. Now, one of the things that was really eye-opening to me as a layperson, I always knew that open-source code was "important," quote unquote. I had absolutely no idea that it is as pervasive and widespread in terms of building blocks as it is. And one of the things we have in here is a timeline of some of the major open-source projects and what they eventually enabled. This goes back to the 1980s, some of this stuff. 

PAT OPET: That's right. 

MICHAEL CEMBALEST: Economists tell me this shouldn't exist. Economists theorize, why would people do all this work for no compensation? And yet, it has existed for 40 years. 

PAT OPET: Yeah, I mean, it's like people get to pursue mastery, and they get purpose, and they can make impact despite being paid. And that's why-- 

MICHAEL CEMBALEST: Despite not being paid. 

PAT OPET: Right, right, despite not being paid, which is why open-source really thrives. 

MICHAEL CEMBALEST: Right. Now, there's a chart in here that just summarizes a couple of things. And these were eye-opening to me, so I wanted to share them with our clients. The share of commercial code bases with open-source code is in the high 90s; the share of open-source projects with fewer than 10 maintainers or developers that are responsible for most of the code, 94%; and then the share of commercial code-- this font is too small for me-- made up of pre-built open-source libraries and networks, 77%. 

So, even within the vendor software universe, of all the things that we buy as JP Morgan, the vendor software we're buying is highly reliant on open-source code. The code that we write internally is reliant on open-source code. So open-source code is a much bigger foundation of everything that I had ever suspected. 

PAT OPET: Yeah, and you have these nested dependencies where a piece of software may overtly use open source, but may also have a dependency on another piece of open source that isn't so overt. And so these things get built over time, and it creates complexity in the software that we use, but also, for defenders, complexity and understanding where all of your open-source dependencies are to fix them where there is an issue. 

MICHAEL CEMBALEST: I saw this one citation from CISA on a JavaScript thing. There were 10 direct dependencies and 680 indirect dependencies-- 

PAT OPET: That's right. 

MICHAEL CEMBALEST: --which is kind of amazing. Oh, yeah, here are the dependencies. The mean number of open-source components per commercial application is almost 1,200. So that means that we're contracting with a certain vendor. And in order for that vendor software to work, either if we're running it remotely or in-house, we have to have 1,200 other pieces of code to support it. 

PAT OPET: Yeah, in some cases, they're built into the software package. I mean, there's probably a bit of influence of the SaaS ecosystem that has changed these numbers. So when a vendor provides a SaaS product, obviously, that's a whole suite of software, which likely includes a significant amount of open source. But-- 

MICHAEL CEMBALEST: And then who's responsible for updating that, them or us? 

PAT OPET: The vendor. So, in any vendor package, it is always going to be a vendor that's responsible for updating the software. So we have very little autonomy when it's a piece of software that we haven't written, whether it's outsourced or whether we're consuming that software, which is an important part of the process of ensuring that your vendors are paying attention to the Patchmageddon, as well as first-party companies. 

MICHAEL CEMBALEST: Look at the last bullet point here. This is from Linux Foundation. 95% of open-source vulnerability reside in the transitive dependencies, rather than the direct ones. 

PAT OPET: That's right. 

MICHAEL CEMBALEST: That's amazing. And for investors, a lot of the names that you know and love-- Red Hat, Databricks, GitHub, Hugging Face-- a lot of these are heavily reliant on, if not built entirely from, open-source code. 

PAT OPET: Yeah, and some of these companies are both the maintainer. They're the professional entity that maintains the open source or the ones that created it itself. And so, when we talk about open source, we differentiate between community-backed, which is individuals, or foundation-backed or professionalized open source, where you have a company that's-- 

MICHAEL CEMBALEST: The standard line. 

PAT OPET: --the steward of the software. 

MICHAEL CEMBALEST: Tell me if you're surprised at this. This was the survey they did. 61% of reported incidents are associated with unapplied, but available patches because over 80% of security professionals decided not to do it because they didn't want to disrupt the workplace. 

PAT OPET: Yeah, I mean, look, patching is hard. And so, I think that that's the first thing to recognize, is that including new software and getting it released to production without incident is a difficult thing for many companies to do. And oftentimes, we bias, as a community, availability. Incidents, whether they're caused by a patching process, or, in some cases, adversary disruption, have the same net effect. The software isn't available to consumers. 

And so, in many organizations, they may bias availability over fixing. And this problem hasn't presented itself as significantly as it's-- 

MICHAEL CEMBALEST: As it presented-- 

PAT OPET: --presenting itself now. And so, the calculus on patching is going to have to change for those organizations that don't have it as a first-class priority. 

MICHAEL CEMBALEST: And by the way, in terms of disruption, I was having all sorts of Zoom problems recently related to a Citrix patch. And I had to roll it back in order to get my Zoom to work. I will deal with that separately. One of the things that you mentioned was physical infrastructure. And explain-- how is physical infrastructure different than cloud-based digital infrastructure? 

PAT OPET: Yeah, so servers or switches or firewalls all run code. And the goal is to keep those kits, the physical infrastructure kit, current. But oftentimes, organizations tend to sweat their assets. They don't replace that physical infrastructure as frequently as the providers would recommend, and it may fall out of maintenance, or it may lag the current release of code. 

What's going to happen now with the number of vulnerabilities that are being found is that providers are going to be forced to fix the current software first. And so, they're going to prioritize, maybe explicitly, only the current software, which means that older software, especially if it's end of life or end of service, may not get patched or may not be available to patch. And so organizations now are starting to think about all of this hardware refresh that they must need to do if the patches don't come for the older end of service kit. 

MICHAEL CEMBALEST: One of the things that we get into on the infrastructure side is sensors and operational switchboards and device controllers. And what are we talking about here? We're talking about the stuff behind air traffic control systems, municipal waste treatment plants, water purification systems, the grid, gas and oil pipelines, electricity networks. This is the kind of stuff. And I think I saw-- a lot of digital assets are often replaced three to five-year cycle. This stuff can be a 10 to 12 or even-- 

PAT OPET: That's right. 

MICHAEL CEMBALEST: --longer cycle. 

PAT OPET: And it may run in environments that aren't easy to access it, distributed across a pipeline, instead inside of a data center. It's tend to be built for the longer periods of time. It isn't refreshed as regularly. But these vulnerabilities, especially when they occur in these devices, can be pretty dangerous to the operation. 

MICHAEL CEMBALEST: Earlier this year, JPMorgan on the investment banking side worked with some of the big industrial companies, ABB and Honeywell and Siemens. And they estimate that only a little more than half of all the industrial networks are patchable. And I spoke to them, and the implication from those engineers was a lot of the rest of the equipment will eventually have to be replaced, which is expensive and, I would imagine, time-consuming. 

Now, this is a controversial point-- and I know that members of your team have differences of opinion, which is totally to be expected. Some people have said to me, well, Mike, no problem, because these tools that are so good at finding the vulnerabilities can-- we can fight fire with fire. And we can use these same tools-- and people are using them-- to propose fixes in the case of Anthropic and actually run the fixes in the case of OpenAI. And I'm talking here about OpenAI's GPT-5.5-Cyber. They have a Codex Security plugin. Anthropic has Claude Security and a cyber verification program. What's your thought on this stuff? 

PAT OPET: Yeah, I mean, it is clear that agentic coding tools can help accelerate the process of fixing the vulnerabilities we're finding. They are, in some cases, difficult to institutionalize in enterprise. And so, while the capabilities may be there, it may be difficult for an enterprise to safely adopt these and scale the tools to all of the developers that need them. And then, separately, there are some emerging challenges around guardrails in these tools. 

So the cyber models are designed with less guardrails, so they allow cyber tasks, and they're typically provisioned to cybersecurity teams as part of trusted access programs or Glasswing, which was an announced program. The general models refuse to do cyber work or offensive cyber work because we don't want to create harm. Oftentimes when you're trying to fix a vulnerability, if the guardrails aren't properly tuned, it makes it actually difficult to fix the vulnerability, because a fix for the vulnerability and a test for the fix could be the same thing as an exploit for the vulnerability. 

And so, the guardrails and the conversation around guardrails, which is now emerging, is going to get a little bit complicated over, how much do we allow offensive cyber work because of the benefit of fixing versus how much do we try and prevent these models from being able to accelerate malicious actors' activity? 

MICHAEL CEMBALEST: Right. I thought it was true to brand, in some ways, that Anthropic would say, we're not going to do the fix, that's on you, and whereas OpenAI goes a step further, and their stuff actually will execute. 

PAT OPET: I think they're all trying to get to-- I mean, clearly, all these programs are aimed at supporting defenders. And I think what they all recognize is, in addition to the frontier labs in the US-- which you called out in the early charts-- there are open late models emerging which don't have the same guardrails and won't refuse to do cyber work. 

And so, for example, Kimi K3, an emerging open weight model, will happily do offensive cyber work and is nearly as capable as some of these frontier models. And so we are entering an era of time where cyber capabilities, whether we like it or not, are going to be readily available to arbitrary individuals. And that's going to create some real challenge for organizations. 

MICHAEL CEMBALEST: Let's get to, then-- that you guys published something that we linked to in the piece on action steps for business owners and governments. And I bolded the first one because I thought that there were some interesting things in here-- run the latest software versions; when possible, move applications off third-party dependencies when you can't identify the steward and when the steward appears to be a single shingle and/or does not exhibit good maintenance practices or where the package appears abandoned. That sounds like a lot of work. 

PAT OPET: Look, I mean, I think the simple way to think about this is, in our own experience with the open-source vulnerability analysis we did, if we simply move to the most current version of open source across all of our dependencies, 50% of our high-end critical issues fall away. 

MICHAEL CEMBALEST: OK. So that's a-- 

PAT OPET: Half the problem. 

MICHAEL CEMBALEST: --great first step for everyone. 

PAT OPET: Just maintain currency. Maintaining currency, again, may be difficult, may require you to be able to release software much more frequently than you typically do. And so we recommend that organizations accelerate their software release process at this point in time so that you can put code in production at will. 

And then the rest of this, frankly, it is kind of cyber hygiene and basics that we've described for many years. Our point in the blog isn't just do the basics, it's get exceptionally good at the basics, because right now, with the risk that's being created through these models, you need to be exceptional at doing the basics. 

MICHAEL CEMBALEST: Right. My guess is that you might not be able to buy insurance against not being good at this. 

PAT OPET: Yeah, insurance providers are certainly going to scrutinize these attributes. 

MICHAEL CEMBALEST: So let's close. In some of the calls that we did a couple of weeks ago, members of-- we have policy people here. JPMorgan has lots of policy people. And they felt pretty strongly about certain things. 

I want to focus on number three, because that's the one that jumped out to me the most, that the US government should create a government-hosted domestic cyber defense strike force capability with clear authority to support lifeline sectors-- health care, finance, electricity, and stuff like that-- both before and during serious incidents. You want to just kind of do a thought experiment about what that means and how it would work? 

PAT OPET: Yeah, I mean, look, the government's, obviously, a close partner with cyber teams across the country, especially those in critical infrastructure, and has been so through DHS and CISA for many years, as well as the US intelligence community. But when you think about the challenges that may be coming-- undeterrable actors, individuals, criminals, activists, or terrorists, with potential state-grade capabilities as delivered through these models-- we would argue that it's appropriate for us to consider a more fulsome homeland defense organization that can actually operate against these actors within US networks, not different than how we generally think of maybe the Department of Homeland Security or the law enforcement measures that we have that would counter criminals. 

Today, private sector entities are left to defend themselves against state actors, sophisticated criminals and individuals. I would argue, when you look at some of the data, we're not winning. The nation at large is suffering cyber attacks regularly. Ransomware is a thriving ecosystem. Fraud is well-funded through attacks. I think given the capabilities that are here today and coming, we need to think about new ways to solve this problem. And it can't simply rely on every organization to just, quote, "do better." And-- 

MICHAEL CEMBALEST: Right. So you'd be able to raise your hand as an organization and say, I need someone to airlift in and help me out here because I'm-- 

PAT OPET: Either that, because the country may get outstripped of the professionals who respond to incidents if incidents occur more frequently, or we may need to start to proactively disrupt operators when they're hosting infrastructure in our cloud providers or hosting links through our search engines or other things like that. We may need to take more active measures to ensure that they can't operate freely within the US. 

MICHAEL CEMBALEST: Right. One of the policy options I thought was interesting is I remember a few years ago, there was a Cash for Clunkers program for people to trade in their old internal combustion engine cars for electric vehicles. And one of your people mentioned to me a targeted rip-and-replace incentive system for obsolete systems that create national level risk. So I'm assuming water treatment plants and things like the FAA. And-- 

PAT OPET: If you look just simply at the last 12 months, the primary vector that bad actors have gained access to organizations is through exploiting what's called perimeter devices. So think security devices that are on the edge of your network or remote access devices that are on the edge of the network that are designed to defend against these adversaries. They're often old. They have vulnerabilities. They have poor trust architecture. And those devices have been the primary gateway for the actors. 

We would propose that across the 16 critical infrastructure sectors, we should scan for all of those vulnerable devices and just replace them. If you limit the actors' what's called initial access, by just taking that vector away, you can make this problem significantly harder, even though there are these great AI capabilities for an attacker. 

MICHAEL CEMBALEST: And, similarly, just updating to the latest software open-source libraries can dramatically reduce your risk as well. And so, Pat, it was great to have you on. And this was a great discussion. 

Why did we do this? We're doing this because we think that a lot of our clients who run large and small and midsize companies may be facing a bit of a tsunami here that they're not expecting. And they need to start to focus on this. And I think it's important for organizations like JP Morgan to take what we're learning from Project Glasswing and share some of those insights. 

PAT OPET: That's right. I really appreciate being here. And as you said, this is an important moment in time for many organizations to recognize the challenge that is now on our doorstep and to start to take those proactive measures to more fulsomely defend the organizations from disruption. 

MICHAEL CEMBALEST: All right. Thank you very much. Good to see everybody. We'll see you again in August. So long.