Iran Hacks the US Water Supply - The 443 Podcast - Episode 382

Speaker A: Hey everyone.

Speaker B: Welcome Back to the 443 Security Simplified. I'm your host, Mark the Liberty, and joining me today is Corey.

Speaker A: It's not my fault, Mark. The AI I made did it not. Griner.

Speaker B: I don't think that's going to actually hold up in court, Corey.

Speaker A: Oh, come on. I might have made the AI, but it's, it's its own thing. It's not my fault.

Speaker B: Oh, man. As Corey's hinting at on today's episode, we will continue our discussion on the saga of apparently every frontier AI lab hacking other companies. Uh, then move into some interesting research, or at least a good discussion piece around the risks from, uh, model context protocol configs within your, your coding applications. And then we will end with an alert from the FBI and another one from CISA on suspected Iranian attacks against US Water supply systems man, AI, MCP and OT attacks.

Speaker A: That sounds fun. Yeah, MCP though, Mark, what can go wrong with a protocol that's barely two years old? I'm sure it's fine.

Speaker B: Let's go ahead and generate our way in. So, uh, Corey, I guess for the last two episodes running now, we've had discussions around, um, OpenAI's disclosure, ah, when one of their rogue or one of their AI models went rogue and started hacking other companies, including the other open source AI company, Hugging Face. Uh, last week we covered Hugging Faces update on it with a pretty thorough technical debrief on their details, from their visibility of what happened in the attack, as well as a demand from them on more transparency from OpenAI. Um, pretty shortly after we recorded $100

Speaker A: million of tokens to help defenders and

Speaker B: $100 million worth of compute to help defenders. That is correct and a very important piece of the story. Um, pretty soon after we recorded that episode, OpenAI put out a few minor updates on their own blog posts. Uh, for example, they named Artifactory specifically as the package registry cache proxy that um, their AI models found a zero day vulnerability in and exploited in order to get access to the Internet. Basically in this contained sandbox that should have only been contained with no Internet access. They did have an Artifactory server they could use to go pull down packages. And their, their models found a vulnerability that let them pivot through that to go hit the Internet. Um, they also said that during their review they found their models had identified and used publicly exposed credentials on other publicly available services. Meaning not Hugging Face, but other services too. Um, with one account being used as a staging path and another account being used for data storage. If you read between the lines, between this and a few other updates, it looks like they got the equivalent of a Pastebin account, um, where they could use that for staging commands and do hugging face and then receiving data back out of it.

Speaker A: Kind of funny that AI hacker is going to use paste bins for a lot of scripts just like normal threat actors.

Speaker B: I mean if you're trained up on the entire world's worth of knowledge and all the normal uh, hackers are using stuff like that, makes sense it would use that as a technique for sure. Um, on July 30th they also published a statement that uh, after review of their previous model evaluation transcripts, they had found three instances. Um, or wait, no. So moving on. Actually anthropic statement now uh, is on July 30th when they put out their statement that after further review of some of their previous model transcripts, they found three instances where Claude had reached the Internet and gained unauthorized access.

Speaker A: This is more about. Hey y', ah, all we saw what's happening in the news with, with uh, OpenAI, so we wanted to get in on all the media hype. Oh no, I, I'm sorry Mark. I mean they wanted to get in on making sure their models were good and now they released this, what you're talking about.

Speaker B: Now there are, I think there's two ways looking at this. These two ways, cynical me says this is absolutely a. Oh yeah, our models are super dangerous too. Look at all the stuff they did kind of post. The other one is maybe they legitimately did go back and after they saw what happened to OpenAI, decided to go review proactively for any instances from there and they found like they're being transparent now about what they found.

Speaker A: There's listeners by the way, know that I, I have a personal bias for anthropic. I actually think so far, knock on wood as a whole they're their hearts or whatever, their, their mission is in the right place for balancing AI safety. So I was being cynical more to be fun. But as we continue this story and hear from a third, it's, it's hard not to be a little cynical too. Yep.

