How to implement Zero Trust in OT environments?

Klaus Mochalski

Hello and welcome to a new episode of OT Security Made Simple. I'm Klaus Mochalski, founder of Rhebo. My guest today is Stefan Sebastian. Stefan has been on this show before, and he also has worked for Rhebo, for quite some time [Aug 2016 – Oct 2018]. This was already some time ago. In our previous episode, we talked about Zero Trust. And we got a lot of positive feedback on this show and a lot of questions regarding Zero Trust and how it can be deployed in critical infrastructures and OT environments. And today, we want to be a little more specific. How can Zero Trust help in specific OT security scenarios? But before we get into this, maybe a quick introduction for the people that missed our first episode with you, Stefan.

Stefan Sebastian

Great to be here, Klaus. Yeah. My name is Stefan Sebastian. I'm the Director of Product Management at a company called Zscaler. We specialize in Zero Trust, and hopefully we can talk about some of those principles, generally, not necessarily specific to Zscaler, but some of those principles, generally, and how they can maybe help some of your audience.

Klaus Mochalski

Yeah, absolutely. Before we dive into how we can protect specific OT environments, Maybe as a reminder to our listeners, can you outline very briefly what Zero Trust means and what are the core principles of Zero Trust?

Stefan Sebastian

Yeah. It's important to state that because Zero Trust is a bit of a buzzword bingo of what people are now taking as principles. But there is something really established. There's a NIST standard, 800-53, that establishes what these core principles of Zero Trust are. People have taken those and genericized them and turned it into a lot of noise. Some have taken it for even corporate marketing reasons, all the wrong reasons. And maybe sometimes as general guidelines, so maybe the right reasons that they're misapplied.

But they're certainly core principles. One of the first core principle is that the endpoints that are initiating the connections have to be authenticated. It's basically, I want to know that Klaus and Stefan on their machines are who they say they are. Challenge and identify those endpoints.

What varies, of course, is that you have endpoints that are headed, human-driven, and then you have endpoints that are headless. There are different ways of challenging and identifying what those endpoints actually are. But what remains one of the core principles, is that you can't just have these unidentified endpoints connecting willy-nilly.

Then there's a method of connecting. The first principle is authentication. Then there's the method of connecting that the endpoint initiates the connection. The endpoint initiates a connection to something that is a distributed multi-tenant architecture. Basically, the authenticated endpoint initiates a connection to something that's always available. This is where the architecture design comes in. I don't get into specifics of how we do it versus somebody else, but clearly, a Zero Trust architecture is no good if it doesn't allow you to do your business. It has to be available there.

Then there's a series of things that happen at that point:

1. Connecting the app to a network.

2. In that connection, you're verifying the identity.  

3. Then you're inspecting the communication of that,

4. And then – depending on the communication, the endpoint and all the factors that you see – allowing the connection to go through to the endpoint.

That's the general gist of Zero Trust.

I didn't want to get into too much detail. But that is the core operating principles. If you don't have those principles, then you're probably not Zero Trust. As I said, there's vendors that talk specifics about things, but connecting authenticated users to locations and making sure that those connections are actively monitored, that's Zero Trust.

Klaus Mochalski

Okay. Now, that's probably a good summary to set the stage. Before we dive into a specific OT security scenario, I have a question with regard to the market that you're seeing. Zero Trust, you said it yourself, has become a bit of a hype. And I assume there's lots of activity in the market as well. Where does this activity come from? Do you see lots of demand coming from the OT sector? And where specifically does it come from? Or is this still a small market segment relative to the entire Zero Trust market that you see out there?

Stefan Sebastian

Well, relative to the entire market, I would say that OT is developing. OT is growing. There's significant participation there. There is probably more on the IT side. I mean, that's where a lot of the value of the attacks are. Destroying a substation is less interesting than taking data. When you think of what the bad folks are doing, they're doing it for economic gain.

It's like, can you attack a substation? Yes. Is there a source of intellectual property or some data that you can take there, or can you ransom that substation? Those are definitely in play, but they're probably more in play in the IT world.

