Session recordings

2025 Cybersecurity Perspectives: LIVE

MICHAEL REGELSKI: Good afternoon, and welcome, everyone, to Eaton Center in Cleveland, Ohio. For those of you who are not native to the area, Cleveland really gets a bad rap. Sunshine, blue skies-- that's what we have all around the year. We just don't like to advertise it because we like to keep the traffic low.

But we're really happy that you're here today. As Matthew said, this has been the sixth year that we've hosted this event. And probably wondering, why Eaton? We deal with electrical power. Why would Eaton be sponsoring this type of event? Why would we care about cybersecurity?

Well, in our part of our portfolio dealing with electrical power, it's really a very dangerous situation. We have high voltages, high amperage. And if functional safety is not built into those products, people could get severely injured or die.

And as technology advances and electromechanical devices start getting replaced with power electronics and with software, what that does is it opens up the products that we make and the electrical infrastructure to a different type of vulnerability. And that vulnerability is cybersecurity, which, if hacked or if insecure, can cause the same amount of damage that could happen if there was a functional safety breach.

So we took that as really a mission and a plea. And we said, you know what? We're going to be champions of that. We want to be trusted advisors in the industry. We want to help educate people on not only how to have the best deployed safety electrical products and comply with safety, but also how they comply with cybersecurity standards.

So for those of you that aren't familiar with Eaton, a little bit of background. So we're known as an intelligent power management company. And what does that really mean? Well, we manage different types of power-- electrical power, which is in our electrical sector, but also mechanical and fluid power, which is part of our vehicle group and our aerospace portfolio.

And we're just under $25 billion in sales. And we serve customers around the globe. And I think this picture really is pretty telling of the amount of breadth that we have when it comes to the customers that we serve. We don't really do anything on the power-generation side. But we take everything from the point of distribution at the substation and transmit it and make sure that there's safe application of electrical power all the way down through to point of use inside of various buildings, inside of machinery, inside of different residences. And this is what we do as a company.

So why the emphasis on data centers? Why are we thinking about that today? Well, I'm sure everybody has heard of the tremendous growth in AI and what that means. And you've probably been reading about the tremendous amount of power that AI factories and data centers are consuming today. So we wanted to just educate everyone and create awareness around the changes that are happening inside of data centers and what that means to the electrical power infrastructure inside of it and also what that means from a cybersecurity vulnerability point of view.

So looking at this, the way that data centers are designed today, it actually starts from the chip. And we'll get into why. But it starts from the chip, and it works outwards towards the grid. And in the past, it always worked just the opposite-- starts from the grid. Say, I'm going to go and build a building. How much power do you need? And it comes inward.

Now it all starts around, how much power is generated from the chip? And it's affecting everything that has to happen on the power-generation side. It's not only how much electricity comes from the utility, but it's how much is done in on-site generation and on-site storage. That transcends itself into how it gets converted from medium voltage down to low voltage, how it's distributed throughout a data center, and ultimately making its way back down to the servers and the processors that are in there.

And one thing that you could see when we start looking at all of these different blocks is that there's new technologies that were there. 10 years ago, we really weren't talking about microgrids being able to go and power a data center or on-site battery storage. And the battle over AC, alternating current, versus direct current seem to have been won centuries ago. But now we start seeing that direct current is being applicable in all of the data center power distribution. And it's really because it's more efficient.

The chips consume direct current power. So every time that we have to go and do a transition from AC to DC, we lose power, we lose efficiency. And ultimately that's requiring us to then go and have more power generated.

So you can see on the chart some of the growth factors that are out there. And essentially it's just tremendous. I mean, these are "once in a generation" type of opportunities for us when we think about the growth in data centers. So let's go back and talk about the chip a little bit, and why is that the center part?

Well, in the era of personal computers back in the '70s, when the CPU was kind of the center point, that had done a lot of tasks. And it consumed anywhere from 50 to 100 watts of power. And then in the late '90s, early 2000s, the GPUs started becoming more pervasive. And this brought up the power consumption inside of servers in the chips to another level. And today, they're hovering anywhere from 800 to a kilowatt of power inside of a server.

And then you start looking at quantum processing units. And now you're talking about another order of magnitude when you're looking at almost 25 kilowatts of power. So as our processing needs go up, the power consumption needs are also going up. And that's what's really driving the tremendous growth and power in data centers.

So, OK, we see that. But why is that changing a lot of the technologies that are occurring inside of the data center? Well, it all has to do with communications. And it's not just a matter of a single processor doing all the work, but it's a matter of multiple processors, multiple GPUs, all communicating together to go and serve the needs of an AI response.

So all of these, if you can look at it from the different layers here, L1 through L3, it's not a matter of a single GPU doing all the computation. But it's a matter of all of those working in concert, working together, and harmonizing across all the GPUs that are inside of a server, to all the servers that are inside of a rack, to all the racks that are inside of a data center. And whenever there's a loss of communications, that disrupts the whole flow of processing.

So this is at the heart of what's driving a lot of the need and a lot of the technology changes inside of the centers. So putting it into a workflow, in order to support these loads, we have to go and create processing as close together as possible. And that's what's creating these high-density racks where all the GPUs are co-located all together.

Well, as you go and increase the rack density and you put more processors in close proximity, what that does is it generates a lot of heat. So now we have a problem where we have thermals building up, and we have to go and get rid of it. So now that drives a need for liquid cooling.

So then in order to go and start accommodating that, we take all of the power electronics that are inside the computers, and we move them outside the rack. And that goes and it brings in all of the direct current technology. So we don't have to go and convert it, but we just take direct current directly into the rack to go and power the GPUs.

OK, that's all great. So what does that have to do with cybersecurity? Well, it's changing the way the technologies are applied inside of these data centers. And on the right-hand side, you can kind of see an illustration of that. So anybody know what that picture might be? It looks like something that would come out of a Formula One racing car. But essentially it's a high-powered computing rack that has manifolds that take liquid throughout and dissipate all of the heat.

On the power distribution side, in the middle, what was traditionally electromagnetic components is now being replaced with power electronics. And this is a new class of infrastructure that's going inside of the data center. And then the last piece is, when we think about a data center, we think about a building like this. We have all the infrastructure sitting inside of a room, or a series of rooms, and it's all tied together. Well, that's changing.

The way that the buildings are constructed is changing, and it's going to modular construction. There simply isn't enough electricians. There isn't enough personnel to do everything on site. So these sheds are getting built with all of the power infrastructure inside. They're getting commissioned. They're getting assembled. They're getting distributed. And you could almost think of a building like this with a number of sheds sitting outside. All of this is now connected together. And that becomes your infrastructure for a data center.

So all of these power requirements are changing the way that the infrastructure is deployed, the way the infrastructure is built. And it's bringing in an influx of new technology. And I tried to put it in a very simple term.

On the left-hand side is how a traditional circuit breaker, something that if you have too much power coming in, it would automatically trip to go and protect equipment, how this would be built. And you can see there's nothing electronic inside there at all. It's all mechanical devices. It's all based on properties of physics. And it's something, you get too much current in, and, boom, it'd trip. And you have a mechanical device that would open up the circuit.

All of that is now changing. And it has to because the increased power and the fact that it's direct current, it cannot be tripped fast enough to protect the equipment with traditional electromechanical components. So power electronics is now inside. And that brings up another set of complexities.

It means that now I have controls. It means that now I have software. And I'm also changing the functionality of this device through software. So typically you can go and you can buy a 100-amp breaker as a part. But now I have the ability to go through software, and I can change the characteristics of that. So that brings up a number of different challenges for us.

First of all, if you're a standards body and you're dealing with electrical safety, how do you go and qualify that part so you know it actually meets what it's designed to do? Yep, you could do the upper limits. And you could say, yeah, the current can't go over 100 amps. But what happens if you set it through software to 60? How do you go and validate that? And more importantly, if somebody changes that in the field, how does it get certified in the actual deployment?

The other piece is, is that now, because it can be controlled by software, it has controls in it, and it can be connected, now it's vulnerable to a cyber attack. And you can say, well, it's not really connected up to the internet. I don't have to worry about that. I'll bring to light, if anybody recalls, the cybersecurity breach that happened at Target, where all of their infrastructure got under attack and their data was compromised.

Well, that happened through a rooftop air-conditioning unit that wasn't connected up to the internet either. But somebody had to go and deploy firmware on it or do maintenance. And they had to plug in with a computer. And the computer was infected with a virus. And the virus got into the infrastructure. And all of a sudden it proliferates throughout the organization.

So when we look at all these new technologies that are being deployed in the data center, they're all going to have to be serviced. They're all going to have to be supported. They're all going to have to be updated with new firmware and functionality. And that opens up the infrastructure to a whole new set of vulnerabilities that we never really had to deal with in the past.

So this is an example. And if we look at the infrastructure from the point of on-site power generation all the way through to the gray space and then into the white space where the servers are, this is a traditional infrastructure that could be there and is being deployed now. But all the dots in red are new attack vectors that the influx of new technology now make us vulnerable to a cyber breach. And in the past, we really haven't had to deal with half of these, but now we do.

So this is where Eaton announced a partnership with Siemens Energy. And a guest speaker is going to be coming up in a little bit. But this is where we've collaborated to say, how do you go and build a solid and safe infrastructure all the way from the point of generation through the point of distribution? So again, new things that we never really had to deal with in the past, but now we have to because of the power requirements which are generating the need for new technology. And the new technology has to be deployed in order to go and meet the demands that are being driven by AI.

So a couple of things that-- changes that are out there. So you can see all of the architectures are transforming. And when we look at this, it's happening in all the equipment. So again, it's just creating an awareness.

There's a lot of security risks. There's virtualization that's occurring. There's new forms of electronics that are inside. And it's just going and increasing the amount of attack vectors that we have. And it's something that, traditionally, we turn cybersecurity over to our IT departments, and away they go. But now you start dealing with all of the devices that are out there and the fact that you have a heterogeneous environment of multi vendors that are out there producing this equipment, it all has to be secured. And it's a daunting task if you don't have your arms around it.

So with the influx of new technologies, we have a challenge because not only do we have to harmonize all of the electrical system codes-- and this is just an example of some existing installation codes and product standards that are out there in the UL world and also the IEC world that have to be modified because of the influx of power electronics and the changing technology that's going into these products. But now all of these have to be adhered for cybersecurity, as well.

So we have a big responsibility in front of us. And one of the things that we're trying to do, especially with direct current, is, how can we go and harmonize these technologies? In the alternating current world, UL and IEC were two different standards-- and UL in North America, IEC around the rest of the world. But as we start bringing direct current technology in, we have the ability to think about harmonizing those and unifying that across the globe. And if we do that, then we could start thinking about unifying the cybersecurity standards, as well.

So what are some of the roles and responsibilities? And how could we go and make sure that our data centers are safe? Well, one is standardizing the controls. Every time that we have a competing standard that's out there by a country or region, it's just additional testing, additional requirements, and additional cost that has to go in to go in building the product. And it also leads to uncertainty.

If you're in the construction business and you're trying to put together a data center or an industrial facility, how do you know that all the products-- if they're certified against different standards and they're put into your facility, how do you know they're all going to work together? How do you know they have the same level of compliance? Well, it's really difficult. But if you can get standardization and harmonization, then you have a better chance of being able to say, this is a component from a trusted provider. And it applies to the same standards across the globe.

A product is secure when it's developed, and it's unsecure as soon as it's deployed because now it's open to humans in the loop. And there's different passwords. There's different ways that those passwords can be protected. So one of the things that has to be done is making sure that you're continually auditing what's happening once products are deployed in the field. And it's something that we really think has to happen with much more rigor.

There's firmware updates that are done all the time. There's vulnerabilities that are reported. And if you think about all the different vendors that are supplying products into a building like this and trying to keep up to date with all of them, it's a pretty daunting task.

OK, classifying risks, classifying your assets based on risk, that's a key thing because not everything has the same level of security needs. But you have to know what's in your building. And you have to have a classified so you know what your vulnerabilities are.

And then the last piece on this is supply chain. There's nobody that's really vertically integrated and produces every single component. We buy chips. We buy electronic components from multiple vendors across the globe. They come together.

How do you know that the parts that you're buying are cyber secure? Well, it's something that the end manufacturer has to go and put together, which is why we believe that you have to have these standards in place developing product. But it goes to assuring that when you build something, it's being certified by a trusted source. And all the products and components are coming from trusted sources, as well.

We're talking about data centers. And there's a lot of new technology that's going in. But the key thing to realize is that all of these technologies will move into other market segments. It's not a matter of if. It's a matter of when.

So the products that are going into the data centers today will find their way into industrial facilities. They'll find their way into commercial buildings. So all of the investments that are being made to secure a data center, to secure the products will transcend into all of the various segments that are out there that we serve today.

So the last thing I'd like to bring up is just a call to action. So everybody's here because they have an interest in cybersecurity. And we'd really urge you to think about the unification of these standards. And again, we want to think about the end user.

If you are putting together a system inside a data center, inside of a building, you're buying all these products, how do you know that they work together? How do you know it's harmonized and that you're not going to have a weak link in there because it doesn't comply to a standard? If we get unification of standards across the globe, we have a better chance at developing products that can go and be certified and be assured that they work together.

The other one is make sure you're continually modernizing your infrastructure. The products that you buy today are going to be vulnerable just because of the increase in computing power that occurs tomorrow or the next year. You have to make sure that you're diligent in making sure you have the right firmware update, the right firewalls in place, and just modernizing your infrastructure. So these are things that you just have to keep in mind. It's good hygiene for the life cycle of a facility.

Make sure that security is part of every product that comes out and everything inside of your life cycle. You have to develop your products with security in mind from the start. It can't be an afterthought. Otherwise, you're going to have design principles that are compromised.

And then the last thing I would say is, think about how you can use technology to advance the practices of cybersecurity. There's a lot of tools that are out there. There's a lot of ways that you can use AI to go and predict what's going to happen, predict different threats, and give you insight into vulnerability. Don't be afraid to use the tools. Use them to help you do your job and to keep the environment, keep the infrastructure safe and secure.

MICHAEL REGELSKI: I'm going to invite up Steve Hiser. So Steve is global head of portfolio for industrial cybersecurity at Siemens Energy. And let's give Steve a big round of applause.

[APPLAUSE]

STEVE HISER: Thanks for having me.

MICHAEL REGELSKI: All right, now I got to put on my glasses because I can't--

STEVE HISER: Can everyone hear me OK? All right, great.

MICHAEL REGELSKI: Hey, Steve. Welcome for joining us here.

STEVE HISER: Thank you. It's good to be here. Hi, everybody.

MICHAEL REGELSKI: So maybe you could give us a little bit around your background and how did you get into the business of cybersecurity?

STEVE HISER: Yeah, it's funny, Almost accidentally I think the OT cyber community is pretty small. It's pretty close knit. The way that I found my way into it is actually through what my first love and passion was, was finance. And I went and I was a consultant with Booz Allen Hamilton for 10 years prior to joining Siemens Energy. And I did a lot of consulting for what they call the finance, energy, and development community with the federal clientele.

And one of the things that we discovered that they struggled with was understanding how to channel investment toward the right cybersecurity investments. And so my current boss and I, along with some other colleagues, actually developed a methodology which was novel at the time-- now not so novel. We called it cyber ROI. And the idea it was a business case analysis methodology specifically designed to channel investment by looking at gaps in the NIST 853 framework.

And so what we do is a customer would come and say, I have a roster of projects, a roster of investments that I want to pursue for cyber. I have no idea what the right mix is. And what we would do is we would leverage this methodology to basically establish a cost avoidance calculation. What would be the potential cost of a breach avoided if proactively investing in these measures? And do they advance maturity to a sufficient degree along that maturity framework in 853 to justify that investment?

And so what that enabled us to do is, of course, they're capital constrained. They only have so much to invest. So we were able to establish the cut line and say, this is not only how much you are going to generate in terms of cost avoidance, generated return, investment by investment, and collectively as a portfolio. But then where is that cut line? If you have to make sacrifices in investments, where does that start?

And so that then got into this rabbit hole of going-- that was very much IT focused. But then we started to partner with other accounts that were commercially oriented, notably commercial energy and the utility space. And so it snowballed and proliferated from there. Down the line, 5 years later, my current boss had moved from Booz Allen to Siemens Energy, gave me a call and said, would you like to come over and run the product business for us? And I said, absolutely.

MICHAEL REGELSKI: Wow, that is great. So it all started. Everything always goes back to finance. You could always put a number on it.

STEVE HISER: Follow the money.

MICHAEL REGELSKI: That's great. So our theme today is around data centers. And from your point of view, how do you see data centers as being maybe the next frontier for cyber risk?

STEVE HISER: And you've touched upon quite a few trends in your keynote speech. I think one is just the rate of growth that we're seeing and demand for that power generation that's attributable to, as you say, like starting at the chip and working up, with that growth comes attention. And with that attention, there's going to be people who want to take advantage of those facilities. The rate of growth is both wonderful from the prosperity and the efficiency standpoint. It's also harmful to us in the sense that sometimes that growth is hard to control. It's hard to protect.

And so as a result of that, there are new avenues created across not only the building envelope, like you said, the power generation side, the edge in which those two connect, that threat actors who, in many cases, are just as smart as us can take advantage of. And while the data center operators primary job is to deliver that compute power and to serve, it's not really to protect. That's where we come in. And so the challenge that lies ahead is significant, given the trends and the rate of demand that we're seeing for these facilities.

MICHAEL REGELSKI: And we saw in some of the graphics and, by the way, we're really happy with the partnership that we have with Siemens Energy. But you have on-site power generation. And then you have kind of the integration of traditional infrastructure, the IT infrastructure. What are the challenges that you have when you start thinking about securing on-site power generation and how it has to integrate in with existing infrastructure?

STEVE HISER: Yeah, I think one thing that's really difficult for facility managers, power generation facilities, fleet managers, distributed networks to understand and to grapple with is just the difference in the life cycle of the equipment that's involved in these two parts of the facility. Power generation, OT equipment has a life cycle that can spend 15, 20, 25, in some cases 30 years. If I'm not mistaken, I think we even-- not super recently, but had some customers that were still running Windows 95 on OT systems because they could support it with it. So obviously, that creates problems.

The IT refresh cycle is what, 3-4 years? How often does everybody get a new laptop? It's pretty quick. And so managing those two disparate life cycles is one really difficult challenge. Another one that's commonly overlooked is the physical complexity of the OT environment versus the IT environment. A lot of things that are done in the IT environment are virtual. And there's a lot of apps. It's mostly compute power.

In the OT environment, there is a lot of physical cabling that requires very specific knowledge around how to manage and how to work with. And I think another piece that dovetails from that is the implication of what happens if you get it wrong, which is in the OT space. We're not talking just about downtime of systems, maybe loss of data, some unhappy customers. We're talking about safety. We're talking about risks to people's lives on the OT side. And so harmonizing those two things in a solution, it actually requires the type of partnership that Siemens and Eaton have come together to create and bringing that expertise from both sides.

MICHAEL REGELSKI: I mean, you can't just go and like reboot the grid?

STEVE HISER: No, not exactly. It would be nice if it had a reset button.

MICHAEL REGELSKI: So can you tell me a little bit about Siemens Energy, the general philosophy on solution design, development, and implementation? And how do you help customers address these challenges?

STEVE HISER: Sure. I think one thing that's interesting and unique about Siemens Energy is, of course, we're an OEM, no different than a Honeywell, a GE, Yokogawa, any of these large equipment manufacturers that serve powergen. And I think one of the things that we do that's very similar to all of them is, of course, we protect our own equipment.

But one of the things that we've done that's a little bit different than them is we've chose not only to compete with them in the equipment space and on the protections that we offer within our own equipment, but also as a service provider that often competes with box companies, so your Dragoses, your Tenables, your Nozomis of the world.

Siemens Energy is often at the table on similar bids that they're competing for. And so I'd say that's-- the first thing I'd say, of course, we are secure by design. Like you said, we use compliance to guide a lot of our strategic investment, but we're also looking toward best practice, and we're also competing in a more holistic fashion.

And so in the portfolio today, the way that we've structured it is we have a foundational level of cybersecurity controls. That's basically what we call cyber hygiene-- application whitelisting, patch management, all of the things that should be included in a part of the control system that people are purchasing to provide a level of assurance to the customer.

But beyond that, we're also providing additional agnostic technology options to serve increasingly complex functions, like monitoring or vulnerability management. And then the forensic analysis expertise, the installation expertise and the managed services that help the customer not just buy a control system and walk away and hope that they can call an engineer if something goes wrong, but to really establish what you call the trusted partnership, to extend the life cycle with the customer, and also to help them increase the sophistication and the maturity of their cybersecurity functions over time.

MICHAEL REGELSKI: So really, you have that deep domain knowledge and how power is generated, how it's distributed, secured, and you're combining that with all of the cyber knowledge to say, look, this is the best way that we're going to go in.

STEVE HISER: That's correct. Yes, exactly. Leveraging a lot of that, as you say, like that OT on-site install engineering knowledge and then combining that with forensic analysis, SOC managed services to deliver increased value to the customer, yes.

MICHAEL REGELSKI: Awesome. How do you balance operational reliability with cybersecurity in these systems?

STEVE HISER: Good question. Interesting question. And I actually think it's kind of a trick question. I think those things, in my opinion, from the perspective of being a portfolio manager in the way that I think about designing new solutions, they're one and the same. Cybersecurity is operational reliability in the OT space. What do power generation companies and operators care about? They care first and foremost about compliance, occupational safety, and then continuity of operations.

And so what can disrupt continuity of operations? Well, you can have something break physically. You can have somebody inside steal something or break something on purpose. Or you could have one of these malicious actors take advantage through one of the vectors that you've described, be it IT/OT-oriented, and to shut the facility down, a ransomware attack, anything of that nature. And so hardening that environment in itself is what facilitates that continuity of operations and an overall hardening of the environment.

MICHAEL REGELSKI: By the way, I love that answer. I really do because when it is about the reliability and continuity of services, and that's why, when we think about the safety standards for electrical that you have to comply because if something happens, it can cause a disruption. It can cause a fault. It's the same thing on the cyber side. It has to be there. You can't think of them independently.

STEVE HISER: Now you can go to different levels of sophistication. You can get creative with how you do it above compliance. But that foundational level that is compliant and that maintains that continuity, that's a nonnegotiable.

MICHAEL REGELSKI: Yeah. So what role does regulatory compliance play when you try to build the cyber strategy for on-site power?

STEVE HISER: Yeah, I'd say it's kind of the foundational guiding light for us. It often serves as a baseline for the specifications to which we design a product or a service. So clearly a good example-- the cyber resilience act in Europe that's emerging. We have some time to demonstrate that our solutions are compliant if we're going to continue to serve our customer base that's in Europe. But we're using those standards to inform our roadmap what investments and feature enhancements we need to make. So I'd say that's the first place we look to make sure that we have of the bases covered.

From a commercial perspective, it's often the first point of entry with a customer that's struggling and lower on the maturity curve, so offering kind of the diagnostic service, the classic gap assessment to inform what protective measures that customer might implement, what technologies they might select to your point around supply chain. There's a number of strategies you can use to control that.

One of those strategies is what we're doing is two companies, which is partnership in order to consolidate the vendor network, but that compliance is really it's a conversation starter with the customer. And it's also that first point of entry with helping them to address a key problem, often on the lower side of the maturity scale.

MICHAEL REGELSKI: So you talked about baseline compliance. And we all know there's different levels. Why would a customer want to go beyond just the baseline? It's kind of like saying, you know what, I got insurance. I'm good. I'm kind of covered. There's these extra set of things that I could put on extra set of risk mitigation techniques. Why would a customer go beyond the basics?

STEVE HISER: Great question. So there's a couple of reasons. Let's start with one that I was actually talking about at lunch, which is that now officers within companies, board members, are being held personally liable for noncompliance or any perceived gap in compliance. So if you don't want to end up in jail, a good reason for proactively investing in cybersecurity is to avoid that consequence. So that's certainly one, at least at its most basic level.

Another is that the regulations. First and foremost, there's a lot of them. Secondly, a lot of the exact verbiage, as far as the standards go, is open to interpretation. So it's not exactly crystal clear as to what the standard is. Going above and beyond the bare minimum helps demonstrate good faith in trying to not just meet the bare minimum of said standard, but to actually anticipate what might be coming next.

And the third is that threat actors are often ahead of the regulation. And so if we're being proactive with thinking about where the threat actor is, as opposed to where the regulator is, which often sometimes is more reactive and in response to what those threat actors are doing, then the organization will be that much more ready for the next incident.

MICHAEL REGELSKI: And you know what? I think that it's interesting you brought up the very first one. You're personally liable. That goes a long way in changing--

STEVE HISER: When it's your neck on the line. All of a sudden things will start to happen.

MICHAEL REGELSKI: A lot of times, when we think about cybersecurity, it's traditionally thought of in the IT space. It's like, OK, we're going to put the moat around and protect the enterprise. And then you think about an industrial site or a data center, and you have all of this OT technology on there. Where do you see the responsibility lying? And how do you ensure that there's visibility?

STEVE HISER: Yeah, we've thought a lot about this exact problem with the Siemens Energy monitoring solution, Omnibus Cyber Monitoring is the brand name for it. But what it really boils down to is a lot of the traditional monitoring solutions that you find on the market are using data that is typically ingested or examined in a silo. So some are using network data, some are using process data, some are using asset data, and they're working off of that data to provide visibility to those who are managing the enterprise.

The problem is, is that in looking at that data in silos, you're missing opportunities to correlate it with other types of information that's available to you both within the OT and at the edge of IT and OT. And so we thought through this and said, really, the best way to do this to increase-- not provide full visibility, but maybe increase the level of visibility.

Let's go from 20% to 50% to 70% visibility across the enterprise is to look at the data sources, to ingest them from nontraditional sources, and to use machine learning-- in some cases, rudimentary AI-- to run algorithms that actually figure out if there are correlations and relationships in that data to say, is there something hidden that we wouldn't otherwise see?

And so that's something that we've integrated. Siemens Energy has a proprietary SIEM. The ML models and the rules engine behind that SIEM does exactly this. One of the interesting things that has actually come out of that is actually with one of our pilot customers early in the infancy of the solution is it's been able to not only uncover anomalies that may have been indicative of cyber threat, but also operational issues.

MICHAEL REGELSKI: Oh, really?

STEVE HISER: Yes. A good example-- the customer was in California, and we were seeing on the dashboard that there were these wild temperature anomaly swings in the cooling stack for where the servers were. And we said, yeah, this has to be an error. Something's weird. It turns out that, after a physical investigation in the server closet, someone had shut the door, and there was no ventilation, and they were about 30 minutes away from having a full-blown meltdown of the facility. And so they were able to get the appropriate cooling into that facility before the servers failed.

So even something as simple as that, by integrating the data sources and ingesting them and maybe being a little bit more advanced with some of the analytics, yields some tangible results, not just for cyber but for operations as well, which, of course, can be very relevant to the gray space and the white space of the data center.

MICHAEL REGELSKI: Wow. That's one of those unseen benefits there. You detect operational issues as well as--

STEVE HISER: Unseen-- ironically created by visibility.

MICHAEL REGELSKI: That's awesome. Shows what you could do when you have access to data.

STEVE HISER: Yes.

MICHAEL REGELSKI: So last question for you-- when you think about the tremendous kind of challenge that you have in protecting the enterprise, protecting the resources that are out there, what are some of the most promising innovations or advances in technology that you see?

STEVE HISER: So ironically, we're talking about AI driving demand for data centers and creating some of the challenges that we're trying to address. AI's been an interesting tool that we can explore, especially with respect to some of the monitoring capabilities that we're able to lend.

A good example, a very tangible example, is that just this past year in our roadmap, we executed an integration-- Microsoft Copilot, into an adapted AI-supported chatbot that our SOC analysts can use to be more efficient with their triaging of alerts. So we're in the process of adapting that to work off of the SIEMs data specifically. But what it ultimately does is does the customer directly see that? Can the customer touch it? No.

But does the customer get results from that? Yes, because the analyst can do and perform his or her workflows more efficiently, can be more targeted with his or her analysis, leveraging what is, at this point, a pretty basic AI function. So if that's kind of the starting point for AI. There are other applications that of it that could be beneficial as well. I mentioned support of the rules engines, the ML algorithms, and we're dabbling in that space to figure out what the right fit is. So that's certainly one that I see that's potentially beneficial.

MICHAEL REGELSKI: Oh, that is great. Are you are you seeing any challenges with training people on how to use the AI tools?

STEVE HISER: To be determined. Right now, it's in its pilot infancy right now. So we're still in that proof of concept testing phase. I do anticipate that there will be some handholding. The good news is that anyone who's familiar with Copilot or ChatGPT or using basic commands and syntax in those programs should be relatively well set up to utilize this. I think it'll be more around how do we integrate it into the process and the workflow of the triaging as opposed to the functionality of the capability.

The other one that I'd comment on as far as trends in innovation, technology-- cloud-enabled solutions. And while this presents its own challenge as well, especially for customers that may be in geographies where cloud is just impermissible-- data has to reside on site-- but there are other areas where we can potentially explore it.

A good example of a capability that we've been examining is a cloud-based backup and restore solution. Right now, most of that backup and restore is done on-prem. If the data is residing on-prem, it still remains at risk to any existing threat that may be on-site.

Having it with redundancy in the cloud does a couple of things. Number one, you know that you have the data stored there locally, and additionally, if it's stored there and separate from on-prem instance, you can use that opportunity to then scan that information for vulnerabilities that you may not-- or potential malware that you may not be able to do while it's on-prem and in use. And so having that mirror image of the data helps you do that continuous auditing that you talked about and then, also, have a version of it that you can restore and then bring back to site. In the event that there is an issue that has to be addressed.

MICHAEL REGELSKI: Do you find that that's-- it's interesting, we're engaged now in online banking, and there's trillions of dollars flying through the ether right now. Do you still find a stigma about people feel if their data is secure if they put it in the cloud or any kind of apprehension?

STEVE HISER: Oh, absolutely. And I think it varies greatly by customer. The ones that are higher maturity and typically have cyber established as a programmatic function within the enterprise tend to be more comfortable, more progressive. They also tend to be more capitally ready to invest. Those who I think in the European market is probably where we see the strongest question marks as far as cloud.

Also in the Middle East, Saudi Arabia, for example, has some pretty stringent regulation around data needing to remain on-prem and on-site, even with something like just having eyes on glass with data in the cloud can be problematic. So it's highly variable in terms of customer maturity, also in terms of geographic distribution.

I think, ultimately, anticipating where regulation will go-- I think we see wider and wider adoption of cloud with some of our North American-based customers, Latin American-based customers. So I think the strategy is really to use those customers as examples of success to then demonstrate, maybe help influence both the regulatory community and the rest of the customer base to progressively adopt as it suits their level of comfort.

MICHAEL REGELSKI: Now you get a couple of beachhead examples out there, and then it kind of takes off from there. Well, great. Well, I think, if it's OK, I think we got a couple of minutes here, and we could open up to any questions that are in the audience. No one was expecting that to happen. Oh, maybe one.

AUDIENCE: You talk about using the cloud and there's firewalls and segmenting off the space, but then you want to start using all these cloud services and there's techniques through data concentrators in certain ports to limit the data out. But I'm running into where folks who are wanting to analyze that data, combine it with product data, uniform data balance, data types, that kind of stuff. And then how do you-- and then now they want to feed back into the process from the cloud, and that makes me nervous. But to innovate and keep up with their competitors, we have to do those kind of things. It's definitely a challenge to innovate and be safe at the same time.

STEVE HISER: Yeah, and it's interesting-- so to touch upon that, and you were talking about beachhead engagements and earning trust through demonstrated application. One of the things I think we've done within our company recently, we executed a reorganization where we've rethought how our business is supposed to-- at least the digital business is supposed to work.

Traditionally, it's been more of a product line transactional sales approach because it was essentially a division within a larger company that was a startup. And we've seen tremendous growth over the past five years, more than doubling the business in terms of annual order entry. And so it begs the question of how do you facilitate that next wave of growth within the super cycle that we're experiencing? And so that had us think about maybe it's a redesign of the way that we operate.