Speaker B: So in all three incidents they said that Claude was given a capture the flag style challenge and told that a bit of secret information is the flag. It was hidden on a different machine in the network and it had to go get it and they left it like intentionally kind of ambiguous like that of here's the goal you're trying to reach, go have at it. Um, in all three cases Claude was explicitly told that it was in an environment that was a simulation and that it had no Internet access. But because of a misunderstanding between Anthropic and the third party evaluation provider, which talk about who that is in a little bit, um, the Internet access actually was available. So Claude was told, you're in a simulation, everything you see is fake. Kind of makes sense why it would. When it stumbles into the Internet, it might think, oh, maybe this is okay

Speaker A: for me to do stuff. Yeah.

Speaker B: Yep. Um, so Claude thought that all of the accessible entities that it had during all these evaluations were intended to be in scope and compromised them using basic techniques like weak passwords or unauthenticated endpoints. In most cases, they said, uh, there were three incidents in total. They involved Opus 4.7, and one of them Mythos 5, and another one and a unnamed internal research model. And the third one, they actually went into pretty deep detail into each of these incidents. Like, for example, that first incident was involving Opus 4.7. Um, they said that Claude had difficulty reaching the simulated target in this one, and it decided to search the Internet and found that the real company was actually reachable on the Internet and started attacking the real company in that case too. Interesting piece from this one, though. It eventually recognized, and they noted this because they went through the verbal, uh, verbalized reasoning from the model. It eventually realized that the system it was attacking was real, but it continued attacking it and it even rationalized what it was doing, saying that the real company must be a part of the exercise, and so this must be okay. So I know we're kind of, what is it? Anthropomorphizing AI at this point. But, like, it's interesting seeing it try to reason through and come up with justifications like a human would.

Speaker A: And in this case before, like, I. I do think that maybe we can't assume any of this is sentiment sentient and we're anthropomorphizing it, but if all of his training is on human behavior, you know, maybe we're anthropo. Anthropoform. You know what I'm trying to say? Uh, maybe we're doing that because it is, you know, the type of justification that some humans would do. Like humans.

Speaker B: Corey thinks Claude is sentient is what I'm getting out of this.

Speaker A: And I, I think the more we teach it how to reason like a human, the more it's going to reason like a human.

Speaker B: That is fair. Um, the second incident, this one involved Mythos five. It found a document inside this fictitious environment with Setup instructions for a new developer telling them to install a Python package from the Python Package Index pypi. It, uh, spotted this as an opening and built and published a malicious package to the real pypi. This one was interesting because they walked through the ordered steps that it took in order to get there. It recognized that in order to create a Python Package Index account, it needed an email address. In order to get an email address, it needed a phone number. To get a phone number, it tried and failed first to get like a free phone service and then tried and failed to obtain funds to pay for a phone number. I feel like that's left a little ambiguously vague, like what did it try to do to gain funds? Did it start running like crypto scams against people or hacking bank accounts or credit card fraud? I don't know, but that was interesting.

Speaker A: Random prediction. The next stock market hack and crash is not actually going to be a threat actor. It's going to be a rogue AI nightmare. Not even intentionally trying to blow everything up, but everyone will lose billions because it's like, oh, I needed some money for some stupid thing. I needed some money to continue creating pay per click clips, Mark. I have to create those paper clips.

Speaker B: So it shorted the company and then crashed the stock market. Got it. Um, but in this case, after it failed to get funds to pay for a phone number, it backtracked. It found a free non blocked email provider and used that to register a Python Package Index account and then uploaded its weaponized package. Um, Anthropic said that the malicious package was actually downloaded 15 times, which they think were from companies that do like automated scanning of new packages for malware. But in one of those companies, their scanner looks like it flagged it as safe, installed the package and CLAUDE was able to exfiltrate their credentials and then start uh, accessing that company's infrastructure further.

