Data Diodes & Remote Access: How Industrial Systems Stay Secure in a Connected World

Aaron Crow: Hey, thank you for joining me on another episode of the PrOTect IT All podcast. I'm super excited today to have the CEO of a company that I've been working with and using products from for a long time. Why don't you introduce yourself, tell us who you are, a little bit about your background, and a little bit about your product and your company as well.

Lior Frenkel: Sure, Aaron. I'm excited to be here. I know your background and I'm happy to be here and share thoughts and discuss. I'm the co-founder and CEO of Waterfall Security, an industrial cybersecurity company focusing on connecting OT and IT in the right way, meaning protecting the OT while allowing good connectivity to IT.

Our company started with technology called unidirectional security gateways, enabling sharing data from closed OT networks to the outside world, mainly for monitoring, for sharing production information, enabling data sharing to the cloud, to third parties, and so on. This is where we started. Back in the days, we focused on more of the regulated part of the market, selling to nuclear power generation and power generation in general, and spread out from there dramatically to practically every type of critical infrastructure and industrial vertical across the globe.

This was our flagship product and technology until recently, where we announced late last year a new product called HERA, which stands for Hardware Enforced Remote Access. We think it is the new standard in remote access for OT and closed networks. It's going really well, getting really good feedback from our customers and prospects. And I'm very excited again to be here and talk about whatever we want to talk about.

Aaron Crow: Yeah, absolutely. And I want to dive in. Most people here know my background coming from power utility, working as an asset owner, having power plants and generation across the state of Texas, substations and mines and all the different things. But the biggest of those being a nuclear power plant in the state of Texas. And it was amazing how different things were at that site versus all of the rest. The security was different, the things that it took to get in.

I tell a story. One of the first things after I got hired at the company, we had to roll out weather stations and secure satellite communications at every facility we had. It was after a winter storm event that happened in Texas, so this was a response to maintaining communications. I installed these weather stations and emergency comms in every facility we had, from our corporate headquarters in downtown Dallas to every power plant, every mine, all of it. I did more than 40 sites in about three months, from the time of finding vendors, finding a product, coming up with an architecture, paying for it, doing site surveys, and installing it.

And I installed it in the parking lot at the nuclear power plant because it was the only place I could install it. It took another year and a half before we actually got it into the control room because it had to have a penetration. You and I know why that's so complicated, but it just goes to show the rigor. It's not complicated to be complicated. It's complicated because we were making a penetration, drilling a hole, putting a cable into the control room, which has to be protected from nuclear radiation. There's a missile door that protects the control room. They shut that door and those operators don't leave. If there's a meltdown, they stay there indefinitely until they control the reaction.

So it just goes to show why you guys started out in nuclear, I'm sure, because of the rigor and the requirements. But they're not the only ones that need the things we need. I love the fact that you guys have branched out. But before we dive into the remote access thing, because we do have a vast difference in people that listen to this podcast, do you mind giving us a high-level, 50,000-foot view, 90-second elevator pitch of what is a data diode? Why is it different, how does it enhance versus a firewall, which is a similar use case but not exactly the same, and why is it so much of a difference and why we need it in these types of spaces?

Lior Frenkel: I can promise five minutes, and I take the stairs, not the elevator, so it will be a bit longer. But before explaining what it is, let's talk about why.

I'm assuming that everybody that listens will agree when I say: we would like the control network, the network controlling a turbine of a power plant -- not even a nuclear one, just a power plant -- not to be accessible from the internet. I'm guessing all the audience are nodding. Same with a railway signaling system. We would really prefer when we're sitting on a train driving 100 miles per hour not to have that network accessible from the internet.

Preferably these networks -- control networks controlling dangerous things, things that have safety issues, things that can end up blowing up or exploding -- we would prefer them not to be accessible from the internet, because bad things will happen.

Can I say shit on your podcast?

Aaron Crow: Absolutely.

Lior Frenkel: Okay, so shit will happen. On the other hand, we would like them to be segregated, a closed network not connected to the outside world, running by itself, as secure as it gets. It's not 100% secure -- nothing is 100% secure. But at least it's not accessible from the internet. All of the online attacks, all of the online risks of malware propagation, virus getting in, remote access attacks -- off the table, we are better off.

On the other hand, we need data to run our business efficiently. We need data that's produced inside these networks. You've been an asset owner. To run your business safely, securely, profitably, you need to know what's going on in each and every one of your sites. It can be a power plant or twenty, it can be a railway, it could be an offshore platform, anything. The company needs to know what's going on.

For them to know, using regular networking, you need systems. Let's make it simple. We're an asset owner, we have 20 power plants, and we want to know what's going on from our headquarters in Texas. Headquarters sends a query, usually over the internet, to the power plant somewhere else in Texas or another state, queries a system inside the control network, and the result is sent out. That's how things are usually done. Sometimes data is just pushed out, but in most cases you query.