What we're seeing is that the IT world connecting to the OT world, that intersection, wants to be protected by Zero Trust. Then there's the question of how deep do you go down in the OT world? But that's really where we're seeing it. So decidedly coming from the IT side, where it's activating. And it's at that bridge. That bridge itself wants to be Zero Trust. That is where we're seeing the penetration.

That might be because where we're coming from that space, But I suspect it's because this is where the pain, this is where the advantage is for attackers is.  

One of the ultimate goals – and why it's used on the bridge of OT – is that if you can't find your targets, then you can't [attack]. OT has survived by not being found, not having that connection to the IT world. But now it is. Then the question becomes, how do we protect it? And what's the priority of that protection versus IT-based data assets that describe corporate plans and designs?

Klaus Mochalski

This is actually nicely supported by our empirical evidence that we collect from customers where threats are coming from. There are still a very low number of targeted OT threats – threats or cyberattacks targeted specifically at OT assets. But what we are seeing quite often is, and what's the usual cases, that attackers are targeting the IT infrastructure and then using the interconnection, which may be poorly managed through network segment and firewalls so that you can have spillovers of security incidents from the IT to the OT. So, securing your IT infrastructure, as you explained, including with methods or concepts like Zero Trust, also helps securing the OT infrastructure.

But for today's show, we also wanted to explain to our listeners how a use case in a specific OT environment could look like. We [Rhebo] sell a lot in the energy sector, to energy infrastructures, and you already mentioned digital substations. We could also talk about industrial manufacturing environment, but let's look at the digital substation at a smart grid provider, let's say. These substations stations are not isolated or they're not as isolated as they used to be in the past anymore.

So, in the substation, you have digital elements, you have controllers, you may have PLCs. Sometimes you have maintenance people coming in, connecting their laptop to the machines, communicating to the local environment for maintenance purpose, for software updates, potentially also connecting to the outside world or to the other part of the corporate network. So how could Zero Trust help secure such an environment?

Stefan Sebastian

Right. What you say are multiple different levels. I don't want to get into the produce stack and what those levels are. But basically, you have the substation itself and the technology elements that are talking to each other, controllers to sensors to PLCs, whatever. This is where the jobs get done and that communication. Then there is, you mentioned this, the maintenance guy who comes into the substation maybe or nearby the substation and wants to talk to that controller.

Most of the operations on the PLCs and that are maybe ladder logic or something that they actually program in, or they're doing actual physical wiring. But basically, there are the controllers with the systems, there's the maintenance to the controllers, and then there is maintenance or remote users into the controllers, or maybe remote users into something like a jump box. Those are the elements, those bridge elements, those connectivity elements are where Zero Trust can really be advantageous.

The best is to probably think of it as a bit of an analogy here where you come into… If you're visiting the corporate office of Zscaler and you're Klaus, and I'm somewhere in the office, or you need to get to a station, you come in, you go to the front desk, and you check in and say: “Hi, I'm Klaus. I'm here to visit Stefan.” They don't send you through the doors and say: “Thanks for waving at us through the way.” They say: “Okay, do you have ID? We're going to give you a badge.” That is the authentication part of Zero Trust.

Then they don't just let you on your way. I mean, they could. But what Zero Trust wants to do is it wants to say: “Klaus, you're here. Now that I established that you're Klaus, you're here to see Stefan, and Stefan's in this particular office. So I'm going to walk you to that office. I'm going to look at everything that you do, the buttons that you press on the elevators, the knob that you turn to actually get into the office.” And that's the inspection of the communication. That's just an analogy.

Ultimately, Klaus ends up in the office with Stefan. And only that! You don't know any of the other offices along the way. You're just escorted. You're authenticated through the door, you're escorted to the office, and you only see that office. So you can't attack any of the other offices, you can't open up any other doors. And that's an important way of viewing that first, these Zero Trust elements like Zscaler are these brokers that broker that connection. Do the authentication, do the validation, make sure that Klaus gets to the office and look at what Klaus is doing at all steps there.