And that operation now is more of a platform-based offering, more integration of the digital solutions. We call it the Omnivise ecosystem. You may have heard about it through the partnership. But the idea is to kind of take us from that plant level selling to more of the partial fleet or fleet-wide or enterprise selling with more integration, leveraging synergies across the various digital solution lines.

Now, why is that important and relevant to your question? What it does is it requires us to think about how to take new ideas and bring them to market fast or faster than we traditionally did so that we know what's going to work and we know what's going to fail real fast. And it puts that focus on innovation of developing new prototypes that we can test through application with willing customers to demonstrate that success or to demonstrate that failure so that we can continue to finetune the portfolio to address problems just like the one that you raised.

AUDIENCE: And the feedback and the other thing-- strategy is we're going to get attacked, so can we contain it? Can we limit it, contain it to one location, one scene, one type of machine, and then can recover? But when you start having central systems that feed 60 factories, that's one pipeline. Somebody gets all of that pipeline, especially when those things can turn the tire an extra 20 seconds because that's going to increase our uniformity, run out, or whatever. So it's a challenge, but we need to figure out how to do it for sure.

MICHAEL REGELSKI: Great. Any other questions? Yes.

AUDIENCE: I am Chris. I work at KeyBank doing cyber incident response and I'm not used to working in austere environments, but I imagine Eaton and Siemens do work in austere environments. Do you ever have issues with operators in these environments needing access to the internet and bootstrapping systems to Starlink with open IP addresses and anything with that? How do you keep oversight of that, or is that not an issue at all?

MICHAEL REGELSKI: I'll give a perspective, and I'm sure, Steve, you have a perspective. I think when people in a work environment are tasked with getting a job done, and it depends on getting connectivity, they're going to default-- a lot of times, you'll see people default to getting access regardless of if it's cyber secure or not. And I think that humans in the loop are really some of the biggest places where vulnerabilities come in.

You can test all we want against different cyber standards, and a product can be secure when it leaves as soon as it gets deployed. If you have unsecure policies on secure networks, then, all of a sudden, it's open to different vulnerabilities. So it really comes down to training and hygiene and, in a lot of cases, making sure that the work that's being done, that people have the right access to the information that they need but being done in a secure manner.

And a lot of times, what happens is where those work practices tend to not be understood. And you just do things like shutting people down automatically, and then they have to go about finding different ways to access information.

STEVE HISER: Yeah, I'd say that we can control so much within the customer environment. Customers are going to make some of its own choices beyond the scope of where we serve them. So that's what we can't control.

What we can control is if we're going to deploy solutions in support of them, be it basic hygiene, be it monitoring, be it vulnerability management, next gen firewall, whatever it might be, if any of those solutions requires internet connectivity or cloud connectivity to function, one of the things that we bring is a secure remote connection along with us to help establish and ensure at least that the connectivity between their environment and our solution is secure.

We do have one of those that's homegrown that works very well with our T3000 control system, which is what's sold with T3000. And then we do have some integrator, or I should say integrated partners that we can deploy in support of vendor-agnostic applications.

AUDIENCE: I can add to that. So cybersecurity at Goodyear, one of the things we did that gave us a lot of governance, we put a segmentation in all our locations, and Mike's down here and Mike writes all the firewall rules, but none of them get installed until I review every single location, every single firewall, IP and port, IP review, and approve.

And I stop all kinds of shenanigans all the time because security gets to look at every firewall. And what is this? This is a nonstandard-- even application portfolio governance, this is a nonstandard app. This is our global solution. I'm not approving this until you get that director to allow this as a secondary option for this solution. So firewalls give you so much governance, especially when you have a little process around approving what goes in what firewall.

AUDIENCE: How are you seeing your customers' organization changing as OT cybersecurity principle [INAUDIBLE] for example, I'm guessing that most of the customers have [INAUDIBLE] not have it on the OT side.

STEVE HISER: Everybody could hear the question-- the question was how are we seeing customers, at least from Siemens Energy customer base, how are they changing their perspective around OT cybersecurity, as it's likely that they have established IT cybersecurity functions, but how is OT catching up? That's the gist of the question.

So I think one thing that we've seen is with the attention that has been brought to OT cyber, there is an increasing responsibility among senior management or increased engagement is the best way to say it. Traditionally, the primary buyer of our solutions, at least for the digital cyber business, has actually been the plant manager. Plant manager knows intimately his or her infrastructure, workforce, the cabling that's within the building, the physical systems and, as a result, is the one that's largely making the buying decisions about that specific facility.

What we've seen now with increasing pressure from regulation, increasing numbers of threats, and also downstream impacts from realized attacks, you see a lot more engagement from the CISO, the CTO, and even the board when it comes to making these decisions. And that's not just increasing in terms of scope at the leadership level, but also broadening the perspective from the facility level to more of the fleet level. So that's certainly one consequence.

I think another trend that you see is the use of capital. Traditionally, a disproportionate amount of the capital was being channeled toward IT security budgets. You see a shift in that spending maybe more of an equalization, channeling more toward the OT space, especially with some of the regulatory mandates that are coming up, like, for example, IEC 62443 saying that, in Europe, you have to have continuous monitoring by '27. So they're all saying, oh boy, this is a big deal. We have to pay attention to it. You'll see a shift in that capital away from the IT side.

The other thing is, as far as the buying decisions go, I think there's a greater understanding among the decision-makers that IT and OT are not the same. We have a number of customers who made what I would call lessons learned, where they made a decision to implement an IT solution in support of an OT function, and then realized that the shoe doesn't fit. And so now they say, you know what, we've learned that lesson. We're ready to go down the path of engaging a trusted OT partner or partnership to address this problem.

And so I think you're seeing a gradual maturation in the understanding of the space, the decision-making, and the attentiveness from the senior leadership, some of that capital beginning to shift. I think what we need to continue to do is to continue to educate our customers, to establish ourselves as solution providers on the IT and OT or IoT kind of space that we are the trusted advisor to help migrate the customer to a point of not just protection, not just visibility, but true resilience. And they're slowly getting to a space where they're ready to engage in that.

MICHAEL REGELSKI: I want to add on what Stephen had said about education. And I think that's really on a big reason why the partnership with Siemens Energy. But we look at that as something that we have to do. I mean, the customer, you can't expect them to know everything.

So if we're out there, we can talk about, OK, if you're putting in communicating devices, do you have an industrial strength firewall at least set up if you don't have good cyber hygiene in there? Do you have a secure commissioning process that are out there? So there's things that we can do as manufacturers to talk about the different partnerships we have, to talk about the ways that we design products, and to talk about the ways that they can be deployed in the field and secured when we're out there.

I think the only way that there's a lot of bad actors that are out there. And there's a whole army. But I think, as an industry, if we unite together and educate each other on what's going on, create the right partnerships, and then help translate that knowledge that we have down to our customers to make them more prepared and more educated, it's going to advance us all.

STEVE HISER: I'd also add, too, it's not just the customers that need engagement. It's organizations like our two together. And the regulatory community as well can really be beneficiaries of some of the lessons learned that we have through, as I mentioned, some of the successes and failures that we have to help make the regulatory mandates easier to understand, easier to achieve, and overall just more effective once achieved for the intended function.

MICHAEL REGELSKI: Well, Stephen, I'd like to thank you for joining us today. It's been a pleasure. Let's give him a big round of applause. Thank you very much.

[APPLAUSE]

STEVE HISER: Thank you for having me.

MODERATOR: I wanted to invite up our next guests that are going to do a little roundtable discussion. So we have Ruben Chacon from Eaton, our vice president and chief information security officer. We have Brian C. McDowell, chief security officer from University Hospitals. Thanks for joining us. Dr. Barbara Walker, vice president, global cyber and information security from Lincoln Electric. And Ed Pollock, vice president and chief information security officer from STERIS. So would you please give them a warm welcome?

[APPLAUSE]

RUBEN CHACON: Thank you, everyone. It's a privilege to be here with many leaders from different organizations and industries sharing a common goal. And that's to learn a little bit more about cyber resiliency.

In today's world, cybersecurity is no longer just a technical issue. It is a strategic conversation about trust. It's about adaptability. It's about continuity because every organization, regardless of their size or sector, now depends on one shared foundation, and that's the confidence in our digital ecosystem.

Resiliency is not about living without risk. It's about our ability to adapt and recover and emerge stronger when disruption comes. And it will come. It's about transforming uncertainty into opportunity and fear into preparedness.

We cannot control when a crisis will hit, but we can control what happens next. So that's why we are here today-- to move the conversation beyond the firewalls and passwords and towards a mindset where cybersecurity is seen as a business-- as an enabler of business resiliency, innovation, and trust.

So as Matthew mentioned, my name is Ruben Chacon, and I serve as an IT VP and chief information security officer for Eaton. I have the privilege to lead our cybersecurity strategy across more than 90,000 employees and hundreds of manufacturing locations around the world. But more importantly, I have seen firsthand that resiliency is not only built in networks and data centers. It really starts in the way that we lead, collaborate, and prepare together.

I am joined by three outstanding cybersecurity leaders, CISOs of complex organizations who have an excellent experience and deep understanding and perspective of this particular topic. And even though you were introduced already, would you like to introduce yourselves and tell a little bit about your organization? Barb.

BARBARA WALKER: Yeah. Hi my name is Barbara Walker, and I want to make sure that you all know it's Dr. Barb. Let's straighten that out first.

So I'm the VP of global cyber and information security at the Lincoln Electric Company. Many of you may be familiar with Lincoln, the global leader in welding products. You may have heard about Lincoln Electric. So we are also represented all around the globe. We have roughly 12,000 employees, and we have many different manufacturing facilities all around the globe.

ED POLLOCK: I'm Ed Pollock. I'm the CISO over at STERIS. We're located in Mentor, Ohio, not too far from here. We're a medical device manufacturer and services company. We build a lot of stuff around sterilization, operating rooms, and also different services to service mainly hospitals, but systems but also pharmaceuticals. And we've got about 19,000 people around all over the world.

BRIAN MCDOWELL: Yeah, and I'm Brian McDowell, University Hospitals. One of the two major health systems in Northeast Ohio. You can't drive five minutes without tripping over either the clinic or us. So hopefully, you've seen our signs and shields.

My world split into a couple of areas-- information security, of course, cybersecurity. I get to represent the good work of the two gentlemen sitting 2/3 of the way up there in the middle. From that, I also have physical security.

So I have 170 police officers, which seems like a lot, but you have to have police officers at your hospitals and EDs given the things that come in. And I also have emergency management and environmental health and safety. So I've learned a ton about needle sticks and active shooter preparation that I never expected in my career. 22 hospitals, 200 locations, et cetera.

RUBEN CHACON: Thank you. And together we are going to explore what it means to build cyber resiliency, not just to survive adversity, but to translate this into competitive advantage. Let's get started. And I will start with a basic question. So how do you define cyber resiliency, and why does that matter?

BARBARA WALKER: So let me start. And Ruben, you actually hit the nail on the head. So it's not just protection, but it's really all about how do you prepare? How do you respond? How do you recover if anything adverse or unplanned happens?

And at the same time, you continue operations. So it is really above and beyond the protection. It talks about the adaptability. You mentioned the strategic consideration, the continuity. Because in the end, without that, we will not be able to fulfill the mission of our organizations.

ED POLLOCK: Yeah, bad things are going to happen. So you have to be able to minimize the impact and also recover quickly. And like why it's important is it's-- your customers are expecting it. If any of you deal with questionnaires that customers get, they're going to ask you about your-- they may call it DR. They may call it continuity planning and whether you have that in place, if you've ever had to deal with cyber insurance companies, they're asking those same type of questions.

And now you've got governments doing the same thing, especially if you're dealing with Europe. They're wanting to make sure that you have-- you're able to recover in case there's a disaster in order to operate in their companies in the country. So if you don't have it or you don't do it well, you may end up having problems keeping and retaining customers.

BRIAN MCDOWELL: Yeah, we echo your statements, both of you. Our strategy or our vision for the last five, six years has been secure, vigilant, and resilient, right? So stop everything you can up front. That's not going to happen.

Something we'll get through-- some way, shape, or form by our end users or otherwise, even if it's a USB that gets picked up in the parking lot that came in. I forget the example earlier of the TJ Maxx. Plug the laptop into something that's connected. Vigilant is being aware and monitoring everything you can possible and then lastly, resilient-- how quickly can you recover?

So we try and build that into every single one of our processes. I'm sure we'll talk more at length about some of the tabletop exercises and things you can do from a resiliency perspective. But yeah, that's what I would add.

RUBEN CHACON: Why do you think that executives and the board should care about this issue?

BARBARA WALKER: Well, if you want to have a company that remains viable, you have to care because without resilience, things are going to happen, right? It's no longer the if. It's the when. Because this is just the world we live in, and we still have obligations towards our stakeholders.

Whether those are the customers, our employees, our communities, there is trust involved. There is brand protection involved. There could be legal repercussions. There could be regulatory repercussions. And let's not forget the revenue impact. So it is really the viability of the company that's at risk.

ED POLLOCK: Yeah to me, I also look at it as from a people issue too is why to care about it. Companies that have been hit hard and have had trouble recovering, they either have to do layoffs or they go out of business. So I always think about, well, what do we need to do to protect it so people can keep their jobs, and we don't have to impact people's lives, being able to pay the bills? Or maybe we don't get a bonus because we had an incident that caused a lot of trouble. So looking at it from the people aspect.

And you could use that to motivate yourself, but you can also use that to motivate other people. So you're going to be running into people that say, well, why do I have to care about DR? That's DR IT's concern. Business continuity-- they're going to still say IT's, but it's really the business.

But try to appeal to them from a people perspective is that they're doing it so that we don't affect the people that we work with every day.

BRIAN MCDOWELL: Yeah, I mean, I try and use some of the examples in the news every time we go to board meetings or senior leadership. It's because what they're seeing in the paper. It's what they're hearing from their peers, but also to be able to relate that. So change health was a big one for the health care industry to wake them up or extension health-- huge health systems that go down. I think.

But the other thing that we generally do is-- we've kind of said this a few times, and it's how can you tie it to the back to the people. And in our case, people's not only our caregivers but also the patients that are there. And so we'll say, look, as our teams are standing on the digital fortress walls, staring into the abyss that is the internet and all the attacks coming at us, we have to turn around and look inside to see why we're doing this and what we're doing.

We're keeping these systems up and running to ensure that our doctors and nurses have all the tools available to them to help make that person better, to heal them, to save them. And at the same time, the people are walking through our doors. They're not there not having a good day.

Generally, probably one of the worst days they're having is when they come to see us. Maybe a birth of a child-- let me set that aside and in that side. But it's you're there to be healed.

And so our job is to keep the systems up and running so that we can help the clinicians, heal those patients, and get them out the door better than when they came in. And so you tie that back to the mission and the board and the senior leaders to understand why this resiliency is so important.

RUBEN CHACON: So what is the impact of businesses when there is a lack of cyber resiliency preparedness? Perhaps you can start now, Brian.

BRIAN MCDOWELL: Say that again.

RUBEN CHACON: What is the impact on businesses when there is a lack of preparation?

BRIAN MCDOWELL: Again, we'll probably talk a little bit more. And I have more to say on the tabletop exercise or the resiliency side, but I think in any of our industries, becoming so reliant upon the technology. Like there is a very small population of doctors and nurses that have ever been on paper. If you think about that, like everyone used to chart on paper. And when that system goes down, they have no idea what your allergies are. I'm being dramatic.

There are downtime systems and BCA devices that have your list of allergies and the bed of patients and appointments and things. But in essence, it's you've gone from your world that tells you everything about that patient from the last medicine they received, what time it was, are they allergic to a z-pack or whatever it is? And now they have to just go back to one on one treating that patient. So I think the lack of cyber resiliency or ill preparedness is going to lead to negative outcomes, certainly from a human perspective.

ED POLLOCK: Yeah, I agree. I mean, we've talked a lot about the impacts of not having it, but the effects on the company, your customers, and then also your shareholders and then the senior leadership because they're-- they're responsible for making sure that the company's resilient.

BARBARA WALKER: Yeah, and not to forget if we have resilience, it translates into other areas because we talk a lot about cyber resilience. But what about resilience to change? I mean, the world we live in today changes rapidly.

And so you have to constantly adapt. And in order to adapt, you have to be resilient. Whether it is, well, all of a sudden, AI has made an emergence, and how we are going to do our jobs is going to change. Well, it requires being adaptable. That's part of resilience.

And so the companies that can resiliently adapt, they have a competitive advantage because they will be able to more quickly react. They will be able to more quickly take advantage of new trends because they are used. They have the processes to deal with that quickly and effectively.

RUBEN CHACON: So do you have any examples of companies that have gone through this without preparation and what the results were?

BARBARA WALKER: Where to start? So I think one that has been widely publicized-- and probably many of you have heard-- is JLR in the UK. I think probably everybody has read about it. And I mean, that's you talked earlier about the people aspect. I mean, not only was GLI the company down, but there was a supply chain ripple effect.

I have seen numbers of 5,000 suppliers being impacted-- so much so that the UK government then stepped in, and there was conversation about employees having to be furloughed and so on and so forth. And so clearly, I think that was one incident where you could say maybe resilience weren't there because the fallout was really tremendous. And the financial impact again, if you believe the media, I mean, you're talking about multiple billion dollars of impact.

RUBEN CHACON: Yeah, so when you prepare your organizations for resiliency, what scenarios do you prepare for?

ED POLLOCK: So what we normally do is we do tabletop exercises at the executive level, and we try to pick something that's in the news. And there's a couple reasons to do that. So ransomware has been one that we've tackled a number of times in the past because that's what they see. That's what the board of directors see. So you're going to get asked have you done a tabletop on ransomware?

We also saw the same thing from if we do a one-on-one talk with the customer, sometimes they'll ask us about that. And definitely the cyber insurance will ask about that. So we try to do something that's in the news that gets them excited and get them thinking about it, because more than likely, if you're going to get hit by something, it's probably going to be something that's major like that.

I don't care too much what the subject is, because the real benefit on the tabletop exercises is that thought process of walking through the problem. And whether it's a ransomware attack or maybe it's some other type of outage, you can use the same type of skills that you learned working together during that tabletop for ransomware for, and it translates over to other things. So the important thing is not necessarily what the subject is, but it's more of actually going through the process to learn to-- to be prepared to deal with an outage. And it's going to be an availability outage more than likely.

BRIAN MCDOWELL: I definitely agree with Ed's comments. I think it's the exercise, and it's exercising that muscle as much as possible. I'm guessing most people in here don't feel like their teams are flush with resources. We have plenty of expertise and time to do these things, but it is really important to do them.

We're embarking on-- it's called the epic honor roll, which is our main application. And we were just on the phone yesterday about it, and we're splitting actually the tabletop exercise into two different functions. They'll be the technical side of it, which is IT, infrastructure, the application team, our cybersecurity team. And we're going to walk through that exercise of what it looks like.

When do we go down? When do we turn off from the internet? When do we do that technical aspect? And then our goal is to get to the point where it is the infrastructure believes they have its back and sound.

Data quality is good. There's no corruption. And the information security team decides that we have a clean environment.

So at that point, we're going to stop this exercise. And that's when the next exercise begins with my director of Emergency Management. She's actually going to go next door to a hujjah, and they're going to simulate a downtime and shadow a patient through the entire process. That will be really impactful from an operational perspective.

Whatever your operation is, try and shadow someone and say, OK, once IT has-- once this part of IT has said it's OK, what data needs to be back loaded in there on medications or on orders or what needs to be brought up? So the infrastructure is up and running. You still have a 3, 4, or 5 day lead time to backload all of that data, probably manually.

And then at that point, we're doing that in parallel on that side, which is someone's back loading the data, making the decisions on what that is. And then the other one is, how is the day in the life of this patient or following this set of patients through these caregivers going to work while they're in that downtime so we can extrapolate across? We're bifurcating the tabletop exercises into two different categories-- one particularly full operations and the other one is the technical side. We're just starting that next week.

BARBARA WALKER: And one of the areas we have looked at-- where are we going into a new product segment? And so we can do a tabletop around that product segment. And we have found that very effective. And what I like about the tabletops is it is something where you can bring the various functions and businesses together. So it isn't just IT.

It isn't just security, it isn't just legal and HR. You are also bringing in the business people that actually own, for example, the commercialization of that new product line. And oftentimes there are these aha moments, and then you can connect in things like phishing tests. And you can say, well, if you have a really high click rate and think about maybe some of your developers that might have elevated rights.

Now you put that together. You can see perhaps how actually that could be the starting point of an incident. And then you might find, well, maybe the existing playbooks that one have, it doesn't work.

Maybe there is a custom playbook that actually has to be created for that particular product line. So it can really spawn a lot of good activity and thinking and aha moments.

RUBEN CHACON: Now when we do this, how do you measure readiness? In other words, how good looks like?

BRIAN MCDOWELL: I don't know. Go ahead, Ed. I don't think I have a good answer for that. I never feel ready. Just honestly, I never feel ready.

ED POLLOCK: So one thing is you got to have a-- you got to have a plan. And that plan can be good, or it can really suck. But the way you make sure that it's good is that you force them to do a DR exercise, and they walk through. And they take the system down, recover it, bring it back. And that's usually on a weekend.

And it's likely that it may fail the first time, maybe even the second time on it. But what you do is you keep on repeating that until all the processes are done on paper. So somebody that may not be as familiar with it is able to bring the system back because you're going to run into something.

More than likely, it's going to be that you didn't realize that there was a supporting system that needs to be part of that DR plan. So you have to add it because it's amazing. It's like something you didn't even think about can cause operations to go down.

BARBARA WALKER: And of course, there are standard metrics that you can measure mean time to detect, mean time to contain, mean time to respond, mean time to restore backups, and so forth. You can have all of these metrics that they might have a place. You can do maturity models around certain domains.

Hey, do you actually know how to do a risk assessment? Are you mature at the very starting point? Are you defined? Are you optimized so you can do some of this?

There are actual standards for resilience. For example, the British standard 65,000. So you could do an assessment against the standard and measure. Where do you currently stand? And then after you fix gaps and so forth, you take another assessment.

So there's a variety of ways that you can apply to measure. Are you making progress on your maturity journey? And are you actually meaningfully reducing risk and increasing resilience?

RUBEN CHACON: I think it's great to have some metrics, and I'm with you as well. I'm never happy with the situation-- always looks awful. We need to continue improving.

ED POLLOCK: Always have a backpack so you can leave the country.

BRIAN MCDOWELL: No, I would just say quickly have the framework and the structure. We talked about it a lot. Every good battle plan survives until first contact with the enemy. And that's going to happen.

So in our environment, we have what's called Hicks Hospital Incident Command Structure. And that actually if you want to look at positives that came out of the pandemic, for us-- God bless you-- that was one of them is we got really good at Hicks.

So we have an incident commander. We have that structure. We have the operation. We have the logistics team. We have planning. We have strategy.

We have all of that defined. And we did it a ton for two, three years. So we have that structure. It's built.

We keep it up to date. I feel a little more comfortable. That is we know what to do on the IT side.

We'll set up our command centers, and we'll go through our actions. The hospital incident command will stand up and handle that half of it. So I feel a little bit more comfortable that we've exercised that quite a bit, albeit 2 and 1/2 to 5 years ago, but it's still there.

BARBARA WALKER: And to add to this, what is interesting, if there's an incident, rarely does it actually play out the way you have laid it out in a tabletop-- rarely, actually never. So what you want to do is you want to have the playbooks and all that in place to cover the 80% that are probably going to happen. You have actually time available for the 20%, which is going to be the unexpected because there is going to be the element of you have to think on your feet.

You have to pivot. You have to come up with solutions in the moment. So the 80% you can prepare for, you've got to have that pattern.

RUBEN CHACON: And we can control what we can control. So there are situations that I have seen. People are not ready to-- I mean, we practice response. But sometimes companies do not have this program management office for crisis. Who's going to be doing what? What is going to be tracked? How is going to be tracked?

Those type of things are very important and can be prepared before the actual incident. But we only have so much budget. Where do you think organizations are underinvesting?

BRIAN MCDOWELL: It's hard because I mean, I'm sure we'll all have different answers, or we could all give a different answer depending on what the other says. I'll start with infrastructure. I think people, yes, always start with throwing technology at a problem, and there's a lot of people in process that go along with it. I'll say people and processes for you guys or what you would use, but I think there's a lot of great technology out there.

Even if you've bought it, I'm not sure it's implemented correctly. I know with all the features and functionality you have inside of those systems. I do see a lot of underspend in infrastructure. There's a lot of wailing and gnashing of teeth on what do you mean the infrastructure cost $22 million a year to refresh, depending on the size of your organization?

Well, that's 3 to 4 years on a laptop-- it was just talked about earlier-- five years on a network device or server. Is it 7 on a network device? That's the built-in spend.

Do we really need to keep two, three, four copies of this? Do have to keep an air gapped-- an offline version? Those are difficult discussions to have. I'll start with technology, whether it's underspend or it's underutilizing the tools that you already have in place.

ED POLLOCK: Yeah. And I'll talk on the people side is that you're-- the people that have to make it happen. You're competing with projects that they have to get out there, applications they have to build, those type of things. And now you're coming to them and say, hey, I want you to plan for something that may or may not happen. And they're on deadlines. So I think investing in the people's time and getting dedicated time for them to work on resiliency is it can be difficult to get that.

The other area is more and more companies are going to cloud-based applications. In the past, IT departments have been very good about building resiliency on on-prem systems. We do HA. We have DR sites, and we rely a lot on cloud systems to do the resiliency for us.

And they do. They do do it. But sometimes that even fails. So taking time and planning is how do you recover if a cloud or SaaS system goes down so that you can continue operations without it.

Now, fortunately, at least what we've seen historically, is that they bring them up usually within a day other than change health care. Yeah, that was bad. It impacted us too, even though we're not a-- we're not a health care provider. But our customers had difficulties paying because they weren't getting reimbursed.

BRIAN MCDOWELL: I'll bet you half of health care could only spell change and didn't know what they did. We don't use them primarily, but they had downstream impacts on a ton of them. We didn't even know who change was. But they're a huge integral.

BARBARA WALKER: So I'm going to cover process. I'm a big proponent of process, and I think we do under-invest in process, both from the perspective of what are those key business processes that the company really needs to operate. What are the processes that we are using during a crisis? Oftentimes, especially in manufacturing, we may look at the processes on the shop floor, for example, because we have to manufacture.

But what about how do you do payroll if your payroll system is not available? How do you manage your financial obligations if your bank's cut off the interfaces to you because they don't want to get what you have? What if you have suppliers that cut you off because they don't want to get what you have in your environment?

All of a sudden, what if you have to go back to pencil and paper, not just on the shop floor, but across the board? How are people going to be prepared for that, not just for 24 hours or 48 or 72 hours? What if you have to run manually for 100 days or longer? People don't think about that.

There is this notion. IT has it covered-- ITDR. It's got to be up like that. No, you may not be up that fast. You may need to actually run in a degraded state for a long time the people aspect of things.

How do you handle shift work? You may have to have shift work for weeks and months on end. How do you manage that? So there is a large process component in the people component.

RUBEN CHACON: All the thought processes that we need to have in these cases sometimes. I see plans storing the server. But the server can get ransomware too. So you have to think about all those details about how you go in case that something gets really across all the company. You were saying.

BRIAN MCDOWELL: No, I'm just going to say, Barb, your CFO's full-time job is signing checks at that point all day long.

BARBARA WALKER: Oh, and by the way, my favorite is crisis communication. It starts with let's inform everybody via email. That makes the critical assumption that your email is available. What if your email is not available? What if your virtual Microsoft Teams, Zoom, whatever is not available? How do you communicate with your employers, with your suppliers and so forth?

RUBEN CHACON: Even among the team. You might not have communication there. You start using WhatsApp or something. So where should organizations start? What is the first step to strengthen the cyber resiliency tomorrow?

BARBARA WALKER: I think recognize that it needs to be focused on. It is something that is not just an operational issue. It's a strategic issue, and it's a company-wide issue. So band together.

Look at it as something where all the business lines, the functions, IT, security have to come together. Look at what's the baseline. Where are you starting from? Identify gaps and go from there. And leverage your suppliers.

I mean, I really appreciated Steven from Siemens talking about what they can bring to the table. We all have a plethora of suppliers that we are working with. They can bring good things to the table, and in crisis, we will need them. So establish relationships with the suppliers and make them part of the solution.

ED POLLOCK: For me, it's assigning the responsibility to the team or the person that owns the resources that is going after the recovery. So in our case, we have a infrastructure and operations team, and they own disaster recovery. They also got dedicated people that they-- that's their part of our DR office. So you have the responsibility with the people that control the resources. And then you have an oversight that makes sure that the plans are done, and the plans are tested.

And then from an IT security perspective, we're more of making sure that it happens from a high level. But if it was just given to me to make sure that it's all done, then they're going to basically-- I would be afraid that those resources wouldn't be as dedicated to doing it because that wasn't their responsibility. So that's where I'd start.

BRIAN MCDOWELL: Yeah, I mean, I'll go-- I'll just say go back to the basics on everything. So I know we had this conversation earlier today, but if I said to most people in this room in a hospital setting or in health care, everyone knows that washing hands is the best-- best prevention for stopping the spread of infections. It's the same thing in cybersecurity. Our boss, our CIO says, we used to say patching and encryption-- now I'm going to add multifactor authentication-- are the hand washing of information security. You need to do those things extremely well.

And if you look at any of the breaches that have happened over the last how many years, it's the-- well, of course, Equifax or Experian. Who was it? They didn't pass something externally facing for nine months. So when you said it's not if, but when, but of course. It's that version of it too if you don't patch something that's externally accessible.

Now if it's a zero-day and it came out 11 hours prior, this is what happened to F5. They got compromised two years ago, and the nation-state actor sat for 13 months and waited. And the way they got compromised was a misconfiguration on an external server that had a patch that was released 11 hours prior. And they sat for 13 months and waited. And then they were in their environment for nine months before something just popped up.

So I'm just trying to say those things are almost unpreventable, and that's why we have the resiliency aspect of it to be able to detect it and recover. It's those other pieces of if that's been out there like meticulously patch. Have multi-factor authentication on everything you can to keep people from infiltrating and getting to that point and get the foothold in.

But on the resiliency side, just go to the basics of have the people-- get someone empowered and people in place. Make sure you have the infrastructure. And that the backups are protected such that they don't get encrypted as well. I mean, honestly.

RUBEN CHACON: Thank you. So how do you balance technology with culture and processes? We were discussing this just a few minutes ago.

BARBARA WALKER: Technology does play an important role. I mean, we talked earlier. I think Steve made the comment about backups. So you need technology to have multiple backups in multiple locations-- obviously immutable because if you don't have backups, you're not going to be able to restore.

So technology does play a role. Process, I talked earlier about process. And it is important that people know what to do, how to do it, where to do it, how long to do it. You're not going to be able to do it without that.

The cultural aspect in my mind starts with resilience has to be looked at. It's everybody's job. It can't be-- and I think that goes to your point-- IT will handle it, or security will handle it.

It is everybody's responsibility. Because if there is a bad incident, everybody will be called upon. And I think we all, certainly myself, I would want my organization to be viable because that's my paycheck. So selfishly, I should actually be motivated to carry my load. And that applies to everybody in our organization.

We always talk about the what's in it for me? Well, don't we all want to get paid? Don't we all want to be able to put food on our family's tables and so forth? So it is a shared responsibility, and that's where the culture comes into play. I think there is still maturity to be had to say, look, everybody plays a role and everybody bears responsibility.

ED POLLOCK: So this got me thinking about 27 years ago in October, I started at STERIS. All right. We've been fortunate that STERIS. We've got a lot of people that have-- a lot have been there quite a while.

And at that time, I was responsible for the enterprise systems and the data center. Two weeks after I started, we had a major database corruption. We were down. Our ERP system was down for like three days.

And the other person that now is my counterpart that runs the infrastructure side, we were side by side working this. He had started maybe three months before I did. And STERIS at that time was maybe the tenth of the size it is now. We were very small.

