Presenter:
Transcript:
[ 00:00:10 ]This is Track 10. And just as you know, we have a microphone here on the stand. If you have any questions, please come up at appropriate times to do so. And this is Markus Mueller. He is the Managed and Professional Services Director with Insane Cyber. And his talk is an intelligence-driven, defensible architecture process case study, Volt Typhoon. Thank you. Good audio? Okay. My name is Mark.
[ 00:01:04 ] Hopefully that works better. So my name is Markus Mueller, and I've spent my career, the majority of my career, defending, building, and responding to security within industrial environments. And during that time, you know, I've thought a lot about what it takes to defend an environment. And before, I used to think, you know, the right combination of people, processes, and technology deployed in any environment would protect it. And it didn't really matter if it was a manufacturing facility for, let's say, furniture or durable goods or a water treatment plant or a generation plant. The same types of technology, people, and processes would work. And that's how we do security a lot of times. We have these reference architectures. We have these sets of technology we deploy. And most of the time, it does work.
[ 00:01:55 ] Most of the time, you're lucky. Most of the time, I've been lucky and haven't had to deal with it. But I've got to work on the other side of it, you know, in a professional services capacity, doing incident response, dealing with customer environments. And we see that it doesn't always work. We see incidents. We continue to see problems. And, you know, even if we're looking at data from this year, and this one I actually pulled Kaspersky because it gives a different view outside of the U. S., a lot. And we still see a lot of impact. Manufacturing being hit the hardest this year. Automotive, power and energy, telecom, all being hit. And this is this year’s ransomware, some of last year’s too, kind of hitting the industry.
[ 00:02:40 ] And so if we’re all following these reference architectures and we’re all doing security, why do we still get hit? And a lot of us will say, hey, they weren’t doing the basics. They weren’t managing the environment correctly. They didn’t have good firewalls. And I can tell you from my experience, I’ve been in environments where people are doing the right things and they’re still getting hit. And so that got me thinking a lot about what it takes to secure an environment. And kind of there’s two main. main white papers that I like a lot. I like the five critical controls from SANS. Tim and Rob's work on that was really good.
[ 00:03:14 ] But honestly, the stuff that Lockheed Martin, that Fitch and Mukin put together, although it's not for OT specifically, I think it's the best approach that we can take. And that's an intelligence-driven approach, where we look at how we build these environments, how we defend these environments, and how we respond to these environments when there's a threat. So the process they outline in this white paper really works with: hey, we have a standard process of design, build, run, and defend. And throughout that process, we're going to have Intel feed into that process. And when I say Intel, most of you guys are probably thinking, okay, I'm going to get an Intel feed, or I'm going to read a report, or I'm going to be part of an ISAC and get that information.
[ 00:04:02 ] And I do mean that, but it's much more. And I've kind of added to this process. So this process works really well, and everybody should read this white paper, but I've kind of added a bit to it and made it more for an OT environment. So when we look at an OT environment, I think one of the things that we're often missing as defenders is the first part of this, which is understanding the operational and business needs. It's building on that and the business constraints, taking those into account. Taking that threat profile, that Intel portion into account. And then finally, what are your capabilities? Not every organization is the same. Not every team's the same. So you have to build for what you can do.
[ 00:04:46 ] So when we look at business and operational needs, it's funny, I meet with security teams and I'll have a conversation with them about their business, about their operations, and they don't understand how their business functions. worked with a manufacturer that they the security team doesn't understand if they're if the manufacturer runs a batch process or a stream type process they don't understand how their operations works or how their business makes money and at the end of the day that's what we're defending against and so taking that into account is really important you know if you work in a water treatment plant The differences in how water treatment can be between different system types. If you're using, you know, a sediment system or more of a bioreactor system, those are two different systems and you need to actually protect them differently.
[ 00:05:36 ] You need to take that into account. You know, how the business makes money. Does it, you know, is it a private equity or a private entity or is it a public entity? You know, what kind of needs are in that? And what's the impact? I'm a huge fan of a systems and system approach, crown jewels analysis. The military kind of came up with that, and it's a really good approach because it gets to the root of what your operations and your business needs are. And I highly recommend everybody go do that within their own organization. So once you kind of understand the business needs, the operational needs, you need to focus on the constraints of your organization. You know, there may be engineering constraints to operations. There may be safety constraints.
[ 00:06:21 ] Really, how operations manage is how they're gonna manage. And you're not gonna be able to impact that necessarily unless you have a really good relationship with operations. And so you need to involve them in that, but you also need to understand what those constraints are. If you're trying to go, 'Hey, I'm gonna apply my patching the same way I patch every environment to operations', you're going to just burn bridges. And at the end of the day, engineers are really, really good at doing what they do to make their operations work. They will figure out a way to make it work without you. And I've seen it a ton of times. Business constraints, that can be a lot of the things around regulation, the business structure, how it's built, what the maturity of the organization might be, the risk tolerance.
[ 00:07:06 ] I've worked with organizations that are; They understand their business and they say, okay, I'm willing to take the risk. It's on the risk register. We are insuring against it. We don't want to spend the money or we don't want to spend the effort to secure that facility. That's the reality. It's the business. They get to make that choice, especially if there's not a safety or regulatory requirement. As a security person, you may want to question whether or not you want to work with them, especially if they're doing something that impacts safety. It is an organizational decision. And pushing against that, you're going to have a limitation. That threat profile is kind of where most people think Intel. And I do think this is really important.
[ 00:07:49 ] The threat profile of your organization is going to be driven by a whole bunch of different things, mainly what industry you're in, who you're doing business with, where you operate, and who your customers are. Based on that threat profile, you're going to build out a set of scenarios. You're going to look at what you're defending against. If I'm defending a small water utility with, let's say, 5,000 customers that provides water that's non-treated, so they're taking well water out and they don't have to treat it, that's a much different threat profile than a 100,000-customer water utility that services some military installations, for example. Those are different threat profiles, and I'm going to have to defend those differently. And then finally, organizational capabilities.
[ 00:08:39 ] And if you've spent any time in this industry, you've probably run across a security tool that somebody deployed and nobody's managing. So, you just wasted a bunch of capital and it has zero benefit on your organization. I will say the SIEM is the classic example of this. I've seen a ton of SIEMs deployed. And as a responder, I'm a huge fan of it. If I show up and nobody's touched the SIEM in six months and they have an incident, it helps me, but it doesn't help you very much. And so, you know really building technology that your organization can use is the most important thing because if you can't manage it well, it could actually hurt you. So let's do a case study. In this case, we've got a utility.
[ 00:09:22 ] This is completely made up. It is an amalgamation of different utilities, different customers I've worked with. There is no San Antonio, Texas-based power company that does generation. But in this fictitious scenario, we've got a power generation company. They're only in the electric generation space, so no transmission, no distribution. They run 14 sites, solar battery, 10 to 50 megawatts each. And this is pretty common. We have a ton of companies like this. Importantly, they are operating with an ERCOT. ERCOT is the market down here in Texas. Famously, reliability is not part of the market here. So if you're a producer, unlike every other market in the US, you don't have to necessarily have reliability as part of your metric. So you can generate when you have power, and you can not generate when you don't have power.
[ 00:10:12 ] And so they're operating down here. Very common stack. They're running a lot of cloud applications. Basically, their entire business side is on cloud or hosted. And then the OT side, they've got each one of the power plants running, but then within kind of an overview. They have a market participation function and an overlay SCADA. And we see this from a large operational point. When folks have multiple plants, they start to want to monitor it, at least from an operational standpoint. Maybe doing some control centrally, but mainly just for making sure the plant is up. So when we look at the business constraints, we have a company that is operating all of these sites. They're producing power for themselves, so to charge the batteries, and then they're doing what's called demand and frequency response.
[ 00:11:01 ] And this is common. They're selling power during peak usage. This is why you do solar with batteries, because you can kind of maximize the amount of revenue. They also have something called a power purchase agreement with some customers, so they have a certain amount of power that they have to generate. And in the power industry, a lot of times your battery and solar inverter suppliers they actually manage the product for you so you have a long-term contract; third parties are in there that's kind of how it is. We have an EPC contractor. You usually don't own the site until the day it goes into commissioning, and if, if you've ever been involved in that where you get handed a site once it's built, you think it's that shiny new site and all; all the security is in place from day one.
[ 00:11:46 ] A lot of us know that that's not the reality when you get these sites even when they're brand new. So, those limitations. I talked about that PPA. That's a mandate of how much power they have to produce. And usually, there is a harsh financial penalty if you don't produce that power. So, we've got a bit of a business need there; a business constraint. You know, they're running that remote operation center where they have that overview, but they don't have a ton of staff. These companies run very lean; you know, there's not a huge margin on some of this stuff, and so they're going to run lean. They have a limited IT and business structure. You know, large financial impacts if they don't deliver, limited budget, and they have contractual obligations.
[ 00:12:27 ] And so all those things are needs that you have to be aware of, constraints that you have to be aware of to make sure that you come up with a good solution. So finally, we're looking at the threat profile. So they've looked at kind of what they're susceptible to, and they've said, 'hey, you know, IT/OT, ransomware spread, number one threat. Just based on history, based on what's out there, we're going to have to protect against that. The other thing they looked at is third-party vendor compromise.' Because they have all these vendors in there, if one of their vendors gets popped and they know some of their vendors don't do great security, they know that that could be a risk for them.
[ 00:13:02 ] And then from a capability standpoint, they have a small IT staff with limited time to focus on OT. They have a lack of visibility and documentation of sites. I'm sure nobody's ever run into that. And a limited budget, of course, like always. So let's talk about what they did. The first thing to build that architecture is they looked at kind of what can we do. At the primary site, they separated out, you know, an OT firewall, OT DMZ, logical separation, trying to do those different subnets. And then at the sites out there in the field, they said, 'Okay, we're going to deploy our firewall, so we control the edge at every one of the sites. We're going to then provide services, both corporate services, so they have vendor wireless and corporate wireless, and also try to do some segmentation all off that firewall.
[ 00:13:51 ] They run some VPNs back so that they can see the traffic and control the traffic too. When they look at identity management, you know, IT side, they run a standard hybrid Azure model for identity. On the OT side, they deployed an OT domain on-prem. That's at the rock, so it's not going to be at the remote sites except for some services.' But the OT domain is there for that overview. And then here's the fun stuff. So, system hardening where they could, doing allow listing where they could, doing EDR in the rock where they could, making sure that it wouldn't interrupt operations. Their whole driver is making sure they have uptime. And then some interesting stuff, stuff coming up with good solutions like, hey, when they're out at a site, when somebody's there, they need the wireless.
[ 00:14:41 ] Like at the end of the day, if you've ever been to these sites, you've got techs out there, they're working on inverters, they're working on batteries, they need connectivity. If you don't give it to them, they're gonna plug in. That's just the reality of how they operate. And so they said, OK, we're going to have wireless out there, but we don't want it on all the time because it's a risk. So they put on a timer. Literally, an operator comes out there; He turns it on. It's just on a timer, powers it up, and they're able to run. And I think four, eight hours, kind of that time frame, and then it shuts down. So they know that it's only going to be running while they have folks out there.
[ 00:15:13 ] They focused on backups; they said, hey, we need to focus on recovery. They did do that scene, although they are monitoring it. And then they added some visibility. They said, 'Hey, what tools do we have, without having to spend a bunch of money, can we deploy some tools? You know, looking at open source, Zeek, Suricata, let's try to have some visibility in Iraq.' And then a big thing was user alerting. And they pushed user alerting. So anytime somebody logged into an operational site, would log to the scene, but they went one step further. They have a ROC, Remote Operations Center, an operator sitting at a desk 24-7, and they added alerting so that any time somebody logs in, the operator sees it in their alarm screen, and they acknowledge it.
[ 00:15:55 ] And something simple like that gives the power to the operator to go, 'Hey, why is John logging into site five right now? It's two in the morning. Let me call John. He didn't check in before doing that.' And it gives them that visibility, gives the control to the operators. They looked at some Intel feeds, EISAC's important one to follow if you're in the electric industry. And really around policies and playbooks, it was about getting that response capability down. You know, understanding how they would recover. So, you know, OT incident response plan, specific for their OT side. They built off their IT one, but made it for the OT side, figured out what changes they would do. And then some playbooks to really go forward with supporting that.
[ 00:16:36 ] And then training, making sure they have that, building that bridge between operations and the OT side of the house. With that, they did tabletops, one a quarter, simple tabletops starting out and made it more complex as they go. So this got them kind of to a good, happy spot. And then they read about Volt Typhoon. And I'm a huge fan of the amount of intel that's out on Volt Typhoon. It's gone by a whole bunch of different names. I think everybody, especially in the electric industry, should read it. But it's actually impacted a lot of others. And Volt Typhoon is interesting because we know a lot about it. A lot has been published. There's a lot of TTPs. As an adversary, they also use a lot of different capabilities.
[ 00:17:19 ] You know, they're not a one-trick pony. They are doing a whole bunch of different things. And it's really a good adversary to kind of, you know, look at and then build defenses for. And that's what we're going to walk through. So they read the reports. They came up with a threat profile for Volt Typhoon. And I've done a very quick one here, a single slide. When you look at Volt Typhoon, there's the big CISA reports, Microsoft reports come out. But there's also stuff in the past. They were actually active along before that. They kind of do a wide range of things. You can see the attack path Miter, and you can see all the different things they hit on. But definitely the botnet activity.
[ 00:18:00 ] The zero days are really interesting because it's been multiple different types of devices. So everybody knows about the edge devices, but they've also hit a lot of remote management type tools. They recently hit an SDN solution. So those type of things. At the end of the day, though, Volt Typhoon is not about destruction. They actually haven't caused any damage per se. No OT damage. It's all about access and information. They want to learn the environment, gain access, and maintain persistence. And so. With that in mind, they do things where they try to be quiet. So low-level bins, living off the land techniques, a lot of PowerShell, a lot of credential dumping. They're trying to get legitimate access, and then they stop doing everything else because they've got legitimate access, and as long as they can maintain it, they're not going to make any noise in the environment.
[ 00:18:52 ] And some malware, although kind of interesting malware. Even when we look at the attack path, so the 2023 attack path is from the CISA report and the 2024 attack path is from the recent Versa, we see a much different attack path, which is kind of interesting. You have an adversary doing two very different things, which is unusual. Most adversaries are, you know, at the end of the day, they do the same thing over and over again. So it's nice to see this and kind of understand that we've got an adversary. Although their end goal is the same, they're doing different things. So, what did they change? Well, to specifically address Volt Typhoon, they said, okay, we need to have some diversity in our technology stack.
[ 00:19:32 ] So, we're going to use a different vendor for our external corporate firewall than our OT firewall. That's a management overhead that you're going to have to deal with. You're going to have to know two technologies. Your team's going to have to deal with two technologies. They said the likelihood of having a zero-day on one firewall and another is less than when you have the same firewall, so they kind of made that choice. They also focused a lot on that remote access, the privileged access management. They really focused on their admin accounts, both on the IT side and the OT side. And we'll talk about a bit about authentication coming up because they really want to do some interesting stuff there.
[ 00:20:11 ] But they had a huge push, and they were doing some of this, but they said basically if it flows from OT over the border, or in or out, we're going to put an intermediate host there. So one of the greatest challenges they had was vendor data flow. So internally, they could put remote access. They already had that in place. They beefed it up. But the mail relays, file transfer, all of those, they said all that data that the vendors require us to send to them, they said, we're going to put OPC gateways, we're going to put MQTT gateways in, and all that's going to flow through us. That allowed them to control that flow, and so nothing leaves the site unless it's through an intermediate host.
[ 00:20:52 ] At the sites, they decided to, at their tier one sites, so they went to the business and said, 'What's the five most critical sites out of our fleet? If we lose those, we lose the most money, we have the greatest impact.' Let's put some diversity there. So at those sites, they put multiple firewalls, separated fully out, made sure that they had two different vendors, and put more data flow relays in at those critical sites. At the end of the day, you want to protect every site the same, but that's not the reality. That's not our constraint. And so they really did focus on those critical sites. When it came to the identity management, a few things that they focused on. They knew that their vendors were already in the cloud.
[ 00:21:37 ] Most of what they were sending up to their vendors was in the cloud. Most of the manufacturers are running data analytics in the cloud. They said, 'we need to embrace that.' So they actually came up with an Azure. Domain in the cloud and some of the mail or some of the data forwarding went to the cloud. So they controlled it, that an MQTT Gateway in the in the relay in the cloud in Azure, and they were able to do cloud-to-cloud connections with their vendors. So they're securing the path even once it was out of their environment. It was still separate from their OT domain. So we're not; we don't have any kind of trust relationship, but that did allow them to control more of it.
[ 00:22:14 ] The other thing that they focused on when it came to those systems is really locking those systems down, doing specific things that you should be doing on every system to defend against Volt Typhoon. That's stuff like enabling the LSA protection, disabling shadow copy, simple things like that that are policy hardening that Volt Typhoon has been known to do. But they also focused on how we do authentication. So they knew user behavior, users will use the same passwords. They already had multifactor in place on their remote access, so they decided to switch it. In the corporate domain, you have a password and multifactor on one side. When you log into the OT domain, the remote access, it's actually a pin, a number, and a multifactor. And that way, you can't have the same password.
[ 00:23:05 ] Because of password policy, it's impossible. You know, they did stuff like looking for people using their phone number and all the normal little tricks that folks do to try to limit, you know, that kind of thing, the OSEN type cracking. But, you know, and then they used RDP in their environment. And that was engineers, how engineers got out to the sites, you know, made changes. They managed all that through their remote access, so they first would multi-factor in remote access. They knew RDP existed, so they tried to do as much as they could to limit it, including deploying certificates, so manage certificates for all their RDP connections, manage their own CA internally. Again, focusing on backups, making sure that they could restore sites, making sure you have solid backups of all of your control systems.
[ 00:23:54 ] Monitoring, they extended it to that user activity. To PowerShell, WMI. They also added network visibility at their tier one sites using the things they'd learned from the process of doing it at their primary site. They extended that out. And they started some vulnerability management. And this really comes down to classifying systems and applying the right vulnerability management to the right places. So if I've got an edge system, I'm going to be very aggressive. That thing's getting patched as soon as possible. I'm going to make sure to talk to the business about why I need those outage windows. If it's a device that's far in my network behind multiple layers, maybe I wait until the next maintenance cycle. That may be once a year, but I'm going to patch at that point because I don't want to cause operational issues.
[ 00:24:39 ] When it came to policies and things they started to develop, it was all about how the business runs without technology. How does the company manually operate these sites? And getting the mindset around operations of technology is going to break. At the end of the day, it doesn't have to be a security event. It can be a piece of hardware fails. The internet goes down. In Texas, the power grid could go down. There's lots of things that can happen that makes it so you don't have the technology that you're used to operating. You need to figure out how you operate it without it. And they really started pushing that a lot with their operational folks. And they did get to hire a few folks and build out a bit of a SOC, not full-time, not 24-7.
[ 00:25:22 ] But they put it together with the ROC. So the ROC was already monitoring all these sites 24-7. You've got an operator there, and they went to operations and said, hey, can we put our SOC next door? Can we put it right next door anytime you need them? When they're there, you can help them, and we'll have an on-call. And building that bridge with your operations folks makes it so that they're force-multiplying your security team. And they really focused on that. They gave them some training. You know, simple stuff. Hey, this is what to look for. Weird operational things. Consider cybersecurity within your troubleshooting plans. So when we look at the outcomes, we really see that the solution supports and enables operations.
[ 00:26:05 ] At no point did I say, hey, shut down all remote access or make it so you have to do X, Y, Z, or you can't do that. As I said, you have to enable and accelerate operations. You have to make it easier on them. If you make it harder on them, they're just going to go around you. They're really good at it. An architecture that's built to address the threat landscape, that threat profile. Even with Volt Typhoon, they had a decent architecture before, but once they saw Volt Typhoon, they made specific changes to improve the architecture to make it better. That architecture aligned to what the defenders could do. They didn't deploy zero trust or advanced EDR everywhere. They didn't do things that weren't going to fit their architecture, and they tried to make it as low overhead as they could for themselves.
[ 00:26:55 ] They focused on those people, processes, and technologies to really come up with solutions that worked well. Focusing on sustainability and reliability and resilience within operations is key to that. So that process that I outlined earlier, I really do think this is something everybody should be doing in an OT environment. And even if it's not in an OT environment, you just strip out the OT portions of it. But developing solutions that really take into account those business needs, those operational needs, they are built to address and work in our environments, taking those constraints into account, using that threat profile to build what I'm defending against. And really making sure that I'm building something that can be supported in the long term. So Intel-driven design that fits that operational model, developing resilience and response capabilities, enabling and supporting defenders, because at the end of the day, it's a long slog to defend these environments, and you don't want to burn folks out. And that is really making sure that you have the right processes and technology in place. And with that, I don't know why the next slide isn't appearing. Oh, there you go. That's my talk, a little quicker than I thought. But any questions?
[ 00:28:41 ] I mean, I'm a huge fan. I built, when I was putting this together, this was actually about five slides, and I tried to get this down to less slides. I'm a huge fan of building, it's usually about four or five pages. If I'm profiling a threat for an environment, building a threat profile, I'm going to build four or five pages for every adversary group that I'm going to put in that profile. I'm a huge fan of doing MITRE. A lot of times you can find this. This is from the MITRE website. Actually, I just exported it to Excel and then stripped stuff out so it'd fit on the slide. And then you can link that back, especially with Volt Typhoon. Volt Typhoon, there's a ton of Intel, specific Intel.
[ 00:29:25 ] So the CISA report, the Microsoft report, I think it's probably the best CISA report that ever has been put out. I wish every report from CISA was like that. Sorry, CISA, if you're in this room. But it had kind of the high-level stuff, it had the attack paths, and then it linked to all the MITRE techniques, all the MITRE numbers. But then at the very bottom of that report, or linked into it, was all of the specific detections. So they had all the file indicators, which aren’t really that valuable because they didn’t reuse them. They also had all the IPs and DNS, again, not as valuable. But they had all the techniques. They talked about exactly what techniques they used. There was a reverse proxy technique that Volt Typhoon was, it was in the report.
[ 00:30:12 ] And there’s zero reason in your OT environment that you should be running reverse proxy. It’s actually a Windows feature that’s in there. And you can basically monitor one registry key. And if that hits, you know you have a likelihood of a Volt Typhoon type adversary in your environment. Like I said, it’s a really easy thing to look at. And that's something I would pull right away. It's actually on my list of like the rest of the slides, the four others about Volt Typhoon. There is a ton of Intel techniques. The diamond model is really good for doing analysis. I tend to do that. Trying to think what other kind of methods. Those are the main ones, I would say.
[ 00:30:58 ] This is from the MITRE. If you go to the MITRE site and then MITRE, I think it's MITRE Navigator where you put in the adversary and you can export it to Excel, which their site I'm not a great fan of, so I export it to Excel. I like the content, it's just harder to play with sometimes. I wouldn't. No, no, you should never present this slide. This is the slide, and this one's stripped down quite a bit. But this is the type of thing that I would present. You should have a one-page on an adversary. And it's really a threat profile. Like for a threat profile like this company, you know, ransomware is going to be my top threat. And it's really going to be here's when I talk to an executive, it is, you know, you have that first page.
[ 00:31:43 ] It's going to be here's my top three threats. Here's the likelihood, which is a hard thing to say, but we need to be talking about it. That's how when you when. Other risks are talked about in a business capacity. Likelihood is part of that equation. And we need to be talking about impact. Ransomware may have a smaller impact. If you get Volt Typhoon in your environment, the impact that you need to consider is, A, what it's going to take to evict them. The fact is you're also going to have every government agency in your environment for about six months. Some of that's good. I'm not saying that's not a good thing, but that's going to impact your business. And you need to have that as part of the impact that you have within your organization. Any other questions on that? Awesome. If you have any other questions, come find me. I work for a company called Insane Cyber. I'll be at their booth. And, yeah. Appreciate you guys coming.
[ 00:33:18 ] Yeah, so, and I'm actually giving a four-hour talk about that exact process at GridSecCon in late October, so if anybody's there, we'll go through that. We'll do a full analysis. But it is, like, the only way to do this from the way I would do it is I have to have a profile organization. So I thought about the profile organization, then I went through that process, the same process. It's not necessarily, I would say it gets easier with the knowledge you have if you work in the industry, if you understand that industry. But it is, yeah, Volt Typhoon, the fact that we're dealing with an electric utility, every electric sector company should be considering Volt Typhoon. I mean, they targeted electric sector in North America; they've targeted others, but that's been their primary target for over the last few years.
[ 00:34:10 ] They wouldn't be the only one that I would target. I will say also from an impact, and this is maybe not as popular: I would be very clear on the impact to organizations. The impact to the country as a whole is really big, but the impact to organizations is non-existent. They have not caused an outage in North America. They've not caused an outage that I can find anywhere in the world, actually. Taken a lot of data and they've established a lot of access, which is really bad. But for an organization, there's been no impact from an operations or from a business perspective. And so I think we have to be clear about that. I would put that in my profile. You asked the executive question. I would make that clear to my leadership team that the impact is bad and we should be kicking them out and doing that. But from a business perspective, there is actually no impact from Volt Typhoon.
[ 00:35:11 ] If you come find me, I can give you some links to some stuff that you can do. Perfect. I really appreciate it. You guys enjoy the rest of the conference.