When you apply that to digital substations, your laptops are essentially the Klaus walking into the office. Who's on that laptop? Is that laptop known? It doesn't have the latest patches. Then that establishes a risk footprint. It connects to the broker, so not to the controller directly. Then the Zero Trust broker says: “Okay, that laptop with that user has this risk level, and it can connect to these controllers.” If it had a different risk level, then maybe it couldn't connect to that controller, maybe it couldn't connect to any controller.

That way you could grant permission to your maintenance tech to actually access that controller. When I come in right beside that same guy, I may look very similar, but different enough that I say: “I don't even have access. I can't even see that controller to even attack it.” And of course, you can't attack what you can't see. And these are some of the core ways that you can secure that connection.

And then the rest is largely us saying: “Well, how do you do that? Do you need some local broker? Can you go through a cloud? Where are you situated? Are you right beside the device or are you half a world away from the device – and do you have to be available in those cases?” A lot of those principles that I led up with, that's basically how the analogy then applies to what it is that you're doing.

Klaus Mochalski

There's some items I wanted to go into. I understand the principle, and the question for me now is, how does the technical implementation in a scenario like an additional substation potentially look like? If we focus on the maintenance laptop coming in and accessing the network and then requiring authentication: Would there be an agent on the laptop initiating the connection?

Stefan Sebastian

Yeah.

Klaus Mochalski

Question one. And question two, I understand there needs to be a service that you can talk to where you establish the level of trust that you require, which enables or disables the connectivity or the communication that you want to start in this environment.

Stefan Sebastian

Yes. One of the easiest ways to explain is starting from an agent. Everybody knows that they can have, say, a Windows machine and they can run an agent there. That agent will do some of the things that I talked about. We'll be able to first look at all the communication, challenge the user with multifactor authentication. When you join that machine, you sign in, you activate the agent, and you don't have any connectivity – or this can be a rule for you: you don't have any connectivity until you prove who you are. There's an agent on your phone, potentially, to authenticate, to provide the multifactor authentication.

This would tie into your Okta [provider of identity and access management software] or Duo [Single-Sign-In solution] or whatever type of IDC [Internet-domain controller] systems that you have today, and offer that challenge. Once that token is granted – once you've proven who you are – that token is put onto your machine and that agent is enabling the connection.

That agent would also do things. Like if you have encrypted communications, to be able to have the certificate where that communication can be encrypted and decrypted. So, all the elements of what you're communicating to that controller are seen in the clear.

The agent can do a lot and does a lot. And it's one of the richest ways to provide that basic form of connection and then the monitoring. The monitoring, though, happens in a level in the cloud, but in kind of this interim level.

The important aspect is the endpoint always initiates connections to the outbound world. It’s one of the key weaknesses of IP that everybody can connect to everybody. The whole promise of IP is that broad connectivity, but that's also its weakness, of course, because everybody can move laterally. But in the Zero Trust world, you only need those agents to initiate the outbound connection. There's no Stefan connecting directly to Klaus. There's only Stefan connecting one way, and that's to that middle tier that is the Zero Trust element that does provide those inspection, that does apply the policy. The endpoint agent is there to make sure all connections go outbound and that there's authentication. We've seen the XP machine has these updates or doesn't. We've seen that the user is who they're or, they're not.

But the rest of the magic then happens in the brokering layer that actually walks Klaus to the office, that walks the connection to the controller – or doesn't. Now, once you get to that broker level, it says: “Well, what controllers can you actually access and process, considering who you are and what your current posture actually looks like?”

Klaus Mochalski

If I understand the concept correctly, the agent would require an outbound connection to this broker element. This would require connectivity to an element outside of the substation, be it in the corporate network or even the cloud. Is this correct?

Stefan Sebastian

That's the default approach. Usually, it's in the cloud. It can be in a centralized security stack, but it also can be local to the substation. If you have a way of deploying that broker, it can be local to it. Especially in the substation environments, you often don't get something that can support [cloud connection] directly. But all those are possible.