And those over those three days, it really beat into us the importance of being able to recover. And I think that between the two of us that we definitely want that culture in place that it's important and have multiple ways to recover. Don't rely on one. Maybe don't rely on two. You may need 3 or 4 ways to recover if there's an issue.

I was kind of laughing when you're talking because when I opened my jaw like this, I can crack it. It was all because of those three days and the stress involved in that. So that's also a reminder that the culture of resiliency is important, because it can also have physical effects on you too, from the stress.

RUBEN CHACON: Stress.

BRIAN MCDOWELL: Yeah. I'll take the opposite approach and piggyback on what Barb said. I talked about technology earlier. I think it is just getting down to the basics of what is minimally necessary in order for you to run your business.

Forget the technology. You're going to have to go back to some level of paper or some process that allow you to still manufacture your widgets or still be able to deliver this to your clients. Figure out what that most important piece is and what you minimally need to run that and then protect the heck out of it. And if you can't, how can you run on-- run without it from a technology perspective?

And one other point on the people side of things. We can have the grant uses paper and pencil and strategy and so on and so forth. But in the end, people is what make it happen. All of the mainland processes and so forth, we need people. We need to keep people motivated.

We have to not lose sight of the human element. And if, for example, there's a prolonged incident, thanking people. I mean something as simple as not taking it for granted. Being thankful, celebrating little wins.

And so important to keep people motivated because a lot of it is for the long haul. People typically thrive if there is recognition, if there are simple thank yous and all that, and that can go a long way to also pull people together and have them step up and take on responsibilities that maybe they typically don't do. But it's those things that you could consider are little things. But they can be huge things. And this is what people will remember.

RUBEN CHACON: Yeah, and typically it's important to consider when there is a prolonged issue, how many people are holding knowledge on one particular area that nobody does? They cannot work 24 by 7. So think about those backups in terms of people that we need to have in place because they will not work 24 by 7 all weeks or months that are going to be needed. That's an important point. Thank you. So looking ahead, what emerging trends or challenges in cyber resiliency should our audience be prepared for, and how can they stay ahead?

ED POLLOCK: So do you want to go?

BRIAN MCDOWELL: No, go ahead.

ED POLLOCK: OK. I had mentioned before is the cloud services in preparing, making sure that you have able to continue to operate if you lose those services. And you're probably going to have to modify some of your processes on how you onboard stuff. For example, if it's a capital project, to request funds, you've got to identify what your DR requirements, your recovery requirements are in to get the project approved.

Expense is different. It doesn't go through the capital-approved process. So you've got to look at, OK, now what do you need to do to modify and adapt that process to take into account, OK, do we need to have a recovery plan for this new service that we're bringing on?

So I think after we've seen what happened with Crowdstrike, we've seen what happened. I think Zscaler had had an issue. We just recently had AWS had an issue. Planning how can you operate until those services come back up.

BRIAN MCDOWELL: Yeah, I would just say we probably can't get away without talking about artificial intelligence on a panel this day and age without being kicked off the circuit. It was an interesting conversation we had at the table. I think Dominic mentioned it where the-- I don't know this for sure. We have to validate, but the AWS outage was likely caused by AI, like almost an internal denial of service where AI was just chewing on itself and just blew up the AWS data center and caused all sorts of catastrophic issues.

So I think from a resiliency perspective, look at AI as an augment to automate and to support the smart individuals that work with you. From a looking-forward perspective, resiliency or otherwise, how can AI augment the individuals that are on your teams, the strong performers on your teams, not replace them?

BARBARA WALKER: A couple of other items. The regulatory complexities. So Steven talked earlier about the EU Cyber Resilience Act. I think that explains itself. Very large, complex requirements that come with that.

And Europe is taking a lead role. It reminds me of privacy-- Europe with the GDPR that set the tone, saying enough. We're going to regulate how personal data is going to be handled. And it's the same now with resilience.

With all of these attacks and so forth, Europe is basically saying, OK, we're going to regulate it. And we are they are, in essence, going to set the gold standard.

And so there's going to be more of that. I think now that Europe is going that route, more regulation is going to come out of it. You look at AI, the regulatory complexities around AI are tremendous because every jurisdiction basically has its own set of requirements. They don't necessarily overlap.

So how do you incorporate the regulatory compliance into your resilience program? It's getting more and more complicated. I know Michael talked earlier about looking for frameworks where you can have one common set of controls to make it a little easier, but the complexity is increasing. It has to be accounted for.

Quantum computing, post-quantum computing-- this is certainly something people talk about. Well, it's 10 years out. Maybe, maybe not. So that is something that has to be factored in.

Particularly for harvest now, decrypt later, how do you prepare for that? That is a multi-year journey to be ready for that. And then I throw one out that people don't typically talk about, climate change.

There was a lot of conversation on energy. Well, with climate change and erratic weather behaviors and temperatures, it is putting more strain on electrical infrastructure. What does that mean from a resilience perspective if you couple that with threat actors absolutely targeting critical infrastructure?

So you have the perfect storm where the electrical grid might be overloaded and, to a degree, is overloaded because of temperature and so forth. You have the threat actor going on top of it. It is the perfect storm. How do you incorporate that into resilience?

RUBEN CHACON: Thank you. Thank you. I appreciate very much your responses. And we have a couple more minutes. Perhaps somebody has a question here.

AUDIENCE: Thank you. Great panel. So as the threat actors get more sophisticated in social engineering, how worried are you about insider threats through bribery or maliciousness?

BRIAN MCDOWELL: Yeah, I think we're seeing it today-- very worried. I'm sure you've seen it. The North Koreans are actually working for you, and they've got-- they work at 20 different companies. And the paychecks are going back to create GDP for North Korean regime. It's happening today.

I mean, we had to train our recruiters, or we're working on training our recruiters, to look for these types of things. There's tools out there that say-- so extremely worried about it. It's kind of here. It's been here, but it's worse.

ED POLLOCK: Yeah, the IT worker is something we're also concerned about. We partner with HR to make sure that-- to develop processes and procedures that help eliminate or minimize that as being-- being able to happen.

Now, the harder one is going to be that you got an employee that's already been vetted, but then they've been bribed to-- to do something malicious on it. And I think a lot of that, you're going to have to-- you deal with limiting their rights to only have access to what they need to do. And then, of course, you're going to have to monitor through your SIEM and other tools. And hopefully, the AI components within the SIEM start to advance so that they can be very good at behavior analysis.

BARBARA WALKER: Yeah, and it's interesting. I recently read an article, and the headline was from sender aware to context aware. And Steve actually made the comment earlier when he talked about the SIEM that we have all of these different sources and the logs, but if you don't look at them in aggregate, you might actually miss things because you don't have the context. So I think having the right tools, looking at the data in aggregate to see the context and the behaviors that may indicate, well, maybe there is insider threat, or maybe there is somebody impersonating the North Korea fake IT worker threat. I think the contextual element is becoming more and more important.

RUBEN CHACON: Well, I want to thank you, Brian, Ed, Barb, for your participation during this panel and addressing this audience as well. Thank you.

ED POLLOCK: Thank you, everyone.

[APPLAUSE]

DAVE KANG: My name is Dave Kang. I'm from Dragos. I don't know how many of you folks are familiar with Dragos or what we do. Some of you may be customers, some of you might have heard of us. There have been books alluding to us, all this kind of stuff.

Really, what I want to talk to you today is about is OT specifically. Dragos concentrates and focuses solely on OT. And one of the things that I always look at and hear is IT is different than OT. Yes, that's true, but no one bothers to really explain why. So what I'm going to do here is maybe insult people's intelligence and/or just level-set for what I want to talk about, which will be coming on the screen sometime.

Effectively, they're completely conflicting systems. So I just wanted to give you an overview of that. We're going to talk again about the threat landscape as well from what Dragos sees, and then we're going to talk a little bit about the five critical controls, which are a framework to go over and how do you approach OT cybersecurity as a whole.

Now what is Dragos? For those of you who don't know, we are a specifically OT cybersecurity company. It's not about technology, it's not about just having a tool in the toolbox. That's just one element of what we do, and that's really fed from our OT Threat Intel Team, which is the largest in the world-- that is first-party, everybody on the team writes their own reports, we're not just regurgitating feeds.

We have vulnerability analysts, we have reverse malware analysts, we have people who are actually in the Telegram chats that you're talking about. A lot of them are former three-letter agency name it. We're based out of Hanover, Maryland, and obviously the proximity to government is important for us there.

We also do services. Probably most famous for doing incident response, things like the second Ukraine power attack in 2016. Perhaps you've heard of the crisis in the Saudi petrochemical plant, which was the first instance of killware.

The other element behind Dragos is really collective defense. Our tagline is "Safeguarding civilization." It sounds corny, but we care as much about this, that you have lights and running water that's clean. We care enough about this that we actually give the product away to municipalities under a certain dollar threshold of revenue.

So that concludes the time-share portion of this. So how did we actually get here? So if you think about the context of what we hear about mostly-- what I've heard about mostly today, with the exception of the-- Stephen from Siemens who was addressing it, IT versus OT. IT, we're typically talking about data. That's why data is so critical as far as what is important as far as information security. You have things like what you see here, digital IP, customer info. All this stuff is a legitimate concern.

But what is OT? OT is really the interaction between computer systems and physical systems. So when he was alluding to safety, for example, it's really maximizing your availability as safely as possible because, yes, people can get hurt in these environments. I've spent my fair share of time in dirty, dusty floors. I've had to throw away clothes after visiting facilities before just because it does get that grimy and gross depending on where you are. And no insult to anybody's business. So it's really the reality of things.

So, you have all these systems that are effectively not governed. We talk about OT systems. Generally everybody thinks about Windows boxes that are out of date. Fine, that's one element of it. We're also talking about automation devices, PLCs, things that are not authenticated, they are not encrypted, there is no audit capability, nothing gets logged. And these are all purpose-built devices that don't run in operating system, you can't apply group policy to them.

And really, how did this come about? Well, in the past, everything was isolated. It used to all be proprietary cables, proprietary protocols. Only those things could communicate with one another. So that security by obscurity used to be a real thing. Protected bubbles, islands of automation. Perhaps you've heard that term before.

So today, with the advent-- well, not today, 30 years ago, I would say, with the introduction of ethernet, what ended up happening is we have the same media and the same capability, the same connections, everything's riding on TCP/IP stack. So all of this came all at once, and these systems just built by accretion. And as the drive for more data came around, it's about connecting multiple devices.

Analogy of your home. 10, 15 years ago, how many devices did you have connected in your own home? That accretion now, you probably have a toaster that's connected to the Wi-Fi or something like that. But the same thing is happening on factory floors. So that expansive and exponential growth of all the devices that are possibly on the network, well, that's open attack surface, and this is stuff that people have never considered in reality.

So that's a brief background. The reality is, it was mentioned before, systems that are 10, 15, 20, 40 years old, they're still in use. It's not realistic to think that anybody's going to rip and replace it without good reason. That's how you make your money. It's how you're delivering a consistent product, and it's the best way you know how to do it.

So, when we talk about threat landscape-- this is kind of weird transition here, but this is the stuff that everybody always wants to hear about, what does the threat landscape look like? What we're seeing now as far as triggers observation is obviously world events that are going on. Political tensions between multiple types of countries and such.

Dragos, we don't do attribution. Just so you know, I'm not going to blame a country like those Denmark people are messing everything up. No, it's not like that. So what we see is a lot of what somebody had mentioned before, a lot of dwell time, and looking to exfiltrate data to have things set up to take later action in the event of something were to happen.

So take, for example, if we think about critical infrastructure and it being compromised, the water treatment plant that he was talking about before, why would anybody attack that? Usually there is a military-based application for that. There was a Massachusetts similar type of issue, and it had to do with a military base located in the area.

So, while we are worrying about trying to get water and electricity running to these folks, what's going to happen? What is the response going to look like? And the fact is, the military is not going to be able to move and respond to any of these conflicts. So, think about it in the context of that.

Targeted operations, this is the trend that we're seeing now, against critical infrastructure, but those things actually can also be used in nearly every manufacturing environment. And you guys generally aren't subject to regulation. So one of the issues behind that is there's been no impetus, there's been no gun to somebody's head saying, you've got to do something about this.

Hacktivist is something-- that used to be something of a side note, like an "also mentioned" kind of thing. What we're seeing, though, is a lot more hacktivist behavior just with the intent to cause disruption, whether it's critical infrastructure or otherwise. It could be they don't like what you do. What did your CEO say? It could be something that simple. And really, the phases that we're seeing now are the intelligence-gathering and just staging.

So it is no longer the nation-state threat actor, the state-sponsored adversary. It is also the hacktivist groups and the cyber criminals all working in unison. They're sharing tools. This is what's going on right now. So it really is a matter of time-- and I'm not trying to scare everybody, but the real fact of the matter is, traditionally you've not been a target. What's the impetus for it? Why would I attack whatever? Just because they can.

Every manufacturing environment that I've ever been in, it's, yes, there's a standard. There's governance associated with maintaining security from an infrastructure standpoint, but the reality is, manufacturing facilities tend to operate in their own fiefdom. So even though you decree something has to be installed, this is the software we need to use, one of the issues there is somebody is the king of the castle.

I heard somebody earlier talking about the plant manager being responsible for that-- and this is another example of it, right? It's the, I'll be damned if corporate is going to tell me what to do kind of mentality. Very proud-- and these are controls engineers from the start.

These are very, very intelligent people who are trying to solve a problem, which is to keep things operating 24/7 as efficiently as possible. So you give them that job to do, they're going to do anything in their power to do it.

This is also not to say ransomware is not a problem. The data is a little bit skewed on this, and I will admit, it's only recently, relatively recently-- past eight years, that we've really been focusing on ransomware statistics. What we're seeing, though, is an exponential increase just because it is known how ineffective security controls in OT are.

So I spoke earlier about legacy systems. Yes, you're going to see Windows 95. You're going to see Windows XP. I've seen Windows NT 4.0. I've seen things that make any IT person shake in their boots, the fact that they have that on their network. The problem is, these machines were created by a company to make your product, they do one specific job, and that's all that gets supported. Maybe that company no longer exists. The guy who programmed it in the first place died or retired or whatever.

Just because you don't have the wherewithal to replace those systems means you have to maintain these legacy pieces of hardware. The first gut reaction is always, well, we need to get rid of that and replace it with a newer operating system, get this up to patch standards.

Well, other news for you about industrial automation software in general, it's not backwards-compatible, so if you patch something in Windows, there's a good chance you're going to break the connection to be able to control that PLC. So patching is not the devil or anything like that, but that, in conjunction with operating in a 24/7 environment, there's not a lot of window to do any remediation even if you can do it in the first place.

So it's often the case that it's just very well-known that industrial systems have legacy equipment in it, and it's not realistic for it to all be ripped and replaced, so that's why the ransomware threat persists regardless. So some stats there.

Operational disruption is your immediate financial loss. It could also lead to safety. Think about waste product. Think about cleaning if it's applicable to you. The staff having to take time out to do that. Perhaps your processor batch manufacturer, you have to throw out all of that because it's not up to standard. So there's operational disruption.

Attack amplification via the supply chain. So I think a good example would be something like Clorox. Everybody heard about Clorox. Even though they're compromised and they could still create their product, they had no way of packaging it. So if you can't get that to the consumer, it's the same thing as not being able to produce a product. If you can't get paid for it, if you can't ship it out--

So this applies to not just the industrial system. As we see, they're all further and further integrated. Whether you have an MES, ERP regulating all of that, there is some crossover there, and all of these systems are so intertwined. And when Dr. Barb had mentioned that-- how do you solve for this to run for 100 days, even? This is something that you have to consider.

Again, legacy OT systems, I can't stress this enough because it is always every single thing I hear is, we got a patch. Tell me what the vulnerabilities are so we can patch it. But the understanding is that if you eliminate the vulnerability, there is no risk, but if you eliminate the vulnerability, oftentimes you're going to stop production, and who knows if it's ever going to happen?

That goes hand in hand with things like restores, backups. How do you find the PLC program that actually did that? Do you have backups? It's usually a case where it's seriously like Joe has a USB stick in his drawer. Nobody's had to redownload that program to the PLC in 20 years, so if that PLC died, what would you do? And that's part of the problem.

I previously worked for Rockwell Automation. So their equipment is so bulletproof that it's still working. I'm not doing that. But really, it's about understanding the needs, right in order to maintain that operating efficiency. And then human safety implications in a lot of systems there.

So I mentioned that Dragos does incident response. And in 2024-- all of these statistics, by the way, are in the Dragos Year in Review 2025, which is a free resource to download that gives you an overview of everything OT-specific. So what we have seen in compromised instances, companies with effective controls.

So something as simple as offline backups, network segmentation, all of these rudimentary basic things are becoming more prevalent, I'm hearing a lot of people paying more attention to it, but it's not actually being done. There's a lot to take on. It's an ongoing process, and you're never going to be done. So a lot of people are daunted by that and rely on the, well, nothing's happened to us for 15 years, so what's the problem now?

One of the things that I also think about in incident response cases, the time to actually respond and investigate what's going on is significantly lengthened just because there's no collection management framework. So what are the data points? Do you know where your Windows logs are? That's a very, very basic item.

But more importantly, these OT systems, if they do get affected, there's no log at all. So how do you have the ability to piece back together what happened when you have no record of what happened?

So lack of controls, which is, time and time again-- in fact, it's most cases, the incident response-- I mean, we're talking about 10 days, two weeks before you can even start the investigation. just because no one knows where the logs are. It's the first thing that Dragos is going to ask you if you call us to respond to something. Where are your logs? What kind of records do you have? And that alone is one of the biggest pain points as far as getting an investigation started.

Risk from the front lines, this is what we've seen essentially. Inadequate network segmentation. How do you contain it? That came up before? The answer is segmentation, but how do you do that? Well, it's going to depend. It's going to really depend on your environment, what your needs are.

I've had people say, I want to segment everything. We're going to have only PLCs on one network. There's a lot of technical reasons why you should never do that, but it's also, don't leave it as a flat network, which is what I see time and time and time again.

If you think about the context, I mentioned these proprietary machines running on legacy technology. These are all built by the lowest bidder. So you're looking at an unmanaged switch sitting inside this cabinet that's controlling 10, 12, 20-plus devices, and there's no way to monitor it. So it presents a huge challenge.

Most of the people on the IT side that I talk to are only aware of the Windows boxes because that's what some kind of active tooling might be able to discover. And, yeah, you not only have the PLCs, you have VFDs, you have I/O, you have all these automation devices, and then you bring into things like a ControlLogix backplane on the chassis with multiple ethernet IP cards. How do you see those hundreds of assets that you had no idea were there?

Shared authentication, this is one that, yes, I am aware that it is an absolute nightmare to even attempt to separate domains and have no overlap with that, but really, if one set of credentials is compromised and then used in the OT and IT environment, you're pretty much giving away access there.

Lack of visibility. Asset visibility, to me, is very funny because, yes, you want to know what's there, but is that really solving a security risk? Well, if you can't do anything about the vulnerability associated with it outside of doing segmentation around it because it's legacy, what do you do? It's really a list of things you kind of can't do anything about. I can't replace this equipment, I can't patch it for vulnerability, so what's really out there?

Asset visibility, to me, goes part and parcel to actual communications. What's the device communicating with, should it be, how is it doing it, and what is it doing? And these are the elements that I'm talking about with monitoring and visibility. We don't really care about the asset inventory, necessarily. It is important, you do need to know that, but it's really the communications that are more important.

And I had mentioned not only unmanaged switches, but unmanaged transient devices. You probably don't know this, but your consultant or your distributor, your electrical distributor, they're going to your sites. They're plugging in, they're plugging in, and somebody giving them an IP address that, yeah, it's on the same subnet, you better hope it's not in use. And I've seen things go out and go very sideways just from that. And a lot of that has to do with just no visibility. You have no control or regulation over what IPs are being consumed.

And yeah, you might say like, I have an IPAM, I have all these controls in place. When it's an unmanaged switch in the first place, you're not really going to know. So this is the reality of what we have to deal with, and that's why, when I talk about legacy systems, I tend to harp on that so much-- this is not stuff that's going to go away short of a massive, massive investment. It's just not economically feasible in most cases.

So let's think about third-party risks. USB drives, you all hear about malware spreading through a flash drive that gets plugged in somewhere. Whether it's your vendor, a subcontractor, someone internally, just, is it clean or not? Is there a VM that has malware on it? Simply connecting is going to cause some problems.

Unauthorized remote access methods. This is one of my favorites because everybody says to me, oh, we use Zscaler, we use Cisco, we use whatever. Did you know about the device that's actually on the machine? Also, it's connected via cellular, and you're giving somebody access externally with credentials that you have no idea or control over, and they have direct access to a machine. Chances are, that machine can reach something else.

And these are the things we do when we do things like OT compromise assessments. We're looking specifically for indications of that. Are there on-machine VPN routers in place? If so, are they authorized? Who is actually doing it? It's something that you really have to monitor.

Insecure vendor portals, we see this all the time. Not to harp on it-- or-- I don't want to insult Europeans or anything like that, but I have often noticed that the documentation for a lot of European manufacturers don't include any stipulations for security. Their knowledge base, I've seen them not have HTTPS on it at all, for example, and they want you to download software from these types of sites. So it's really another thing to consider, what are you actually connecting to? Is it legitimate?

There was-- there's a company, HMS, that, relatively recently, purchased eWON. Anyone familiar? Yeah. See? I've seen a thumbs down. So nobody wants those in the environment. Just as an example of vendor compromise, there is an application that's the VPN client for these devices, they actually got into the website and put a malicious copy of what looked like the VPN application on their website, people were downloading that and using that to connect, but it had a wide open backdoor.

So this is the thing that's going on. And again, it's done out of necessity, it's done out a lack of resources, it's done out of keeping things running. There is a facility-- I'm from Philly. I know, boo, but there's a company called Eastern Controls, and they run what was called the-- well, what is called the Process Training Unit there. I believe there's one here in Cleveland as well, but it's like a testbed for all the software and equipment that's all out there.

When I think about the control side of things, their last priority is doing security for it because it is hard enough to keep that running. And all this facility does, I'm not kidding, it heats up water in a tank and moves it to another tank. Yet it takes two guys to maintain this full-time, specifically dedicated to making sure it works. You think that guy is going to care about security? No. Do you think he wants to be restricted by a privilege on there? No. I'm going to make it admin. Everything's local admin, make life easier. This is the mentality, and it's really unawareness on both sides. What are the objectives? What are you doing?

So, all this gloom and doom. Five Critical Controls is a document written by SANS. So Tim Conway, who is a Fellow at SANS, and our CEO at Dragos, Rob Lee, co-wrote this document for the SANS.org Institute-- SANS Institute, that is. Five Critical Controls. It is a white paper. I'm going to give you a hyper-shortened version of this all in one slide here.

So when we think about what can you actually do, every framework that's out there is talking about this. It's not about checking the boxes. It's about, are you providing actual protection for your environment? And right here, this is all those frameworks distilled into five different categories.

One, incident response plan specifically for your OT ICS environment. If you don't have that, you're not going to know how to respond. We do incident response plan tests. We do the tabletop exercises, whether it's from an operator level, from an executive level, knowing who to call. Having that data ready to go.

And I love to talk about tabletops earlier because I've never seen grown people cry as much as watching tabletops. They think their jobs on the line, and we need to get out of that mentality.

Number two, defensible architecture. When I talk about those unmanaged devices, there are a ton of them out there. I ask nearly anybody in a leadership position, how many unmanaged switches do you think we have? Nope, none. We got Cisco 9000s in every closet, but downstream of that, what do you have? Well, we never looked.

That brings up another point of ownership. Does IT own it? Does OT own it? Who is responsible for the maintenance? Who is responsible for collaborating? And that's what we see time and time again. Traditionally, these organizations have absolutely butted heads.

What I'm seeing now is a little bit more of a understanding and willingness to go forward, probably because they're receiving pressure from leadership, but it's refreshing to see-- and it's a guy-- I've been telling you to do this for 10 years, but go ahead and not listen more.

Defensible architecture, though, that's really where the rubber meets the road, so to speak. So you think about the infrastructure that exists. I'm talking about unmanaged switches. Maybe you have to rip and replace those switches just to have some monitoring capabilities, some visibility associated with that. How do you maximize what you see?

It is absolutely ridiculous to think you'll get 100% coverage of every single piece of equipment. Short of going back and looking at the documents that show you bought whatever. You don't know if they're in service. You don't know if there are spares. You don't really know.

And it's those unknowns that become easier if you have an architecture that can be defended, as opposed to the flat network, which I see every single day. /16 subnet. Seeing that, too. It's wild what folks are doing in their environments. And there's no oversight to it. And the excuse is, well, I just keep it running.

It really needs to be a mutual communication and respect, and knowledge of what one side's priorities are versus the other. Where can you get together? There was a-- I referred to it as a-- I got interrogated by these folks here. There were some pre-canned questions-- well, it was one-- about how do you best do IT and OT together under the framework of IT? How do you do it easily?

Well, the answer is, you don't really do it easily. It is, for all intents and purposes, despite speaking the same language of ethernet, they're entirely separate estates. And they need to be treated differently, and there needs to be understanding behind that. Yes, policy is policy.

I don't care if it's an exception, I don't care if it's a whole new policy just for OT. That has to work hand in hand, just because, as I've told you, you fundamentally can't do some of the normal controls in IT. So everybody needs to get on the same page with that, that ownership aspect as well.

And I bring that up with defensible architecture just because network design, who's planning this? What is it plan for? What's the scale? How are you dividing your network up? How are you making it so you can contain things? How are you, number 3, achieving network visibility? And that's another challenge that we face.

Obviously, we have a network visibility tool that does look for threats, the Dragos platform and such. I don't care who you use. It doesn't matter. It's just getting any semblance of visibility in your environment is absolutely key. And again, I'm not just talking about asset identification. I'm talking about what are the things that are communicating, and should they be? Why is this PLC traversing four zones over? Does it actually need to communicate with that? Typically no.

And this is where you need the operations folks, the control side of the house, to help understand exactly what's necessary in order to better design and architect that defensible architecture.

So it goes hand in hand, segmentation, validation. You think these are air-gapped, but you have a tool in place that's showing you the communication, telling you when it was, what it was, what do you do about that? Well, obviously your segmentation is flawed and you're not air-gapped. So visibility is absolutely key.

Secure remote access. We don't offer any kind of solution for that, but what we do is monitoring for that, and this is what I was talking about, centralizing your remote access into as few different manners as possible. So what you don't want to see is this facility using eWONs, this one using ProSoft, this one using Secomea, this one's using a Hirschmann, this one's using whatever. There needs to be a policy instated on that, and above all, it needs to be monitored.

I just can't even believe that some of these pieces of equipment rely on credentials that you have no control over. Your vendor, the guy who built the machine, doesn't want to travel. He's working in a five-man shop. They don't have the resources to do anything.

Remote access is very interesting because of that. Think of the cost savings and the immediate help. You don't have to send a guy on site, et cetera, et cetera. How do you control that? How do you regulate that? Just don't forget, you're the customer to them. You can say no, and you can push back.

And one of the things that I particularly liked was a guy who said, this is the dollar amount that a compromise would actually-- what could be compromised, this is how much it's going to cost if this machine was compromised. And the idea is, that dollar figure, are you prepared to underwrite for that? They're going to get on a plane and see you next time your equipment breaks.

So the last of the critical controls, risk-based vulnerability management. Again, I'm not saying throw patches out the window, but think about it in terms of genuine risk. I'll give you an example. You have two PLCs. One is in a cabinet and it is your workhorse, it is your crown jewel asset. It is controlling water flow to every system in the place. You have the exact same PLC on Fred's desk that he uses to test on. Are you going to treat those the same?

What's the actual risk? Well, one is significant, one is irrelevant. How do you determine that? It's really about where does it make sense to actually go after these vulnerabilities?

And it's not just me who will say this. Rob Lee, the CEO, will say, if you spend more than x number of hours on vulnerability management in an OT environment, you're doing it wrong because a lot of this is beyond what a patch can do, it's all about mitigation. And that's something that, those of you who are familiar with Dragos Platform, we do offer guidance as far as what can be done for that. How am I doing on time?

MODERATOR: You have five minutes.

DAVE KANG: Yeah, well, that's good because I'm just done here. Are there any questions? Was this all stuff that everybody knows already? Am I just preaching to the choir here? Yes, sir?

AUDIENCE: Yeah the question is, you mentioned about legacy equipment and everything else that goes in the OT network. But a lot of the things you cover here is focusing on the network itself. How do you deal when the vulnerability is constrained to the legacy equipment?

You cannot even see any traffic or malicious traffic on the network, and you still can shut down the facility if you go directly to the equipment by plugging in service to or whatever-- there are several different ways of bringing that down. Even if you leave some latent malicious code on that equipment, it can shut down on its own or cause harm.

So everything, I completely agree with everything you said there, but that's all focused mostly on the network. How do you handle the vulnerabilities that are not based on network traffic?

DAVE KANG: It is-- it really is about the network, though. If you have those segments contributed to a piece of Rockwall hardware, 44818 and UDP 2222, that segmentation alone will restrict just the type of traffic that goes to those endpoints. So it really has a lot to do with the network if you can't patch.

So it is network controls. Nearly every recommended solution is going to be segmentation. And we would recommend looking at things like obviously having firewalls, ACLs, within switching environments. There's a lot that you can do about it outside of doing the actual patching.

If you can, during a shutdown or something like that, absolutely. Even better, modernize the equipment, but it's hard to make a case for that because it's been working fine, it's not broke, don't fix. So, yeah, I mean, a lot of that is contingent on network segmentation, and it's really about containing it.

AUDIENCE: Yeah, I agree, but network segmentation doesn't solve the problem of malicious--

DAVE KANG: It mitigates--

AUDIENCE: It mitigate--

DAVE KANG: And that's the thing. This is a problem that we're going to have. One of the things I say about vulnerabilities is you give one of our guys a piece of equipment and enough time, he's going to find so many vulnerabilities. And do we go and publish that and say, oh my God, look, there's this vulnerability? No, that's not what Dragos does.

We do publish vulnerabilities when they're real. We do them if there's a possibility of actual compromise. If it requires physical access, probably you have a bigger problem than just your device.

So I just like the focus to be on less on vulnerability and more on risk. What is actually going to hit you the hardest financially or safety-wise? This is why-- this is when we get into exercises a lot about what would you consider your crown jewel assets? What do you prioritize? Which sites are making the most money? That's usually the one that's going to take priority over others.

What's responsible for the bulk of your production, et cetera? And those are the things that you prioritize where you might think about doing things like addressing the vulnerabilities, but those are the ones that you want to segment. And it's really just about mitigating the risk associated with it rather than having the mentality of the patch solves everything. Yes, sir?

AUDIENCE: Yeah, I'd just like to say, I align perfectly with your strategy. My strategy is to stop one location from impacting another patient first, so top-level segmentation. Once you get that done, get micro-segmentation.

DAVE KANG: Yep.

AUDIENCE: If I go out and collect all the IoT, the PLCs, all the OT equipment, I find all these vulnerabilities, we're going to go broke patching them.

DAVE KANG: Yep, yep.

AUDIENCE: And then when we do all that, the engineering team's like, I don't even have the time to go do it, and if they do have the time, we don't have the budget to go implement it. So I totally align with segmentation for OT. Stop one location to another location, and then micro-segmentation.

So we're even going to a point where this machine can send downtime alarms and counts, get schedules down. This IP talks to these three IPs on these two ports, that's the only thing that goes on. If you want to do remote support, they throw a switch. Now the firewall rules change and we let VNC, RDP, whatever protocols, in, but the guy at the machine from a safety standpoint knows I let the guys in to do the work. They throw the switch, now none of that there, and you contain it even to a machine.

DAVE KANG: It's kind of like a lockout tagout just for that machine, except from a data-- from a network standpoint, yeah, yeah.

AUDIENCE: What are you doing about the engineering workstation talking about things that are even possible in an IT purview? That's probably something from that answer.