The problem is you need access. You need network access over the internet, over public network, to get into that control network and get the information. Doing that, you're happy because you have the data you need, but you've opened up the control network to the internet. Now it's internet accessible, which we just said is not a good idea.

So fixing that is why Waterfall was founded. Enabling businesses to have the data they need in real time, 24/7, anywhere they need it, without opening up the control networks to all of the bad things that happen when you connect them to the internet.

In most cases, even today, the main motivation to connect the control network to the outside is to share information. Most of them, most of the time. So let's talk about that part of the market, which is big and growing. That is what we were set to fix and we built Waterfall to solve.

Now you should say -- but you won't because you know better -- "So put a firewall at the perimeter of the control network and we're good. Firewalls are perfect. Everybody uses firewalls for decades. What's the problem?"

There's no problem with firewalls as a technology. It's really good technology. There are really good products out there, really good professional companies producing and selling them. The issue is they were never designed to sit in between a control network controlling a physical process and the internet. They were designed to sit in between two IT networks and verify what goes in and out.

A firewall is like a bouncer in a club. You have that big bouncer and behind him is the door of the club. You want to get in. He asks you to show your ID. You show it. It looks okay, you look like your picture, your birthday is fine, go in. You're showing an ID and you're below age, stay out.

But like a firewall, that bouncer -- you can run really fast and bypass him. You can show him a fake ID and he lets you in. You can give him a hundred-dollar bill and he lets you in. You can shoot him and run in. There's a lot of things you can do and get yourself inside the club.

Now, when this is a control network controlling a railway system, getting in is all you need. Now there's a safety issue. Now the rail can derail. Now the power plant turbine can get out of sync. Now bad things can happen. The only thing you need is to be able to access -- once you're in, that's enough. You can do bad things. Even if they catch you afterwards, you're still there. You can infect stuff, mix things, mess things up. And now we need to fix it and clean it and look everywhere for residual things, shut down the systems, go back to safety, come back. This is horrible.

Firewalls verify packets, they check them, they do their best. But sometimes you can bypass them. You can show them fake credentials. You can find ways to trick their logic. There are many ways to do that. Each and every one of the cyber attacks that are public, and those that are not public, were successful because someone managed to get through one or more firewalls on the way.

Firewalls are good in your bank because they can back up your data, run it from other places, restore information from cold backups and get things back in. It doesn't fit when this is an offshore platform and now it breaks. You cannot restore from backup an offshore platform. If something breaks, you need to fix it. It's just not the right thing.

So recapping all of this really long elevator pitch -- I told you it would be longer. We designed the unidirectional security gateway, which is a specialized hardware that we deploy instead of that perimeter firewall. That hardware is capable, by the way it's built, by the physics that it's built on, of sending data only in one way. Only from this side to this side. Nothing can ever go back.

By the way, this is why Waterfall is called Waterfall, because water can go only one direction. There's a physical barrier that doesn't allow it to go back up.

We have software on each side of our gateway. One part is inside the control network, gathers data, sends it out through the outbound one-way-only hardware, where our software on the external side gets that data, propagates it, and sends it to whatever recipients it's intended for.

We have the system that gathers the data the asset owner needs. Let's say production information, rates. It can also be security alerts. It can be network monitoring information, logs from systems. Whatever is needed on the outside by centralized engineering, by the company headquarters, sometimes by vendors that are helping you with remote monitoring for preemptive maintenance. Our software gathers that data, sends it out down the waterfall through the one-way-only hardware that can only send data in one direction. And then it's continued downstream to the recipients.

Because the hardware is built in a way that it's physically capable of sending data really only in one way -- again, think of it as a waterfall -- nothing can go back in. There's a physical block that doesn't allow water in that direction. It doesn't have the capability. It's physically impossible.

So we have a physical barrier on the communication. Not like that bouncer. You can't fake an ID and tell the waterfall to climb up. You can't run fast, you can't bribe, you can't trick with logic. There's nothing you can do.

We gather that information in real time, send it out, share it with the external sources, providing in many cases digital twins of systems that are inside the OT network. Now they are outside and the company headquarters uses those. Sometimes we replicate log files, alerts, traps, and signals, then send them to your vendor who processes and does whatever they need with that data. Data is being sent out. Nothing is capable of getting back in. Your control network is off the grid as we wanted, but we have all of the data we need outside, in real time, at the hands of the systems and people that we want them to have.

