Industrial environments have long counted on isolation to keep them safe, and the people who run them trust whoever is already inside. Shared accounts and standing vendor access still connect operators and contractors to systems that cannot go down. As more of those systems connect to the internet for upgrades and monitoring, one valid login can now reach a physical process.
Emmanuel Poux is CTO at Junto, with 26 years across systems architecture, security, and identity and access management. He worked 19 years in the defense sector as an engineer, architect, program lead, and enterprise architect. He supported the Department of Defense's Mission Partner Environment, helping build and migrate an identity stack that let US combatant commands collaborate securely with international partners. Today he works on identity for AI agents and non-human identities, and on applying zero trust principles in operational technology and critical infrastructure.
This is the full conversation behind an issue of InfoSec Leadership, the newsletter from InfoSec Relations. Hosted by Shant Ebenezer Jena, a volunteer host at InfoSec Relations.
Watch the full conversation below or read the interview.
The transcript below has been lightly edited for clarity.
Take us through your career, and how someone who spent years on identity architecture ended up focused on critical infrastructure.
Poux: So, yeah, I've been in IT now for 26 years. The first seven years were in the commercial sector, working for temporary staffing companies. After that, I got an opportunity to work in the defense sector and spent the next 19 years in various roles in that defense sector.
I was an engineer, an architect. I was a program lead at one point, an enterprise architect, and then that enterprise architect role is what led me into identity as a whole, and then identity on what they call the edge, which are disconnected operations inside of these enterprises that are not connected to the internet.
They control and manage various devices, communication devices, and IT at that point was not really an edge-focused thing, and identity wasn't either. Identity was always the enterprise directory or your Active Directory. But in that silo type of environment is where I got my first experience developing and architecting siloed identity infrastructure platforms, which led me to Junto, and that's what we continue to do here.
So that's how I got into identity as a whole, and then specifically identity in that disconnected OT environment.
Let's talk first about identity where it was not designed to be. Industrial environments run on shared accounts, control room terminals that stay logged in, and standing vendor access. When you walk into one of those environments with an identity background, what is the first thing that stops you?
Poux: Well, the first thing is, I think from their standpoint, everything is safe because they're not really connected to the outside world. And there is a great, I guess, inherent trust when you're in those environments from the operators, from the people who access that type of environment. But from an identity standpoint, when you're talking IT, when we're talking information technology and enterprise, it's the complete opposite in where it was going.
So for me, I was always shocked, but I think what happens is the fact that they're isolated and off the internet gives them a very good sense of security, which does work for the most part. It's not going well as of late. But they've operated in those silos, and even access to these places is very hard to get to, so they rely on that for their security.
So from my standpoint, it was like, well, how about if one of these operators becomes a bad actor, what happens? And there are no safeguards at this point in the industry for that. It's getting a lot better, don't get me wrong, but it's still very much an implicit trust type of environment.
Every identity principle we take for granted assumes you can interrupt someone to authenticate them. In a plant, an operator responding to an alarm has physical consequences waiting. How do you resolve that tension without either weakening the control or endangering the process?
Poux: I think it's a matter of, when it comes to identity, the principles are the same. In a local environment like that, if you do have a system, an ICAM system that can catalog the user devices, all the physical elements of the environment, and make sure they're doing the right thing at the right time with the right credentials, I think it can happen. The problem is when, like with your question, somebody's coming in there and they're responding to something. OT environments cannot have disruption.
The reason why they don't allow technology into those spaces is primarily because they can't go down. Your internet can go down. Your IT infrastructure can go down. You can recover from that. But when we're talking about water and sewage, physical electricity, lights, these operators don't like to introduce things that could potentially bring the system down or lock them out of the system.
They have to be able to log in successfully and deal with an issue without lots of barriers. So it's a tension on both sides. It can't stay the way it is now, where you have shared accounts, long-lived credentials, but at the same time, there has to be a transition to go from that full trust model to more of a zero trust model, which is happening in IT enterprises.
Where does zero trust genuinely hold in an operational technology environment, and where does the principle have to bend?
Poux: So I think, again, if you can have a small type of environment, an ICAM system that can live in that OT environment that does just-in-time provisioning, catalogs all human and non-human devices, and makes sure that it's constantly authenticated, there is no implied trust, the principles stay the same.
Now, where it would differ is that, like in an enterprise environment, some applications have no local identity controls. Everything is done from an external IdP. There is no break glass type of environment in case something happens to a user. So that's where you would have to have the best of both worlds.
You would have to have that local ICAM system, but there has to be a backup to where, if something happens, something gets tripped, then that operator has that break glass identity to get into the system and work with the controllers, the programmable logic controllers, and all the different devices, the HMIs, the DCSs. All those things in the OT environment you need to get access to, and if you have a very strict zero trust model where there's no such thing as a local user account on an application or a device, that becomes problematic.
Segmentation between IT and OT is the most repeated advice in this field, and one of the most commonly failed controls. From an identity perspective, why does it keep failing in practice?
Poux: Because they're doing, again, the isolation. The isolation and implicit trust in that isolation is the problem. So I think zero trust came about when people realized that the traditional model of a DMZ, your LAN, your WAN, that type of segmentation... And, oh, you had a VPN and you were safe, because you had a virtual private network or a VLAN. That's all great, but if you're not monitoring what that device is doing, what that user is doing, what that network flow is doing, then you're going to have issues. It's the same thing, just in the OT environment it's a lot worse.
The enterprise environment, it's completely going towards zero trust, where nothing is trusted. Everything is on a continuous evaluation or trust score to see where that device, user, and all three of those together make up that kind of trust. So you have a trusted workstation with a trusted user, probably using MFA, and a trusted network with the device.
And the nature of OT is just, it's very difficult. You cannot introduce technologies that could hinder the actual operation of that environment. So we're talking utilities, but let's say you're a manufacturer. You don't want your machines going down, because you rely on that plant to produce things. So when you introduce technology, when you introduce these policies like zero trust, it has to be very methodical on how you do that, because you cannot afford downtime.
Some of this equipment has a 20-year service life, no authentication support, and a vendor who no longer exists. How do you build identity controls around something you cannot change?
Poux: I think you can change that, because of the device. You can start at the device level, which is what a lot of people in the OT space are doing, even some of the larger vendors. OT right now, everything is trusted inside of that little segmentation. You can start very easily with just the device.
So think about the... Have you guys heard about the water treatment hack that happened last week? So that one was very strange. That was probably a more modern programming interface that had access to the internet. Somebody was accessing that from the internet. I think it was a Rockwell or something like that. So the problem is, where did the hack take place? That is a very modern controller. That PLC is very modern. So was the actual vendor hacked? Was the vendor potentially doing something, was logged in as that identity, and it was like, "Okay, you're authenticated, you're good to go"?
You would assume there was a firewall there. There was a firewall there. Where did it fail? Because that one is a very complicated thing, but that says everything in a nutshell, where you had this isolated environment with certain pieces of the environment connected to the internet for upgrades or monitoring. And through that interface, the identity obviously checked out, because somebody had to get into the controller to do the hack.
So I think in the end, you can start with the device. At the very bare minimum, you start with the device, the non-human element, because that's what comprises the OT environment, making sure that device is good and the device actually accessing the controller or the human control interface. Just making sure that those two things are authenticated and monitored to be authentic. You start there, and then you branch out from there to the other human interfaces.
What do people get wrong when they carry an IT identity playbook into an industrial environment?
Poux: Well, I think, again, back to my last answer, they try to treat OT like IT, and it's not. We have to separate that. The OT environment needs to be simplified, because when it's something critical, you can't have too many inputs and outputs to troubleshoot.
Because if you do introduce a lot of input and output, a lot of security like you do on the information side or the enterprise side, it can be disastrous. Because then you're not even dealing with the issue. You're dealing with other things that are not allowing you, potentially.
Because any time you make a system more secure, you introduce entropy. Meaning you introduce something that you can't see, potentially, that can come up. And when you do that, it can be disastrous in an OT environment. So I think that's the main mistake, to try to treat it like IT when you can't, because the economy, the world runs on water and electricity.
If you take the modern data center, these things are mini cities. They're kind of like new OT environments. They are connected, but they're little mini cities with their own power, their own water. You can't have those things go bad. So you have to really have a good plan, a methodical plan, that when you're introducing more security into the OT environment, you're not producing a lot of entropy or things that can come up that you can't troubleshoot, and then everybody's power is out while you troubleshoot the IT problems.
You helped build an identity stack so US combatant commands could work with international partners. What is genuinely hard about federating identity across organizations that answer to different authorities and do not fully trust each other?
Poux: Yeah, so they were connected, but they were connected in a limited way. For instance, it was kind of a hub and spoke and spoke-to-spoke type of permission model and architecture, meaning it was just enough permissions to certain pieces of the architecture, whether it be a SharePoint or something like that.
Not full access. It's not like a federated enterprise. So that's the only way it can happen, because yes, there is trust between the partners. That's why you have agreements with your partners. But at the same time, you need to segment and isolate and give them just enough information for them to collaborate with you to do something in a mission.
So a lot of that was ICAM, a lot of that was IdPs and SPs, and of course getting together to figure out... The biggest thing is, what are you sharing? What are you sharing with the other partner? Because it's rarely that you just federate and you have access. It's very limited in those environments what you're sharing, and it's defined in the agreement what you're going to share.
What did that work teach you that applies directly to critical infrastructure operators sharing access with regulators, vendors, and each other?
Poux: It's kind of the same thing. When you think of the mission partner environment, you have an agreement. So you can consider those other countries outside of the US like a vendor. They need access to certain things that potentially helps you and helps them, but nothing more. So the OT environment is exactly like that.
For instance, with this water treatment problem, I'm sure it was the vendor accessing that controller, or somebody remotely accessing that controller. But just because somebody's authenticated doesn't mean that they should have access to certain things, and they should not be allowed to move laterally, which is what you want to make sure never happens. That once that person is authenticated, they move laterally inside of the network. So the same principles apply, because you just change the name. You have a partner that's like a vendor.
The identity questions change when the thing acting can move something physical. What has to be true before an autonomous system gets permission to act on a physical process?
Poux: That really is going to be based on policy. Well, it's happening faster, especially when you're talking about modern-day warfare. You're having AI and stuff like that make decisions. But from an OT perspective, most of these automated systems, whether it's an LLM or some AI system, for the most part, from what I understand and what we're hearing from our customers, it's read-only.
I don't think we're at the point in the OT environment, especially when you're talking about AI potentially affecting an actuator or a sensor. You probably don't want that, in a sense, without some critical check of a human being. Meaning, hey, the automated system caught something via sensor, but then there should be human eyes to say, "Oh, well, good catch. Yes, this is valid. Let's move on."
I don't see that automated piece coming just yet. That's just my opinion. I'm sure a lot is happening, but in my opinion, I don't see that happening just yet.
Non-human identities already outnumber human ones by a very wide margin. In an environment where the consequences are physical, what does that ratio actually demand that most organizations have not yet built?
Poux: Well, I think from an OT perspective, that's not going to happen. From the IT perspective, yes. You have agents, you have all those things. You have non-human identities that outnumber. But in an OT environment, you're not going to have that. You can't have these things living inside without lots of controls on them. So from an OT perspective, not happening right now.
And think about it. From an OT perspective, there are lots of non-human interfaces if you're talking about the sensors, the actuators, the PLCs, the remote terminal units. They're there, but remember, they're very segmented to a machine. Now, where it gets kind of interesting is when you're talking about the distributed control system, which controls the PLCs and can make decisions based on all those other things. That too, those devices, what I was talking about, starting at the device level. At the device level, you should have that zero trust authentication and authorization piece locked down to where all those controls inside of that OT environment cannot do anything without explicit permissions.
And if it is automated, then you have to have a set of human eyes to make sure that it's correct.
From an attacker's point of view, what does an attacker see when they look at the identity layer of an industrial environment that the operator does not see about themselves?
Poux: Well, the attacker, depending on what they're using... The attacker is at a much lower level. So the attacker, number one, would have to have an identity to get into the system. And then in the modern world now, with language models, that attacker can run payloads and see things that the actual operator is not seeing. That attacker can embed themselves into that environment. So the operator never knows what's going on. The attacker is the one who, number one, has to have that identity to log in with. And once that attacker has that identity, they can stay in there for a long time. So the operator may never know.
But identity is 90% of it. Most of these attacks, I think it was Palo Alto, their Unit 42 branch just did, and it's like 90% are all identity-based attacks. Some kind of identity. Because you need an identity, you need a credential to get in.
For a security leader responsible for an industrial environment who knows identity is the weak point, what is the first thing they should do?
Poux: I think, again, you need to do an inventory of all the inputs into your system. Meaning you could start with the machines, and then get rid of shared accounts, just-in-time provisioning to where, if somebody is in that plant, it's with a finite time. You're always cataloging all movements of all these devices at all times to make a policy.
And inside of that policy, if something changes, then you can downgrade the access or the authentication to not allow somebody to move laterally inside of your network. So it comes down to, if you don't know what your inputs and outputs are on the platform, on the network, even if it's isolated, then you're blind.
And nobody knows 100%, no matter what anybody tells you. But if you're in the 99, 98%, your chances of having an attack are rare. But I think things get introduced at a rapid pace for various reasons. And when that happens is when you don't know your inventory. Your configuration management database in the enterprise is what they call it, and OT environments definitely don't have that. And even in IT, that's a very hard thing to do, because IT usually moves at the speed of the business, and those two things don't always align.
What is something you believed about identity early in your career that you no longer believe?
Poux: I would say the siloed model of your DMZ, your internal network, your wide area network. I think a lot of us just felt, hey, we had firewalls, we had segmentation, we had all these barriers, physical barriers to entry, not realizing that it's human nature. I think people are very trusting for the most part.
So you're figuring, hey, if the guy has an identity, he's logged into the VPN, it's got to be good, not understanding, how do you even know that's the guy on the other side? So they introduce multi-factor. But still, how do you know that's the guy on the other side? How about if somebody has access to his house and his token and his password?
So I think that is the biggest shock for the industry as a whole, the zero trust model, to deem the network as always hostile. You have to view the network as hostile and trust no one. Trust and verify, as they say. So I think that's the biggest shock, that, again, humans are very trusting, so we kind of believe that, hey, if somebody has access, they're good, and that's not the realization.
So basically, doubt everything in your path.
Poux: Yeah. That is the tenet of zero trust. The original zero trust philosophy is that you always assume breach, and you always assume that the network is hostile. You have to trust and verify.
Emmanuel, this has been a genuinely useful conversation, and I appreciate you being so direct about where the hard parts actually are. Is there anything you would like to add?
Poux: Yeah, no. Thank you for having me. I think it's always very interesting when people talk about OT, because OT gets slammed a lot. And I don't think it's fair, because it's very critical. And people always think IT is the solution, more IT and more security is the solution, and it's not like that in the real world. It has to be done very methodically and in a very careful way.
Read the full issue drawn from this conversation in the InfoSec Leadership newsletter by InfoSec Relations.