AUDIENCE: Basically you gotta get those impacted servers. You gotta worry about supply chain attacks. There's all kinds--

DAVE KANG: Where you can patch those, because sometimes a KB will break factory talk or whatever. That happens more often than not, and that's why they have those product compatibility matrices posted as far as what can you actually install and what can't you.

Obviously, endpoint protection is huge for that. I'm not saying that no Windows box is safe. It's very possible to actually have that EDR solution locally on that desktop as well. Any other questions? Going once? OK, cool. Thanks--

MODERATOR: Awesome, thank you.

[APPLAUSE]

NICHOLAS ALEXIADES: So my topic is The Future of Data Centers-- Safety and Cybersecurity. I've been teed up really well with the discussions at the beginning of the day, what Michael and Stephen were talking about. David also talked about a little bit, too. There's a significant amount of overlap here, and I'm going to try to touch on some different topics that we've had as themes, and then talk about a little bit of solutions from the standards and regulations point of view.

So I'm going to talk a little bit really briefly about myself. I'm not going to go through my resume or anything like that. I just want to say that I've been at UL for the last eight years, but I spent a couple decades of my career actually developing these products. I was a customer of UL's.

My first job out of school was actually designing PLC software and application code and so forth, and there was a couple of horror stories I thought of when David's talk and also at the beginning of the day with Michael's talk, where I was working on Siemens and Rockwell and other PLC types like that, and people were just plugging in an ethernet cable just because they could. And then we're talking 25 years ago. And they were doing this, connecting it to a network, just so they could try to access it remotely. Those products were not designed for that.

And over my career, I've had the opportunity to develop software from a functional safety point of view. And I was really happy to hear Michael talk about that earlier in the day. I think that's fundamental to understanding, also, security is that if we don't build it right in the first place, vulnerability is a secondary concern.

And I think Luis was kind of alluding to that a little bit in your question, where if you've got a bad product, you've still got possibly a vulnerability at the lowest level. The networks can mitigate, I think, some of that, but I will say that it is important to have the functional safety and cybersecurity covered at the component level, too. Otherwise, it's garbage in, garbage out problem.

So I do not have data specifically on data centers yet about the number of vulnerabilities. So these are some of the residential numbers. But it gives you an idea of the frequency of attacks that we see on a daily basis. Basically, if you think about 46 devices per household, imagine multiplying that out into a data center, with eight attacks every 24 hours on your home. And your assets are not nearly as critical as what's going on in a data center. So you can just imagine how often that they're trying to get into those more critical assets, all those malicious actors, and also those that just want to prove that they can do it, like David was talking about a moment ago.

The other thing that's happening is the proliferation of all of these new different endpoints, new different access points. As we try to build more smart systems, we try to get more data, we create more connectivity, which creates more vulnerabilities. So we want more data to go into AI to make these inferences on systems. We're trying to reduce downtime on a major power plant or a steel mill or something of that nature. Well, in order to get that data, now we've connected new points to legacy systems that maybe weren't connected in that way before. So it becomes easier and easier to get access to it.

I would say that, in general, AI workloads are driving a lot of this change. We're seeing also AI drive more, let's say, horsepower into cybersecurity. And what I mean by that is imagine the difference of cutting your grass with a motored lawnmower versus one of those push mowers. I mean, you're going to get a lot more done when you've got a motor on that thing. And that's what AI is doing with vulnerability, with hacking, and so forth.

You could go into one of these GPTs right now and ask it to build you some type of source code that will exploit a vulnerability on a piece of the devices that you're working on today. And it'll spit it out in less than a minute. And that was something that, you know, somebody as a software engineer, someone that when I started out my career, it would take maybe a day. You're reading manuals and so forth. And so going from a day to a minute is a huge escalation and whatnot. And so I think that's one of the aspects that we're trying to deal with from a cybersecurity from the blue team or white hat perspective.

The cyber physical realm is also something as we get-- I mentioned the more connected systems, but also, we're dealing with higher power. We're dealing with larger infrastructure. I mean, there's heating management, there's cooling, and all these types of things. So data centers themselves introduce new types of threats that we didn't have to deal with before.

You can put a vulnerability into a cooling system and be able to catastrophically fail the data center, data and so forth. You can find the vulnerability in the power management, the batteries. There's so many different points to go after. It can be an inverter. So there's a stack of all of these different devices that all can lead to catastrophic failures. And the higher the power, the more critical it becomes.

Safety and operational resilience-- I talked about how fundamental this is. There are standards, even as UL solutions and the standards bodies that we participate in. There are standards around cooling. There are standards around safety, there are standards around functional safety. And those lay a foundation that's important.

But the problem is that as we cross over between IT and OT, a lot of those legacy assets in the OT space knew about functional safety. They knew about criticality levels. They had risk-based frameworks that were based on standards. A lot of the IT folks were not dealing in that space. And so they're not necessarily building risk-based frameworks for development. They don't always have a risk assessment that they've done, either from a safety perspective or a security perspective.

And so you're transitioning from that Silicon Valley mindset into those legacy types of products and assets. And in some ways, it's a conflict. And so if we try to just mitigate the issue in the network, you're dealing with folks that maybe don't have the right knowledge. And that's where they'll go to consulting organizations. And they're going to try to outsource that information. But now you're lagging behind change. And that's the challenge.

Electrical and cybersecurity-- so one of the things my team and parts of UL's solutions we try to do is look at some of the existing product safety standards. We look at regulations and so forth that are coming about and think about, well, what happens if a cyber vulnerability can introduce a safety risk? So what happens if that inverter system, for example, can be attacked and lead to a failure of the energy system?

And so because of that, standards for safety, like UL 1741, have now included some, for now, optional references and so forth to cybersecurity standards to have that consideration in your mind. And as National Electrical Code starts thinking about these things too, they're also making considerations to making updates to reference existing cybersecurity standards as well.

So there's this bridge that's happening between safety and security. And it's a challenge because there's a lot of really great knowledge on cybersecurity that comes from, let's say, IT management domains and so forth that maybe didn't have to deal with safety integrity levels and things of that nature. And vice versa-- there's a lot of people that were in the compliance world and safety risk-based frameworks that don't have the knowledge of networks and infrastructures and data protocols.

And so you're trying to marry those things together. And it's very rare to have people that have all of that experience because you need decades in both realms, and it's not as common to find both. That's why I know that some of the folks here that I talk with on a regular basis at Eaton are trying to source those that talent here as well. I think there was some recruiting happening earlier this morning as well.

So I brought this one up-- I've used this slide a few times, and there's a lot of standardization that already exists today in a lot of the products. And so we're going to start on a product basis and then kind of go bottom-up and then top-down.

So bottom-up, I'm thinking about individual products that we deal with. And on the consumer side, we're pretty familiar with some of these things that we deal with on a day to day basis, your watches and so forth can create vulnerabilities. And there are standards that exist for those. And a common example is EN 303 645. And the reason I bring this up is that a lot of your IT equipment goes through standards like these.

Now these standards on the left-hand side are good standards. There's nothing wrong with them, but they're not necessarily built for the higher criticality systems on the right. And so you get a little bit of a conflict where you got something that was good enough for an IT space, and now you're using it in a safety-critical application.

Think about, for example, you have your laptop, and using it on your desk in your house is very different. If that laptop is now controlling large 800 volts DC. It's a big difference there. And so standards like IEC 62443 on the top there, that was built more for those OT systems that were controlling high power and things of that nature. And so you're taking IT equipment, and you're putting it into those spaces now that are safety-critical. And you're not often using the same standards bases.

And so that's where we run into sometimes a little bit of a conflict because these standards in-- other than medical, which is a different story, and we can talk about that over a beer rather than in this context here-- but 303 645 is not the same as 62443. They're both very good standards, but they're intended for different applications.

So we should be aware of that. If you're sourcing components, if you're a system integrator, for example, and you're getting a network switch or router and so forth, and it has been certified to cybersecurity, is it certified to the right type of cybersecurity? Is it really going to understand the level of risk that's associated with the application? And that's something I just want to plant a bug in all of your minds and so forth to think about because I know there's a lot of people here that are responsible for managing that level of security within the assets and system integration and the products themselves.

So the threats landscape continues to evolve. The challenge that we have-- I just showed some of those standards. There's so many different standards. It's a fragmented landscape. It's hard to really navigate all these things. And then that also leads to regulatory mapping and challenges as well. We just experienced a big rush for the radio equipment directive. How many of you are familiar with Radio Equipment Directive? Raise your hands. A couple hands.

So in Europe, there was this requirement for anything that had a radio in it. It could be Wi-Fi. It could be 3G, Bluetooth, whatever, or 5G. Any of those types of things had to go through wireless testing, like electromagnetic compatibility, but also cybersecurity. And so as of August this year, everybody had to be compliant. And so there was a rush from all of these product manufacturers to be compliant with RED. I know Eaton was dealing with that challenge too. UL Solutions was working with them, and we work with other clients like that to understand how do you comply with that?

The challenge is Europe released this regulation very quickly without a lot of notice, and all these manufacturers are struggling to map to it when there was already all those other standards that existed before. And so now you're trying to map to a new paradigm, and all of a sudden, there's a new regulation coming out, Cybersecurity Resiliency Act, which we've talked about. And it's a whole new paradigm that doesn't necessarily build on RED. It's going back to the legacy paradigms again. And so it's a little bit of a flip-flopping there.

And that's not to mention the US that hasn't really directly published guidance as of today that comes anywhere close to the level of formality that we're seeing in Europe. And so that leads to the challenge of the manufacturers that are developing global product portfolios, that you have certain guidance in Europe.

Do you create the same solution for the US when there aren't regulations in place? So maybe you're overengineering a solution for a different market. Or do you try to make a national deviation between the product designs? And now you have more SKUs, more products to maintain, and it creates additional complexity. And so there has to be some balance and trade off. And I know that a lot of the folks in this room are dealing with that challenge today.

And that leads us to this limited access to market intelligence. There's not, let's say, a published database that's really reflective of the current state of all of these standards, all these regulations. As UL Solutions, we have some tools that we try to publish, but that's always a lagging indicator. The governments themselves are still working on their guidance as well.

And so we don't have up-to-date information for a product manufacturer to get everything they need all at once. So we'll often engage in advisement and so forth with individual clients as we help them navigate through this. But the goalposts keep moving. We just had Radio Equipment Directive. I mean, August was two months ago. I mean, it's not that long ago. And now CRA is right around the corner, and we're dealing with that.

And who knows what else is out there. The machinery directive has now been updated to machine regulation. So for those of you that don't have to deal with that, imagine large-scale robotics in a smart manufacturing deployment would have some type of connected systems. Traditionally, it had functional safety built in, which means you had a risk-based evaluation of the safety functions that are built in. Don't have that robot arm crush somebody.

Now there's also AI and cybersecurity requirements being added to that regulation as well. And that's coming in Europe. So there's more of these regulatory demand drivers that keep getting released. And we continue to try to figure out what's the appropriate level of security for the appropriate level of risk that we're dealing with.

So I've talked a little bit about some of these things, like the high power densities. There's targeted control systems attacks. So my horror story about when I was starting to do development and they were plugging in those ethernet cables, those types of products have not traditionally been designed for security. I mean, you talked about it earlier in some of the discussions here. You might have legacy software that's been out there for 20 or 30 years. And so that might be a targeted attack because you might still be even using default passwords on these devices. I mean, people just weren't thinking about security in this way back then.

But now we layer on additional threat levels. Now we have these CUDA X types of deployments and GPTs and all this very fun and interesting types of platforms, but it creates additional attack surfaces. There's additional access points to the data. As you're taking, let's say, an interface to all the information that you're processing from the data centers and so forth, that may have some type of platform where you're sharing that information, and so forth.

And so can somebody get in that way, access the application that's being created? And it might be a Power BI dashboard, or it might be something that's custom created. There's a lot of different ways to get after this information now. And the more layers we add, the more vulnerability points we add.

And then, finally, new risks require cybersecurity strategies to integrate physical safety and operational resilience and AI factories. So what I mean by this bullet point is that the physical security is bleeding over into cybersecurity and vice versa. I talked about earlier cybersecurity threats can lead to safety issues-- the physical security as well. As we know, many of these types of vulnerabilities are through social engineering. People are actually physically accessing a device or getting in there.

So how are we preventing access to the system itself? Do we have access management controls, authentication procedures, and so forth? And not enough consideration, in my opinion, gets put into the infrastructure around the systems we're trying to protect because I think David was saying earlier, once you have physical access to the device, you've got a problem. And so I think, sometimes, that gets undervalued in the whole discussion.

So when we talk about what's at stake, I mean, so I mentioned this briefly earlier. Imagine you have these higher voltage systems. You've got 800 volts DC plus in some of these places. That is a level of voltage that can create a safety risk for people that are within proximity. It creates a risk that the actual data that you're housing can be destroyed because if you can somehow, through a cyber breach, manipulate those DC systems that are in the data center, you can create a safety risk. You can create a vulnerability for the data itself.

There's also a lack of standardized safety models as well. NFPA has been looking at these things, the National Fire Protection Association, I believe, is the acronym there. And so they are looking at ways to harmonize strategies. But fire protection, traditionally, did not have cybersecurity experts. This is a different type of forensic analysis being done there. You're talking about chemical and material safety and things like that. And so you're trying to blend chemical engineering with computer science. They're different disciplines for the most part. And so you don't just flick a switch and automatically have that knowledge.

And so there have been questions to my team and related teams around what should the NFPA be considering from a cybersecurity perspective? Could we start a fire with a cybersecurity breach? is the short question. And I think the answer is, yeah, in theory. If you got access to the right types of products within the data center, you could start a fire or worse.

And then I talked about the liquid-cooled cables, breaker performance. I mean, breakers also-- I mean, if you've got access to a breaker system and you put some malicious code there, or you prevent it from acting the way that it should, if it doesn't trip when it's intended, again, another fire and safety issue. So there's a need for cybersecurity assessments that can address some of these physical safety issues and the gaps that are in these standards.

So I'm going to give a really high-level overview. I saw a lack of hands when I mentioned some of the things earlier. I'm going to try to take a poll here on some of these things. How many people have been dealing with Cybersecurity Resiliency Act so far? And I see about six hands. I'm very surprised.

So in the EU, there's a regulation called the Cybersecurity Resilience Act that's going into effect as of 2027. And so manufacturers are spending the time between now and then to try to go through this process. And while the technical requirements are not yet fully formalized, the product-related essential requirements and the vulnerability essential handling requirements, those are some of the technical details of actual vulnerability management.

But right now, everything starts with the risk assessment. I think David said it earlier, too. Getting into risk-based frameworks is how many of these standards and regulations work. And that's how we should all be thinking. What is the risk we're trying to mitigate? Is it access to the data? Is it fire? Is it electrical shock? Is it all of the above?

But the mitigation might be different depending on the risk. How we prevent a fire might be different than how we protect the data that's in the data center? And we have to think about there's different mitigation mechanisms that we're going to use. A lot of the access to the data might be done through the network controls, but a lot of the fire protection might be through the actual products themselves, making better selections for products, replacing legacy components that might be more costly. But what's the cost of burning down one of these data centers? You have to balance out that risk trade-off. What often doesn't get factored in is the cost of noncompliance. What is the cost of that fire and so forth?

So risk assessment, vulnerability, product-related essential requirements, that will lead into a conformity assessment. So the expectation of the EU is that manufacturers are going to do a risk assessment, they're going to evaluate the technical requirements, and they're going to go through some type of assessment.

And so depending on the criticality level of the product will determine whether you need a third party, a notified body, like UL Solutions, for example, or if you can do a self-assessment, if it's a lower criticality of product. It really just depends, and that's where the risk assessment is critical. It's going to determine the level of rigor you have to put into the system. And it's going to determine the level of formality you put into actually proving that you did your homework correctly.

And then vulnerability handling-- so the thing to keep in mind with cybersecurity, as we all know, it's not just a point in time. It's not like product safety evaluation, where we evaluate a version of the product, and that version can stay static. And maybe we never change it for 20 years, and it's deemed compliant. Cybersecurity vulnerabilities is another moving target. And so we have to have a mechanism for handling vulnerabilities.

There's always going to be a vulnerability eventually. If the product is out there for 10 years, there's going to be something we didn't think about, or 20 years and beyond. How many of you have been to one of these industrial sites and seen a piece of equipment that's been installed for 20 years plus? Raise your hand-- a lot more hands this time, right? And that's common.

And now if it's got software in there and so forth, you could just imagine how quickly that software becomes obsolete. So the EU is asking you to have a method for vulnerability handling. And then there's going to be an obligation to report through a single reporting platform.

That's still a work in progress as far as what exactly that platform is going to look like. We get some of these insights through our engagement with committees like the TIC Council, and also directly with certain working groups for the Cybersecurity Resiliency Act. So again, this is still something that's being formalized. But I do want to make sure that we have a level of awareness because if you're not dealing with this directly, then probably your clients and customers and so forth are dealing with it.

So then what that leads to is a need to have certain types of frameworks to deal with this. If you're going to have to do conformity assessment, you need to show that you did your due diligence. And the way to show that you did your due diligence is through traceability. And normally, we would take a standard is a great way to do that. You can take some type of industry standard and then you walk through the requirements. And then, for each requirement, you may have a test or some type of analysis that you've done and so forth. And you can show that you've done the right things to try to mitigate the risks you've identified.

Existing standards include IEC 62443. How many have dealt with IEC 62443? All right, a handful, or maybe the rest are asleep. But either way, 62443 is probably one of the most common in the industrial space. It has requirements at the product level all the way up to the asset level. And so you're going to see that very commonly in the industrial space. UL developed 2900 to cover a lot more products from consumer to medical and also things like building access controls and so forth, so covering some of the gaps that are nonindustrial from that perspective.

So as we look at the data centers and the new stress factors that we're going to deal with, we may have to update which standards we look at. You may have just been thinking about IT security. You might be looking at your IT management system, like 27001. And so maybe you've got good documentation control procedures, and you've got good version control and all of that. And that's great. But you may have forgotten to think about the vulnerabilities of the actual products you're protecting.

So this is going to lead to mandatory security integration and component certification expansion. There's going to be a need for cybersecurity on a component level that we didn't have before because Cybersecurity Resiliency Act is going to force that from a European perspective. And so it's something to keep in mind as you go into this. In the past, cybersecurity was something to think about in many of these categories. There was a liability thing. We talked about financial loss in David's presentation. Now it's going to be a compliance issue. And so it becomes mandatory at that point.

So 62443, just for those that didn't raise their hands, is a layered standard approach. We have general requirements in the dash 1. We have policies and procedures in dash 2, which will also include some of the requirements on the systems. And then the system integrators will be concerned with dash 3. And then the component and product requirements are in dash 4. Dash 4-1 is a development life cycle. So how do you develop the product in a secure way? Dash 4-2 are technical security requirements.

There are programs that will dictate how you show compliance to this. So IEEE-- I'm sorry, IECEE CB Scheme-- it's too many letters, and it's too late in the day for me to say all those. But CB scheme covers this standard from an assessment and evaluation methodology. ISA, the International Society of Automation, also created ISA Secure, which is a program that also adds in a formalized way of demonstrating compliance for this that also prescribes testing for this as well.

So the standard itself is an assessment methodology that uses security levels and then an organizational maturity model to determine, OK, if there's a certain criticality of the product, it'll have a certain security level. That's the amount of risk. And that's going to dictate the amount of mitigation we have to do, the amount of engineering rigor that has to go into the design of the product to mitigate that risk. And then we'll map our organizational maturity as part of that and our development lifecycle and so forth.

As another risk factor, I wanted to mention distributed energy and inverter-based resources as one of those types of products. This is a standard that's been in our line of investigation, UL 2941, for a couple of years now and actually just completed consensus voting and balloting and should be released within the November time frame. So it's coming into play next month, a couple of weeks, and covers inverter-based cybersecurity.

So if you're dealing with inverter manufacturers, if you manufacture inverters yourselves and so forth, this is going to be something to consider. And so while 62443 often is looked at from an infrastructure perspective, from a standardization point of view, there are individual component level standards as well for cybersecurity, like 2941. And you could see some of the topics that these types of standard covers, from cryptography, secure data protection, the management from security management, risk management, and so forth, all the way down into antitamper and annexes on how to implement this standard.

Within the same vein. There's also the access controls. So how do you get in to the data center? How do you prevent unauthorized access and so forth? So building life security systems, your signaling, your alarm systems, and so forth, UL also has a standard-- 2900-2-3. And again, I'm not just advocating UL standards. I'm just trying to show you different aspects of the system to be aware of from a security vulnerabilities point of view.

So there's products like the inverters and the energy systems and so forth. There's the building access itself. And then there's the infrastructure that will be more of the 62443 types of methodologies. So there's different layers of security that we can look at as we look at the data center as an asset-- the actual building that has heating and cooling and things like that-- and the data center as a product itself, that's generating data that needs to have uptime and so forth, just like you would a manufacturing operation and so forth.

So suppliers will need to design secure products as supply chain is going to have more and more requirements coming to them because of additional regulations like Cybersecurity Resiliency Act. So suppliers to Eaton, Eaton as a supplier, as examples, they're going to have to deal with more mandatory compliance frameworks around cybersecurity.

And so it's something you need to be aware of and also to be selective of as well. If people are going to be dealing with these standards, there's a value-add to you, if you're a system integrator or an asset owner, to not have to go and take on that responsibility yourself to verify the security of the component. Buying and sourcing secure components should be part of that strategy, if they exist on the market.

Secure by design-- it's a principle we talk about everywhere. I don't want to beleaguer that point because I think we talked about it in multiple different presentations so far.

The customers themselves-- so something I heard also when Stephen was talking from Stephen's-- Siemens Energy, not Stephen's Energy. I don't think he owns the company. But he was talking about the idea that they're transitioning not just from an OEM, but also a system integrator in a way.

And one of the questions I wanted to ask but I didn't want to get stuck here for 30 minutes while he was answering just my question is, how are they educating the users of these systems? Because there's a lot of that security responsibility that gets taken on by the asset owner, the people that are actually supporting these plants and systems.

And so if you're maintaining a data center operation, how are you maintaining your security posture? Somebody like Siemens and Eaton and otherwise might come in with certain solutions for you. But at the end of the day, you're interfacing these OT systems with IT systems. And their IT systems may not have been built with the level of security criticality that's needed here. It's, again, transitioning between that Silicon Valley mindset to the critical infrastructure mindset. They're just different approaches. We don't want to move fast and break things when we have billions of data in that building.

So that leads to a need for training and awareness. There should be more training on the safety of these systems, and it's training of the users of the equipment. It's training of the designers of the equipment, and so forth. UL Solutions try to participate in that by developing standards based training and regulatory trainings and so forth.

So we have CRA, Cybersecurity Resiliency Act, training that we do, UL and IEC standards. But I would urge you, as system integrators, product manufacturers, and so forth, to also educate your customers to make sure they understand what are they buying, what is the benefit of secure by design, not just at the product level, but at the asset level?

So maybe I went a little too fast, but it looks like I've got a few minutes left here. Again, I just wanted to make sure that I highlight some of the things that are coming down the pipeline. And there's regulations that are driving this demand. There's high-criticality systems. And so, hopefully, this helps to open your eyes a little bit, for those of you that your eyelids are getting heavy at the end of the day here, to all of the different challenges we're dealing with from a data center perspective.

I'm happy to dive into details on any of that, either through questions here today or after the fact. My contact information-- you can reach me directly, or we can meet up at the Rock and Roll Hall of Fame later, too.

AUDIENCE: Great presentation. I think it touches on a lot of specific things that we from Eaton have to deal with, and you know that very well. I think the point you made that at the end is, essentially, in my mind, is the heart of what I was asking before, when we need to deal with the equipment itself, beyond just network traffic and all these regulations, like CRA, create mechanisms for the equipment to be upgradable, to address vulnerabilities through the life cycle of the equipment, address a lot of the legacy problems that we've been discussing.

And the question is this is as good as people-- I think that's what you're implying at the end. This is as good as people having the knowledge and taking the advantage of those regulations. We can, Eaton, or any other company here, can build the equipment and comply with the CRA. But if the customer or the manager or the facility that has that equipment doesn't understand the benefit of that, the capability of the equipment that the manufacturer needs to be able to fix, patch, upgrade the software that's running on that equipment, and nobody takes action on those vulnerabilities that are patched, then this is of no use to the end user or the equipment here.

So I think it's more a comment than a question, but how do you see these training programs that you have at UL? How do you see this driving the end user knowledge about what is becoming available with the equipment, the ones that have to comply with theory? How do you see this education process with the end user becoming effective in driving the user to request the patches and the updates there?

NICHOLAS ALEXIADES: I think honestly what we do scratches the surface of awareness. So I just did a webinar on cybersecurity regulations and the landscape and so forth. And we had, I think, over 800 people register for that event when, typically, it's 100 to 200 people. So it's a huge amount of interest is being drawn into this space.

And I think that there's two things that start changing the thinking. So we joked a couple of times today about all this legacy equipment running Windows 95 and things like that, and I've seen it myself too. But I think there's two things that causes people to go and make the software updates you talk about and replace legacy equipment. One is CRA, an actual regulation that now comes into place that actually forces these asset owners, system integrators, and product manufacturers to now think about cybersecurity from a regulatory perspective.

But the other thing that I think gets forgotten sometimes is in the effort to get more AI-driven, to drive more automation and so forth, you need data. And these legacy systems that are running Windows 95 and so forth aren't going to give you the data that you need to make the inference that you want to then predictively measure when downtime is going to happen and prevent it and so forth.

And so because of that, I think that that's going to be a huge demand driver that actually has a financial incentive for many of these organizations. And I think that's going to be probably even bigger than the regulatory demand driver is the need for many of these assets to want to go more AI-driven decision-making, AI-driven forecasting models and so forth, whether it's on power management or data flows and so forth. So they're going to need the latest versions of the products and software to enable that transition to AI-driven. So I think that's going to be a bigger demand driver.

So I would educate clients, consumers, and so forth on what that means to do that. We do that through functional safety training and cybersecurity training. But from a UL perspective, we're often just looking at the compliance view. Where I think that those types of financial impacts and so forth-- that's a supplier to customer type of conversation-- that, I think, has to happen. I mean, they want AI. They want this new data. But they may not be realizing what they're asking for.

They need more intelligent systems, which then have more robust and complex software. And it's going to cost more to replace those out. So that Windows 95 machine gets thrown out eventually in order to get something that can actually interface with the network and give you the data that you need.

We used to isolate everything and that was on purpose through obscurity, like we talked about before. But we can't be obscure if we want to have remote access and we want to have AI data models that with cloud computing and so forth and all of that, that we're trying to enable. So the technology itself and the ubiquity of it, I think, drives the need for many of these legacy operations to now update the software and products. I think that's going to be the biggest demand driver.

So if I was in Eaton's shoes, that would be probably the approach that I would go after because a lot of these people, they only think what their wallets at the end of the day. And we'll continue to do what we can from a regulatory standards perspective. And we're happy to partner with all of you on any individual engagements and so forth that might be helpful from an education perspective or anything like that as well.

We do have software tools that we try to use, too. So we're happy to use those solutions to help you as you're navigating this journey because it's complex. There's a lot that's going on that I mentioned earlier, and it's a moving target as well. And so you can spend time adding resources and so forth. Or you can also leverage some of our expertise to help you fast forward that knowledge gap.

AUDIENCE: Thank you.

NICHOLAS ALEXIADES: Other questions, if I have time.

MODERATOR: I actually had a question if there's no more. So I liked at the end there how you kind of spoke about responsibilities. One of the things that, I'll be honest, I personally deal with is knowing who does what. So can you speak to the importance of including those certifications and those requirements in specifications?

Because a lot of times-- I'll just give you an example. At Eaton, we'll get a specification, and it's not always clear, is a customer's IT team doing this? Is a different cybersecurity partner doing this or provider? And it's sometimes trying to figure that out on the fly. So you could speak to the importance of clearly defining what's required by the individual parties?

NICHOLAS ALEXIADES: Yeah, that's a great question. And it's often overlooked is that there's an assumption that's often built in to either the asset owner's mind or the component manufacturer or the system integrator. They're always pointing fingers externally. That person needs to do this or that or the other thing.

Something that I like to borrow from my personal experience is something we used in functional safety. So I'm going to borrow an automotive example. There's actually a tool that we use. We call it a development interface agreement, and it's basically a contractual obligation between the two parties. It could be the OEM, like let's say we're talking about BMW or Ford or Toyota or somebody like that, and a supplier like Bosch or ZETA F, or Eaton, for example, and all of these different organizations that they need to work with.

And that basically defines a RASIC-- responsible parties, who's the approver, who's going to support and so forth-- for deliverables. And we use this for functional safety that has very clear, defined deliverables. And if you use a standards-based framework, like 62443, for example, you can also develop a deliverables-based framework that you would have as part of your contractual obligation.

So for example, typically, the risk assessment is done by the OEM, the person that owns the product and so forth because they know the application. If we're talking about a component, a component might be out of context on its own, but when it's being put into an actual asset, now it has a certain use case that gets associated with it.

And so it doesn't make sense for a component manufacturer on their own to do a risk assessment on the whole use cases, but it probably makes sense for the asset owner who knows exactly where they're going to use a certain type of sensor or PLC or whatever the case might be.

So the risk assessment is a perfect example where you can assign that responsibility, but then that's going to dictate those safety and security requirements downstream. And so now you assign those requirements to one of those suppliers. And so you build this RASIC, if you will, that will help to establish an agreement.

And we used to use it as actually part of a supplier qualification process. So first, on the front end, making sure that we knew what we were signing up for when we're working with a supplier, and then, also, as part of our PPAP, our acceptance programs that we would have, where we actually evaluate, did the supplier do what we expected them to do? And so we use that development interface agreement to confirm that.

That's an example. You don't have to use that methodology. But I do recommend, in general, to have some type of agreement from a security basis, who's going to handle what? What part of the security infrastructure is going to be handled by the asset owner versus the system integrator versus the product manufacturer?

And I would guarantee that you will be-- somebody's going to be surprised in that. There's going to be a certain expectation or assumption that was built into their head. It's like, oh, I assume that the product already handled this or so forth. Or I assumed that the asset owner already knew about this. Somebody is going to be surprised along the way. And that's why it's important to have those conversations upfront. And then maybe you end up making better selections of your suppliers at the end of the day, and you can use it as a market differentiator as well.

JP BUZZELL: Hi, everybody. JP Buzzell, so built like a bear, fast as a gazelle, Buzzell. So a little bit of my background. I'll talk through this because I think it's more experiential in that aspect rate. So I've got a really checkered past when it comes to data centers associated with it.

So I had power generation for a few years in nuclear power. After power generation, I went on to working for the artist formerly known as Facebook, building out data centers, operating those data centers, and then starting to actually build the first clusters that came out.

So the A100 cluster that Facebook announced a few years ago, I helped build. Then I went to Oracle Cloud Infrastructure as director of operations, helped build out their first A100 cluster, 4,000 GPUs. I scaled out their Ashburn cluster, which is-- for those who are not familiar with the data center industry, Ashburn is the largest concentration of data centers in the world.

That's usually where the flagship clusters are for it. So I built, scaled out that. And then I was asked to take over data design for Oracle Cloud Infrastructure and designed most of the air-cooled standardized designs and the liquid cooling as well.

Michael called me up a few years ago, along with Louise, and said, hey, come on over and party with us and invent and work on 800 volt DC and all the other stuff doing that. So that's what I'm focused on right now, along with also the global strategy. So Louise and Michael like to be disruptors. I like to hang out with disruptors.

So walking through that a little bit, so right now, if you think about the data center industry and where we're at, everything in gray on the screen right now, all of that is bottom-line expense. The only thing that actually makes money in the entire data center industry is the software as a service, or soon to be the agentic as a service, right?

And I say that because without a human experience improvement, there's no reason to be doing a data center, right? So typically, we're bringing in power somehow, converting that power to data. And most of that power is rejected as heat in order to cool the chip.