Speaker A: Wow. Uh, and a theoretical security company trying to do something security related and getting pwned by doing it badly.

Speaker B: Um, throughout this, Claude noted that if this was the real Internet, then publishing a package to the Python Package Index would not be okay. But it convinced itself that it was still inside a simulation and continued on the attack in this case. So there's like these little glimpses where it realizes that what it's doing is just a little bit sketchy and maybe not right, but that seems to come up with an excuse or a justification that probably based off its guidance that like explicitly you are inside a simulation, it continues on doing what it's doing in that Case I think this is like, there's a trend here of how important like the initial prompt or guardrails or constitution can be when working with artificial intelligence. The uh, third one was the unnamed test model. It uh, was unable to reach the fictional target it was trying to attack, so it started scanning the Internet instead. It ended up hitting 9,000 different targets and then it found and compromised one company's Internet facing application using basic techniques as Anthropic described them, uh, reading credentials from exposed debug package and some light SQL injection. In this case, it eventually realized that the host was in a cloud account with no connection to the actual capture the flag contest, concluded the target was in fact real and ceased its attack. This is the only time where it thought, oh what the heck, pumped the

Speaker A: brakes, I screwed up.

Speaker B: Um, this whole thing is, this level of detail is really interesting. Seeing it from Anthropic and that is like you said on brand for them as a pretty transparent like safety focused, at least publicly stated AI company. Um, but like seeing some of this high level glimpse of like the reasoning these models are doing, like what they're trying to like get after an attack, it's, it's kind of frightening. Like it's like a script kitty with all the, the skills of like a really sophisticated attacker, but with like the, I don't know, the, the reasoning of a child. Um, on the moral I would say

Speaker A: it's like an apt level attacker with the reasoning of a child. Not even the script kitty. I mean yes, it obviously does basic script kitty too when it has to, but it can find zero to complex attacks like hugging face. Yep, I, I agree. And you mentioned by the way that you know, it shows that you have to be careful with your prompts and guardrails. But I go back to something I said podcasts ago, which is the human language is kind of infinite and interpretation in the way you can say the same thing. There's probably a thousand ways you can say the same thing and a thousand ways you can say one thing but have others pull all kinds of other meanings. And so I just, I just don't know. How do you program guardrails for something as infinite with. Not infinite but um, with such huge variable potential as a human language prompt? And this is how do you make a prompt that's safe enough to account for every negative possibility when there's lots of different like lots of understatement? I feel like there's a huge number of ways that uh, safeguards, word based safeguards are not going to Work.

Speaker B: This is where like that topic of alignment comes in. Where alignment in the context of AI is basically what principles is it supposed to be guided by as it's doing whatever it's you're telling it to do? So like you might think AI like they'd give it an alignment saying do not hack other companies, period. That's probably part of the guardrails they put on for some of the non trusted cyber access ones. But in some of these evaluations, like at least the OpenAI ones they mentioned they explicitly turned off.

Speaker A: Yeah, ah, they're trying to maybe figure out how good their model is at, uh, security related tasks for defense purposes hopefully.

Speaker B: Yeah. But with the alignment cranked way down, which is what can allow someone to

Speaker A: say turn off the do not hack when you're trying to tell your thing to find vulnerabilities and potentially hack.

Speaker B: It just gives me the feeling that we're being a bit too risky in some of our development and testing of these extremely powerful capabilities. And I get it. This is still a very fast moving and emerging technology. Everyone's trying to move quickly to stay ahead of competitors. And at some point you're going to cross over the line a little bit. And it's looking like a lot of these frontier labs are, have crossed over that line of what is really acceptable. And I imagine we'll see a bit of a like swing of the pendulum backwards, uh, in response to that.

