Transcript
of Schneider Electric. Thanks for joining me. Thank you for having me. I'm very excited to be here. So you did a great talk on this subject of kind of just internet facing OT and the security issues that it causes. Before we get into that, just introduce yourself a little bit. Give me a little bit about your day-to-day, your responsibilities. Sure. So I am a director of product cybersecurity in Schneider Electric. Day-to-day, one of my core responsibilities is cybersecurity-focused innovation, which is really what this idea is all about. So that's a primary focus that I'm of mine now. So let's dig into the subject, just internet facing OT. How do you characterize the security state of it? Because I mean, we see a lot of OT assets that are exposed online, a lot of them not very securely. Just kind of how do you characterize just the status quo of everything out there today? We know that there's currently over 145,000 OT assets exposed to the internet today. And governments around the globe view this as a significant security risk. So it's not just a lot of much ado about nothing. Many of those devices are reachable and they have basic login credentials, username and password. While I cannot attempt to log in using default usernames and passwords, I do know from third-hand accounts that some of these at least actually are still using default username and password, and it can be logged into in that manner. So it's not insignificant at all in terms of the risk. And they're fairly easy to enumerate too, correct? It is. I mean, tools like Shodan, Census, Criminal IP, they find these devices and they're easily researched to locate what you're looking for. So the decision to put these assets online, what's driving that? Is it strictly a business case for it? Actually, I think many of these exposures happen by accident. They're not intentional. They're misconfigurations. Secure deployment practices are not followed. Yes, there are cases where somebody is intentionally exposing it to the internet because they want remote access and they don't understand the ramifications of what they've done. And so in terms of the scanning, the tools are available. You mentioned Shodan, Census. How widespread is the scanning? What are you seeing in terms from a threat actor's point of view? How often are they looking for these types of assets? Very widespread. We can expose a device to the internet, which we did as part of our proof of concept. And within 10 minutes, maybe, it's discovered. If not by Shodan, by a malicious actor that are looking for targets to go after, that are using their own scanning tools. So in a Shodan search reveals pretty extensive device information, right? It tells you which ports are open. It might give you banner information. This is such and such vendor, such and such product, model number, et cetera. So it gives you some very good reconnaissance as a starting point to go after these devices. And so do attackers, I guess, what does it say about their capabilities that they're kind of looking for these internet facing devices? I mean, are we talking about basically low tech kind of sophistication in terms of their capabilities? I think there's a range. There are some people that are completely reliant on tools like Shodan and Census, et cetera, to do their initial reconnaissance before they dig in and do some of their own. And they don't do any scanning beyond that. However, criminal organizations, nation states, they'll leverage tools like Shodan and Census, but they will build upon that and do more sophisticated scanning with their own tools that they've developed. And has the scanning changed in terms of, or I should say, the targeting of these scans changed in terms of, are they going after device classes versus specific organizations, for example? I think that they are targeting perhaps devices that are exposed in certain target regions of the world that perhaps they feel they want to make a political statement with, or they believe that there's some criminal opportunity available there that they can take advantage of because they know that perhaps security standards are not followed as completely as they should be in those regions, et cetera. But in terms of targeting devices, certainly in an OT perspective, things like PLCs, any type of things that do control systems, ability management systems, UPSs, all of those are attractive targets. But they first start out trying to find targets such as those, and then they dig in deeper to go after them. Sounds a little more opportunistic than targeted. It can be. Yeah. Okay. So let's talk about internet exposure prevention, which is basically the crux of your discussion this week here at S4. The key, it seems, is to drop unsolicited inbound traffic to these devices. Is that correct? Kind of take me inside what this is all about. So we use the term unsolicited inbound traffic to represent incoming traffic from an internet-routable source IP address that the device did not initiate communications to. So therefore, it just happened out of the blue. It's analogous to how you use your phone. You pick up your phone. You make an outbound call. That call operates smoothly. Hopefully somebody at the other end answers. You have the communication. You terminate the call. But if somebody calls you and they're not on your contact list, you're going to ignore them. Right. Same concept applied here with these devices. And so are there scenarios where the inbound traffic would be legitimate and you wouldn't want to touch it, for example? In terms of inbound traffic from a routable source IP address? Short answer is yes, because in rare cases, some enterprises, especially older ones that were in place before RFC 1918 went into place, which defines private IP address ranges for IPv4, they are using internet-routable IP addresses for their internal networks. So that is a use case that we have to accommodate in this solution. But we do have an approach defined that accommodates those and provides a means for the end user to define what should be allowed in that internet-routable IP without actually circumventing the overall concept of internet exposure prevention, which we really want to have in place as a secure-by-default behavior. So where does this capability live? I'm talking about internet exposure prevention. Does it live on the asset itself, on the network? It's in the device itself. It resides down in the stack. And as a packet is received, down low in the stack, before we process it in any other way, we check that source IP address. If it is a routable source IP address, then we check it to see, did we initiate communications to that in the first place? If we did not, we ignore it. If we did, we allow it through. If it's a private IP address, we allow it through. And I'm just curious, feedback on the capability and in terms of what kind of demand are you meeting for this? Well, we've presented this concept to both the CISA and the ANSSI out of France, and both organizations are very positive, gave us very positive feedback on the concept and interest in seeing it really carried forward. We were told by one that it showed avant-garde thinking, which I really appreciate it. That's a great compliment. And feedback from today's session was also very positive. And so what can you share about what's happening under the covers that kind of masks these devices, so to speak? We went through a lot of thinking and complex ideas and perhaps crazy ideas. We kept chipping away at it, and eventually, we came up with what we believe to be a pretty simple solution that we can implement easily in the devices, and it's simply this, check that incoming source IP address. Is it a private IP address? Yes. Let it through. Is it a private IP address? Yes. Let it through. If it's not, then it's a public routable address. Did we initiate communications to it? If yes, let it through. If not, drop it. It's as simple as that at its core. Now, we have to accommodate the edge case of these internet routable IP addresses being used for internal networks, but we also have solutions identified for that. Are users nervous that their devices might not be reachable if necessary, or any concerns that you guys needed to address in that respect? There are some customers who we believe would be concerned for their existing install base. I think it should not be a problem going forward, really, because in that situation, the networking should accommodate the solution that we've already got put in place, but for existing devices, if we download new firmware to them that has this in there, then it would block those incoming packets. So even today, I ask them, what would you like? And what they prefer is to have us detect an alert, which we can certainly do. We apply the same mechanisms, but rather than ignoring, we detect, alert, log, and make the end user aware that this is happening, and they want the option then to then turn it on and stop that exposure from happening. So we start with detecting and alerting, give them that option to enable it if they see fit, and that seems to make them very comfortable. How much advocacy and what does it look like if you are doing it in terms of making users aware of the risks involved of exposing OT assets the way that they might be? Well, so today, as vendors, as all vendors do, we put a lot of time and effort into documenting how to securely deploy the devices, the dos and the don'ts, and I guarantee we are saying, do not expose this to the internet, yet it is still happening. People are not reading the manual, people are not following the guidance in the manual, and that is not something that we can really fix, so to speak. It doesn't matter how much awareness we raise, people are still going to continue to ignore it to some level. That's why we want to implement this as secure by default behavior in the device, so it's there and prevented at the get-go. Tell me about some of the results you might be seeing. How are you measuring success, for example? What we've done so far is we've done some proof of concepts where we have implemented this idea in a device. We took two identical devices, in one of them we implemented internet exposure prevention, in the other we didn't. Our first proof of concept was we put them behind a firewall and we port forwarded to each of the devices. We monitored the firewall traffic and the logs and captured those and looked at them. We also verified that private internet access addresses continued to work smoothly and were not hindered whatsoever. What we found and proved through the firewall logs is that these devices without internet exposure prevention were found quickly, then continuously hit with scans and different people trying to gain access. Ultimately, those devices ended up in tools like Shodan and Census, etc. While the device with internet exposure prevention, it might be scanned, but no response was sent back. It wasn't discovered, never showed up in any Shodan or Census tool. I'm curious, how many times you walk into an enterprise and they're saying, oh, we don't have anything in securely connected? How much do you have to show them? Yeah, maybe you do. Well, sometimes it can be difficult, but one of the things we can do, though, is if we know that a customer's internet-facing IP address is, we can look at what we've discovered and see if any of their internet IP addresses show up on our list. In fact, that would be a great help because then we could alert them to the risks that they face. But when we do identify a customer and put a name to an IP address and alert them, quite often, they were not aware that this exposure was happening. And they are thankful that we alerted them and either asked us to step in and help them resolve it, or they were able to resolve it themselves. Do you have a sense of why that lack of awareness is still happening? Is it just a matter of maybe non-security folks being involved in these decisions, the engineers not necessarily being aware of the risks? Part of it, I think, today is despite everything that's going on, some people really don't believe it's going to happen to them or they just don't get it in terms of what that risk really is. They don't understand. They're naive, perhaps. I think that's part of it. And again, I think part of it is they don't read the manual. They don't know what they're supposed to be doing because they never read it and educated themselves on the secure deployment practices recommended for the device. I mean, it's kind of the battle we've had in security all along in terms of folks being more reactive than proactive, I would imagine. Correct. And that's why we're trying to be proactive at the device level ourselves rather than being dependent on the human who can make errors, even if they did read the manual. We want to take that human factor out of the equation and have that secure by default behavior in there. It sounds like a lot of this might have been addressed, might be addressed by kind of the secure by default conversation that's happening. I mean, CISA is pushing for a lot of security out of the box and so forth. How big of an issue is that that you're running into in terms of these devices just being insecure out of the box? Well, we and I believe our fellow vendors work to make those products secure out of the box, secure by default out of the box. But this is a new secure by default behavior that we're wanting to implement in those products. And having this secure by default behaviors really helped to set a baseline of security for the end asset owner and operator, because at least it starts it off at a good spot where they're not dealing with exposure from the outset because it's blocking that. But still, we're dependent on having these secure by design, secure by default, secure as deployed and secure by operations. And Schneider Electric has an entire posture paper on secure by operations that's available. And so do your users have an expectation about security by default or security coming out of the box that you're you're running into? What kind of questions are the questions are getting better, I guess, maybe is. Our customers run the gamut. Yeah, some of them are very mature. If you look at depending on especially depending on the segment, perhaps oil and gas for immature data centers, very mature, but others not so much. And they don't know the questions to ask. And we'll still receive many requests for quotes that don't include anything about cybersecurity because they don't know what to ask. And I keep encouraging our customers, you need to ask for it. Sure. If you really want to make sure it's there, you need to ask for it. So in terms of, I mean, the pros and cons point of view, the pros seem obvious. But do you run into objections about something being some security capability being turned on? And, you know, for fear of it impeding a process or something like that? And how do you handle those objections? Well, again, we start out with those security capabilities being turned on by default. However, we do provide mechanisms in some cases for them to be disabled. So, for example, as we migrate to secure protocols in support of, among other things, Cyber Resilience Act, but just in terms of improving the overall security posture of our devices, we have to recognize that there are myriad legacy systems out there that are using insecure or that the legacy protocols, I should say, that we have to have some backwards compatibility for. And we recognize that and we provide those mechanisms for it to be turned off by the customer as required. And in terms of from a regulatory point of view, how involved do you expect governments to get in terms of protecting critical infrastructure, especially from this respect? Well, certainly overall, I think we can look at the European Cyber Resilience Act as a great example, not just focusing on critical infrastructure, though, it's really focusing on cybersecurity of products overall from consumer products through those products using critical infrastructure. But they do separate and classify different types of products and how they're used in terms of what you can self-declare versus what you need to have a third party certify. So I think government will see that more and more from governments around the world. What we really need is to make sure that they are aligned with each other because we can't have conflicting requirements from one government to another. We need to have an aligned otherwise we can't meet. Yeah, there's there's no uniformity at that. Yes. So just kind of wrapping up in terms of, you know. The fact that you guys are doing this is great, but it's an ecosystem problem. I mean, what what would you like to see other vendors kind of come along on this in terms of the ecosystem and protecting the whole thing? Well, certainly I'd like to see other vendors look for a means to provide a similar solution to the Internet exposure prevention problem that can be inherent in their devices, just as we've done with our Internet exposure prevention solution. I would like to make sure that we as a community work together and we have some consortiums that we are working together to try to heighten that awareness. And we come together on the standards like IEC 62443. I think that's a very important standard. It continues to evolve as it needs to to accommodate new and changing environments like AI in the future. So if we can align on those and especially then the government regulations can align on the utilizing a common set of standards for the most part, it'll get us a long way as to being where we need to be. And just as a final thought, just what would you like to see asset owners, asset operators do from this perspective as well as a matter of just more awareness? Well, I think focus on their secure by operation, put the right technology in place. There's growing and better and better offers out there that can be used to detect intrusion, prevent intrusion, assist with the asset management overall. And they just need to leverage those tools and stay current with that, keep their products current and patched, which I know is difficult at times because we don't want to disrupt operations in order to take time to install a patch. But we need to definitely have a regular sequence of patching scheduled by them. And OK, so if we picked up this discussion in a year, what do you imagine some progress to be in terms of either the capability or just kind of the ecosystem? We'll start seeing our Internet exposure prevention implemented in devices. Of course, it won't happen across the board all at once, but we'll start rolling that out. I think that'll go a long ways to that. We will continue to do what we can to heighten awareness, contact customers that are exposing that or have exposed assets that as we can identify them and alert them. But that is a difficult thing to do. So really what we're going to do is focus quite a bit on on promoting secure by operations. And and I think we can make a lot of progress on that. All right, Michael, thank you so much for coming on the podcast. Appreciate it. Great stuff. My pleasure. Thank you very much for having me. Thank you.