And as you said at the beginning, you have past experience with our technology. It is so well designed -- and this is why we call our product a unidirectional gateway, because it's a whole system. It's not the hardware, it's not the software, it's a whole system that is built so this very strange way of solving a problem in the otherwise fully bidirectional, fully access-everything type of networking is capable of being deployed in real-life environments and complex environments like power plants, railway systems, chemical plants, water systems, and still work almost seamlessly.

The people that need the data just have the data as before. They are super happy. They can do what they want. And the people responsible for cyber, for risk, for continuity -- they are really happy because nothing can get back in. They can now take that big issue they had before and invest their funds, time, and resources on other things.

Aaron Crow: Absolutely. It's truly the best of both worlds. You go into these places and especially back in the beginning of time, when we were putting these firewalls or connecting these networks, a lot of the operators or the plant managers would say, "I'll just air gap." I hear air gap all the time. I think I've never been into a system that's actually air-gapped, even the ones that claim to be, because I always find that back channel. "Well, yeah, we connected over there because this company needs to monitor." So it's not air-gapped.

But this truly gives you the ability to be an air-gapped system that can send data out. One of the jokes in power -- I'm sure you've heard this -- we only generate electricity to make sure we have enough PI data for the executives to see their dashboards. OSI PI is a product used in power generation that has all the monitors and all the things. And that's a prime use case for Waterfall in power utility: to be able to get that PI data.

You've got a PI server sitting inside the control network getting all the real-time data from sensors, temperatures, pressures, valve positions, all of it. And it sends that data. But in these environments, especially in a nuclear power plant, I would have to be in the control room to see those screens. Well, the plant manager says, "I want to be able to see that data outside." You can't, because as soon as I connect that, I don't have an air-gapped environment anymore. I've bridged that network with the one your corporate laptop is on. I've added risk to my environment.

So this is in theory a one outbound-only way of making a copy of that data. Like you said, a digital twin. I've got a PI server now sitting on the outside. I'm getting that data out. So now that laptop can connect in. Use that use case as an example for wherever you put this.

It started, as you mentioned, like nuclear power because that was one of the few that really had the vision and maybe even the budget to have an air gap or that type of system. But I think now it's bigger. More and more folks are seeing the value and the need for that level of rigor in their environments and their OT spaces.

Lior Frenkel: Yeah, it's also because the awareness was there way before it was in other verticals. I think because of the criticality, because of the safety, because of what can go wrong in a nuclear power plant. Everything is so critical. So even before cyber was a big issue like it is today, the potential risk was so big, so they were thinking about everything, all of the risks, what can go wrong.

Today, this understanding, the level of awareness, and also the level of risk, is dramatically higher. The understanding that bad things happen from the internet, that attacks happen -- sometimes targeted specifically at you, sometimes just because you have a bank account and they succeeded, and sometimes just because a virus propagates and malware propagates and you just do not want that to happen to your production environment.

So now it's becoming dramatically wider, the use case, the usage. We are today deployed in casinos. I know that some people treat them as critical infrastructure, but it's not the classic definition. We're deployed in casinos, we're deployed in big campuses and buildings protecting the building management system, which is way on the other side of what people think of as the big utilities, the big moving parts, the big turbines.

We're talking about elevators and HVACs and sprinklers and air purification systems that, in a big building, if those systems malfunction, in most cases you need to evacuate the building. And thinking of ransomware -- we don't even need to think about nation-backed attacks or terror, just ransomware. If I'm getting into the system that controls your fire alarm and I'm telling you: now I own that system. Pay me $50,000 or I shut it down and you need to evacuate this big building, this university campus, this high-rise, this casino. You'll just pay me that money. It's better than anything else.

So protecting them from the internet and protecting a nuclear power plant from the internet: different everything, but the same Waterfall unidirectional gateway technology protects both.

Aaron Crow: Yeah. And unfortunately, or fortunately, depending on how you look at it, we're seeing more and more events showing up in the news and the media. More and more people are seeing these. This is not fear selling. This is not hypothetical. These are not things that are pretend, that vendors are making up to try to sell fear.

There are events constantly. We saw recently airports in the UK impacted by issues, the CrowdStrike thing, which wasn't a cyber attack but still spread. There are so many things that go into this. Now people are starting to realize, to your point, casinos being a great example -- they're not technically one of the 17 critical infrastructures by the US government or others, but to those businesses, they are critical. Whatever your thing is, it's critical to your business. Because usually in OT, that is the thing that makes you the money. If you are making widgets, making cars, making whatever, or selling whatever -- if that system goes down, it may not be critical to me as a human driving down the street, but it's absolutely critical to the people that work there, the shareholders, and the company's existence.

When those things go down, it is absolutely critical, which is why we have to be intentional about how we protect and what we do in an OT space.