Over the last few years, we've had a convergence that's occurring, right? So from 1990 to 2020, we've had a convergence going from 3 Kw a rack over to 17 Kw a rack. So that increase in power demand over 30 years was one order of magnitude. And then it went up in the last five years another order of magnitude to 120 Kw. I have 100 on the screen for a reason, just make it easier for the numbers. You just move the 0 over.

That aspect that was in 7.5% of the time that the last order of magnitude occurred. So if you feel like we're having to run faster, we actually are, right? The next order of magnitude to 1,000 Kw, which is now officially been announced, that's happening, most likely, in less than 7.5% of the time, most likely in the next three years. Before the end of the decade, it's targeted to be at 1,000 a rack.

So going back, if you are an OEM, Original Equipment Manufacturer, or if you're a facility owner, you're the highest asset at risk in the entire data center value chain. Because you're the highest asset at risk, there's a lot of questions, because typically, a facility owner uses a CapEx expenditure or capital investment that's a 15-year payback period, roughly about 9% interest.

And those facility owners will then go on to actually make money by running the facility and leasing that space. If you get into that portion called Ready for Service, or RFS, that's how a co-location or an MTDC starts making money, by charging rents on that space.

After that, you can become an IaaS, or Infrastructure as a Service provider. And that's where if you have 20mw and 10,000 GPUs, you can rent those 10,000 GPUs of H100s out for about $3.4 million a week. That then monetizes to a SaaS customer at a 3 to 5x multiple at $15 million a week.

While we were in this room, Jensen put out the one gigawatt standardized cluster. That one standardized gigawatt cluster, roughly, can be about $100 million a day. So there's a lot of money in that value chain. But without that human experience improvement, you can't achieve that. And how do you mitigate that risk, along with being an OEM supplier, and particularly, what's coming next is that cybersecurity.

Because we've talked about how the convergence occurs. And when you converge a lot of items, they need to connect together, right? In the past, we've had discrete items of the racks, the cooling, the power, and the networking. But I think the last two presenters did a really great job talking about how you want more and more connected.

And as you connect more things, there's more risk profile because you have to talk between each other. Particularly when you link cooling and the racks and cooling and the power, those items that used to be separate control loops. Now have to talk together.

In addition to that, you have to have now portions of the systems that were originally disparate and disconnected or disaggregated, power of the rack or the rack to the UPS or the UPS to the generator inside of there connecting back to the grid or the medium voltage transition, the high voltage transition in that aspect.

So typically, you had three separate. HV had a ring bus on site where you went from HV to MV, which had a certain control scheme in the ladder logic, medium voltage, second control scheme, and finally, the low voltage had another control scheme. With the need to be able to talk across those boundaries that are already naturally in place, there's more risk in that appetite occurring.

This is a load filtering strategy, just to walk through it real quick. Something that's happening in the market right now that's probably a six month target for the data center industry is, as you put everything together, things that used to have something called power diversity, or multiple different loads running at the same time, now are all working in concert.

So imagine all of us were talking-- or all musicians. We're going to go to the Rock and Roll Hall of Fame. So I'll use the props. So everybody gets a guitar. Everybody gets a different sheet of music. And we all start playing.

That sounds different because we'll have the diversity. Might not sound that great. But it's diversity on that aspect. Then I pass out the same sheet of music to everybody in the room with everybody on the same guitar. And we start playing together.

The amplitude of the music will all go up and down at the same aspect. Because of that, you'll see those GPU spikes. Those GPU spikes will now be seen on the low voltage grid side that you have to then mitigate through certain means. This is talking about the actual use case is using active harmonic filters at that level. Then you step up to the medium voltage, where you're talking about the medium voltage, low voltage transition and how you're using UPSs for that.

That UPS now needs to be coordinated with that active harmonic filter. Then that active harmonic filter goes and talks then to the BEZ on site, because then you have something called connection to the grid. So load ramp studies are now becoming another regulatory item that's coming into the market.

How many of you heard about the 1.5gw drop that happened to the Eastern grid in the United States? How many of you guys heard about the 1 gigawatt drop in Spain? The blackout in Spain? All right, so hopefully, more people heard about that one than the other one.

The reason why you heard about the one in Spain is you actually lost power due to stringiness in the grid and a lack of resiliency in a load ramp. The reason why you didn't hear about it in the US is just because the US grid, we're lucky in the fact that we only have two, East, West, and then Texas has one because they're Texas.

Texas has been having problems when you have a polar vortex. Have you ever heard about losing power, freezing of the gas lines in Texas because it's a smaller grid in the United States. But these things are actually happening already over in the immediate grids that are coming for load ramp studies. That's why this item that's coming in-- so it's pertinent as a use case to cybersecurity because we're actively collapsing these boundaries as we get more complex in the need.

But in the end of the day, it's all about how you support that chip, right? We talked about getting the power into the chip, going from high voltage down to 0.6 volts DC. Not the focus of this talk, so we won't get into those details.

But then you have to remove the heat. The heat needs to be removed because when you go to the fundamental unit of a chip, a positive, the negative or negative the positive, 0.6 volt turns out to be a 1 or a 0. You add up a bunch of 1s or 0s together. You start getting data packets. We call them tokens now.

Those tokens then will be transported to create the human experience improvement. Forgive me if you guys have heard my favorite one to use about the human experience improvement. I love my mom. I'm a mama's boy. So you hear it a lot.

My mom, about eight months ago, got an AI inference uploaded to her hearing aid. Same hardware, but the firmware upgrade then allowed her to hear her grandkids again. It's all about the connection for families, for me, how do you improve the human experience? Healthcare connecting communities so we can work better together.

Societies are built by mutual trust and positive intent and ensuring those things. That's what the AI promises and can actually do, right? Whether you like it or not, the self-driving cars, I love them because it minimizes the amount of strain on me when I drive up to and from. It makes me safer. Like, those are trained on the actual waveforms or the actual models, right? So that was trained on one of the clusters I helped build.

So you actually get that human experience improvement when we're doing that. But we have to think about the totality of that as we combine together. So linking it back to the data centers and cybersecurity, I really love Dragos's presentation from that company because it talked about factories and the factory application.

The new mindset shift of where we're going is we're going to AI factories. These AI factories or data centers are groupings of ladder logic controllers, groupings of antiquated equipment that might not have been put together and are now being linked together in different ways that we didn't think before. So there's a lot of things that we can do together to improve the future. All right. See you at the Rock and Roll Hall of Fame. Thanks.

[APPLAUSE]

BALAJI GANESAN: So great to be here. Thank you for the opportunity. Appreciate our customers and partners also taking time and spending their day and a half here with us. Before I begin, I have two co-conspirators with me in this room. One is Vinod Nair. If you haven't had a chance to say Hi to Vinod, Vinod runs both our mission critical facilities, our data centers, and they use all Eaton products. We consider ourselves as customer zero for Eaton products. So if you haven't had a chance to say, Hi, Vinod, then you can talk to him about our experiences using our power quality, power distribution, as well as our digital platforms Brightlayer, both at data center at the edge. And then we have our Deputy CISO, Jason Koler. I'm sure you ran into him. Maybe he lost his jacket last night?

AUDIENCE: No. No.

BALAJI GANESAN: You're good? OK. You behaved. All right. So if you have any cyber-related questions, Jason's going to answer it, and not me. So with that, the topic that was given to me is-- let's talk about AI and cybersecurity. So I'll probably spend more time talking about AI because I think that's more fun, and I don't know about cybersecurity. But it is needed, so we'll touch on that as well.

So there's no doubt that AI is transforming how businesses and consumers are leveraging AI to operate their enterprises or in their personal lives, and so on and so forth. Some of the stats that you see here, more than 75% of organizations today using genAI are using that at least in one of their business processes. And I know for sure in Eaton, we are using it more than-- and more than one.

And as they become more sophisticated, as they become more faster, they're becoming more multimodal, it's text, it's video, it's voice, the inference rates are really improving. The last time I was doing some research on ChatGPT versus Llama versus Gemini, they're moving from billions of parameters they're using to make their models better and slowly getting into the trillions of parameters. So the amount of research and innovation that is happening in this space is really staggering.

And then agentic AI is taking over everything. And soon, agent-to-agent interaction. And we are deploying some agents in some of our critical functions as well, and I'll touch on that a little bit. Companies like Eaton, we are moving from the pilot phase to deploying more at an enterprise scale. And there are some statistics here that talks about 21% of the organizations are using genAI to redesign their work place. It is just not "let's take what we have today and plug in AI," but it's fundamentally rethinking how we operate, and how we work, and how do we make-- add more value, both to our customers, to our employees and partners, and so on and so forth.

Just as an example, Microsoft Copilot, for us, went from pilot to enterprise scale in 12 months. We started with a few hundred, couple hundred users. For the first time, we also started with our C-suite. We never deploy new technology to our C-suite. We try to test it-- run it to the ground before we deploy it, but not in this situation. It was painful, but we did it. But now we have more than 10,000 people, employees, on Microsoft Copilot. And we are very proud of that fact, because it's now really embedded in how we do work. And that represents, I think, close to maybe 20% of our-- I want to say people that have these technology assets. And continues to grow year over year.

And the way we are thinking about it is we are placing bets both on everyday use of AI. That's what is putting AI in everybody's hands so they get to know-- get a feel of it. But at the same time, encouraging them to think about big bets. And big bets here are how do we achieve those bigger business outcomes? How do we increase our revenue? How do we increase our profitability, improve our cash flow, improve customer experience, improve employee experience, and so on and so forth. So we started with everyday AI, but we have not let go of everyday AI, but at the same time transforming the way we think about AI in placing big bets.

Investments, as you can see here, in AI is just unprecedented. I was not able to get an accurate number. I looked at various sources as I coded here, and the numbers are all over the place. I landed on $600 billion in global spending in terms of AI, large companies and all the usual suspects. In US alone, the number that I got was close to about $100, $110 billion in AI. That's about 12 times more than what China is investing just in 2025.

Interesting fact about medical devices. I was looking at the FDA website for something else, and I realized that the FDA has approved about 200-- I think the number changed overnight. It's 290 plus medical devices that are AI-capable. So think about you visiting your physician's office, and they're doing a scan, or an X-ray or something, and nine times out of 10, the first person-- or first thing to see your scan is an AI. Radiologists are using AI for quick inferences, and their productivity is improving. The detection rate of anomalies is all improving. And that translates into every medical field, every medical opportunity. And I thought that was an amazing fact that I thought is also going to change the way how we think about health and so on and so forth.

There are challenges, right? And there are common barriers that we are seeing across the industry. Companies in the manufacturing space, we have a lot of legacy infrastructure, and there's an amazing conversation about OT yesterday and the challenges of OT cybersecurity. It all adds up over time. Data quality is a big challenge, and there is an immense amount of focus within the company today to consider data as a critical asset. And how do we improve the quality of data?

Talent is another one. We are all learning as we go, and we're trying to keep up as much as possible. But finding people that can think how AI can help us improve businesses and actually improve our outcomes, so on and so forth. Regulatory complexities. You see there's 9x increase in the amount of regulations related to AI just in the past year. Last but-- if you think about the maturity, how do you counter the threats related to AI? That is still a big opportunity for all of them.

So why it matters is that clearly, AI is no longer exponential. It is transforming operations. It's transforming productivity and decision making. What is key for us here is how do we balance the speed of innovation with the right amount of cybersecurity and governance in place? Let me move on here. Again, feel free to stop me at any time. I don't really have to go through all the content, but I'd rather have a dialogue here with you folks.

So again, this one, for me-- again, we have a conversation within our team, are we really ready? The pace of change here, again, as you see, is exponential. ChatGPT. I hope we all remember what we were doing the exact day ChatGPT was released I do. I'm really a geek that way, right. I'm like, what the hell is this? It's going to change our lives.

And I was chatting with my son, who-- like, are you guys using this in your school and all that? He's like, oh, you're late to the game thing. So GPT reached 100 million users in two months. Instagram took 2.5 years to reach the same amount of users, and Netflix took 10 years. Two months. That's the rate of-- it's just mind boggling to just see the amount of adoption ChatGPT got just in a couple of months.

And I thought, OK, we're going to be in this space for some time, and then comes agentic. I'm like, what is happening here? And now in 2026, we are talking about other capabilities beyond agentic. We're talking about agent-to-agent interaction. We're talking about human general AI, and so on and so forth. So why is this disconnect right now? 97% of companies saying that there is an urgency to deploy AI, whereas only 14% feel that they are AI ready?

The urgency is rising because of the competitive pressures. It's no longer OK, let's do this. It's a nice thing to have. It's considered as a competitive advantage. It's becoming baseline expectations. The way we change work, the way we think about going about doing our work, if we have, for example, even the function that I run within IT, we deal with a lot of critical infrastructure. And what I'm asking my team is, how can we make this infrastructure self-driving?

It is not just be proactive about making this mission-critical infrastructure available to our consumers, but how do you make it self-driving? How do you make it more predictive? So it's becoming the baseline expectation. It may not be ready, but at least expectations are there, because I am going to all these sessions such as these. I'm hearing people speak about that, and I'm like, what are we doing? When are we going to bring this so that there's a lot of pressure from that perspective and becoming baseline expectation, and the fact that it's becoming a core differentiator, and it's no longer a "nice to have."

The challenges that I mentioned about legacy, infrastructure, data, talent, is there ROI on the investment that we are making? That is a big question. That's a big question that we are talking about right now. And how do you measure the ROI on the investments that we are making? And while we have executive buy-in on investment, the conversations are going beyond just the investment and focusing on, OK, now let's talk about the return on that investment.

So what are companies like us doing to close this gap? We're making sure that our AI roadmap and our AI strategy is really intertwined with our business strategy. It is how do we achieve these business outcomes, these business goals, and how do we make AI as a core part of achieving that business strategy? I mentioned about data. Anytime we talk about AI, it's always data and AI. And it's a critical asset that we are really focusing on so that we can do better AI down the road as well.

A lot of effort in cross-functional AI literacy. It's not just IT. It's all the other functions and the function leaders talking about AI and understanding how it can really help improve their operations. And last but not the least, it's really strong governance framework, and again, a cross-functional governance framework is needed to increase that 14% number.

Again, unprecedented investment. $1 trillion worth of AI deals have been made. It's a really squiggly diagram here, and if you really want to see how this was built up, the source of this one is CNBC. Everybody's investing everywhere. I don't know whether it's the same billion rotating. Sometimes I get confused. But $500 billion Stargate, $300 billion, OpenAI and Oracle, Microsoft investing in OpenAI. And then there's Core-V in the middle of everything. So it's all becoming one giant ecosystem.

It's interesting how this is evolving. And again, this is just OpenAI thinking about the amount of investment they make. And I'm not complaining. None of us in Eaton are complaining. What it means is we need more data centers. We need more power, more power quality, more power distribution, more things that we need to put physically to enable all of that. So we are estimating that there's going to be a four to 6x increase in the amount of data center power capacity measured in gigawatts here. So this is exciting for us. And we are in the sweet spot for providing-- supporting our customers and enabling them to build these capabilities rapidly.

AI is not perfect. I'm sure you guys have seen all these examples. I'm from the Detroit area, so my favorite one is the Chevy chatbot recommending a Ford. Can you imagine that happening? Imagine the reputational risk. Somebody is going and saying, hey, I want to pick up truck. Tell me which is the best pickup truck available? And the Chevy chatbot's saying, go buy a Ford F-150.

So that is the risk that is there today. And there are other examples, Apple saying that some prime minister was arrested, but it was not true. It was just making stuff up. So this is where the real challenge is in terms of how companies are leveraging AI. And this is what is making the importance of cybersecurity, and governance, and data even more critical to be-- for this to be a success.

So I'll talk a little bit now about the Eaton story. We are making a really bold shift at Eaton. We are embedding AI into how we do work on a day-to-day basis. It is core to our strategy. It's going to be core to our operations. It is how we will achieve our business outcomes. It is not just another thing. It is how we will achieve our business outcomes and create value, both internally as well as externally.

The way to think about this is we are focusing on three main areas. I'll touch on enterprise AI. Again, it's about all the functions. You think about creating a digital thread for, for example, a process such as how do I purchase all the way to paying our suppliers. How do I get an order, all the way to how do I get the payment from our customers. We are thinking about creating a digital thread that's built on data and AI across the board, and how is AI going to help make that process more efficient? Not just the process, but also achieve better outcomes. I have one example I'll share later.

The other one is, how do we make the products that we design, and sell, and service, and solutions to our customers, how do we make them more intelligent? And since a lot of our products are already connected, the insights we get from the data, how can they help our customers and serve our end markets to do whatever they are meant to do? So if we have an energy meter deployed in the field, the data coming from the energy meter, will it help our customers to save energy cost? It's building intelligence into our products.

And last but not least, there's a heavy focus of engineering and design in the company. How can we make our engineers' lives easier? How do we speed up the time it takes from design to manufacturing? How do we improve speed to market? Simple things like AI-assisted design. Can we use AI-assisted simulation? Do we have to run the simulation over and over again, or can we use physics AI to not do a few rounds of simulation and get from point A to point Z quickly using AI? So there are many areas that we are exploring within the company. So again, it becomes a core part of how we operate.

I borrowed this slide from our CEO, Paulo when he was talking to the New York analyst in terms of how AI is going to make our company more faster and profitable. And he spoke about several areas, like customers. We talk about customer service. We are talking about sales. We're talking about opportunity pipeline. We're talking about how we can do quotes faster, so on and so forth. And there's one example where we have something called the AI spec reader.

So we make a lot of engineered-to-order products for the data center segment, as an example. It has a lot of panel boards and things like that. Each panel board is engineered to order. So today, what happens is a customer sends in a requirement. A person sits and thinks about, OK, how am I going to design this panel? What are the components I'm going to put in? They spend hundreds of hours doing that.

So instead, think about AI using something like what we are calling as a similarity engine. Hey, we have already done something like this in the past. Can we build not from the ground up, but start from point 10, not from point zero? Here is a template that you can already use. That way, we can configure or engineer the product faster, create a code faster, meet the customer requirements faster, and so on and so forth. So that's the example here, say, that's really helping us in improving our sales engineers productivity.

And we are not doing this alone. And I think this is very critical for us. We are working with a robust partner ecosystem. It is a collaborative effort. It is not just the product is ready and then we are using it. We are working with them to cocreate in some cases. We are creating this value together with our partnership. And it's not going to be possible without that strong collaboration that we have with our strategic partners. They're kind of investments that they are making is something that we are really leveraging in this space.

So I'm doing a plug for IT. We are the eye of the storm here, the IT organization. We understand what the new market realities are. We spoke about all of that in my first slide. And then our senior leadership has really set the tone by what are the outcomes we want to achieve in the next strategic plan period for the company. Paulo announced that we want to grow into a $38 billion company in our strat plan period while managing costs. So here is a great opportunity for AI to play a role.

And then within the organization, we have strategic initiatives and what we call as operating for growth. How do we lead, invest, and execute for growth? And how does AI become a core part of all of that? So we know what the market reality is, what the outcomes that we need to achieve. So we organize ourselves into what we call as AI factories. These are dedicated-- you can think of AI pods by function. So supply chain will have an AI pod. Engineering will have an AI pod.

Other functions like HR, and so on and so forth. So we have dedicated, agile teams that can move really forward, that have the technology capabilities, that have the process expertise. It has sponsorship and championship from that particular function. So it's not just an IT team. It's a cross-functional team that is enabling us to move faster in deploying our IT strategy. And so far, it has worked.

And each factory is also measured by the outcomes they are achieving. If it is engineering, how do you improve speed to market? How do you improve design timing and so on and so forth? If it is supply chain and manufacturing, in the shop floor, how can we do better scheduling of our manufacturing capacity, and so on and so forth. So that's how we are attacking this and organizing ourselves to meet the commitments that we have made.

I mentioned one example about big bets. We are really doubling down on this digital thread. And if you look at the process from left to right, from sales all the way to service and how we are achieving that, and how we are embedding AI in each one of those critical processes, and it's not just-- I gave you the example of the spec reader, and the spec reader and ETO automation, and how do you improve accuracy, how do you improve efficiency, or reusing your designs, finally resulting in end user or the sales team productivity. But it's also in the manufacturing shop floor, improving on-time delivery, productivity of folks on the shop floor using, for example, vision AI to improve quality. And finally, all of that is helping us to manage our inventory process as well.

And then recently, we deployed something called the Eaton Digital Assistant, which is an AI-powered capability for our support engineers. So while they are on a call, they can easily use information available to them based on what the customer needs. And then we went one step ahead and exposed this agent to our customers as well, this digital agent. So they can directly interact and get information. And while we have the human in the loop, we still have improved satisfaction with the customers because they get these answers more quickly.

And it's also shifting left, and redirecting calls, and so on and so forth. That is something that we are-- built the foundation last year, and we're building on top of that. And we are taking a similar concept and deploying that internally within the company. And a couple weeks ago, we deployed something called-- our intranet is called Joe. So we deployed a capability called Ask Joe, where-- and I used it recently. This is the season where we have to go and do our benefits. It's really complicated and confusing. You have to click through like 10 websites.

I don't know if you guys have used it. Then I just use it, hey, how do I do this stuff? And it was laying the instructions in a very simple, easy to digest manner. And so it just makes my life easier. It improves my productivity. I don't have to go read 10 documents or three presentations to know what to do. So those are the kinds of things we are doing at Eaton, where it's not just customer facing, but it's also employee facing, and again, making sure that everybody has access to this capability.

Now we have a few more minutes here. Securing AI. Just a quick poll. You guys know what this is? Anybody wants to take a guess? Go ahead, Jesse.

AUDIENCE: Mona Lisa.

BALAJI GANESAN: Mona Lisa. A little bit more.

AUDIENCE: It's a painting by Leonardo da Vinci.

BALAJI GANESAN: Leonardo da Vinci.

AUDIENCE: Yes.

BALAJI GANESAN: OK. All right. However, this is not the one by Leonardo da Vinci. This was created by Midjourney AI. OK. What is this, then? Is that the real Mona Lisa?

AUDIENCE: We don't know.

BALAJI GANESAN: We don't know, right? Maybe, maybe not. So this is what is happening because of-- this is the threat.

So none of these is real, I think. The other is clearly AI generated. But what if I tell you that both are AI generated? So what does it take to create a deep fake like this? In my mind, you need two things. You just think about-- if you are a painter and you're going to recreate the Mona Lisa, what do you need to be? You need to be the best painter, like Leonardo DiCaprio. Oh, sorry. Leonardo da Vinci. Did I say DiCaprio? Da Vinci.

AUDIENCE: Maybe he did paint the Mona Lisa.

BALAJI GANESAN: Right. Yeah. Maybe. So we have AI models that are really good fake painters today. So now you really painted the Mona Lisa. So who else do you need to tell you whether this looks like the real Mona Lisa? You need an art critic, or an art expert. And now you have models that are the best art critics. So you have them talk to each other. And what are you going to produce?

You're going to produce a damn really close replica of the Mona Lisa. And that is what is happening in terms of the threats that we are seeing today. So you saw this. Maybe you guys read this example of a video call that happened in Hong Kong where the teams were chatting with the CEO of a company, video through video chat, like a Teams meeting. They thought they were chatting with the CEO of the company, but they were just chatting with a deepfake. And the CEO asked them, hey, transfer this $25 million to this account. I want you guys to do it right now. It's super urgent, blah, blah, blah. And the people did it. And it was deepfake.

And there are so many examples, all these spam emails that we are seeing. AI and human in the loop spam emails have a 55% clickthrough rate. And that's a big number. And the human in the loop is really acting as the critic in this case. And the more-- I'm sure there'll be another AI that's going to replace-- a model that's going to replace that human in the loop as well. But the rate of spam clickthrough is just unbelievable. That is the real threat that we are facing because of AI.

So what is the role of cybersecurity professionals here? How do we protect against the use of AI by threat actors who are using AI for these threat vectors, but also cybersecurity professionals enhancing our cybersecurity posture by using AI, and then talking about how do you secure this AI. So these are the three pillars that we are focusing at Eaton. I think I have like one or two more slides, and I think I'm running out of time here.

I'll be very quick. We're focusing on the user awareness. A lot of user campaigns going on today, in terms of how to use genAI more safely. Don't put your confidential IP-related information in Copilot, or GPT, or whatever. Don't do that. Don't download AI models and so on and so forth. We have created a ringed fence approach to endpoint security so that we can do some behavior analysis where we are blocking, I don't know, hundreds of thousands of malicious sites and so on and so forth every month.

Threat behavior detection is something that our teams are focusing on. We are using agents in red teams to predict what is going to happen. So that's another activity that we are pursuing. And then we have multiple layers of email protection for phishing, and spear phishing, and so on and so forth. So some examples here on AI systems, how we are using threat report summarization so that we can quickly get to what is a real threat for the company, as well as-- I mentioned about using AI agents to simulate adversary behavior and threat behaviors, and so on and so forth. So I think I'm out of time here. But if I can spare a few minutes, I'm open for--

MODERATOR: You have five minutes.

BALAJI GANESAN: I have five more minutes? OK. Just open it up for Q&A. I don't have any more slides here, I think. Yep. Thank you.

AUDIENCE: I have a question.

BALAJI GANESAN: Yeah.

AUDIENCE: What do you think about an innovative technology as far as using blockchain nonfungible tokens for artwork and music to legitimize it, even like a Browns ticket in the future? If you don't have the NFT on the blockchain, it can't be duplicated. This is really a ticket to the game.

BALAJI GANESAN: See, I've not spent too much time on researching how we can validate some of these, I want to say "artifacts" or images, whether they're real or something like that. Although I did spend some time with some folks at Google who are coming up with technologies such as if it is AI generated, it has to be watermarked. Or there are other models that are currently being released, or either available. I'm not sure where they are. Some of them were in the beta phase where you can use-- let's say you got-- I don't know. I'm going to use the Lions tickets, and you don't know whether it's real or not. You can use those AI models to validate whether that is coming from a trusted source.

Again, AI coming to the rescue here, but also responsible from the companies that are helping to create those images, saying that if I'm going to create an image of a Mona Lisa using my software, it's going to be watermarked. But again, It has to be the right balance. I'll give you a simple example.

Just for the sake of it, I was googling last week, give me-- I was writing in the Google search window, give me an image of a person holding an automatic rifle sitting in the company. It gave me many images. I could see people holding automatic rifles and all that. Then I went to Copilot. And I said, give me an image of a person-- same prompt in Copilot. And Copilot said, I'm not going to do that.

So there was a big disconnect for me, saying that, OK, are we becoming more worse? Are the models trained in such a way that it's not giving me basic information that a search window is giving me? So that is where the-- there's a fine line on how we do the governance on what these models are supposed to do versus what we are available to consumers using regular platforms. So that's where the dilemma is. But I think how we solve that is where responsible AI comes in. Responsible AI is just not blocking stuff, but also making sure people get access to the right information. So I think that's still--

AUDIENCE: I just think that blockchain is going to help solve some of these problems.

BALAJI GANESAN: Perhaps, yeah. Yeah.

MICHAEL JANOSKO: Good morning, everyone. And I want to say, first of all, thank you, Eaton, for hosting this conference, inviting us here, giving us the opportunity to speak.

My name is Mike Janosko. I've spent my whole career in security. The first half of my career, I was a hacker. Second half, I've been a defender, so I kind of bridge both those perspectives. Matt?

MATT LEMAY: My name is Matt Lemay. Well, I manage the Global Autodesk and Eaton relationship. We actually just announced a partnership last month.

Key to what we really want to talk about with our common customers, with the ecosystem is how we manage all of the rich information that's created across project lifecycles, which we can think about more of the IT phase, into that convergence on more of the OT phase.

So for the presentation today, Mike will share from his rich experience some of the risks, some of the challenges from the OT side. Then I'll share a little bit from the Autodesk side as we think about project lifecycles, how we see these things merging from the upfront IT into the OT. And then Mike will finish with speaking a little bit more about how we secure and think about secure information across lifecycles.

MICHAEL JANOSKO: Cool. Do we have a clicker? Cool. I'll just steal that from you.

So I missed the karaoke last night, so I'm happy to see that there's some instruments up here. The last half is all musical performance, so look forward to that.

So we titled this, "Trusted Data Across Building Project Lifecycles." But what does project management and project lifecycles have to do with data security? So that's what we're going to hopefully answer for you.

We'll start with, as Matt talked about, the need to know, like what does security need to know to harden some of these environments, and then get into how that turns into the project lifecycle and our software, and then how do we protect that layer as well? Because security is all about layers, right? You need to have these layers of both the problem and the solution.

So this was a build. So unfortunately, you get all of my individual breaches that I want to talk about in one slide. I'll start with at the top, though. I wanted to highlight breaches because from an attacker and defender standpoint, it's important to know what's happening, what attackers are targeting, how they're targeting those environments, and the TTPs-- the Tactics, Techniques, and Procedures-- that they use to compromise these environments. That allows you to set up an effective strategy to defend.

So starting in 2018, which is actually a typo, if everyone-- NotPetya actually happened in 2017, so just aware of that. It actually-- this incident started six years earlier in 2011. In 2011, the NSA discovered a flaw in the way that Windows machines talked to each other via a protocol called SMBv1. This flaw, through a zero day, an unknown vulnerability to the industry and to Microsoft, allowed an attacker to send malicious code to another Windows machine and run code, take over that machine.

This was something that NSA found extremely useful in 2011, didn't tell anyone about, held on to it for, I'm sure, just benevolent reasons. A few years later, in what was known as the-- so this became known as the EternalBlue exploit. A few years later, the NSA was hacked, an attack propagated by a group called Shadow Brokers. The Shadow Broker attack actually exposed this vulnerability to the world.

Microsoft scrambled, patched it, and obviously, everyone knows the patch cycles take a while to propagate. So it took a little while for this to make its way into different companies' infrastructure.

What was also happening in the world during that time, in 2015, the Russia-Ukrainian conflict was escalating into the digital space. There was a lot of targeting of Ukrainian IT infrastructure, the systems and the companies that made Ukraine money and helped that country run. And they and the Russian cybersecurity group, their adversarial group, discovered this EternalBlue compromise code was extremely useful. So they packaged that with another tool called Mimikatz, which looks at secrets that are housed in memory on Windows machines as well.

And they made a worm. This worm was targeted at Ukrainian systems initially but was actually so effective that it spread to non-Ukranian environments and companies as well.

So how did it get into Maersk? So Maersk is a global shipping company. And one of the ways that Russian adversaries looked to compromise other companies was by embedding this in software that other companies used. There's a tax preparation software that's mandated by the Ukrainian government called Amdocs. And through a supply chain attack, a compromise of Amdocs' software publisher, they embedded the NotPetya worm inside of that software.

In 2017, someone in Maersk needed to start the filing process of that year's tax returns and had the IT department install Amdocs on a Maersk system. Within minutes, this red screen started showing up on systems throughout the Maersk IT environment.

This looks like a ransomware screen. It says that you need to contact a site in order to get your machine unlocked, but it's purely destructive code. There's no way to recover the systems that this infected.

The impact of this was that all operations, all shipping operations for global shipping conglomerate ports, physical cranes, shipping yards, and the gates that controlled access to them, were all crippled over the next two weeks while Maersk rebuilt.

Funny story about how they rebuilt-- they pulled everyone to their headquarters in Ireland. People were working overnight. They had a good plan on how to rebuild the network, rebuild a lot of the IT systems that were compromised. But one of the keys to this rebuild was their Active Directory environment. And all of their Active Directory servers were compromised by NotPetya and unrecoverable.

And they went to all of their sites, they looked at all their domain controllers, their backup domain controllers, and finally, they found one site in Ghana that was offline during the attack because of a power outage locally that still had a pre-infection version of their Active Directory. So they had to get that hard drive from Ghana, which basically was the key to rebuilding their entire shipping operation. They had to get that from Ghana to the UK, where they were restoring, and that became the key to rebuild their Active Directory environment.

So I know one of the themes that we talked about yesterday and is common across these is blending this overlap between IT environments and OT environments. So the next one I'll talk about is Colonial Pipeline ransomware attack. So show of hands, who's heard of the Colonial Pipeline attack? Many-- many of you have.