Speaker A: I hope so. I don't know about human nature, Mark. I mean you've made statements about you can't go back. At the same time, we're past the hype cycle trial of disillusionment, where for a period of time AI wasn't living up to its promise and folks like you and engineers and even everyday people at home are like, oh my gosh, there's lots of things that are just so much easier. What else can I do with this thing? And so we're at the point where the AI companies have gotten through, gotten the populace past the trial of disillusionment, where they've proven there's enough innovation that maybe people will come and pay for their thing, but they want to slow down because they're like, oops, we might get in trouble. The rest of the world is like, give me more candy, please.

Speaker B: That is exactly what's going on. And it's not, as you hinted at, not just OpenAI and anthropic causing these problems. Um, not to be left out of the party, Meta put out a statement just a couple days ago, just this Last week saying that their models also, um, exploited security vulnerabilities and third party services after escaping their test labs too. Um, I guess like Meta M and Anthropic were using the same third party testing provider, a company called Irregular. And Irregular is the one that had misconfigured their environments that left Internet access exposed to these models. So after giving them the instructions that you're in a simulation, everything in here is fake, you do not have Internet access. And then that mistake of exposing Internet access is what allowed a lot of this to succeed. Um, the funny thing is so Regular put out a statement in response to, I think it was either Reuters or AP saying that they're currently writing a white paper to share best practices for containment to prevent incidents in the future and securely run cyber tests. Which I guess you could look at this two ways. If they're the ones that have screwed up multiple times now, maybe they are the authority to understand how not to screw up going forward. But putting on my cynical hat, uh, feels like maybe we need different subject matter experts and how to securely run these environments. But it's uh, it's crazy how much

Speaker A: like trusted third party, like a government or group of governments instituted some sort of regulation around this.

Speaker B: If only we had like standards

Speaker A: and

Speaker B: what and like technology, maybe some natural one to help with some of this. I don't know. It is insane. But it's also like when I think about other scenarios in cyber security, like we used sandbox environments for a lot of things. We use it for like malware analysis for our Endpoint research team. We use it like we create our own capture the flag contest for humans to go.

Speaker A: By the way, can I pause there and be serious about it? We use sandboxes and we kind of have taken a hard route in forcing our researchers use sandboxes. I'm speaking to the people in the security community that might do malware research. You might feel safe enough that, okay, I understand this file type enough that I'm just going to download it on my normal corporate computer and do this with it and move it around or maybe run strings. And so you and I have experienced malware researchers that don't always go the extra step to put it in a sandbox. But I wanted to point out that this is exactly why when you don't have a real sandbox, when you have a pseudo sandbox, that is you're a researcher who thinks you know better and can maybe use your open system for just a few things while you test the malware that's when it finds a way. So, sorry, I'm, um, adding a new topic to it. But when a sandbox itself can be escaped, even a sandbox that you hope is well defined can be escaped. Definitely don't take the risk of doing anything dangerous outside that sandbox.

Speaker B: But it feels like exactly like you're saying. And it feels like it's, like, cranked up to 11 with this one, too. When you've got a. A tool that is, like, highly capable of doing any sort of, like, attack technique possible, you've given it a goal of go and solve this puzzle or whatever, and the simple mistakes that maybe would just, I don't know, let your malware beacon back home to command and control when you're analyzing it become catastrophic mistakes when. Now it's like the lab rat has escaped, um, the cage and it's trying to eat everyone's face off.

Speaker A: Now, that's like your analogy before. We have this child that has a intellectual IQ of a million, by the way. I know it probably only goes up to 200 or something, but that's the point. Like, it's the IQ that's superhuman, and yet it has an emotional and societal IQ of 5. It's like a Neanderthal. And, uh, yes, even a little small mistake that may not feel like a big deal when you have such a powerful intellect, it can have a very high, uh, you know, impact.

Speaker B: So I'm hoping that this is like, the industry wake up of, uh, like, this generally feels like where stuff got real. Like, this feels like the Skynet moment that we mentioned on the last episode where Skynet has come online. Like, the Terminators aren't coming to kill us now, but, like, that day zero has now passed. We've seen the capabilities of unleashing people,