Lior Frenkel: Yeah, and we really try not to sell by fear. But as you said, if this industrial process, this physical process that you run, which is the core of your business -- if I can make it unsafe and you need to shut it down -- that's the basic threat in ransomware. This is an unacceptable risk in most businesses.

If the damage, even the potential damage that happens from malware now inside that control network, takes you days or weeks and sometimes a month of downtime to clean up, fix, and make sure everything is back up and running and safe -- most businesses find that an unacceptable risk. We don't need to go and talk about adversary nation states getting into your networks. We don't even need to get into the risk of humans being hurt or dying. There's that too. But the daily threat, the one that happens day in and day out where there's a big economy supporting it, is ransomware. And the damage is unacceptable, even just with that.

Aaron Crow: Absolutely. OT is vastly different. The risk is higher, the impact of an issue or outage -- not all of them involve threatening lives, but many of them do. There are legitimate things that put people's lives at risk. You can actually injure or kill. I've been at sites where people have lost their life -- not because of a cyber incident, but because of something to do with the system failing. That system can fail from a misconfiguration, from human error, or from something like a ransomware. We already know the impact is different than losing your Facebook account.

But on the flip side, we also know that these systems are inherently at higher risk from the technology stack as well, because most of them are older technologies. I'm usually not patching them as frequently. I usually have a smaller staff that isn't 100% focused on technology. There are so many factors that go against us in this OT space.

I was an asset owner for a power utility here in Texas, and we had more than 40 power plants across the state of Texas. I know you don't live in Texas, but if you've seen Texas on a map, it's a really big state. There's six to eight hours of driving distance from my headquarters to where one of my power plants was. It's not like I'm just a mile down the street. There's ten or twelve hours between sites at some locations, just in my state.

When I'm looking at the impact, it's huge and it's vastly different. I had a team of six people, six employees, and then some contractors -- let's say ten total on my team -- that supported 45 power plants plus mines plus all the things. And that was everything at the plant from our connection, our OT side down, all of the technology in between.

On the flip side, the IT team -- now granted, this is at a power utility company, that is our product, generating electricity is the only product we have -- the IT team had a dedicated server team, a dedicated firewall team, a dedicated networking team, a dedicated application team. They had a hundred people probably in their IT organization. I'm not saying they shouldn't have had those things, but it's a bit of the tail wagging the dog, in my perspective. They had a lot bigger budget, way more people, way more training, way more expertise, where my guys had to know how to do the firewall, the VMware, the networking. They had to be able to do all the technology. I didn't expect one guy to be an expert in all of those technologies, but they couldn't just focus on being the firewall guy.

All of these things make it that much more difficult. And then I throw in all these new technologies and firewalls and all the patching and everything that goes with that. It's overwhelming very quickly.

Lior Frenkel: Yeah, I agree.

Aaron Crow: The biggest thing we always focused on was: how do I reduce the risk? I can't get the risk to zero. It's never zero. Ever.

Lior Frenkel: If you want to take it to zero, shut down your company. There's always risk attached to business.

Aaron Crow: Exactly. But how can we reduce the risk? Many times we have these conversations where we're accepting risk, understanding it, quantifying it, putting numbers associated to risk and saying we're going to accept that risk. I feel many times the risk that's accepted -- and it's getting better -- but I think many organizations accept risk because they don't truly understand what that risk is. If they really understood what that risk really is, I don't think there's any way they would actually accept it the way that they do. I think they would want to mitigate it and reduce the likelihood of that risk or the impact of that risk instead of just accepting it.

Lior Frenkel: I think you're right. It is in a way a bit local. There are industries where the situation is better than others, and geographies where this is the case and others where it's less. From my perspective, from the Waterfall perspective, selling to these types of customers really across the globe, we see that where the government, either through regulators or through types of guidelines or guidance, have the ability to educate the practitioners on what the real risks are.

We see places where people learn how to protect systems, which is great. But they don't learn what bad guys know how to do. They have these building blocks and good people with good intentions, professional people telling them, "Put this building block here and use this one." And that's the good thing to do.

The practitioners -- everybody is generally a good person with good intentions, wanting to do their best -- they do what they were taught. But without understanding, really understanding, what the risk is, what the threat is, how it looks, what the way that an attack happens, how a bad person views a target infrastructure -- without that understanding, it's really hard to do a good job. It's not because they don't want to, it's not because they are lazy or incompetent, it's just they are lacking a part of the problem.

We see that when governments do a better job -- and there's a problem because they don't want to share that information in many cases. There's sometimes a disconnect.

Aaron Crow: Yeah, you're in Texas, so I don't want the federal government getting into my business.