Is everyone aware that it's not well believed that any OT systems were compromised as part of that ransomware attack? The target of the ransomware attack was their finance systems. They compromised-- so the ransomware adversaries compromised their finance systems.

And out of one of three possible conclusions, either abundance of caution, an abundance of uncertainty, or a lack of ability to attribute billing and usage to their customers, Colonial Pipeline shut down their entire pipeline operations in the Southeast. So this overlap, this dependency on, back office IT systems-- billing, in this case-- and actual physical systems like pipeline control valves, flow control, monitoring, et cetera, very real dependency.

Funny story about this is, they paid the ransom. It was 75 bitcoin, which in 2021 dollars was $4.4 million. They got the decryption tool. So there is honor among thieves. The ransomware actors provided a way to recover the data. That recovery tool was so slow and so ineffective that they had enough time to look around and find the backups that they had to restore from anyways. So they could have just restored from backups.

The government was able to recover about 80% of the bitcoin tokens. There's not really clear attribution of how they did that. But at that time, due to fluctuations in the Bitcoin value, it was only worth about half as much as they had originally paid.

The last example I'll talk about is Norway's Lake Risevatnet Dam. So in this instance, an internet-accessible HMI device, Human Management Interface, into dam flow control was internet facing. This internet-facing device included a easily guessable password, username and password, and in I think it was February or March of this year, the dam's flow control was opened wide, and millions of-- or, sorry, hundreds of liters of water per second leaked out. This was attributed by the Norwegian government to Russian state actors as well and is a real-world kind of escalation of how control systems, industrial control systems, physical systems, are being targeted by adversaries, especially in this kind of conflict-laden European situation now.

So we have an infected IT system through Amdocs software, a supply chain incident. We have in the case of Colonial Pipeline issue, we have a username and password to an old VPN account, which allowed actors to run code inside of the Colonial finance system environment. And we have an internet-facing management device.

So why did these things show up? And I'm sure that-- these aren't revolutionary kind of ideas here. When building out OT and DC systems, there is a lot of customization. There's a lot of original equipment manufacturer deployment requirements, templates, subcontractors that are implementing all of these systems in the way that their company has confirmed and validated that they work.

So from an IT system standpoint, this presents some very high levels of complexity of understanding how this is deployed and how best to secure it. You don't really have a centralized control plane, oftentimes. Can these systems be hooked up into your Active Directory environment? Can you even manage them via Intune? Are the operating systems going to be able to be joined to your domain?

If you have third-party policy management, do those agents run? Can you even put agents on these systems? So things that you look for in terms of understanding where systems are and how they're configured typically are hard to implement in these deployments.

There's legacy protocols and devices. Oftentimes, these systems are implemented via custom protocol. They have low compute resources on device. They're very efficient.

But at the same time, they don't speak or comply with normal IT expectations. So there's a lot of customization at the network level.

Because of that, oftentimes, networks are configured to just work, so they're flat. There's a lot of network-based trust. If you're familiar with the zero trust model, it basically moves all of the authorization of connections to application services, user identity. That's all very hard to do when you're dealing with all these different bespoke systems.

Because these technologies are so custom and vendor specific, vendors have to administer them. They have to support them. There's an ongoing need to access and oftentimes remotely manage them. And at the end of the day, how does your IT team and your security team even know what's deployed and how it's deployed? So you can see the hooks into project management, right?

So the result of the other main component here, though-- category of issues here-- is that in the deployment of this, there is a huge real and important safety and availability concern. These are physical devices. Sometimes they have moving componentry, multi tons. They can literally kill people if their people are in the wrong place at the wrong time.

They're controlling power distribution. They're controlling your cooling systems, large volumes of liquid and fuel. So if they go wrong, there's a bad human health safety outcome there. So you have to prioritize the identity and how access, you have to weigh that, those typical controls that you see in traditional IT security models, you have to weigh those against the availability and the safety needs.

And patch management, change management, is a real issue. One of these systems goes down, it acts badly around a patch, that can really disrupt a physical space as well as the IT space.

So from these, you have high levels of system complexity, because it's unique. There's some protocols and configurations that are unfamiliar to the generalists. You have poor asset inventory as maybe each site is following its own site-specific deployment categories. New requirements are added as physical limitations or constraints are discovered.

There's ownership. Who owns securing this stack? Who owns the integration that happens between two systems by two different vendors? There's all this ambiguity around ownership, and thus who applies security controls to those systems.

And a defender the past 15 years, I see just scaling problems, like how do I manage my time and my team's time in all of this complexity that requires really strong, really deep dives into understanding them?

So I have a wish list. And I think that these will hopefully all make a lot of sense. Please MFA-- so multifactor authentication for all administrative and privileged access at least.

Please tie this to hardware tokens. The value of it being a hardware-based MFA versus software-based is really about phishability. How portable is that key that is generated from that token? It's a lot easier to phish a software security string of numbers that's generated by an on-device authenticator app versus an actual cryptographic token, which has cryptographic primitives protecting the secret that's on it. So please MFA.

Network zones minimally scoped requires real, deep understanding of what protocols, what network traffic enables a lot of the data center and OT system connectivity. So what is the minimum level of connectivity that you need there, and how do you scope those zones into a reasonably small and principled least-privilege container?

And then inventory and schematics, how would you tell someone that's not-- if you're responsible for the build of a component in a data center or an OT environment, and you have to work with a security engineer like myself to figure out how to secure it-- we need all the information that we can have around how this works. How is this integrated together, how is it designed, what are its capabilities, requirements, et cetera?

So aside from inventory schematics, bill of materials, what's in there, both from a hardware standpoint, but also from a software standpoint? If we can get into components libraries, that's even better as we start talking about open-source supply chain attacks and vulnerabilities in open-source components that are included in software.

And then telemetry, at the very least, at the minimum, how do we know what's there? Can we get some reporting out? Do we know what's normal versus abnormal?

One thing these environments often have, which is a benefit, is there because of that purpose-built attribute. The network traffic is fairly-- and I'm going to say this with a big caveat-- is fairly consistent, so you can profile what normal looks like. And therefore abnormal, whether it's a volume signal or it's a type of protocol or it's a security alert, an authentication event, those things should be fairly easy to pick out of the haystack.

So one thing as a security engineer that I like to see is some in the build schematics, a structured approach, a high-quality organized deployment model. So I'm going to hand it over to Matt to talk a little bit about-- oops, I went back, sorry-- about some project management software.

MATT LEMAY: Thank you. So I guess prior to jumping into this really quickly from a show of hands, is anyone familiar with Autodesk and what we do? I know a few people who have already told, but thank you, everyone.

So really quickly, I think Mike made a really interesting point there on the OT side. So Autodesk, a lot of the other CAD and engineering companies, if we think about a project lifecycle-- and when I say "project," this is architecture, engineering, construction. This could be hyperscale. This could be hospitals, manufacturing facilities. It's really focused on the left here historically.

So this is where it's been for many, many years. This is your drawings. This is your models for your facility, your equipment assets. One of the things that we're trying to do to address some of the challenges that Mike shared from the OT side is what we've seen across the industry is that there's really rich information that's created up front in these projects. This has equipment model information. This has scheduling information. This has maintenance information.

Typically, what we see as projects get handed over from architecture through to engineering through to the construction phase is, a lot of that rich information is lost, which could be used later, as Mike mentioned, to help secure some of the operational environments.

So where we've moved is focusing on the construction side of things as well, so extending a lot of that engineering and that architectural information into a common platform where all of that information can be managed from all of the ecosystem and all of the important members internally. And then as we mentioned up front, we do see this world of IT converging with OT. And here's really where that happens.

So we talked about up front with architecture, up front with engineering. That's merging into the construction space. As we think about handover to the owner, we're taking all of that information again-- the equipment assets, the scheduling, all of that-- feeding it into a platform where the owner can visualize all of these assets, they can stream IoT information, they can identify and track for things like asset management and preventative maintenance, even.

So this is where from yesterday into today, we've heard a lot about some of the requirements of OT. And what we're trying to share here as well is from all the information that gets created in what we would think about the IT phases can actually feed into that to help secure the OT side.

So for the sake of time, I'm just going to skip through a couple of these others here really quickly and then really focus on a tangible example, when we think about project management and then security. So as we think about hyperscale projects in general, I think this has been shared significantly over the last 24 hours. The scope, the timelines, the money of these projects is like something a lot of the industry has never seen before. So that criticality of having the asset information, of having the maintenance schedules, of having those kind of rich factors available from the operational side really becomes even more important.

So the way that we think about that-- so I mentioned this idea of a common construction platform or a common project management structure. The way that we've worked with hyperscale and colos and many others in this space is to think about standardized project templates.

So any capital project that's happening across the company-- it could be as small as an equipment change, it could be a retrofit, it could be a brand new greenfield project have a standardized way to track all the information, to have it all in one place so you have all of that asset information as a handover to the operations side. So when you do that handover, when it gets handed off into the OT phase, the idea here is to protect against what Mike said is a risk, which is not knowing what's in your project and actually having all those details.

So with that, I'm going to hand it off to Mike again to talk a little bit about the security structure for those platforms.

MICHAEL JANOSKO: So I'm always wary when the solution to a security problem is to put more layers of complexity and things into an environment. It is another thing to manage. So what should you be asking for from your additional layers of management and additional layers of software, of infrastructure that you're introducing into an already fraught environment?

So what I'm going to use as a model for that is how we do it at Autodesk. I'm not saying that you need to use Autodesk for this and our products. But I think that we have a model here that's effective, that's focused on protecting data, and provides some transparency to users, which I think is key.

So one of the things that we identified early is that we have these three pillars inside of the trust organization, which is what I'm a part of. And within the trust organization, we have to make sure that we have-- customers know that we enable trust by design. So we shift left in terms of our product security, in terms of our data security story.

We're really looking at prioritizing. We have an internal prioritization framework to reduce risk to customer-impacting threat vectors. So data loss, compromise of an environment through an exploit in our software-- these are priority zero issues for us. And then also, be empathetic as we're putting out this model, and we're working with customers to help them understand it.

I'll skip through this. So build secure-- this is much in the shift-left idea that we have security, both automation, default secure options, and then good training and understanding on how to utilize those in all of our developers and the product ecosystem.

When we run these tools-- because Autodesk is as well as a client application provider, we're also a SaaS service. So we run some of these services, and we house this data in our own cloud and our own managed environments. So how do we do that securely? Hardened images, the right identity and access controls-- how do we identify our crown jewels, which is the data that we protect at all costs with priority zero and ensure that that is protected continuously? And we do that through this observability, staying secure through monitoring detection and a real heightened awareness of where those threats are should they show up in our environment.

Because no talk-- I'm obligated by being in technology to talk about AI anytime I speak to anyone, anywhere. This has creeped into Autodesk. In a not tongue-in-cheek way, we believe that AI is a great enabler for our customers and for our products.

But how do we do that securely? We thought long and hard about how to train models, how to give visibility, and how this data is being used to advance AI capabilities, and what type of AI capabilities are the right ones to implement in our products. So we hold ourselves to high standards through the responsibility to do the right thing with our AI services. And we're transparent about what we're doing, how we're using our customers' data, and when we do it, and we're accountable for holding to those ways and our declared usage.

We also want to make sure that our services are reliable and available when our customers need them and not go too far out on the AI limb to implement something that's cutting-edge, but not as reliable for our customers. And making sure that through the AI lifecycle, we have a key eye on what data types we're handling, and we're doing the right things, both in terms of our values in terms of regulation and compliance and privacy.

This translates into a pretty cool, accessible transparency card. Looks like the nutrition labels that you may gloss over at the grocery store or ignore. Your choice is totally your own. That is a way for us to provide this common, structured insight into our AI services and how we embed them in our products. So I think this has been a big hit, and we've gotten some great feedback on this.

There are emerging standards and ways to comply with industry regulation around-- and certification around AI and AI in products. So one of these is ISO 42001, something that Autodesk just was certified around. But I would look for in whatever vendor you're interfacing with, if they are using AI, to have some sort of eye towards standards like this.

And finally, to be transparent, we have this Autodesk Trust Center. So again, looking at your vendor population, looking at how you secure those third-party products that you're deploying in secure and potentially sensitive ways. How are they communicating back to you in terms of security incidents, security patches, and best practices?

ROHAN SINGLA: Thank you. It's been an engaging two days. I think the last presentation has woken all of us up, right, with all the NotPetya and other ransomwares. Growing up, I would hear a lot about airplanes being hijacked and governments being held ransom. You've obviously heard about Panama IC814, and other things. In today's world, we hear about companies being hijacked not by someone with a gun, but by a ransomware, which involves organizations and different countries.

So, yeah. Rohan Singla, CISO and head of IT at ChargePoint. I'm here to talk about securing the EV charging infrastructure. How is security moving forward in the entire EV ecosystem? As part of it, I'll talk about a few myths we have around EV charging space. What are some of the risks, the threats we see, and how do we protect the infrastructure from them?

Before I do that, my sales and marketing team wouldn't let me move forward if I don't talk about ChargePoint. So we were founded in 2007. A big thing is we are a B2B company. At least an impression I had before I started researching ChargePoint was I always thought it was a B2C. We obviously serve our drivers on behalf of the organizations, but most of our customers are Fortune 50, Fortune 100. Anyone with a piece of land can-- we sell or we lease charging stations. We have a lot of PII. We have a lot of data on our systems. We have more than 5.5 million downloads of our mobile app and a lot of charging sessions, which you can see over here.

Moving on, let's talk about the myths. The first one I hear a lot is charging stations and the EVSE space is all about hardware. We don't see any software element to it. You just go there, plug a car, and the charging starts over there. But in reality, there is more cloud, there's more data, right? The ecosystem is powered on the cloud environment. You have so many APIs. We have different players talking to each other. As a company, ChargePoint talks to other EVSE players.

We talk to so many OEMs. We integrate with all the leading car makers with their apps, and all that is done with the backend cloud environment or the data centers. So all the data is stored over there. How do you secure it? How do you protect it? So this is a very big myth I feel in the industry, at least on the Bay area side. I feel the audience over here is more educated.

The next one following the first one is what kind of cybersecurity do we have? You only have to protect the hardware. It's more physical safety and physical security rather than cybersecurity. But if you ask me, I see security risks all across the entire ecosystem. You have security issues on the cloud, on the station, and then finally towards the grid as well. These are some examples around the recent attacks and hacks which have happened. The first one was around a CPU. The CPUs were attacked and there was 116,000-- at least that's the public information we have. The PII data was breached and leaked publicly.

The next one is around the Russia-Ukraine war. So Russia has a lot of chargers. Interestingly, they have a supply chain issue where some of the parts are being supplied by Ukrainian companies. And after the war, what ended up happening is the Ukrainian company introduced a backdoor into the station and started displaying messages all across the EV Chargers in Russia. So that was a big one when the war started. And then finally around OCPP on the APIs and how the APIs are being attacked because OCPP is a standard. I'll talk more about it later on, but that's the standard which helps the chargers and different players communicate to each other. Before OCPP, it was a bit difficult on how-- what is the standard and what is the framework on how organizations communicate with each other?

Moving on, the third one. We talk about the grid. So with V2G and vehicle-to-everything right now, there are a lot of cyber implications which are not known and which we do not understand about. The thing everyone keeps talking about is you're only supplying power back to the grid. I don't know how many of you have seen Die Hard. If you have seen a Die Hard 4 or 2, it has a scene where we talk about the gas being supplied back to the grid.

Think about it in that angle. You can manipulate the amount of energy that can go back to the grid. And what aspect or what issues can it have? So how do you manage the energy and power being sent back to the grid? There was a research done on this. Some of the researchers from New York University, what they ended up doing was they got access to the Manhattan EV Chargers, and they manipulated it to send power back to the grid in Manhattan, obviously. So the grid had triggers which were invoked, and then the entire area had a blackout. The grid which it was on was blacked out for a few minutes.

Now obviously, there are ways to protect it. Now with V2G, the vehicle to grid, you can actually use power from the grid to control the load. So you can start supplying more power to the grid to manage the spike. Obviously, that vehicle-to-grid can be manipulated to send more power to the grid as well and cause the false trigger. So moving on, the fourth one and the last one. This is more on compliance, which we touched upon in the last two days. What kind of compliance? This is purely hardware OT. If you go to the west, I don't think they understand OT and compliance has a big role. For them, it's all about SaaS and technology.

If you ask me, we have so many stringent compliance to look at. When I first joined, we had to look at [INAUDIBLE] for secure boot. Then we had the UK secure boot law. We're talking about GDPR, CCPA, PCI, ISO. The list goes on, right? And then FedRAMP. Now with us selling to all the government agencies, the three-letter agencies, we need FedRAMP certification, and their data needs to be masked.

If you think about charging stations, the thing is, as a driver, I have a set pattern. I am charging on specific stations at a certain time, be it at my house, or be it on the road or at work. If someone wants, they can easily understand your pattern, especially from an army perspective, from a federal perspective. That becomes a big risk. Someone can easily track your generals, your higher ups, which is where we have to be conscious about how we mask that data and that data is never published.

In those cases, actually, we do not store data on where the charger is and the charger location is. So yes, which is where compliance over here plays a big role, especially now with AI coming into play, the EU AI Act, and ISO 42001 and so on. So these are some of the myths right. Moving on, I'll-- this slide talks about the ecosystem. How is the EV charging ecosystem set up? It is not as easy as it looks. What are the different boxes which connect to each other?

On the middle of the screen, what you see is the different services we have. What services does a company provide, be it access control, the tariffs, the pricing. Every administrator can control the pricing policy on different stations based on what time you charge. OTAs. OTA is a big thing because we have to apply security updates, new features, and all that is controlled from the cloud where we push OTAs on a regular basis, which is another vector for an attack and introduces a risk for us.

And I'll talk about how we protect against it later on. So on the middle of it, there's waitlists, there are tariffs, there are other features over here. On your left-hand side, you see different integrations with the EV player or the EVSE over here. Payments is a key thing, which is a big area of fraud for us where we control it and we manage it, how do payments happen, be it through the app or at the station level. Then you're talking about different systems being integrated internally from a sales perspective, from a payments-- from invoicing. So all those systems are being integrated. And then finally, your CX and your customer systems, because obviously, we have issues. And how is the customer being serviced from there?

And on the right-hand side, you obviously see what are the different modes of EV charging, residential, commercial, fleet is another big one. We see more and more organizations moving their fleet to EV, especially with the US Postal Service. I'm sure some of you have read about it. They are looking at-- they've started changing their entire fleet to an electric fleet. And that started a couple of years back. Imagine the entire USPS is on EV, and all the chargers are not available. There's no mail. There's no delivery for us, which is where security becomes paramount to it.

On the bottom, you see ChargePoint hardware and other hardware. So ChargePoint, as an organization, we support all types of chargers on our cloud system. And our chargers can be supported on all other cloud systems as well, which is where we call it OnRamp. So we can onramp other hardware or other cloud providers. And then on the top, you see different applications which connect to this ecosystem.

Moving on, let's talk about some of the threats. I've touched upon it at a high level. But the first one being from the station to the EV, how you have "man in the middle" attacks. You have spoofing over here. We've seen a lot of EVs being hacked. And then how can the EV be used to get back to the station and to control the station from there?

Authentication. Before ISO 15118 and then OCPP, there was not a lot of encryption being used from a communication perspective, which is where authentication came into play. And that's how-- that was a big vector of attack for us. Back to the grid, we spoke about it from the station to the grid, how load can be balanced, or how load can be manipulated. That's a big threat and a risk. The

Next one is cloud. We see a lot of attacks from a cloud perspective, DDoS, SQL injection, and so on, which keeps going on and on. API abuse is a big one, because we have a lot of APIs with our third parties, with our partners. How do you protect against these APIs? Because I do not have control on my third parties and on my partner. So we have to implement ways on what data is being shared with these APIs, what control do they have to the ecosystem as well from there.

Yeah. And then integrations. The problem we've seen is obviously, engineers are very-- how do I put it? Very enthusiastic. And they wouldn't follow a process. They know the product team and the engineering team, they know about an integration, or third-party app, or an AI application coming up. They'll go ahead and integrate these applications with our main application without going through a proper governance process. How do you control that? That introduces a new vector of challenge, a risk for us as an organization.

So those are a lot of threats and risks which we've been dealing with, which we've been looking at. I'll talk a bit about data manipulation when I get to AI. But yes, another vector of risk. So vectors. The first one is physical tampering. Physical tampering. This is more related to all stations that are out there in the wild in public. And we cannot control these stations because I personally do not own the physical security as a company.

That's owned by my business partner, by the business organization who owns the station. Some forms of attack we've seen is, obviously, the QR tampering, where a QR code can be used, or a fraudster can put up a QR code instead of a ChargePoint or a business QR code. Then the skimming attacks from a credit card perspective. There are different types of skimming devices. This is well known. We've seen this on ATMs and other point of sales.

Companies, or fraudsters, hackers can open up the station, they can connect to the control boards. Most of these control boards have default credentials, admin password, if you if you do not pay attention to it. From a ChargePoint perspective, we have sensors on most of our stations. So any physical tampering on the stations is closely being monitored. We get signals and alerts on our cloud environment. We also have a network operating system team. So from an operational perspective, if the charger has any issues, those are being recorded back on the cloud environment. And then secure boot, obviously. Any physical tampering on the station boots the station into a secure boot mode, which is where it becomes difficult for anyone to do any tampering from there.

Actually, before I move on, from a physical security perspective, there's a big issue we've seen or noticed across the industry over the last few months is around cables being cut. Not sure if most of you have heard about it. A lot of cables are being cut across all chargers. Our HQ is in Campbell in San Francisco. At our particular site, we've experienced it twice where all the cables were being cut. So what we ended up doing was we used OCPP protocols and other security features we have where, if any station is being tampered with from a physical wire perspective, if it's being cut, an alarm goes off on all the stations in that particular network, and the stations start blinking red with the signal being sent to the network admin. And obviously, the sound as well on these stations. So the stations start sounding an alarm.

Additionally, all the next-gen chargers, which we are producing from now on, have a specific material in the cables where it becomes difficult for anyone to cut it. It's not impossible. Obviously, if you have a seesaw with a motored machine, you can get through it. It will take you time, but you will get through it, and it is noisy. So you will come to know about it. But that's, again, a big physical security risk which we've noticed in the industry.

The next one is "man in the middle" attacks. This is more between the EV and the charger which I was talking about. How do you spoof a signal from the EV back to the charger, or from the charger to the EV? Both sides, right? And any point of entry can create a risk or a whole gap for the entire ecosystem. How do you manage that? How do you control it? Especially with the physical security, which we spoke about. It is easy to get to a charger, and then you can try to control the EV from there.

The next one is more around cloud. So we spoke about APIs. We spoke about DDoS. DDoS is something which we keep seeing again and again on a daily basis. I'm sure most organizations over here face that. How do we protect an app or a feature before it is being released? Every new feature is introducing a new risk from a cloud perspective, from an application perspective. It has to go through proper checks and balances from a security by design, by defense in depth, and all those things. So all our chargers are not available on the public.

So you can only access the charges from our particular cloud environment or data center environment, whatever you want to call it. It has a VPN connection. So if I try to connect it from this particular Wi-Fi network to a charger, I cannot. I have to go through my data center through a VPN to service it, which is where we're trying to protect it from the public. The charger is not-- it's not easy to get to a charger, from a public internet perspective, but you can get to the cloud, obviously. And from there, you get to the chargers.

And finally, we talk about the grid. We spoke about load manipulation from a V2G perspective. The V2G, as I said, can act in two ways. It can act as a boon, or it can act as a risk where you use it to actually manipulate the load and change how much energy is being sent, or when you need it, you send more energy to control the load as well, which is where we need more players to help us securely manage the power being sent. As a charger, the charger cannot-- it's not a circuit or a power board where it can control from an electrical perspective. We need electrical companies to come in and help the entire EV ecosystem to securely manage it.

So these are some of the attack vectors which we see in the ecosystem. Next up, I'm going to talk about role of AI in our space. By the way, all these images you saw in the last four slides and this image are AI generated. We've spoken about AI a bit this morning with Balaji. I'm going to touch upon it over here. In ChargePoint, we see AI in three different verticals. One is increasing productivity internally from an enterprise AI perspective.

So we use, obviously your GitHub, Copilot, your Gemini from an IT perspective, and we use different tools to automate the different workflows and help us from a support desk perspective. As of today, we do not have a help desk team servicing any access management requests. All of them are being automated. They are based on-- AI makes decisions based on the team you are in, based on the role you have. Obviously, we did some fine tuning defining it, but after that, it is all automated from there on.

From an internal sales systems and customer systems, we look at those systems and how can we automate some of the use cases, how can AI help us over there. So that's internal productivity. The next section is more around our application. How can I help our ChargePoint cloud software for our customers? So we are working on different features.

We spoke about chatbots this morning, where Balaji was giving us an example about Chevrolet and Ford. Some of you might have heard about the Salesforce Drift issue which happened a few days back, where Drift is a chatbot used by a lot of companies on the website. It was acquired by Salesloft and it integrates with Salesforce. Drift was hacked and Drift was breached, resulting in all the Salesforce data for their customers being exposed externally as well, which is where-- we are building our own chatbot using Gemini.

That is going to come out pretty soon on the mobile app and also on our website, which will enable our drivers to get answers quickly without being on the phone for hours on someone from customer support. So the initial root cause analysis will all be done using this chatbot, which will connect to AI on the back end. Additionally, as a network admin, we are adding natural language. From a reporting perspective, we see that more and more in all the tools we use today where natural language is being used to query the tool and get reports in real time. So those features are being worked on.

And then finally, from a customer experience perspective, where I spoke about us being on the phone with customer support, what we want to get to is remote diagnostics from a root cause analysis, all this being automated and helping our drivers solving the issues, or even the station owners, rather than calling us. How can that be reduced from a level one help desk perspective, rather than someone trying to query it? Can this be automated? Can we get to the root cause quickly? And then if someone needs to go on the field and replace a part, that is where we get into the mix.

So obviously, AI is a two-edged sword. There are a lot of new risks and threats which AI introduces from data poisoning injection perspective, which is where we have an AI governance committee internally. So any new use of AI goes through this governance team where we review the use cases, what models are being used. DeepSeek and a few others are not allowed. And this is what we support. These are the open source. It has to go through a security check and a privacy check as well. What data is being shared from a ChargePoint perspective?

The other thing is the hallucination and bias. Again, I think we this was touched upon where is our data being used to give a competitive advantage to our competitors, because a lot of our competitors might end up using the same AI tools, or SaaS third-party tools. How is our data protected and not being used over there? And a lot of third party SaaS applications we use have inbuilt AI, like Agentforce from Salesforce and other applications. So how do they connect? How do they manage the ecosystem?

The other part on AI being hackers are using more and more AI to get into the environment. Deepfake. Deepfake videos, we know about it. Deepfake videos have been used to start an attack, more so from a phishing perspective, where your finance team gets a message from a CFO or a CEO. This is becoming more and more involved. And all the phishing exercises, even from a security awareness, are moving towards deepfake videos and talking about how deepfake can be used.

And then how do you inject more data or manipulate data from your customer perspective driver perspective. You create fake accounts. What data are they sending, be it using bots. And I think that whole process is becoming more complicated. We have different tools to protect against bots. But now with agentic AI coming into play, they are acting more like humans, and they are able to bypass the controls you have. So how do you control against-- how do you protect against it?

So finally, protecting the EV charging ecosystem. The first one is more around the charger and the vehicle. This goes with the threats I spoke about earlier. So ISO 15118. This is a standard, which was built by SAE We've played a key role in bringing all the players together as part of SAE and starting this forum. It's called the SAE EVPKI, which allows all the EVSE players to communicate with each other, not only the operators, but also the OEMs. So we have different partners over here. They've all volunteered, and we are defining a standard as part of it, which is based on ISO 15118-20. OCPP is, again, being used to protect-- we spoke about secure boot, which is another key aspect of protecting communication between the station and the EV.

We've spoken about the grid, and how can we securely manage all the communication going back? How do we manage the load over there? The firmware integrity checks. This is another big issue. How do you manage the FIM aspect, because the circuits and the boards-- we have a big dependency on our third parties, fourth parties where we buy a small part of a chip. And how do we track they are being patched, they are being secured?

So as an organization, I have to maintain an SBOM and an HBOM, which we have to regularly share with our customers, with government agencies. There are a certain set of products, which, obviously, the US government wouldn't let us use. So how do you ensure these are being patched on a regular basis? They do not have default credentials like admin password. And are these being changed? So that has to go through a rigorous check from our side.

And then finally, on the cloud side. We spoke about secure by design. We spoke about zero-trust architecture. How do you have red teaming involved? The couple of big things which this slide does not talk about is the bug bounty program, and how do you bring the community together? There's so much you can do as an organization. And every product, every application, as much as you want to do, will still have feature issues, will still have vulnerabilities and risks. So how can you use-- I can get an annual pen test done by some organization, but that does not mean I do not have any issues.

So we partner with different forums and different communities, Pontoon being one of them, Hardwear.io, where we actively send our stations to be pen tested and to be broken apart. The message from us is tell us as many issues and vulnerabilities as you can. Because they bring the best ethical hackers and attackers from the world to a specific location and know best-- no other way to identify those issues. I would rather have them, as opposed to a hacker, finding those out.

So obviously, there are issues with that as well, because they do publish the report. I do get a lot of questions from my customers and partners. We've noticed this publication from you, where it talks about this issue. But obviously, we are quick on fixing that. So that's another good angle where it helps us protect the ecosystem. Then there are different ISACs, be it Auto ISAC, Energy ISAC, which helps us with all the chatter and threats which we see around EVs and the EV ecosystem. That's me. Thank you. Are there any questions, comments?

AUDIENCE: Yeah. I noticed there's some third-party battery power stations like EcoFlow and Anker SOLIX, et cetera that allow you to plug into an EV charging station to charge them up. Are you seeing any increased risk of threats coming from those types of devices, or has ChargePoint looked into that?

ROHAN SINGLA: Yeah, no. We have. So they are more-- what they are doing is they are supplying power from the EV to the vehicle. And we control the entire communication on our side, where even if someone is trying to manipulate it-- it's like a "man in the middle" attack, if you think about it. Someone can spoof or someone can take over that particular device. The same controls which we use to protect against "man in the middle," that is being used over here as well. So for us, we communicate directly with the EV, and our keys are being exchanged with the vehicle rather than the device in the middle. It is just a mode. If you think about it, right now, NACS is becoming a standard for charging. So most EVs do not have a NACS control. So you use an adapter, even for a Tesla, to charge on a ChargePoint station. We have an adapter. It's only a mode for initiating a charge. But the communication is between the vehicle and the charger.

AUDIENCE: When you mentioned the third-party chargers, and all the cybersecurity protections that you have there that you showed in the prior slide, how do you handle that with the third party? Do you define the requirements for the chargers, both downstream in terms of secure boot and other things, as well as upstream to the cloud and the OCPP protocol? How do you handle that from your company, let's say, certifying that the charge is compliant to the requirements that you showed there?

ROHAN SINGLA: Yeah, no. Great question. So yes, we do have a certain set of standards, requirements from a third party, or different partners' perspectives where they have to comply to a certain standard to connect to our charger. There is OCPP over there, again, a specific standard of OCPP. We've seen different organizations implement OCPP in several different ways, and there's no one right way of implementing it. We are on OCPP 2.1. Some organizations are on 1.6 version, and 2.01 being the last-- the one before 2.1. So we have a certain specific standard how we want them to connect.

There's a patching policy. There's a vulnerability management standard, which everyone has to maintain, including us and our partners. And apart from that, when you go to upstream to, be it a cloud providers or be it the OEMs, we have to comply to a certain set of standards for our OEMs. When I integrate with my vehicles, or a partner over there, they send a specific standard which we have to comply to. So my third-party management program is based on that. And that is what is being shared with our partners downstream.

AUDIENCE: So you do tests, you pass the requirements for the third parties. And do you have in-house testing of the product that is-- let's say the supplier claims that it's compliant with your requirements. Do you do a validation on your side once you get that product?