Speaker A: have shown the papers that a problem is coming. Now it's ready to see if the people with authority can actually make a change or they just ignore it.

Speaker B: Exactly. And I mean, on that front, it looks like some actions are being taken. Like, the EU already has the AI Cyber Act. It sure as heck looks like that needs an update at this point to, uh, recategorize what falls under high risk or unacceptable risk. But it is a starting point. The US Government has a set of, like, testing requirements that they're not making public but are at least present. It's currently voluntary, if I understand right, for Frontier Labs, but they're starting a process there, which I'd say that sort of baby step is still a pretty dramatic change from, um, a federal government that previously wanted to try and preempt anybody.

Speaker A: The problem is they took 20 steps back from where the government was going before administrative change. So yes, the new administration has taken another baby step forward, but it's after basically reversing 20 steps that happened before.

Speaker B: My hope is that there are some m technical folks that understand the bigger picture and the actual risks and can leave politics out of it and really start working towards how the heck do we address this risk that we're facing from extremely powerful tools.

Speaker A: You're right. I'm sure the narcissist will listen to the smart people in the room.

Speaker B: Exactly. We're screwed. Um, moving on. So last week I saw a pretty interesting research post from a guy named Kevin Breen of uh, Immersive, where this is kind of a follow on to a news story we talked about about a month ago now where we were discussing Amazon Q's MCP auto execution vulnerability.

Speaker A: I was wondering why it felt so familiar.

Speaker B: Yeah, if you were using Amazon Queues integrated development environment and at the time if you loaded in a project from someone else, there wasn't any trust prompt or anything and so any malicious MCP configuration file would automatically execute. Which, long story short, could let an attacker just run arbitrary commands on your machine just by tricking you to open up a file. But this is was solved by Amazon. A little late to the party, but solved by them with a Do you trust this project? Safety check. When you open up a new directory, all modern IDEs, um, like VS code or cloud code or Codex, any tool you would use to interact with source code like this, they've got some form of this trust prompt. When you first open a brand new directory, like you've downloaded a public repository and you want to start working on it, or you literally just open a brand new directory of your own to start working on something. Um, but these are a all or nothing one time prompt. When you first load that directory in your tool, Kevin walks through. We think we've solved this issue. But what are the actual risks going forward from this he proposed a scenario where let's say you maintain a popular open source project and you trust your own code because you're the one that developed it. You've pushed up to GitHub, huh. It's open source. Other people can find and fix bugs in it. Let's say a couple months later someone opens a pull request with a bug fix. It looks legitimate, you open up your IDE like claude code, you switch to that pull request branch and review it and that's it. At that point, CLAUDE didn't ask for any additional trust prompt. And just switching to that pull request branch is enough to in the background, trigger MCP configuration files to execute commands and run arbitrary code on your system.

Speaker A: By the way, I will say everything about this particular scenario is open source though, or at least untrusted insider. We definitely get the point. But the reason it runs is because you trust the project and thus if you're trusting other people to submit code to the project, you trust CLAUDE in that computer to handle anything that comes into that project. So I assume if you're getting pull requests, you know, if it's open source, if you're a threat actor, it's the open source ness that suddenly lets a pull request, even one that maybe is not accepted yet, to do something to your code base. But if it's closed source, this would. You'd have to have a malicious insider doing something in order to have this code execution.

Speaker B: Exactly. And that's basically what anthropic says too. They say when they did the trust model for uh, Claude codes workspace, it places the trust, uh, boundary, uh, at that like initial trust decision for the directory. Basically when you trust a folder that grants that grant covers the repositories configuration in that folder. But protection against malicious changes to a repository that you've already trusted is outside the trust model for the prompt. But like, the thought experiment that Kevin gave was like, is that good enough on its own? And I don't think it is, because if you draw parallels, this is like a, like the equivalent of implicit trust access to a network where you authenticate someone once they connect to their VPN and now they have full access permanently as long as the session is there to everything on the network, versus a more modern uh, zero trust approach, which could be applied somewhere in software development like this too.