Lior Frenkel: Exactly. We see that in other countries where it's more interconnected or they're more open to talk freely, the situation is better. Because when you as a defender understand the real level of threat you are up against, you do a better job. I think over time we'll see this improving. You and I have been in this business for a long while. It has not improved at the rate that it should have. I think the bad guys have improved dramatically more than the good guys. And this is something that we as an industry need to think really hard about.

Aaron Crow: I 100% agree. Unfortunately, without throwing people under the bus or naming names, because it doesn't matter, there are still people out there arguing that there's never been OT cyber incidents, or that there's not enough and this is fear selling. Unfortunately, as we know, it's just not true.

I can't talk about it because I have NDAs, but I've personally been in OT incidents and critical infrastructure around the world -- literally where I live now and on other continents -- specifically OT-related incident response where bad things have happened from a cyber perspective impacting and affecting OT systems. But because they're not on the front page of the news, others say, "Those things never happened. That wasn't an OT incident."

I've had this argument around Colonial Pipeline, how Colonial Pipeline wasn't an OT attack. You're right -- it hit an IT system. But it impacted OT. Does it matter that the system was IT or OT? The end result is the problem. That's where we need to better understand this.

To your point, we have great people who, like you and I, want to do the right thing. But we need to make sure they have the understanding and skill set, or partner them with people coming from the offensive side. Because if you haven't been in that offensive role, you don't necessarily know what to look for and how to defend against those things. You think you're doing the right things, and you are, but you're missing all this stuff over here that you don't know to look for.

Lior Frenkel: Exactly. Because of that, one thing we do at Waterfall is we track all of the public incidents that happen -- OT attacks, or at least attacks that have an OT impact. We document them throughout the year and compile all of that in a big annual threat report.

You might think the numbers seem a bit low, but each and every one of the incidents and cyber attacks, the ones that have physical damages, these are public incidents where you can go see the source of the publication and verify it yourself. We're not trying to exaggerate. These are the facts.

The thing we all know is: if we document 100 attacks, there are probably 10,000. Because in many cases, many geographies, many countries, many verticals, there is no requirement to make a cyber attack public. And if they don't have to, they won't. It's embarrassing, it's bad for reputation. So they don't.

Those that didn't end up with a physical consequence because maybe they paid the ransom -- not public. Sometimes there's no apparent physical consequence because one of your sites went down but the other one is still okay, so you don't need to publicly say anything. Nobody noticed, nobody wrote about it.

But the fact is, as you said, you've been in incident response activities, and I'm sure most of those were never public. We produce that threat report just to show the trend, to show the examples, without being accused of exaggerating. These are facts. You can go to our website and download all of the reports from recent years and see the trends and analyze it yourself. Things are not getting better. There's enough business for us for the next few years, for sure.

Aaron Crow: That's right. It's trending upwards as we integrate more OT systems because we want more access and more capabilities. A lot of the stuff came from the vendors -- the VARs who said, "This thing has Active Directory now," and all these things with firewalls. So I'm connecting all these things to my corporate network.

I always assumed, when I was an asset owner, that the corporate network was the internet. I assumed it was bad. I assumed it was at risk, and I didn't trust anything from that. Very much a zero trust architecture mindset way back in 2010 when I officially started, when we started calling it OT.

We always assumed that corporate was bad. I had to assume that because I didn't control it. I didn't know. That doesn't mean bad from a China perspective, like you said before. It doesn't mean a nation state is attacking. It just means I don't want some IT guy -- because it's happened -- making a change on a firewall or a network thing that's going to impact my OT system. Not all of these things are malicious nation-state attacks. That doesn't change the fact that they impacted my system. And that's unacceptable in these environments. Even an oops.

Lior Frenkel: Sometimes it's a server that managed to reach out to the internet, get an update, install the update automatically, and do a reset.

Aaron Crow: And it broke. It broke everything.

Lior Frenkel: Or just did a reset when it shouldn't be reset because it's controlling a dangerous process that should never have the control network server go off the grid. Or as I said, it breaks. Sometimes you run an update and it doesn't work.

Aaron Crow: So all this to say, I want to dive into your new product as well, because I obviously look at my architecture -- I just talked about it. I had a team of six people. I had power plants all over the state of Texas. I didn't have enough people to have one at every site. We were supporting way more facilities than I had people to be at, which meant I had to be able to remotely access all of those environments.

How did I do that? Did I just allow remote access directly to the control network? No. I had all of this rigor, and it was a pain in the backside the way I had to do it back then. We used Microsoft Terminal Services. I had a boundary remote access that we'd jump into with multi-factor authentication, then jump into a different one. We were like daisy chains. It was like the movie Inception -- I jumped into this, then I jumped into this, then I jumped into this, and you had to remember which window you were in. It was complicated. But we had to do that to make sure I wasn't allowing my control network to be on the internet. That was never acceptable.