ROHAN SINGLA: Yeah, no. We do. We do definitely. So we test each and every product that is being connected to our environment. It goes through a security test. As a matter of fact, we're doing it with Eaton right now. So obviously, all our products-- every product goes through a specific testing. We have labs across Europe and across North America, and then India as well. So the chargers are being tested over there.

AUDIENCE: OK. Thank you.

ROHAN SINGLA: Perfect. Thank you all.

AUDIENCE: Just one more question. Just a follow up to what Luis was asking you. So the entire ecosystem is based on so many regulations and standards that you have to comply with. So how do you guys keep the entire ecosystem to stay on top of all those requirements? Do you have different groups trying to comply-- to make sure you comply with all these different standards that you have to meet?

ROHAN SINGLA: Yeah. Again, a good question, because we have that issue. Europe has a different standards body [INAUDIBLE] over there. We have SAE in North America, which is where we are part of all these different organizations, different standards bodies. And we are trying to centralize and standardize the framework, even across different countries, different regions. How can we do that? And we have an auto team, automotive team, which meets every auto player out in the market which works with different EV players as well.

So we constantly communicate with them on what new standards are they using, or is there something on the roadmap? We have a standards and a regulation team, which is separate from security, and their job is to monitor all the different regulations in the industry coming up in the next five years. How is every organization taking that on? Because what we do not want is an EV player on a specific set of standard, which we do not comply to, and those vehicles cannot charge on our stations, which is where it becomes important for us to constantly talk to them and communicate with them.

WES MALABY: OT security in the age of AI-- that's a lot of buzzwordy stuff to piece together. So I'm going to make the same plea that the previous speakers did. That if we can make this interactive-- and I apologize to the cameraman because he's got to keep up with me going left and right. But as we go through this space, please, like, flag me down with the hand. It's really interesting to me what's on your mind as you see one of these topics.

One of the awesome things about Microsoft is the exposure that we have across every industry, every country in the world. My interaction with our clients and customer organizations is that you hear a lot of the same things, but you hear new, crazy, zany things as well that you can go explore on.

I lead a customer success team within Microsoft. And so I have solution architects that are spread around the world, and I call them the unstuckers because their goal is that one of our clients gets into a cybersecurity challenge. They call, and they say, I need your help.

And we're a relationship team. So we work with our account teams. We work with engineering. We work with marketing-- everyone to try to piece together a better solution for them.

Before I joined Microsoft in 2020, I was-- I'm sorry, I'm giving you a stat there. I was in the oil and gas business for about 20 years. And so former CISO and I try to make sure that I maintain that presence, that's where my OT experience comes from. And I really want to thank Eaton-- the keynote this morning listening to the AI use cases that are there. They're really a leader in the industry the way that they're thinking about it.

And so I will sprinkle anecdotes throughout this presentation just to try to get you all to be thinking about what's the positive use of AI. How do you secure AI? How do you start to tie these together?

But the reality is I'm highly distracted by musical instruments. So the event last night at the Rock Hall was amazing. I am a guitar nerd, so I was just talking to Matt. And I was like, I collect guitars. And then my wife kind of interjected, and she said, I think you might have an actual problem.

So I was like, OK, you got to think quick on your feet. Cybersecurity is good for that. So now I have traveling exhibits, and I loan guitars out to my friends and my family so that I can kind of-- it's like diffusion. So you can't quite keep track of the catalog and the inventory that way.

So I've sent her pictures last night. I was like, I don't have this guitar. What do you think? And she's like, yeah, that's really nice.

The deck that I'm going to use is from the Microsoft AI Tour. And I'm not a good clicker guy, so there must be a title slide. So there's going to be some statistics here that will anchor into the narrative. But like I said, I'm a storyteller. So my goal and objective is to kind of make this a little bit more real. This is a great place to start.

So out of this survey, four out of five leaders within organizations are looking at agentic AI as a mechanism to augment their workforce. So how many of you, by a show of hands, have heard that AI is going to replace all of our jobs? OK, yeah, that's less than I thought.

That's not what this stat is saying. What this stat is-- So I'm going to come back to a point about how hard it is to hire and retain cybersecurity professionals in a bit. This is a mechanism to where senior leaders are like, can I use this technology to augment my hiring challenge? Can I find an efficiency so that I don't have to go through that trouble of hiring and retaining on a constant cycle in this industry?

The second, this is a massive number. I should have put all the zeros just to make it real instead of the B. But you heard already how prevalent the use of agentic AI is.

And this is 1.3 billion agents in three years in the ecosystem. This is not every one of your companies using the same agents tens of thousands of times. And to count to that 1.3, this is 1.3 billion unique agents in the world. That's terrifying, because now you have to start to secure the attack surface that creates.

And agents for all, it'll let me come back to that in a minute. But so how are you possibly going to get your head around all the things that are coming along, that sprawl?

So there's three things. We can skip the rest of the presentation. I'll just tell you the three things that I want you to walk away with. We'll give the time back.

Number one, AI has made data security and data governance more important than it has ever been before. Do any of you in the room have responsibility for data governance? If so, we're going to have a therapy session afterward. OK, I didn't see a hand.

So when I was on the industry side, I had legal as a partner. Marketing for us was the actual the business side of that. And they were responsible for putting together a strategy for managing unstructured data. And I was in that role for about four years. I left the company when they were still trying to put a strategy together for unstructured data. The introduction of AI has accelerated the need, so make sure whoever's responsible for data security, if they're going to look at AI, that they're thinking about this.

The second one is AI is an amazing tool to help you scale. So I already went back to the statistic that you have all of these open roles, and the senior leaders are thinking about how to use AI in order to cover that.

And the third one is I'm going to reference MDDR. It's the Microsoft Digital Defense Report. I always like there to be a takeaway for you to have to come back and reference.

And so some of the stats in this presentation are coming straight out of the MDDR that was released about a month ago. This is an annual report. I will not say a single Microsoft security product name in this presentation, unless you ask me a question about it.

The Digital Defense Report is fantastic because we work with every country. We work with every industry. And so all of those insights and the frameworks are baked into that report. It's the threat intelligence team that takes those signals, and they say, folks, what do you need to be worried about in cybersecurity? And so it's 225 pages.

You can read it on the drive or the flight home. In seriousness, there's an executive summary in that that takes the whole 225 pages, and it jams it down. I neglected to put the link to this thing in there. So it is aka.ms-- for Microsoft-- aka.ms/mddr. And then it'll take you straight to the report for 2025. And I will also make sure that we get that link to it afterward. Sorry.

Yeah. I heard trust in the presentation earlier. And I think about how trust and security are completely interrelated. And I think that's another key message to take away.

As you're thinking about using AI and GenAI, you have to trust the data. Was that Mona Lisa was either one of those two things that looked like the Mona Lisa, the actual thing? Can you trust what you're getting from that output is accurate? And then if you're baking trust into it and you have that with your policy and your compliance, then you can move forward in a responsible way.

I like to hire brilliant, lazy people. So AI has been such an enabler for that. The reason I want brilliant, lazy people is that I want them taking all of the repetitive things from their job and automating them so that they can stare at the ceiling, find those moments of creativity, and do better awesome things.

So there's a guy on my team, and his name is Ron. And he was showing me how he was using AI with Copilot. Sorry, I did use a Microsoft product name. I apologize. So he's prompting Copilot, and he said, give me a picture of a lion wearing a dress.

And so AI spits back out this image. It's exactly how you would imagine it, and it's very cartoonish. And so then his cyber brain kicks on. He's talking to the model.

Tell me what factors you used to create this image. And so it spit it out. So he prompts back and forth, and he gets to that spot. Then he goes back, and he uses that, the inverse.

And he says, create an image without a dependency upon any of those factors that the model used to tell him that it was going to be an image generation. So now give me that lion in the dress. It was photorealistic.

And so put yourself in the shoes of a threat actor that doesn't have to participate in the rule set that you do to defend against that. That's the style. That's what they're using AI for.

So there's two veins of this. There is using security for AI, and there's using AI for security. I'll step out of that.

The next two slides are something that I use in every single presentation to when I'm talking to a group of people. And this comes back to the Digital Defense Report. Everything is sourced on the bottom. But these numbers change year over year. That first one, 72 minutes, the average or the median time it takes for a threat actor that successfully gets you in a fish and has access to your private data.

And I'm curious if your organization has a resilient playbook in order to respond to that. So after that 72 minutes, you can make sure that you stop that. Do you have zero-trust principles in the way that are going to mitigate the impact after that 72 minutes?

That 72 minutes is going to happen. That's not the root problem. The challenge is how do you respond to that space.

From a scale perspective, a guy named Brett that was the CISO for Microsoft for 20 years, he recently retired, asked him what he thinks about in his spare time, and he said golf. So he's excited to move away from cybersecurity and do something different.

But one of his slogans was threat actors do not break in. They log in. This isn't a difficult business.

Ransomware that we heard about earlier is a for-profit business. Folks are still attracted to that. So seeing that we had almost double in the blocked attacks per second. That's another one. It's like the 1 billion stat.

How do you wrap your mind around 7,000 blocked password attempts in a second? Because that's going by, and those things are multiplying. Use zero trust. Make sure that your identity plane is protected. This is basic security.

I like to talk to clients that want to talk about fancy security. They're like, I want to use AI to do all these really cool things. And I try to go back and say, tell me about your identity strategy.

What are you doing? Have you thought about password lists? Are you using conditional access? Do you have the basics? Have you swept the corners?

Because if I'm a basketball player and I want to have a friendly wager-- I had this analogy before the FBI had a probe into the NBA, and there were folks there. But I'll still use it.

If I'm a basketball player and I think I have a little bit of skill and I want to test myself, I'm not going to go to LeBron James out of the gate and say, do you want to play one on one for money? I'm going to go down to the local YMCA, and I'm going to test my skill that way. Threat actors think the exact same way.

They don't want to be Tom Cruise in Mission Impossible and come down through the roof and not touch the floor so that they can get your data. They're going to walk around the back of the house and see if that door is unlocked, walk in, and grab it. So the sophistication of these threat actors is not about nation-state or nation-state affiliated threat actors that want all of your data to recreate this in their own environment so that they can profit off of it.

Microsoft has those seen a 5x increase year over year in the number of named threat actors. So the ransomware business is active and growing. I'm going to take a pause after this and see if there's questions.

This is the other slide that I like to use to see those numbers change. Honestly, the 41 to 60-- last year, this said the company has an average of 70 cybersecurity tools. And that's just on their IT enterprise network before you talk about what they're doing on their OT network.

What this one is saying-- so we've had some improvement. Now we're saying a quarter of the population has reduced that down to 41 to 60. So the upper limit, people are finding an efficiency.

Why is this important? Are you getting the logging and all of the security information out of all those tools into your SIEM or into your eyes on screen, so that when you have that 72 minutes from the fish that you're shutting it down quicker, faster, more efficiently?

Threat actors hide in the seams. They hide where you can't see. Tool sprawl still continues to be a major challenge.

And if you think that you don't have this many tools, you could start from the off the shelf software, but then go into the space to where your SOC engineers are writing hunting tools of their own to manage-- to make their job more efficient. Start adding in. If they have access to agents, start thinking about that agent as a tool that they're using into that space.

I stepped on the tambourine. I'm going to pick it up and play it in a minute and get you guys woken up.

5 million cybersecurity professionals. So I've been in this industry a long time. That number stood at three. So we can argue is it 3 million, or is it 5 million?

The difference in that is irrelevant. This is a lot of people. It is difficult to hire, attract, and retain cybersecurity professionals. At Microsoft, what we do is we measure folks from a quantitative perspective so that we can give them skilling plans in L 100, 200, 300, 400.

And I have a digital university program within my team so that folks are-- if they're L400 on an identity, I'm like, great. Let's get you exposed to another one. Here's a training plan. You can get going.

AI has made that easier to where agents help them train. But this is why those-- on that first slide, why 4 out of 5 leaders-- 8 out of 10 leaders are looking at using agentic AI to scale. It's to bring that number down.

The last one is another one that's hard to imagine. But this is not new regulations. This is 250 updates to regulation. I think almost everyone in here is in a regulated industry.

And so even if you move past the fact of data privacy regulations, whether it's GDPR or one of the-- I've lost count-- but one of the 27 states in the US that has specific privacy law that you have to acclimate to, you have to keep your standards up to date to account for those things. And it's an arduous task. So let me pause there. Any questions about any of these magical numbers? I'm going to push back on them.

AUDIENCE: Yeah, I actually had a question. The quote from your CISO-- cybersecurity threat actors don't break in. They log in-- resonated with me. And when you look at these numbers, they're somewhat overwhelming. Maybe you'll get to this. But the way we combat that, do we have to get more sophisticated in our security approach, or do we have to get better at the basics, or is it a combination?

WES MALABY: It's a great question, and I'm going to use an analogy to help explain what it means to me. Ultimately, your cybersecurity program and the maturity of that, whether you're modernizing it, if you're multi-cloud, if you have on-prem infrastructure, how you're balancing it, where you have downstream customers, there's a lot of factors. It's very complicated. You go to bake it in.

If I'm going to go to my physician and if I have a symptom, I don't want to tell them how to treat me. I want to explain the symptoms to them, and I want them to be like, great, I think I know what's wrong with you. Let's use this as a treatment plan step by step. I don't necessarily want to jump into the MRI machine if I have a toothache.

And so fitting the right tool for the right solution-- I know it sounds silly, but the honest answer is that if you go back and you think of-- pick your favorite framework. If it's NIST, if it comes from anyone else, look at what the basics are on how to prepare for cybersecurity and be honest with quantifiable metrics if you're hitting that goal. The fancy security isn't as effective if you haven't taken care of that foundation. And it's also you have to manage costs that come around to that.

And you have to make sure that your people, which is probably your most precious investment, are aligned to what your strategy is as far as executing it. And if you're constantly throwing them the latest buzzword and fancy security out in front of them, they're going to get distracted from the foundation and the basics. So any other?

OK, so the challenges that are arising from AI today. I said one of the three takeaways that you have to have is data security. Data oversharing and leakage. The vast majority of the time, this is unintentional. This is someone within your organization trying to do the right thing to be better, and they accidentally expose information that you don't want them to. Basic labeling, data governance, data security helps with that component.

The number of times that your employees-- if you've locked down models, if you have-- you say, hey, I want to use Gemini. I want to use Copilot. That's the tool. And you've started to lock down from some of the other models within your company walls. How do you make sure that they're not harvesting that data onto their personal machines, so that they can get that same answer out of the space?

Non-compliance, there's a resiliency thing that comes along with this. Agent sprawl-- 1.2 billion agents. Emerging threats-- I get asked a lot about prompt injection. Like, hey, how do I secure myself against malicious insider that can bypass some of these other controls?

They've got a payload on their computer. They're going to do prompt injection into the model. The good news is you've already all taken an advantage of EDR, Extended Detection and Response, or XDR, depending on what the company is going to call it, to do data loss prevention and to do basic blocking and tackling in that space. You're trying to guard against the payload.

So that's back to your question is like basic security. You don't want a malicious payload to come into your environment from any source. The fact that it's going to come in a prompt injection is just another method of delivery into that space.

Working for Microsoft, I'd be remiss if I didn't talk about vulnerabilities with our Patch Tuesdays and CVEs. I get charts put in front of me when I talk to clients about that. What about this one? What about that one? Yes, there are a lot. It comes with the environment of having so many flavors of operating system and being left or right-- left or right broad with how to use applications that sit on your full tech stack and managing that. AI opens up additional vectors on vulnerabilities. So you have to be conscious of it.

Heard shift left earlier. This is great. It's this exact same thing.

So more companies are moving toward open-source AI models. There's companies that are taking-- that are building their own AI models. You hear about large language models, small language models. This is one of those cool intersections with OT.

When I was in industry, we hired a chief digital officer to come in, and we're going to do a massive digital transformation. It was really exciting. Everybody got fired up in it because we're like, it's going to be-- it's going to be fun. And after they took stock, they were like, we're not ready for a digital transformation. We need a business transformation.

And so if you're not familiar with a refinery, there's always a physical perimeter around it. There's a gate. If you run that refinery, you don't want anyone outside of the refinery telling you how to run operations within the refinery. But if the company has multiple and you're managing feedstocks to say it's such a low-margin business and I want feedstock to go to refinery A instead of B because my profit margin is going to increase, I'm using machine learning. I'm using applications that are built for that.

And so the very first instance that we had for business transformation at that time was in secure operator rounds. And in the old world, you had to have the safety agent had to drive out in the golf cart or on a bike or in a truck and go there. Before any hot work could be done on a unit, they had to fill out a physical form. They'd have to get back in the truck, go to the admin office, and file that in case OSHA showed up.

So the solution was take an iPad, put it in an intrinsically safe case, have that form on there so that they could hit a Print button from the job, not have to go all the way back, and go to the next one. Refineries can be very large, hard to navigate, so a simple use case and efficiency into that spot.

So now I start thinking about, OK, great. So edge computing five years ago was really popular to say, how do we push edge computing inside the fence at a refinery so that process control can activate on that information quicker and faster? How do I worry about the convergence in my Purdue model if that data is going to egress and go to that spot? So it's Spider-Man. With great power comes great responsibility.

There's some upside in looking at how you use AI in OT to accelerate those really simple use cases, but you have to do it in a safe way. And so that's where I think in this industry, we're starting to see more companies look at different types of models that fit them. The second one, I think we already kind of burned that one down. But of course, attackers are exploiting weaknesses.

Supply chain is a concern with or without AI. You have to have policies in place. You have to have reinforcement in place. You have to ensure your part of the ownership stack. And that shared responsibility is locked down really tightly so that you don't have the downstream impact.

And then there's the Captain Obvious third box. If you catch vulnerabilities early, it's going to save you cost and time. So I want to shift gears.

A couple of years ago, unfortunately, and it was in January because I was in Colorado on a ski slope. My phone started buzzing like incessantly in my pocket. I'm mid average. I like blacks and like a double black.

I got my wife stuck on the double black one time. My son and I skied all the way down. I looked back up, and she's a half a mile up the mountain. And I was like, oh, this was a-- I'm going to hear about that. She's not going to complain about my guitar collection anymore. And so I get down to the bottom and I'm like, what? What's going on?

Well, what we found at Microsoft is that we had some Russian interference with some inside operation, and that's not something that you want to hear ever. And it was a day zero and Microsoft completely rethinking how they approach security. And the fact that I'm talking about this-- I mean, you can read anything you want about it that. We publish.

But the fact that I'm purposefully choosing to talk about this is that one of our premises is to make sure that we are doing collaboration. The rising tide raises all ships. It's really difficult to talk about vulnerabilities. What happened?

And one of the key findings that we had in that space, and the reason why our customers were preserved from the impact that we had internally, is that the mindset that we have for securing Azure and securing the applications on it and taking that shared responsibility was off the charts. We have a well-published ring methodology for how code makes it into production. So the production system was fine. The problem was is that these very smart, resilient developers weren't taking that same sense of responsibility into their development environments.

So one of the things we talked about is rolling credentials. We're completely passwordless. I set my password the day that I moved to Microsoft. I haven't used it since.

So every time I log into a new system, I'm starting to see the refresh screen as it's catching up. And it's wild to shift from that world back into one to where you're using passwords. I'm pulling out my personal safe to authenticate with MFA.

So we went on this journey. And what's not on here to reinforce this is that our executives are paid based on the maturity of this program. It's October. It's cybersecurity month. I can put these things.

You all read that those protect tenants all the way across to accelerate response. You're like that's Cybersecurity 101. Microsoft, you're not doing anything special here or fancy. This just seems like table stakes.

But the CSO that is in place right now has a go anywhere, do anything card. And we're past wave nine of SFI for how we drive out this efficiency to ensure it. So no system is to make it out of dev without security being integrated up front. It's never meant to be a bolt-on. Secure by default means that you can't use a different procedure that's not one that's sanctioned by the office of the CSO.

And secure operations-- we were talking about observability earlier. Are you getting the logging information so that if it's 72 minutes after a successful fish that you've limited that impact in that blast radius, can you respond to that target? There's an executive correspondence on this.

Last count, we had nine deputy CSOs within Microsoft that were specifically allocated to business units. They meet, and they talk about, great, this is the challenge I have in my space. This is the challenge I have in my space. So that path is constantly taking every learning from every wave of SFI and putting it into those six bubbles that are Cybersecurity 101 to make it better. Now shift gears on you again.

And this is from the Microsoft Digital Defense Report for this year. This was the best thing that they added to it unless you're looking for a very specific piece of information. The reason that I like this-- and this is at an altitude that you may not find extremely effective-- but I want you to do a binary test and see. If you don't have responsibility for it, go engage with the security professional, with your CISO in your company and ask them what their response is to these 10 bubbles.

If you're a publicly traded company, your CISO is most likely already talking to the audit and finance committee. They're are going quarterly with a quality and a quantifiable measure of where the program is. They're making sure that they have the investment to mature that aspect.

Your board is reading Wall Street Journal articles. They see ransomware impacts. They're calling the CISO, calling the CIO, the CIO, and CEO. What are we doing about this? You want that plan?

So if you think about that top-down approach of what it means to educate your board on cybersecurity, it also will help your engineers reinforce the importance of their day-to-day tasks to achieve that mission. It gives them a sense of accountability. I've talked about two too many times.

Number three, again, make sure that you're bringing your folks along for the journey. The security Copilot tool that we have, the very first use case was within a SOC. There was two things. Number one, post-incident, they could say, summarize everything that happened. Build me the outbreak so that I can go build a remediation plan. Now it's going to build the remediation plan for you.

The second one was, is that every time you're trying to bring that 4.8 million number down and you hire a new engineer in your SOC, you need to train them. And so that's inexpensive. What I used to do in the old world was that if I had someone new coming in, I would take a senior person that I wanted to make sure they learned right, and I would pair them up. The opportunity cost is now I've pulled one of my best people out of looking at eyes on screen and doing a skilling.

And so an AI model using something like Copilot to pair this up, they've got a safe environment that they can range on and skill. And so we've seen that curve of getting smart faster really accelerate. For time purposes, I'm going to skip a couple of these.

Number five, I think is probably one of the most critical ones. And it ties it back to resiliency in the core of your business. So every single one of you, your company has, I hope, a BCDR plan. You've written it down.

And I bet the majority of you, if you find the person that owns that and you ask them, have you tested that? Have you actually tested it? And what I don't mean is, have you gone through so that the phone numbers are active in the sheet so that the right person picks it up?

But I'm saying I mean, that's the Microsoft on the Azure side. Trust me. We went through a resilience wave a couple of years ago to where we recognized that we needed to bolster this up, and so we have an entire mission critical effort now to where we say this is our commitment on Azure. We're asking you as our customers to make sure that you have your workloads across there.

You read the news last week. AWS had an outage. I told you I moved too much. Yeah, the AWS outage, I think, you know, one of the gotchas there is how many of those companies had tested their BCDR plan? How many of those companies had made some intentionality with where they were putting workloads with geographic residency, so that they knew what was going to happen?

So, I mean, actually test it. Find applications that you can failover. Know what those weaknesses are. And when you're doing that, go through your call trees. Make sure that you're testing your BCDR. You'll learn more from that.

One of the coolest things that I think we do from a proactive services standpoint is we have three different types of offerings to guide people through number five. Number one is a cyber range. So we have it is a Microsoft production environment. It's a lab environment, but it sits in the production environment.

And we like to ask our customers to bring their security configurations for their products into the range. And then we want them to bring their SOC to come on site, and we'll introduce a vulnerability. So we bring the Microsoft SOC into that room. We introduce the vulnerability.

We play the role of the Red team. We let the customer defend against it. If they're really good and they go really fast, we'll put another one on there. We'll accelerate that.

If they're struggling, we'll time out, and we'll go sit. And we'll help them understand. The best thing about that is that we're using their configuration so that when they go home, it's custom built.

The second part of that is doing a traditional cybersecurity tabletop. Test your plan. Know what's going to happen. One of the number one things that I hear about with that that folks aren't testing as much is when you have that bad day. And if you're in an industry to where the brand on the front of your building is a known brand, and someone's going to call from the press and say, what happened?

Who within your company is going to go in front of the microphone and talk about that incident? You probably know who's going to come. That part of it tends to be defined-- much less if you get hauled in front of Congress, and you have to defend everything that happened up front of that.

But this could happen today. You could have that incident today. And if you know the named individual, but they're not prepared with how they acclimate to what happened in the incident, then you got to start running them through it. So number five is very closely tied to number one.

The third part of that is an executive tabletop. So if you do a cyber range followed by a cybersecurity tabletop, and then you run your executives through it with the findings that you had, it tends to shake free some couch cushion money for your cybersecurity program because they see the importance of what they need to do to back you up to improve it.

Number eight is the last one that I'll mention. There are a lot of different feeds of intelligence out there. We have a team of 1,000 people in Mystic. That is to say their researchers that are specifically focused on this within Microsoft.

ISACs-- every industry has an ISAC. Get a Chatham House rules. Pull together a group of peer-- CISOs of your peers across other companies and talk, and you get Chatham House rules. Nothing leaves the room. Have a real conversation.

This is another lesson I learned in oil and gas. It's a very dangerous business. And so the mantra the Phillips 66 had was that everyone was supposed to go home in the same condition that they came to work today. I'm sure the Eaton has something very familiar and similar to that. And it's a dangerous business.

And unfortunately, at times, there are very serious injuries up to fatalities. And I remember that when I was CISO, we had a fatality on site, and the CEO of that business. If it happened across any of the majors, they got on a conference call, and they said, this is what's happened. And again, with the competition, what we wanted to ensure was that no one else had to experience what that was like, and they went through their entire operating rhythm to close those doors. Why don't we do that in cybersecurity?

We're scared to talk about the vulnerabilities that we have so that rising tide can raise all ships, and we can make it better. So these are simple principles. But I think, again, if you're thinking about your binary output and where you're at against them, it's going to come back to your question of, how do I make sure that the basics are invested in here?

This kind of pieces-- pieces it all together in a way too simple slide, and so you think about AI for security, security for AI, doing zero-trust principles, looking left or right across your landscape. I want to touch back on skilling again with another example.

We have a query language that if you use our suite and you're trying to hunt against the environment, it's called KQL. And I hear a lot that when you're new to that, they're like, I don't want to learn KQL, and I got to pick up another language into this space. And the tool that I used before this had a completely different language.

So my entire SOC has to reskill on this spot. This is a fantastic use case for scaling to where AI is helping. It's now it'll write the code for you.

Right now, you structure the query that you're trying to do into that space, and then you can copy-paste and put it into the tool. And so there's an efficiency to get to the best query quicker.

There's an accuracy component because now your model is also training on that so that if you have a similar incident six months down the road, you can start with that question. Show me all the incidents that had the same footprint of this aspect of it. That's human language. It's not KQL. There's a simplification component of it.

The other component that I want to really make sure that is understood is around data security. And the best analogy that's ever been given to me is about securing the president in motion when the president is in the motorcade. So they're outside the White House. They've got-- what's it called-- the beast that rolls around in with the bulletproof windows if you have a president that likes to get out of that and walk the street.

So the beast is intentionally very visible. This is like, this is my security. This is what's keeping me safe. The moment that your asset's outside of that, then you have a reliance on visible Secret Service agents that have a firearm, and they're surrounding the president. And they can take action in case there's a risk that's introduced.

You have plainclothes Secret Service agents that are two blocks ahead of the route that are constantly looking at that risk. You have snipers that are on roofs. So these things are all baked into that spot. That's your data. Your president is your data. It's the most important thing that you have in your company, and it's always in motion.

So the data center world has shifted over the last 15 years from, oh, I have a perimeter. I have a firewall. I have a moat. I know where it's at.

I can have people on-prem to access this to now. It's completely been inverted. My data is everywhere. Do I know where it is? Show my age.

But I remember my mom talking to me at the 10:00 news like it's 10:00. Do you know where your kids are? It's 10:00 AM closely. Do you know where your data is at? So simple analogy. That's zero-trust in a nutshell.

You have to assume breach. What are you going to do? You have to have your resiliency plan in place for when that happens. Now pull into AI this.

Imagine that the Secret Service is like, OK, the president's going to be in Cleveland next week or a month from now. And so you might want to know the last time the president was in Cleveland, what the route was, all of the things that you did then that were successful. You're going to want to know how Cleveland's changed since then. You're going to want to know what else is going on in the event-- or in the city at that time. So you're piecing these things together.

The Secret Service is using a large language model to put that information in proactively. They're using AI for good, and they're like, OK, great. I'm being proactive, and I'm putting all this information. Well, now they've just also created a threat landscape that if someone can access that, then they've got an x month head start on how the president is vulnerable in that space-- two sides of the same coin. So I encourage you as you embrace AI to embrace AI securely.

I've got about five minutes left. I can tell you more crazy, zany, off the wall, out there analogies. Love to hear if there's questions on your mind about any of this. Yeah. I'm going to give you one more that's not so crazy.

But it's another really fascinating conversation that I had within Microsoft. And agentic. AI have 1.3 billion agents.

Agents are talking to agents now. They start to get scaled efficiency. It's another data center point. So all the AI is driving capacity. So you need more compute in order to transact this.

Now you have MARL, M-A-R-L, where you have multiple agents, Multiple Agent Response Language, I think. But this is an aspect of like agent one is responsible for task one. Agent B is responsible for task two. How do you get to outcome three in a transitive property where those are working together? So that's a controlled environment.

The conversation that I had within Microsoft about where this is going is right now, compute is the constraining factor on responsible AI to where agents can actually go to that next step and start to be autonomous on their own. Humans are the constraint in that model. If we catch up with compute, then we've got Skynet on day one. We have to start thinking about that interaction. So it's another point, just as an example of what we're thinking about in the next space of this, where the awesome responsibility and the power of this has to be managed very securely and safely.

So there's no other questions? Thanks for your time.

AUDIENCE: I'm going to throw one more at you-- this group's karaoke too much last night. So love what you said. But can you talk a little bit about how do we take-- all this change is happening so fast. How do we take this and apply it-- apply it to an OT environment that traditionally changes slow?

WES MALABY: Yeah. Yeah. Responsibly, sure. No, it's a great question. And that again, I go back to the aspect of it's the importance of segmentation up front. And to me, cybersecurity and OT the sweeping the corners and the foundation is do you have asset inventory? Do you know what assets you have on your OT network?

If you've done the segmentation, then your safety systems are on a different network. And you have that map. If you have contractors in your OT environment and they're responsible for deploying any kind of tech stack in there, then you have another risk that's introduced into that spot.

So I think foundations you build in-- that's the first question you should ask yourself. Do you know what assets you have? Do you have asset inventory? On top of that great, you have it, now how do I look at making better use of that information?

I know I can't patch this, so I just want to know what the vulnerabilities are. Again, basic cybersecurity-- you don't need AI for it. I'm going to take you on a different path for the answer to this. The

Most important thing to focus on here, if you haven't, is are your IT security professionals and your OT security professionals in the same room? And it can be a virtual room. But that convergence is happening more now, and it needs to happen faster. And the beauty is, is that I had a network operations team before I had the SOC, and if a new engineer came onto my team within six months, I needed them at two sites. And I needed them to know how crappy their IT service was out in the field.

And so I had a good example of one of those people did that, and they were taken into the back of the refinery. They were given that iPad and that intrinsically case safe. And they were like, go walk around there and tell me what your signal strength is. Of course, it didn't work. Heat, metal, fluid are not great things for Wi-Fi.

So they came back. We had to call a telco and start thinking about coverage to get to that environment. They had been complaining about it for six months.

The OT person had been complaining about it for six months. We had to see it firsthand. So that power of human relationship and that convergence.

So where I would encourage you to be thinking about this is that if you take an OT operator and you're bringing them into the same side as the IT person, the OT person is going to teach them how the plant works. The IT person should be like, great. I've been doing patch management for 25 years. Let's talk about the principles.

Start to figure out because every plant is going to be different. Industries are going to have a little bit different approach on how you do it, but sussing that in there is going to mature you. The other element of it is you've got a place to have a safe environment to skill. And so that's back to where these models-- like I have Copilot on my phone and it's making me dumber because I just have a guitarist.