The principle is the same, though – however you do it. Some vendors may not offer all these different configurations, but the principle is the same. There's the element that makes it easy to challenge the user and to monitor the posture of the endpoint, ensuring the connectivity is outbound only, so nothing can come back in or initiated back in, nothing can move laterally. That's the element. Then there's the broker layer that says: “Can Klaus connect to this controller, yes or no?” And which examines those connections on an ongoing basis to make sure Klaus is doing what we expect him to do and only that.

Klaus Mochalski

Now, that's important to understand that this programming process can also, in theory, work locally because today, most often the security of a digital substation or an element like the digital substation relies on very limited connectivity to the outside world. If we now come in and say: “We want to increase your security for your substation, but first we have to open up a channel to the outside world, even to the cloud”, many customers would be skeptical. But to know that this is just one option and the other option would be to run the brokering service locally in a pre-configured way, I think that's an important potential benefit for these types of customers.

Stefan Sebastian

Yeah. I think that we definitely see that there's a voyage of discovery. But some of the reasons why OT was removed from IT was because if they have an IP address, if they can access the public Internet, then the public Internet can access them. That's frightening, right? You don't want anybody, that some kid in a basement somewhere, to be able to connect to that IP address or whatever is exposed publicly to be able to connect to that and attack it.

And that's exactly what Zero Trust does: It removes that visibility. That endpoint, yes, it would have internet connectivity in a very limited sense. It would have internet connectivity to one location and one location only – and that's your Zero Trust provider. And your only connection to the outside world is to your Zero Trust provider. There's nothing else. You have to initiate that connection. There's nothing inbound. There's never any inbound. There's nobody else connecting to you. There's only the connection that you've initiated to the internet to your provider. That means that this substation can no longer be found anymore. It's not on the public internet. It's a brokered connection, which means that Klaus somewhere or Stefan somewhere connects to the same Zero Trust exchange and is able or not able to see that substation.

One of the core reasons that [substation operators] don't have that [cloud] connectivity is thatthey're leery about that connectivity being subject to attack. Well, you're no longer subject to attack because you can't be attacked if you can't be found. You can't be found unless you're authenticated and have the right posture and have the rules, the business rules that allow that particular authenticated endpoint to connect to that particular substation for this particular purpose. That's really the core strength.

That means that there's no more segmentation in this world, or at least traditional segmentation, because it's a policy-based segment. Because the challenge with segmentation is you can't spend enough money to actually do it. And that's why Zero Trust principles are replacing the legacy firewalls. And that's why folks like... Anyway, the big firewall vendors are running scared because they've made a business by selling more stuff and more people focusing on dividing more and more rules that they simply can't spend enough to actually achieve this. And Zero Trust changes that.  

Klaus Mochalski

It's a very interesting approach and very compelling also, especially for these very critical environments. But [most of thema] re still all about network segmentation. That's still the talk of the hour. I think it definitely will take more persuasion for companies of operators of critical infrastructure to seriously look into [Zero Trust].

As a last piece of advice to customers wanting to look into Zero Trust for their OT infrastructures. Do you think that you can start with your OT Security Zero Trust project right away or should you always start in your wider corporate IT infrastructure before moving it to the OT level? Just one sentence here.

Stefan Sebastian

Yeah, great question. The simple answer is, focus on your top use case pains first. This is your most valuable stuff with your most troublesome employees that are connecting to the most valuable stuff. Always focus at the top of the pyramid and and work down. Talk to the value pyramid. It's really easy to focus on just what you need initially and let the rest be the Wild West.

Klaus Mochalski

Yeah, very interesting answer. Like with any technology, the answer always is: Look at your risk and tackle the highest risk, highest consequence problems first. And it's the same here. So that's a very interesting perspective for our listeners. Thank you, Stefan, for this interesting discussion, going into technical details. We can always continue and discuss more. It was very interesting to get this insight with this specific use case. Thank you for being on the show again.

Stefan Sebastian

Always a pleasure, Klaus. Thanks.

Klaus Mochalski

Thank you.

‍