So it was really complex. The vendors didn't like it. The operators didn't like it. But it was the best we had at the time to be able to enable my team and others to remotely control, access, manage, and maintain these systems.

Lior Frenkel: Yeah, and like Inception, at the end you always have that spinner to make sure you're still in reality.

Aaron Crow: Exactly.

Lior Frenkel: Some vendors, some asset owners, some sites, quite a lot of them by the way, do not allow remote access. Some do. And as you said, when they do, they put in everything they can and pray really hard. Others just say, "I'll pay more, I'll have more people on site," or "I'll have a bit less of the quality of service that I want, but people will drive all day between the sites and do things locally."

But as things progress, as the world advances -- as we had COVID, the big push towards remote accessing OT happened through COVID because you just didn't have the ability to get on site. People were confined to their houses or couldn't be more than a certain number on the same site at the same time. Vendors from other companies you would never allow in. Vendors from another country, irrelevant anymore.

But you need to keep the lights on and the business running and the systems running. So you allowed remote access. And what you just described -- that system getting in, a jump station, multi-factor authentication, and another thing -- at the end, you had your control network with a firewall. That bouncer from an hour ago. All good intentions, and you added everything on top of it, monitored it, patched it, added more and more layers. At the end, it's a firewall between your OT network and the wild, wild west, which is the outside.

And this is what Waterfall fixed when we envisioned and designed HERA -- Hardware Enforced Remote Access. Trying to keep things really high level: all of the remote access solutions out there, general or OT-specific, it doesn't really matter. All of them suffer from the same basic three issues.

First, they require a firewall at your perimeter of the OT network. Game over.

The second thing: the underlying protocol that carries the remote access session -- these protocols are really good, the products are really good, but these protocols are super complicated. Windows Remote Desktop, RDP -- I don't want to name names, it's not specific against any of the vendors or the standards. Super complex protocols, unfilterable. So you have that firewall -- big mistake -- but you have that firewall to allow a remote access protocol pass through it, meaning you open a port, any to any. There's no filtering, no control. I'm not even talking about those protocols that are encrypted end to end, which in some point of view is more secure, but in this context it's less secure. They're encrypted point to point, meaning the firewall cannot filter them. It cannot even add the residual security a firewall can add, like seeing if the protocol is weird or if something bad is happening. They just cannot do that.

And the last thing: the device you're remoting from, your laptop, your desktop, is weak from a security standpoint. How do we know that it's you? How do we know you're remoting in from the laptop we issued you as an employee? We don't really know how to do that.

So we designed HERA to solve these three things that are shared across all of the remote access solutions in the market, while providing a full-blown interactive advanced remote access experience.

We've designed it so you have a special unidirectional gateway. It's like the one we discussed at the beginning, but this special one, this HERA gateway, is a unidirectional gateway that you deploy inbound at your OT perimeter. On top of just being a really good unidirectional gateway, this gateway has specialized hardware that we use to filter our protocol, keep our encryption keys, and so on. Our gateway has a TPM -- Trusted Platform Module -- which is like a small crypto chip inside the motherboard, like a secure enclave securing crypto keys.

We have that inbound gateway. We have an outbound gateway. They are not connected between them. Just one inbound gateway and one outbound gateway. And we have a client application that you run on your laptop or desktop. The only prerequisite we have from that laptop or desktop is that it has a TPM inside the motherboard. That's a basic requirement today. All business-grade computers and laptops have a TPM.

The way HERA works -- bear with me for a second, you'll need to envision this. Like what we did with the unidirectional gateway, this is a different way of solving a problem.

You fire up your HERA client, say "Hi, I'm Aaron." You log in, authenticate yourself using whatever systems you have in your enterprise network, and you say, "I want to remote into site A."

From now on, every keyboard key that you strike and every mouse move inside our client application -- every keystrike is being captured, sent to the TPM where it's encrypted and signed, then sent to the HERA gateway on site A's OT perimeter. So you type "Hello, my name is Aaron." H-E-L-L-O, each keystrike in your laptop encrypted, signed, and sent to our inbound gateway.

This inbound gateway on the outside verifies whatever it needs to verify, but we're on the outside, so we don't trust that too much. We verify anyway, just to be cautious. We send it in one way only into the internal side of our gateway. There, we verify the protocol again through our hardware. It's a very simple protocol -- keystrikes, mouse moves, ASCII codes. Encrypted and signed in a very simple packet. We see that it's our type of packet, then we verify the digital signature through the internal TPM.

At the beginning, when we install the systems, we do a secure key exchange between your client TPM and the HERA gateway TPM. So we verify the digital signature. If it's good, we continue with decryption and we get the keystrikes. Then these keystrikes are activated on the target device you want to remote into. It can be a Windows server, a Linux server, whatever application, it doesn't really matter. It can be an HMI of an embedded device that you log into. Your keystrikes and mouse moves are activated on that device.