I'm like, I need to learn music theory. So I said, build me a multi-point plan to learn music theory accurately. I got 10 points, and then I had to ask him what each of those 10 points meant and go on to that space.

But at the end, when you hit the proverbial print, I've got a roadmap. And so I think that same aspect to where your focus is your people. If you can get them to where they have the safe training environment, you can use production data in a lab environment to start to see IT.

This is how we hunt in the SOC on these vulnerabilities. Now apply that to the OT data that you're harvesting through Historian and say, how would I look at the vulnerabilities from this side of it? So that's a good question. OK, thanks, everyone.

RAY HARISHANKAR: All right. I know I'm between you and the end of the session, so I'll try and keep it as entertaining as possible. If you don't ask me questions, I will. All right? So what am I going to talk about? A little bit of background. I've been with IBM for 26 years now, and every five years or so, it looks like I have a new job.

So I've been in this new job on quantum for about four years now, and my focus has primarily been, in addition to having a background in quantum mechanics and computer science, I started getting into cybersecurity. So my focus has been on the cybersecurity implications of quantum. Now, how many of you know what quantum computing is?

Good. Two or three hands, which is good because I will start with what is quantum computing, and then, where are we with quantum computing? Where is it real? Because many people still think that it is somewhere out in the future, may or may not happen, something that you read in comic books stuff. Right? But I'm just going to show you how real it is. That's one.

Second is more here and now, what are the cybersecurity implications of that? Right? And then what can we do about it? That's primarily going to be my discussion here. So one thing I want to be clear is when we start looking at computing and the future of computing, the way we look at it is it's not just bits or just, you know, your classical computing now. We have CPUs, which are bits, and we have GPUs that we call kind of neurons.

And then you have qubits that are quantum computers. These three work together. So it is bits, neurons, and qubits is how we look at it. And these three don't-- well, they do operate independently. But the power of the future of computing is in actually all three of them collaborating together and working on a specific workload to help drive a desired outcome. So we are not looking at quantum computing as something that operates independently by itself.

As far as I can see now and foresee in the future, quantum computers do not operate on their own. They do need a classical counterpart. They always work in conjunction with a classical computer. Right? So in that context now, let's get into what is quantum computing. There is probably one geeky chart in this, right? Other than that, I'll try to keep it as consumable as I possibly can.

So what we focus on at IBM, on quantum computing is we focus on bringing useful quantum computing to the world and to keep the world quantum safe. Now, I particularly made the second part colorful so I can also add a line that says my focus is on the colorful part of the mission statement. All right? Now you're not laughing. Man, this is a tough crowd here.

All right. So this is the only geeky chart. How many of you know about logic gates? Something you studied in high school? Maybe, you know, yeah, some hands go up. So classical computing, at the end of the day, operates on a certain set of gates. And, or, not, and so on. The same principle applies in quantum as well. And there is a reason why I call out this gate philosophy, to show that there are fundamentally certain gates that you need to operate to execute a desired outcome that you're looking for.

In the case of classical, it is addition, multiplication, movement of data, that stuff, right? Similar stuff happens in quantum as well. There is a Hadamard gate, a Toffoli gate, so on and so forth. I'm not going to go into any of the details. But suffice to say that the same paradigm applies in quantum as well. And they two work together to execute an outcome. The second thing that I'll call out is I kind of hinted at this already. If you have bits in classical, you have qubits in quantum computing. Similar.

Now, similar, but yet entirely different. The difference is in this. If you look at bits, they are like an on/off switch. They're either zero or one. Whereas if you take a qubit, it's like a dimmer switch. It can have a value of zero or it can have a value of one, which is the other end, or any value in between. So there are technically infinite set of values that it can take. And that's the big difference.

The other one is it can have those values simultaneously, which means it can be a zero or one or anywhere in between at the same time. That is difficult to comprehend, but that is nature. That is what quantum computing is. And when you begin to manipulate and operate with those principles, you find that you have significantly more number of data values that you can represent.

So if it is zero or one, it's one or the other. Whereas if you look at zero, one, or anywhere in between, you have an exponential set of values that you can have. Therein lies the capacity or the strength of quantum computing. So pretty soon you will find, I think there's a chart later on that kind of explains this better, so I'll hold off on that. So that's about all the fundamentals that I want to leave you with on quantum computing.

If you do want to have an interesting cocktail conversation and show that I do know something about quantum computing and, wow, somebody else you're talking to, then a few tidbits for that. This dimmer switch analogy is an excellent one that you can use. The other is, at least in the quantum computing technology that we adopt, which is called superconducting qubits, the qubits are at almost absolute zero temperature, which is colder than outer space because you are operating with fundamental particles that get agitated pretty easily, noise, sound, electromagnetic interference, vibration, temperature.

All of them will upset it, so you have to cool it down to the lowest possible temperature you can. I think it's about 15 millikelvin above absolute zero, which is very, very, very, very cold. And then that's when you operate on it. That's another technique that you can use. The last piece of information that I'll leave you with is while quantum mechanics-- sorry, quantum computing can do a number of interesting things, it sucks at doing multiplication. You can do multiplication in classical computing in a nanosecond, or even subnanosecond.

You think about doing multiplication in quantum. It takes a long time, in milliseconds, if not more, again. What can you do with quantum computing? Right? The simple way to understand the chart behind you is to say, look, there are problems that classical can solve, and there are problems that only classical will continue to solve. You will never expect to see quantum computing doing your payroll, or customer call management, or any of the other standard applications that you typically see.

There are certain applications that classical solves well, but quantum solves much better. Case in point. Some AI problems. Detection of fraud, right? Or anti-money laundering, fraud management, that stuff. Optimization. These are all things that classical does kind of well, but quantum can do much better. And then there are a certain class of problems that classical simply cannot solve and quantum solves much better, or quantum can solve. Right?

Obviously, it's better if it cannot be solved by classical. And factoring is one of those problems that classical cannot solve but quantum solves better. Hold that thought. I'll come back to it in the second half of my discussion. With me so far? All right. I see a few nods. Good. So what can it do? Double click on this a little bit. I've already touched on this. I'm not going to go into this a lot more detail. You can look at what's on your left-hand side as a set of mathematical algorithms that are fundamentally solvable in quantum.

And what's on the right-hand side is where you apply those to really drive some business value. So you can see that there is a whole set of industry solutions that quantum can solve, and I dare say is solving using the primitives or the fundamentals you see on the left-hand side. So you can pick your favorite industry and go into any of these use cases.

The other way to look at this is optimization is one problem that quantum solves. AI, in a way, is another problem, or quantum machine learning is another problem that quantum solves well, because at the end of the day, AI is about identifying patterns in a sparse matrix where there is very little data. Can I go and find a pattern? Right? Quantum is good at doing that, right? So some of these fall into that as well.

Now, for those of you who are doubters, I just want you to take a minute to look at this. The progress in quantum computing over the years. You'll see that even though in the last 20 years or so, from 2006 to 2025, you will see that there is a heck a lot of progress made in the last few years than in the years-- in the previous set of years that are put together.

And I'll quickly give you a walkthrough of what the progress looks like, and then I'll take a minute to or take a pause to look at some of them in depth. Right? Now, we have been a leader in this space for 40 years. We started working on quantum computing almost 40, 42 years ago. But I'll just take you through the last 10 years. In 2016, we put the first quantum computer on the cloud.

I don't know if many of you know about that or not. And then we also released the following year an open source SDK for anyone to go and work on quantum computers. It's available today in a much more robust form, and you can go and play with it and begin to learn a lot by actually doing it. And then in 2017, we also said, look, it cannot be an individual sport. It has to be a team sport.

So we began to put together a quantum network that consists of enterprises, academia, national labs, and other interested parties coming together. I think have a short letter that talks about this a little bit more. But we began that collaboration almost eight years ago, and to date, we have over 80 computers, quantum computers on the cloud that you can use.

And there are over 600,000 users in the community around who have been using this, and the quantum network I just talked about that we started in 2017 has about 280 or so members right now. Across the world, there have been over 10 million learners who have used SDK quantum, Qiskit, to learn about quantum computing. So this is not something that is kept in a closet or kept in a research lab. This is very much out in the open and people are adopting and following it.

So I talked about the quantum network. Right? I do want to pause here for a minute for you guys to scan through this set of icons here to see if you recognize any of them. The one in the middle of the top column there is-- top of the middle column there is Cleveland Clinic, which is not too far from here. They are one of the, I think eight or nine instances where they have a quantum computer on their premise.

Interestingly enough, it is in their cafeteria, so you can go and take a look at it, even if you don't want to go in for anything else. It's an interesting observation to see how they have displayed that. RPI, Rensselaer Polytechnic Institute in New York, and there are several others that have a quantum computer in their own premise. So in addition to the 80 or so that are on the cloud, there is about eight or nine that are on custom installations or custom on-premise installations.

So what are they doing with this? Right? what they're doing with this is there's a set of activities or problems that they're solving. And before I get into that, you need to know-- so how does how does one go about measuring this. Right? And so I'll just give you three snapshots to give you a data points on where we are today. In 2022, we hit the or we crossed the 100 qubit barrier, meaning there is a chip that has 100 qubits or more that is available for folks to do computations on. Right?

Now, why is this 100 qubit barrier important? Because at about the 100 qubit barrier, which is part of this-- I think we called we have named our chips after birds. So you will have Eagle as the current one. Heron is a current one that we have. In 2022, we released the Eagle processor with 127 qubits. What does 127 qubit really mean? Just for comparison, if you had 30 qubits, it's about the size of-- it takes about 17 gigabytes, or it can represent 17 gigabytes of data.

So 30 qubits is about that. 49 qubits, given-- I'll give you one more thing. 31 qubits will require two of these laptops because of the exponential nature of the qubits themselves. So if you have 49 qubits, it will take up the frontier supercomputer memory capacity as to how much data frontier can represent. We can represent in 49 qubits. With 100 qubits, you are exceeding or touching the connected capacity of all classical computers on Earth.

And where we are today is 156 qubits. The Hadron processor I talked about is about 156 qubits. Now, this gives you a feel for the amount of data that you can represent, and that is where the power of quantum comes in. Because classical stops at visualizing certain data beyond a certain point. You cannot visualize three dimensionally the molecules, the materials. You cannot model certain things beyond a certain capacity. I earlier alluded to the fact that classical does certain things well, but quantum does better.

One of them is optimization or fraud detection. Any of those problems is actually a multi-objective optimization problem. You want to balance your portfolio against a set of parameters. You want a reduced cost, increased returns, relatively flat against the market fluctuations, and you have to balance that against the market indices, weather, geopolitical activities, blah, blah, blah.

There's only so much you can do in classical. So you make assumptions and operate within that. And we are reasonably comfortable with it because that's all you have. With quantum, you get to do a lot more. You have given. That's the representation. That's where the value of or the capacity of the data that you can evaluate becomes important. Hence, the number of qubits that you have gives you the ability to solve more and more complex problems that you can only imagine in classical.

Now, why are we able to do this work so well? This is a little bit of a plug for IBM. We have been in semiconductor business for about 60 plus years, if not more. And the consequence of that is-- and you may know that we have a fabrication plant, 2 nanometer fabrication plant in upstate New York. And we have been in that business, like I said, for several decades. The consequence is that we are the only ones approaching quantum computing as an engineering problem and not as a research problem.

What do I mean by that? So there is an issue. For example, all these quantum computers have this notion of noise. Right? The qubits that are kept at almost absolute zero are manipulated by microwave signals to do what you want them to do. But they don't want to behave. They will decohere. They will reset from their zero state. And so you have to reset them again every so often. That is called a coherence issue. And we can call it as noise. You can call it as error or a combination of it.

So these are fundamental problems that exist. Now, these problems are not new. Your classical computer, your laptop, your Windows machine, Mac machine, they all have an error correction chip inside them that we've just taken for granted. If I remember right, the name of that is hamming error correction code. If I remember right, that was discovered years ago. So it is known that these semiconductor devices will have errors. And you know what's causing them, figure out a way to correct it and move on.

That's how your laptops and computers produce the same result repeatedly, again and again and again. We are not yet at that stage with quantum. We are at the stage where we know what the errors are. I'll tell you when we intend to recognize the errors and correct them. But the point that is where they are. Which means that you have a problem. You need to know what the solution is.

So there is theory first. Then you say, hey, can I take that theory and implement it as a proof of concept, a pilot, a prototype in my lab. That is a research problem. You take the theory and say, can I create a solution for it in the lab, in a controlled environment? Yes, I can. Then it becomes an engineering problem where you take that and say, now that I have a proof of concept in the lab, I want to take that and build it into the chip, manufacture it at scale, make it work in unconstrained environments.

That is what engineering problem is. So when I say that we are dealing with this as an engineering problem and not as a research problem, I mean that we have solutions that we have proven in the lab that we are now scaling out. That is why we are able to produce a new quantum device every 17 days, if we have to, in order to correct whatever we find.

So a combination of the expertise we have in-- sorry, nanometer fabrication combined with our ability to churn out these chips as an engineering problem gives us the ability to make measured progress. The next year we wanted to show utility. So that was about getting to 100 qubits. Utility is about saying, I can solve a problem accurately and at scale. And I'm not going to go into the depth of this except to call out a couple of data points here.

We demonstrated this with 127 qubit Eagle chip and 2,880 gates. That's what we needed to demonstrate that there is a repeatable utility value and we can solve a problem accurately. And all of what we talk about is published in refereed journals. So it's not us making any of this up, but it is in a referenceable as well. The next thing we said was, OK, that's '22 and '23.

Now, in order to get to scaling out beyond that, we cannot look at it as quantum computer alone. It has to be done in conjunction with a classical computer. Any of you are familiar with workloads that you deploy on the cloud. So take a similar pattern. You take a workload. Some part of that problem or workload is best executed on a CPU. Some of them may be better executed on a GPU. Some of them may be best executed on a QPU.

The challenge is figuring out which part does well where, and then using that particular component or chip to make that happen. That's what essentially quantum centric supercomputing means. It means it's hybrid computing architecture that leverages classical and quantum, not classical or quantum. Right? So you move from one versus the other to one plus the other. That's the fundamental notion. This goes back to my very first slide about bits, neurons, and qubits. They all work together, and that's the best way to solve any problem. And we demonstrated this in collaboration with Riken, which is a chemistry research facility.

And here we used a workload that ran on Fugaku, a supercomputer in Japan, and on the quantum computer, Heron based quantum computer that we have, to show that there is significant, demonstrable value in this quantum centric supercomputing model. Now, before I go into where we are today, any questions on this so far? I know I've been rambling on for a bit to establish the context and background. Any questions on this so far?

All right. I am thrilled to see that I'm absolutely clear as always. So you may say, fine, I kind of get all that, or I believe you, but then where is the proof point? Who is using this today to make any useful value out of it? Now there is nobody using it in production. I'll tell you that, because it's emerging technology. However, about a month ago, HSBC put out a paper. They are one of the quantum network partners.

They put out a paper saying that they executed trade execution strategies for, I think it was around bonds, where they found that their quantum based model produced 34% improvement in trade affiliate estimates. Now, 34% in billions of dollars being moved around or filled orders being made is significant. Soon after that, almost days after that, Vanguard came up and said, hey, we have been working on this as well and we found that in fixed income asset portfolio optimization, we have seen that quantum gives us better results than classical.

Then Wells Fargo came along and said, I've been doing some time series analysis where, in time series, typically resource consumption is a huge issue. And we said we are finding that quantum is more frugal than classical in this. So these are just three recent examples. But there are many more that are being done. But almost all of them are in their internal experimentation stage. And they're coming out with proof points so that they can learn and see how they can apply this.

Now let me switch to the next part where I do want to talk about the here and now of this. I said, I'll talk about quantum computing and then the cybersecurity implications of that. This is where that is. Remember I talked about one problem that quantum solves that classical cannot. Anybody remember what that is? Sorry? Multiplication.

Kind of. Multiplication is one that quantum does poorly and classical does better. But in my Venn diagram chart I had factorization, which is reverse of multiplication. So if I gave you a number 65 and say give me the factors for that, please, you can easily come up and say 13 and 5. However, there is really no algorithm to arrive at that in classical sense. There is no formula you can apply other than brute force to come at it. And this fundamental-- and this is called factorization, by the way. And this fundamental mathematical problem is what we rely on for all our cryptography.

Now I mean, this is a cybersecurity perspective, so I'm sure you know about cryptography within the context of cybersecurity. Still, a basic primer. Two types of cryptography. Synchronous and asynchronous. And simplifying this, synchronous is for data at rest and asynchronous is for data in transit. Asynchronous is using these protocols that you see, RSA, DSA, Diffie-Hellman, ECC, et cetera.

Well, all of them are based on this factorization problem. The fact that if I give you a large number, a 637 digit number that you see as RSA 2048, and I say, go find me two prime numbers that you have to multiply to arrive at that, you can do it. I can do it. A supercomputer cannot do it. And it is based on that assumption. Premise is what all the cybersecurity protocols are based on, or encryption protocols are based on. Simple problem that cannot be solved by classical computer.

However, in 1994, Peter Shor from MIT, without even having a quantum computer to work with, theoretically figured out, oh, I can solve factorization by creating an algorithm. And he did. So there is an algorithm that exists. When executed on a quantum computer, it is capable of factorizing these large numbers. In other words, all of today's cryptography or much of today's cryptography will be broken when a quantum computer of sufficient scale and capacity becomes available. We call that a cryptographically relevant quantum computer.

So the simple problem is our assumption that there is no solution for factorization, and therefore, I'm going to use that as the fundamental underpinning for cryptographic algorithms-- more precisely, asymmetric cryptography-- is broken. And you may say, wow, that seems scary. So when is that going to happen? When a quantum computer becomes available, yes, somebody can use it and break that.

Now, just to rub it in a little bit more and to scare you a bit more. What does it mean when asynchronous cryptography is broken? Every digital communication that you send and receive is likely to be compromised. I can masquerade as you. I can create fraudulent transactions and you won't even know it. And Wes mentioned, if I remember right, the threat actor doesn't break in. He logs in. Right?

That's what's happening here. I will be able to log in as you. You wouldn't know it. Nobody would know it until something really bad happens later on. Right? So essentially, this is really bad. So you say, hm. So I do have some time because you said when a cryptographically relevant quantum computer is available, that is when somebody can break in. Yes, absolutely. Stuff to the right. Right?

We don't know what that cue day is. It's not like Y2K, where you knew when that was going to happen. This is something that will happen sometime in the mid 2030s is what we believe. Right? So you don't know when it's going to happen, but you know it's going to happen. And when it happens, all the stuff you see on the right-hand side will happen. So you say, wow, OK. So I still have, what, maybe seven, eight years? I'd say think again, because what's happening today is what you see on the left-hand side.

Motivated bad actors are exfiltrating data as we speak today. Whether they're sensitive or not doesn't matter. Data is being exfiltrated, with the expectation that sometime in the future, when a quantum computer becomes available, I can apply quantum computer to the data that I have and decrypt that and then see what goodies I have. How many of you know of this TV show called Storage Wars? A few, right? Where you go and bid on a locker that you kind of know what may be in it, or you probably don't know what's in it and say, eh, $5,000.

And then you go and figure out what's inside. And if you find a good heirloom, something there, or a signed baseball or a guitar that's worth something, then yes, you have hit the jackpot. Same thing can happen on the dark web with respect to data that has been harvested. I'm exaggerating this to make a point, which is motivated actors have data that they've exfiltrated, mostly nation states. They have exfiltrated the data with no hope of breaking it today. They don't want to break it today. They'll wait for years down the road to figure out what they have.

And you and I, if we want to do it, we can also offload the data and then put it up on the dark web and sell it for some money later on. Possible. So my point is this is something to watch out for. And as you very well know, we are not confident today in that our data is secure, not because nobody can exfiltrate it, but because even if they exfiltrated it, there is no way they can read it. That is how. So data is being exfiltrated for a variety of reasons. But they can't read it, and that's why we are happy about it. But here, that is going to be broken. So that is something I want you to internalize.

Is something being done about it? Yes. In 2016, NIST started a competition to figure out, hey, what are the solutions out here? Who can produce algorithms that cannot be broken by classical as well as quantum? 84 submissions came in. Four of them were selected for standardization. Three of them have been standardized. And interestingly, three of the four came from IBM. And then subsequently the fourth guy also joined IBM.

And these are the four algorithms, the three algorithms that have been standardized. And they have asked for a second round of algorithms as well that are a little more performant or that are form factor oriented. So the bottom line is, yes, there is solution available. Post-quantum cryptographic algorithms are available today that one can begin to incorporate into your existing systems so that you can begin to protect what is happening. Sorry. Begin to protect your existing systems.

However, data that has been exfiltrated, if the horse has left the barn, if the train has left the station, whatever analogy you want to use, there is no bringing it back. What is gone is gone. However, not all is lost. You only need to be concerned about, is that data that might have been exfiltrated valuable over time? Credit card information? No big issue. You can always change it. It's life isn't very long and they're not breaking it today.

So the point is patent information, drug discovery information, anything that has value over the next seven years or after the next seven years or so is where you have to watch out. So the takeaway is identify your crown jewels and make sure you're protected. The government has put out some timelines. I'm just giving you one of the timelines from CNSA that says, look, anybody who wants to do business with the federal government, you better be quantum safe by 2033.

And they've even said, which means that here are the other milestones based on that. If you have to meet 2033, you have to meet these other deadlines. Several other governments around the world have done the same. Now, the question is we are sitting in 2025. You have about eight years. When was the last time we ever looked at what cybersecurity, what protocols are being used anywhere in our enterprise? Never. We haven't had a need.

How many of you remember the Log4j problem that came up in December of whenever, 2017, 2018? We scrambled around. We didn't know where our Log4j was being used, so it scrambled around, and crazy enough, it happens during December if I remember. So you're waking people up during Christmas holidays, asking them to go look for this. And then it took months to really figure out what that is. This is several orders of magnitude more complex than that.

Where are we using cryptography within our enterprise? Not just in our custom applications, but also in applications that all the third parties are providing us with. So you look at the supply chain, software supply chain, and say, how do I make sure everything in the software supply chain is quantum safe? That's where the problem is, right? With me so far? Are you scared enough? Right. So that's the reality of one of the negative implications of bad actors using quantum.

Now, why do I think it is real? Why do I think it's going to happen in 2033? This is IBM's point of view, and based on where we are today, plus based on what we have read so far as well. So what we put out in May of this year, we have a roadmap that we have published that you can go and look at it. It's a quantum roadmap that we have put out on our website. You can go look at what we have said since 2016, 2017, or even before that.

And we have been hitting every single one of them because, as I told you, we are looking at it as an engineering problem. And so we have solved it in the lab earlier and now we are trying to scale it so we know exactly what it will take to get there. So we're pretty confident about it. Based on that, we are saying that we will reach what is called quantum advantage in 2026, which means a classical-- sorry, a quantum computer will solve problems better than what classical can.

Now I've already shown you some examples of this with HSBC and Wells Fargo and Vanguard. So there are emerging solutions, but we will have a definitive, repeatable problem that we will demonstrate next year. That is an inflection point because there are certain techniques that we are going to have that we will demonstrate that will show that this is important. And here is what a section of our roadmap looks like. And I'll just bring you to this part.

I think Nighthawk, if you look at it, we are going with Nighthawk is the next bird or next name of the chip. So we are at Heron and we'll go to Nighthawk, which has got 120 qubits, and it will support 5,000 gates. Remember I told you to remember that for the chemistry example or the one before that, we had 2,880 gates that we used? So this one has 5,000. Then every year we're going to increase that from 5,000 all the way to 15,000 by 2028. So essentially building up the capacity of these.

And we also are not going to look at growing-- if you want 10,000 qubits, we are not looking at a chip that has 10,000 qubits in them. We are looking at integrating or modularly interconnecting maybe three, four, five of these chips together. So you get to a total of 10,000. Right? So there is form factor of that involved in as well. So that work happens and you will get up to 15,000 gates that we will have and 120 qubits.

After that, we said we will reach fault tolerance in 2029. Fault tolerance means remember I talked about errors. We have the ability to error correct in 2029. Which means that, similar to the hamming circuit I talked about in classical machines, we'll be able to put forth something that will correct this. Now you may have caught-- some of you may have caught this in the news the last few days where IBM and AMD said, hey, we just figured out that we can apply commercial off the shelf AMD chips to do error correction, which will help us get to fault tolerance.

So there are errors that occur. You need to figure out a way to correct them. And instead of having to create chips that will help implement that, in collaboration with AMD, we have figured out that we have commercially off the shelf chips that we can use, which means we can do it at a ridiculously inexpensive manner. And it left shifted the entire schedule by about a year. My point is that there is a lot of work happening as we speak. We announce this in May. At that time, we didn't know about the AMD work, so the schedule gets left shifted consistently. That's a takeaway.

So 2029 is where we believe we will get to fault tolerance. What does fault tolerance mean? It means that the next set of chip from Nighthawk to Starling, when we get, we will have 200 logical qubits, and take this-- 100 million gates that you can operate on, which means you can solve a large problem, significantly large problem compared to the 2,880 I showed earlier to the 15,000 we will have a couple of years from now. And guess what? Sorry. Went the wrong way.

By 2033, mid 2033, we will have Blue Jay, which will have 2,000 logical qubits, which will have a staggering 1 billion gates that you can operate on. So you can solve a significantly large complex problem using quantum computers during that time. Are we approaching a cryptographically relevant quantum computer by that time? You're within spitting distance of that when you get to that.

Now RSA 2,048 requires a large machine to solve. RSA 1,024 requires significantly smaller machine to solve. So don't quote me on this, but just for reference purposes, when you're at Blue Jay in mid 2033 with 2,000 logical qubits and a billion gates, you should be in the vicinity of solving RSA 1,024. Now all that we need are a couple of inflection points, a couple of advancements to left shift it. Then you're in real trouble.

Now, given this is all about data center, I thought I'll leave you with this, which is, we are building a data center in Poughkeepsie or expanding our data center in Poughkeepsie to have these quantum systems that we will begin to establish. I already talked about 80 systems that we have on the cloud there. Most of them are sitting in Poughkeepsie, and now we are beginning to install system twos and system twos, where we can interconnect these together.

And you will see that this is real. This is not a PowerPoint magic that I'm showing. But this is really stuff that exists today. All right? So that's pretty much all I wanted to cover with you today. Any questions? Yes, sir?

AUDIENCE: Yeah. I'll make an assumption. So GPUs that are used now in the data center, if we were to move to quantum computing, will that reduce the size of the data centers?

RAY HARISHANKAR: Will that reduce the size of GPUs?

AUDIENCE: Because now you're moving to quantum now, are we going to still require all these huge data centers?

RAY HARISHANKAR: Well, you will require-- remember I told you that your workload is broken up into what is appropriate for CPU, what is appropriate for GPU, what is appropriate for QPUs. And quantum doesn't solve all the problems that GPUs and classical typically do.

However, there are certain class of problems that are now typically executed, AI related problems that we get to that are typically executed on GPUs. You find that they are likely to be executed on QPUs. Will they result in a reduction in a data center? I do not believe so, but it's speculation at this point. Any other question? Yep?

AUDIENCE: Have you solved your form factor problem for a QPU inside the data center yet?

RAY HARISHANKAR: Have I solved a form factor problem of a QPU inside a data center? This picture does show that we do have racks of quantum computers. So what you see on the picture is a real rack that exists that if you visit Yorktown, for example, you'll be able to see. So we know what it takes to install them. Yes. I don't know if it is a form factor problem or not, but we know that we can install racks and racks of these system tools.

AUDIENCE: How much does a quantum computer cost?

RAY HARISHANKAR: To own or to use? To own, it's an inordinate amount of money because right now, again, it's very expensive to have an on-prem setup simply because of, first, the refrigeration that is needed to cool it down, plus all of the supporting electronics that you need to have that you need to support to operate that. So owning your own, like Cleveland Clinic does, is primarily for research purposes and an early investment. I wouldn't go there.

But to use it, you can use it for free, technically, if you want to learn Qiskit. But then if you want your own dedicated time as an enterprise, then we have a certain pay as you go type of plans that you can buy into. I'm just throwing some numbers out. I don't remember exactly what the numbers are right now, but you can commit to using up to $1 million for over two years or something like that, and you will get your time. And along with that comes help, subject matter experts who will help you with identifying use cases that you can try and experiment with and solve. You don't want to waste your million dollars of time share on a quantum computer. We'll help you with identifying algorithms and solving them.

AUDIENCE: There's a rough order of magnitude of cost, right? The ZettaScale computer for GB 200 costs you about [INAUDIBLE] to put in 127,000 in cluster, right? So if I buy one of those and I want to hook it up on yours, how much does four to five of those units cost?

RAY HARISHANKAR: Not my forte. I have no knowledge. I don't want to BS you by giving you a random answer. But I can, if you can drop me an email on that, first, I can pass it on to somebody who understands the question and can answer it.

AUDIENCE: What is the percentage of the total power consumption needed for cooling?

RAY HARISHANKAR: It's an interesting question. Everybody thinks that power consumption for cooling is enormous, but it is not, because refrigeration has come a long way, and this is cheaper than what it takes to cool down, interestingly enough, the GPUs, because they generate a heck of a lot of heat. Here, a QPU doesn't generate heat, because you're not doing a lot of math with it that generates heat. You want it to remain at a cool temperature.

So I believe that 150 watts is what it takes to keep the temperature cool once it has cooled down. I do not know what it takes to get it down to that level first. All right. I see my friend standing up, which is an indication that I am out of time, so. Sure.

AUDIENCE: On the algorithms, quantum computing proof, the ones that niche adopted, have we-- two questions on that. Have we assessed the computational power that needs to be embedded in devices to run those algorithms, the potential impacts of them on devices that will have to run them instead of running RSA 2,048, for example? Is there any comparison on that? And second, how long they will be quantum computing proof? How many years do we expect them to survive, considering the progress we are making on quantum?

RAY HARISHANKAR: OK, so two questions. The first one, when you say you want a comparison with what? I didn't quite catch the comparative part.

AUDIENCE: Today we have processors in, for example, in our products that have to encrypt using RSA 2,048. I want to know if we have an idea of the difference in computational power for running--

RAY HARISHANKAR: Good question.

AUDIENCE: OK.

RAY HARISHANKAR: OK. So difference in computational power needed for the algorithms, classical versus post-quantum cryptography algorithms. We have actually-- if you're interested, I can send you a link. We have done some work on that. So has Open Quantum-- OQS, whatever that stands for. There are there is work that has been done by NIST, OQS, and us to show these algorithms that we have chosen. So there are four algorithms, a couple of digital signature, a couple of key encryption algorithms, and they all have different key values that you can have.

So these, they have different variations, permutations, and combinations of how you can use them. So we have a tabulated a set of-- if you use these values in these curves, here's what the performance characteristic is. So there is a performance index that has been published. So you can use that to compare in your environment what classical performance is versus what quantum PQC algorithm performance is. There is at least one instance where PQC is faster than classical, but that's a benchmark result.

It gives you a guidance, but you have to test it within your own environment. And there are test harnesses that we have built that are freely available that you can go and use it in your environment to figure that out. It is a factor that we pay close attention to because you want it to be better performance, if not definitely at least equally performant as classical. That's one.

The second is how long are they going to hold good? The new math that-- so one of the things I said was, hey, we picked up one math problem, which is factorization, and said there is no solution for it. Let's go 100% down on it and create all algorithms based on that. Easy to do. Started in 1974. 50 years later, it still works. This new one, we didn't want to put all eggs in one basket so we have different math problems. Hash based, lattice based, isogeny based, multivariate, quadratic equation based, different math problems.

So even if one happens to perform poorly, or one happens to be broken in the future, you have something else to fall back to if you choose to do so. So I'm not saying it will never be broken, because I cannot predict that, because some creative algorithm using quantum computer may come up. But in the event it does, we have other algorithms to fall back to.

AUDIENCE: OK. Thank you.

RAY HARISHANKAR: All right. Thank you so much guys. Enjoyed it.

[APPLAUSE]