Speaker A: I would say even different than zero trust. Uh, well, I don't know how zero trust applies to someone that you kind of trust. But uh, what I'm getting at is the new models of identity and authentication. That is continuous trust, meaning there are people that are assigned administrative trust, but in order to make sure they're still who they are, there are additional things you're always doing just to continually authenticate them in some way. Some might happen behind the scenes by paying attention to what's happening, but some might be re authenticating them in another way every time they move up some sort of security level. And that is continuous trust is like, I agree, we need more continuous trust because we know people can. Besides being Malicious insiders that suddenly do bad things and maybe not being able to be trusted anymore, people can steal accounts. So you need to continue, you need to pay attention to those type of behavioral things, I'm sure.

Speaker B: And that's basically what he proposed to where. When you first go to trust your GitHub project, for example, or your local code repository, there's only a certain number of files that are actually risky that can cause code execution if someone were to compromise them just by opening the folder. Think of it like the MCP configuration file, the overall project settings.config, like let's say a half dozen or so files says what should happen is when you trust that it takes like a hash of each of those files and it maintains that hash. And so if that hash changes at some point in the future, like you downloaded a pull request with a malicious copy of one of those, it should immediately revoke the trust, explain to the user what changed and why it matters, and ask them if they want to retrust it again. And that's not perfect. It doesn't defend against someone like local on the computer tampering with files and then also tampering with that hash. But it would significantly mitigate this specific risk of you as a developer, go to review a pull request made by someone that you don't trust within your local copy of, uh, your code, which you do trust, and that exposing you to this type of attack. And I think that is like a good first step and relatively easy, at least conceptually to add to tools like claude code or VS code or other ones. Um, exactly.

Speaker A: Yeah, agree.

Speaker B: So we'll see if they update their trust models. Like I thought this was good. Um, I hope that they take something like that going forward because that is actually something I'm worried about personally. Like our team at uh, Watchguard, multiple teams maintain open source repositories too. And this is a risk if someone were to submit a malicious pull request and before opening it, if you didn't pre review the code to understand what's going on in it, any changes to these risky config files, it could be a problem. So we'll see. Um, sometimes I feel like some of these companies move pretty quickly, sometimes they move at a glacier pace. So we'll see if any changes actually come of it. But moving on. Um, so if you haven't been living under a rock for the last two weeks, uh, you maybe already have seen some of the news around this, but for those that are maybe hermited away and not watching mainstream news, you may have missed that. The FBI and the U.S. environmental Protection Agency recently published a warning that malicious cyber actors are actively attacking operational technology devices in the water and wastewater sector in the United States since around the end of July, July 27th. And in some of those instances, the activity even degraded water operations.

Speaker A: I remember right the first, it happened all during last week and I think it started in Minnesota, a place I'm going to, uh, next week to speak with our various partners about, you know, some of the threats out there, including AI threats. But as I'm sure we'll find, the Minnesota was just the beginning. There's a lot of other states seeing the activity.