The screen of that system, we stream it back encrypted through the TPM, then stream it out encrypted through the one-way outbound gateway back to your laptop where it's verified, decrypted through the TPM, and displayed on your screen.

So all of that under the hood. What you see is the screen of the remote device, and everything you do -- your typing and mouse moves -- is encrypted, signed, sent, got in, verified, decrypted, activated, and the screen is sent back. You see everything you do. You see the effect of it on the remote screen being displayed on your laptop. In real time, our latencies are below the threshold you'd notice.

In your mind, you're remoting into that computer. But in fact, there's no TCP/IP going back and forth. There's no networking going from your computer, from your network, from the internet into the OT network. There's no firewall. There's one way in that verifies cryptographically, based on a one-way-only hardware, that those packets are coming from that specific computer. We can verify this protocol as much as we'd like. It's a pretty simple protocol -- keystrikes, mouse moves.

No firewall, simple protocol, very strong coupling between the user's laptop through the TPM and the inbound gateway through the TPM, coupled at deployment. This is a bit complex, I apologize.

Aaron Crow: No, it's okay.

Lior Frenkel: It's like magic. If you think about all the things we're doing under the hood, at the end the user just sees the remote. It's as if he's sitting in front of that computer. But now he's in a coffee shop in the neighborhood where he lives, remoting in without TCP/IP, without opening up the OT network, without using firewalls, remoting into a closed network and keeping it closed.

Aaron Crow: And that's the key. Most other architectures, to your point, go through a firewall. We're having to punch a hole to enable this protocol through, and I can't filter it. I have no ability to really understand what's in that protocol. RDP is a great example. I can do all sorts of things across RDP. I can copy and paste files. I can do all sorts of things. To your point, the firewall just has to either let it in or it doesn't.

And as we know -- this is diving further in -- TCP all day long. You hear people talk about, "Well, it's a one-way firewall rule. It's outbound only." But TCP is a two-way protocol. By definition, packets are coming both ways down that path. Yes, it's initiated from inside out, but it is a two-way handshake. Go back to your CCNA books from 1985. TCP has always been two-way communication. UDP is one way, of course, but still you're looking for SYN, SYN-ACK. It is a two-way conversation.

Lior Frenkel: UDP is one way, but the underlying physical layer is bidirectional. The firewall is a device that allows data to go in both directions, even if you configure a port just to allow UDP. It still has bugs, vulnerabilities, misconfiguration -- all the things we discussed before.

Aaron Crow: And then you start adding encryption and complex protocols that you don't have to have. It adds so much complexity. To your point, we need to be able to have a safe way to enable these capabilities without increasing the risk drastically. It's obviously better to have the person sitting at the keyboard in the facility. That is the best way. You can't always do that.

So what is the next best thing to do without poking holes in my firewall that's allowing traffic in? Because that drastically increases the risk to my environment because of all those holes I've now had to punch through that firewall and all the other things that come with that. I love this. They go hand in hand.

I appreciate you diving into the technical side, because I think it's important for people to really understand. This is not to bash firewalls. This is not to bash secure remote access. There's a scenario and a use case depending on the validity, the impact to your organization, how critical is this system, and how much you need to make sure nothing bad happens.

Nuclear power is a great example, but that's not the only place where these things are critical enough that we need to be really sure nobody can get in and that I'm not allowing other things in this door when I'm allowing remote access.

Lior Frenkel: The market for HERA is renewable energy, where you have solar plants and wind farms that are designed to be remotely controlled. These are sites where you don't have an office. They are designed from the get-go to be remote-controlled. But let's do it in a safe manner, in a manner that creates the least added risk to the safety and operational status of our control network.

Same with almost any other type of control network. If you must have somebody remoting into your water purification system of whatever municipality, because it's spread out, because you don't have people on site, because it's a system of a vendor that doesn't have local people -- you have to do it. Do it in a safe way. Putting firewalls and VPNs and saying "we're good" -- maybe that was okay in the 1990s. It's not okay today.

Aaron Crow: I agree a hundred percent. I see the tide shifting. I expected and hoped it would be further down the road than we are today. I think finally we're starting to see budgets getting better aligned. Executives who are non-OT, non-cyber people are starting to see the real value and criticality of these things.

Along with that, that leads into my wrap-up question. In the next five to ten years, what's one thing you see coming, maybe one thing that's concerning and one thing that's exciting, regarding all of this?

Lior Frenkel: Well, I don't know. For me, everything here is exciting. I like this industry. I like the people that work here. I'm so happy to see a customer that understands what they're getting out of it, that they're so much better off with using this technology. We come in, we deploy the systems, and now they are dramatically safer than before. We have examples from here to the end of the world in so many places where we deployed our systems, so many countries and states and societies that are just in a safer position now than before they deployed us. This is what excites me, and I'm guessing it will excite me in the next five to ten years too.

I think the cyber threat will become bigger and more imminent in the next years because of the use of automation based on AI. It'll just be easier to run more attacks in parallel, in bigger volume, in bigger frequency on the same target, and get in through somewhere.

Again, to get what you want, you just need to get in somewhere. When you're protecting, you need to protect everything all the time. When you're hacking in, you just need to succeed through somewhere. So having AI instead of manual power just makes it easier, and will just make it cheaper, and because of that, more effective and more used.

That's what I'm seeing as what's going to happen in the future. And we will need to find better ways to make sure -- this is a different angle -- but we always used to say and trust the fact that, worst case, Aaron will call me and say, "Hey, Lior, this is Aaron, let's do this or that," or "That operation that you noticed, I actually did that, let's approve it and move on."

With AI, deepfake, voice mimicking, video mimicking, that fallback -- people say, "We are back to the Stone Age, we're writing things on papers and calling" -- I'm not sure that will work with AI anymore. How do I know that Aaron is actually calling me when your voice can be so easily mimicked and your video can also? The voice may be there already, but video is still not there. It will be.

We will need to find better ways to do that. In smaller countries -- I'm based out of Israel -- in smaller countries with smaller populations, it's a bit better because we know each other personally, smaller communities, more tightly knit, it'll just be a bit harder. But good AI, five to ten years from now, how do I know it's my mother calling? You won't know.

This is something we will all face. It's not specific to OT, but this is an OT fallback as it is an IT fallback. It's a basic fallback we all have: we can always fall back on "I'll just call him and verify." We'll need to find better ways for that. And the bigger force of attacks I said before -- these are the things that will grow and be a bigger threat on our industry and others. As I said, there's enough business for all of us for a while.

Aaron Crow: I agree. It's not declining for sure. Fortunately and unfortunately, there are not that many people who understand and have the experience and background that I do and people like us do -- coming up in IT, working in the plants and all these different spaces. There are just not enough of us to go around.

We see that -- I have this conversation all the time. If an incident happens, something really bad, and all of these people who have hired incident response companies all call at the same time because something really bad spread across a certain industry, who are they going to go to? And then what do the rest of the people do? There are just so many problems we need to be able to solve.

I love products that come out solving a real issue with a real solution. I'm not trying to bad-mouth any other products. I was a product owner myself, at Industrial Defender. There's a value for a lot of those products. It's just a matter of there's a difference between providing a real concrete solution and then policy, procedures -- all those things are needed. But sometimes you just need to be able to close the door and lock it and know that it's good. I can go focus elsewhere. There are other things I need to solve. That's not the only thing. You can't just put something like that in and be done. But at least I know I put that in and I'm okay there. I can focus my attention elsewhere and solve other problems.

Lior Frenkel: Yeah, agreed.

Aaron Crow: So thank you for taking all the time today. What's the call to action? How do people find out more if they want to look at Waterfall, the remote access solution? What's the call to action for everybody listening?

Lior Frenkel: WaterfallSecurity.com. We are spread out, we have people in every continent across the world. We have subsidiaries covering most of the regions. We can speak to you in your own language and communicate, especially of course in the US, but also Europe, APAC, the Middle East.

Reach out through any means that you feel comfortable with and we will help. Of course with our products, but also as I said, we have our reports, we have experts that can share information and consult with you. The best thing to do is be well educated. After that, you can make your own choices.

Aaron Crow: Absolutely. And I say it all the time, it's one of the reasons I do this podcast. I'm not getting rich off of this. I don't make money off of this. I do this because I enjoy having these conversations because I think there's a value in them. Not everybody has had my experience or your experience, but they can listen to a conversation like this and get the value and the knowledge from that, and then take that and put it into their own scenario, the environment they're looking at, and use that to their benefit.

That's the value I see and that's why I do this. It's why I'm so passionate about having these conversations and very much appreciative for folks like you coming on and sharing your knowledge with the audience and myself as well. So thank you so much. It was great spending time with you today. I appreciate your time. I know you're busy, and I very much appreciate you sharing with us today in your evening there in Israel versus my almost noon here in Texas.

Lior Frenkel: Thank you, Aaron, and all of the listeners. Hope it was fun. Just keep the fun. The rest will follow.

Aaron Crow: We'll keep it at fun. Well, thank you again, sir. I really appreciate your time.

Lior Frenkel: Perfect. Thank you.

Transcript lightly edited for readability.