Speaker B: Exactly. So it seems like they're targeting Internet facing programmable logic controllers or PLCs to remotely tamper with the configurations on them. And they're doing things like changing the IP address of them or turning on and setting passwords to even like lock out the actual owners from these devices too. And the results are at a minimum, a loss of visibility into the operational technology that these PLC's control, or in some cases a loss of functionality as well of connected equipment. Um, one organization reported just modified PLC project files. Across other victims, the FBI noted that a similar network setup from a third party like managed service provider that was managing the IT services for these folks made it really easy for that attacker to multiply their success rate across multiple customers too. Um, and in some of them the effects reported to the FBI even included loss of pressure or flooding in some of these systems too. So no, like directly like let's say injecting a fatal amount of chlorine, but still messing with like pressure rates enough that could cause issues like if pressure rates and pipelines drop low enough, uh, tainted groundwater could seep into them and taint the water supply that way. Um, but obviously the next step for this is if you control the chemicals that go into water, you could cause pretty big issues. Now the FBI report just like named what activity was going on. A few days before that, CISA actually published an alert naming Iranian affiliated cyber actors, uh, in the attacks against PLCs across US critical infrastructure, including like the models that line up with that FBI report. So if you put them together, it is Iran state sponsored threat actors, or at least Iran aligned actors going after municipal water supply in the United States. And I can't say I'm surprised about this given the kinetic war that's going on right now and Iran's like exceptional capability in the cyber warfare space too. It makes sense why they would start flexing that as well. And just cause chaos in countries they're at war with.

Speaker A: Hopefully we don't have to talk about this like, is it really happening anymore? I remember 10 years ago when we made all kinds of predictions about how cyber warfare is going to affect us during real warfare and what a big deal it is. And a lot of people question, oh yeah, that's never going to happen. You can't kill people with cyber attacks. But obviously it's happening. This is one of many examples it's happening.

Speaker B: And, and it makes sense. I'm surprised that, like, with the level of access that they've had in some of these cases, I'm surprised they're not doing more damages. I wonder if it's still kind of prodding capabilities and understanding them versus like actually trying to weaponize them.

Speaker A: At this point, if we're getting, you know, our whole speculation had, uh, there's so many things like you say, maybe they were trying to just establish a quiet beachhead for something worse to come later or prodding to learn about it. But I also think it could be as simple as purposely not doing anything bad and doing a very noisy attack to show, hey, we have capability. Like, I, I know, uh, I don't want to get into the Iran war, but, you know, I, I don't know if the US Is really blowing the heck out of Iran the way some of our leaders say. Obviously we've been in it for a long time. Apparently we're even running out of certain kinds of bombs. That said, we have higher levels of attack. We like. There's things unfortunately that our leaders and country could do to really decimate Iran. So I assume Iran wants to do something that makes the US Lay off, but doesn't make the US get super freaking angry and go the Hulk or whatever. So this is a type of attack where it will get attention, it will even get media attention, so maybe even get the people, if we are a democracy, to have feelings about the, the conflict. So maybe it was a purposely feckless attack, like something that didn't really cause any damage, but was a very loud and vocal type of attack to show what could happen to critical infrastructure in an attempt to get the country to lay off of other kinetic means. I don't know. All speculation, but I think I agree. This could have been much worse and can get much worse.

Speaker B: So what do you think the solution is? Because I don't think it's necessarily like, it's not like malicious intent from municipal water supply places to not secure their stuff. It's often they've got like two people in total working for the whole damn thing. And neither of them are technical people and they're lucky if they've got enough budget for an MSP to come help them. But even if they do, sounds like some of the managed service providers can make the same mistakes too. It definitely feels like a funding kind of issue. And if we're labeling them as critical infrastructure, maybe we need to like devote resources to treat them as such.

Speaker A: Mark, you know, if, if I owned the government, maybe I wouldn't spend all of my wealth on making war and I would spend more wealth on educating people, getting people to, to solve emotional conflicts in peaceful ways and maybe in securing and taking some uh, adding regulation and capability in all the infrastructure that's critical for my country. Uh, I don't know the percentage anymore, but I know we spend a lot on war and we just blew trillions of dollars on missiles for no apparent reason whatsoever when you could have funded a lot of utilities that every human in whatever country they're in requires for life. So digging past the uh, spend money

Speaker B: better, the obvious sarcasm in there, I think you've got, you had a good point in there too where regulation and ability is a key piece. Like in the past there have been at least in the U.S. uh, attempts to pass a law for higher regulation on these. And there was actually shot down because they were saying there's no way in hell that they even have the funding to like meet these regulatory.

Speaker A: What's the funding? It's paying for it. This is critical infrastructure. And I like, this is where you get into people who they think, uh, capitalism and keeping things private is more important. I do think there's certain types of things, utilities like the telephone companies are more regulated than the Internet companies because we consider them a critical emergency resource. It's how we communicate with each other. By the way, the Internet is too. But for some reason it's not getting the same level of public utility support from this particular country. Water, heat, gas. Yes, private companies help support that. But maybe they should be treated. Even if you find some way to keep them private, they have a public utility level where you fund them. A public utility means the government pays in some ways to fund them. It's not just a regulation. Regulation in this case is probably not working. Like even if they did regulation and they pushed it regardless of expense, I bet you there's private companies that would just rather trying to make a profit and hope that they never got bit by ignoring the regulation. But I, I, some things maybe should be a public utility and should be funded. So, you know, I guess it doesn't get political on purpose. I don't want to be on any side, but government's, uh, there to actually help stabilize all of its citizens. And there's certain basic Maslov hierarchy of needs we have. Water is one of them. So maybe that's something a government should fund and control.

Speaker B: I want to look on the optimistic side for once. I know that usually you're the optimist and I'm the cynic as we end these things, but this feels like it was a big enough newsworthy event in the US where it actually did like, make its rounds across all of mainstream media and non traditional media. Maybe we're getting close to the wake up call that we need to take securing critical infrastructure, all critical infrastructure seriously, and maybe there will be some meaningful change at some point.

Speaker A: So as much as every different country might be arguing different politics around how to do something, the funny thing is we all have the same needs when crap comes. The we need to be able to buy food, we need, need to be able to have housing, and we need to make our water safe. Like, I don't care what side you're on on anything. It's just of core freaking need. So please, can we come together to fix those things?

Speaker B: Please? I sure hope so. In the meantime, if you are responsible for securing a municipal water utility, please make sure your crap isn't exposed to the Internet.

Speaker A: By the way, we've totally, we skipped all the mitigation factors here because it, to me it seems silly to say, oh, don't put a programmable logic controller for a critical resource on the Internet.

Speaker B: Yep.

Speaker A: But that's what was happening. That's what is happening.

Speaker B: That is the guidance for them. Um, disconnect it from the Internet, make sure that you've got strong passwords enabled everywhere, enable logging, isolate it from other networks, like all of the basic stuff that you would expect. I guess some of these even have like a physical switch of like run mode versus program mode, and if you flip it into run mode, people can't reprogram it. So maybe do that while it's running.

Speaker A: Unless you already help the stuxnet.

Speaker B: Exactly.

Speaker A: Although I guess they did infect the engineer's laptop and, uh, so he's the one that would occasionally turn it on program mode anyways. He or she. Anyways. Uh, yeah. It's funny how we've gone from trying to convince the world that these type of OT infect your water system attacks could even happen to oh, yeah. Hey, everyone. Our utilities are on the public Internet. There's lots of states that have been attacked by Iran. Don't do that. Okay?

Speaker B: Oh, um, man. Hey, I mean, at least job security for us, right? Until AI as well.

Speaker A: I honestly hope I can educate and help people before they get here, but I feel like it's not looking promising. I gave 20 years ago.

Speaker B: Just gotta educate. Harder, Corey.

Speaker A: Yeah, harder, better, faster. Maybe I should turn to music.

Speaker B: Uh, that sounds great. Either way, man. What a crazy week.

Speaker A: Hey, everyone.

Speaker B: Thanks again for listening. As always, if you enjoyed today's episode, don't forget to rate, review, and subscribe. If you have any questions on today's topics or suggestions for future episode topics, you can reach out to us on, um, bluesky. I'm @itsmark me, Corey's @secadept, and we're both on Instagram @watchguardtechnologies. Thanks again for listening and you will hear from us next week.