Now they're smart. You might have smart meters, smart valves. So those are industrial Internet of Things that come with vulnerabilities built in that the end user may not even want. They buy a valve. They don't necessarily need Wi-Fi on the valve, but it might come with Wi-Fi.

So there's, iIoT is in there as well, down in that mix. So I want to talk about that area here, and how a lot of those things are inherently insecure by design. So you're never going to hear a vendor say, hey, we're insecure by design.

Trademark. So we all know what's been happening with OT in the past, from the early past, or long ago past in our world, 2010 with Stuxnet, or Ukraine, or lately with the Russians hacking into the electrical system.

So have we been improving since all those times? Have we improved since 2010? I think in OT, in a traditional OT sense, yes. But there's a legend that before Putin, there was Boris Yeltsin. And there was a legend that Boris Yeltsin, when he was asked, how's the economy doing

in Russia? And Boris Yeltsin said, in a word, good. Then he said, in two words, not good. And that's basically where we are now. It's like we are good, but there's a lot of areas where we can improve. And one area where we can really improve is the IoT or iIoT area.

That's just the wild west. And as I said in the title, the great unwashed masses of those devices can really affect the rest of OT. So it's a mixed bag of how we're doing. And where are we going with this? What's helping us to move forward?

Well, there's a lot of standards out there. There's a standard for everybody. Some OT installations, some plants use IT standards, like ISO 27001. That might be all they use. Some plants might say, oh, no, we want to really look at ISA 62443, which is the ICS standard.

But as we all know, except for the NERC SIP with the electrical industry, there's no regulation. You don't have to do anything except in that area. But in all these other areas, there's no regulation. There's no incentive. So what are you going to do? Well, one of the things that did come out a couple years ago, we all know about this, is the NIST framework.

It's almost like the standard that shall rule them all kind of thing. It encompasses everything. So what does that do for us? Well, it protects us from all these vulnerabilities that are coming after us. So we've got a lot of attacks, different ways of attacks, different attack vectors. The NIST framework helps us protect the OT space.

And on the right side there, we have a typical OT space. And how many people are familiar with the Purdue model, if I say that word? OK. All right, so it's just a model of OT. It's a model of industrial control systems. And on the right side is effectively a diagram of that model. And what it shows is that at every level, you could have these industrial Internet of

Things. You could have regular Internet of Things. And any of those levels. The lower level represents the IO, which you could have smart cyber devices at the IO level. More and more, you see that. Even though they're below the PLC, they actually can do processing themselves in some way, some of it limited, but some of it's very vulnerable.

And then you can have the next level up is the PLC itself, which, of course, we know that, again, insecurity by design sometimes. And then higher level than that is the HMIs, which are usually just Windows machines, which, of course, are insecure in that way. And then higher level than that is the enterprise, where you could have other types

of vulnerabilities. And any level there can be attacked. So we need that NIST framework to help, or that we can use that NIST framework. What we like to do, though, is to say that that's not enough. We really want to look at a foundation that supports that framework. So that foundation is what we provide.

And one of the things we do is we have these special tools. We can support that NIST framework in anything you need. So in every one of those levels, identify, protect, detect, all of those things have cyber and physical components to them. So, for example, for detect, a cyber advanced threat detection would be needed.

But for physical, you might have some special scanning processes with cameras. And with protect, for cyber, you want to protect some OT communication between OT devices. And with physical, you might have some physical access control.

So what we're doing today is I want to talk about one little area, and that is under the protect in cyber, we want to introduce a way to protect that communication in that area. So what that does is we want to say, OK, you might need the whole thing. It's a holistic idea, right? We want to do everything.

But we want to talk about today just one area of that everything. And how do we protect that infrastructure? Well, there's many reasons why we need to. There's insecure ways of accessing it. There's lots of vulnerabilities in IoT and IIoT devices. There's instability with regards to communication.

So you could brick something with sending certain packets to these devices. There's back doors to these devices. There's buffer overflows. There's lots of different, 10 years ago, vulnerabilities are now creeping back in because people are using IoT and IoT. So the problem is that we have all these devices out there.

Smart meters would be a typical thing. Cameras would be another typical thing. There's other things as well that are more like IIoT devices that support the bigger OT. And so we want to show now how do we protect these devices against attacks that will occur. So we could use VLANs. There's lots of different ways you could do it.

You could use VLANs, but they're not that secure, especially how they're implemented. You could use VPN in general, the classic VPN. But we want to show a different way of doing it with enclaves and with ways to protect different devices using a secure tunnel. So Ben is going to explain a little bit more about how that goes in a deeper sense.

You think you can? Okay. So what we're looking at here is on the left is a typical IToT mix on a network. We're doing a high level discovery and topology of all devices under one scan.

In the center of what we're doing is identifying the OT devices and pulling those into a secure enclave and removing them from the attack surface of the IT infrastructure. So those are being pulled out and separated from IT. So we're in a secure tunnel with our OT devices.

OT can't see IT, IT can't see OT. And this boils down to essentially a closed network operation where we have our OT devices on a secure tunnel that are separated from the rest of the IT devices and therefore out of the IT domain. So how could you do this now? How is it typically done in the current environment?

Well, VPN is unfortunately probably the best example or similar concept, but there are some fundamental differences with the domain 6 protect. But with the VPN, I think a good example is a Cisco VPN with IPsec. We're going to need at least two Cisco routers, accompanying devices, licenses, power supplies,

those types of things, the infrastructure to support it. So power, make sure we have air conditioning requirements in the data center. Configuration utilities, any types of higher level management infrastructure we'd need for those. And most importantly would be an experienced and certified network engineer to design and

configure these to be with security in mind. So we have a very secure VPN that's creating a tunnel between these devices. Unfortunately, the biggest problem is with misconfiguration or putting the time to deployment and the simplicity of the design ahead of the security requirements.

And that may be they don't have the background to understand that these are important or worry about those attack surfaces or it could just be they're being pushed to get this out and they have end users who are using Windows machines or other operating systems with VPN clients to communicate with these devices. So that increases our attack surface because we have misconfigurations, but we also have

software and other pieces that we have to build into this in order to be able to communicate on this VPN. Some of the other common vulnerabilities and exploits, a good one is the January 2018, and I have to read this because it's long, but it's a Cisco adaptive security appliance remote code execution and denial of service vulnerability.

That was a mouthful. But that was an exploit in the way XML was parsed, which allow an unauthenticated attacker to gain access to the network and possibly to the VPN itself and take the network down. So it's just a good example of the common vulnerabilities and some of the reasons why VPNs aren't the best solution even though they can technically be secure.

So with Domain 6 protect gateways, they're a, essentially what they are is a small network appliance that is, that goes in between the OT device to be protected and the rest of the network that you want to connect to. So these are, come in several different flavors to a small embedded computer to a small bump

in the wire device. So between a camera and the bump in the wire to the internet to connect back to a remote site where you have a monitoring system set up. So you have multiple cameras, different locations with a gateway that connects them. As far as the device is concerned, it's on a flat network.

That's all it sees. So in this diagram, this is our camera demo, which is kind of a very simple boiled down explanation of how this is configured to give an idea. And we have essentially two cameras and a monitoring station on this network. What you see inside of the yellow box is going to be seen as a flat network across those devices, and the end map scan to the left is from the workstation on that.

But they're communicating through the gateway zero and gateway one that you see above them, and then to whatever local network they're on, whatever route or whatever existing IT infrastructure they're on, but they're in an encrypted tunnel at that point. And they're communicating with their embedded hardware keys through embedded TPM modules, which is a private key to a remote server for authentication and establishment of that tunnel.

And the great thing about this is really the key piece is these are very simple. We're not trying to manage an enterprise-level VPN. We're not trying to get all of the policies and procedures that have to be in place for your particular VPN.

These are encrypted tunnels. That's what they do. That's all they do. So it's done once, and it's done well, and it's done secure across the platform. And they're simple devices. It's essentially a plug and play, very small appliance plug-in, and it's done, which eliminates a lot of the overhead in equipment and configuration of the utilities. And this is our ICS village CTF.

So we do have a camera in the capture the flag area. So the flag is the MAC address of that camera, which you can see the IP right there. And the goal is then to capture that MAC address in the capture the flag area. We also have a laptop set up, which is monitoring the live attacks on the outside of that gateway.

And we have monitoring the inside of the gateway as well, so we can see on both sides of it with our remote ELK stack and viewing of the software. Do you want to? Yeah, okay. Yeah, so that's a quick overview of the details, but we're going to go into questions

and answers. But basically, we just covered that one area on the NIST framework, and we wanted to say why it might be a good idea to look at that kind of an option for that kind of a hybrid VPN, you might say, or something else than that. But any questions?

No, this would be, you're creating a, you flatten up, I'm sorry, you're creating a, so the question was, I'm supposed to repeat that, is there any inherent security built

in for wireless devices, correct? So it's, no there is not. So these are for ethernet hardwired devices. You're essentially creating a magic ethernet cable is one way to look at it. So between the end device that you're connecting to, to whatever remote site it is, it's this infinitely long network cable. So there is no inherent, you know, internet connectivity to that, there is no inherent

other infrastructure on top of that, or support for wireless devices, it is just connecting those two together. And any wireless or any other connectivity would be on top of your enclave.

So if you were, if you had a wireless access point, say, so you have your wireless devices on this LAN and your wireless access point, and you need to connect back to a remote server, then you would have that wireless access point connected to the enclave gateway, that enclave gateway out. But you're also exposing through the wireless, those devices to that gateway on the inside.

Yes. Oh, sorry. Oh, no, I'm sorry. So the question was, what are the security measures as opposed to IPSec or VPN?

So it actually is not IPSec over VPN, that is an explanation, just a similar concept. So the, oh, I'm sorry. Oh, okay, yes. So these are, they create an encrypted tunnel through the, they have a remote server that has a shared hardware key. So there's a TPM module on the device, a crypto key, that is connecting to a remote server

for authentication. So there's an encrypted tunnel that's established between the two, and then the data inside of that tunnel is encrypted with layer two, three over layer two. Oh, I'm sorry. Okay. I may have to ask Christina Phillips here, who is an engineer that has worked on this

for a little more help on that. Okay. So since you asked about the encryption, sorry, I'm Christina Phillips. I work with the Parsons guys. These devices use strong encryption. It, they're currently, you can, we've been doing it with 2048 bit.

The actual devices were developed, it's a repackage of, and I see hardware that's been around for 20 years that's never been hacked. So the thing is, the key exchange is done by the secure bridge environment that could be on-prem or off-prem. And the encryption is actually put onto a USB-I key.

It's not a hard drive. It's just a USB-I key. And that creates the, that has all the instructions for the secure tunnel. And then there's a complete key rotation using PFS, but at layer two. The initial tunnel is created at layer three and, you know, for the negotiation, and

then it drops down to layer two. So we're doing Mac to Mac encryption. So whatever IP traffic you throw out on that, on that encrypted tunnel is protected. I know that sounds kind of odd, but that's what we do.

So we, okay, so this is about, the question was about pursuing third party certification. This hardware is FIPS 140-2 compliant. The original spec developed 20 years ago was actually FIPS 140-2 certified.

But it has not been recertified since due to cost issues and a lot of changes in the certification process. So it is that. As I said, there is a complete key exchange and it's, there's no, you don't have to put an SSL cert to do this because we don't use SSL, we don't use TLS, but there

is an actual encryption when we create the secure policies that gets pushed down. So if I had the hardware set up, I could create tunnels for HVAC in one, door controls in another, and cameras in the third, segregate them all, and pass the traffic

and nobody would see it but encrypted traffic on the outside network. Hopefully that helps you with your question. I'm sorry with your question. I can't explain all of the pieces because I'm not an encryption expert in terms of designing the algorithm for this.

But it does work. It hasn't been hacked in 20 plus years. That I know. Yes, sorry. It will scale to that.

It will scale to that. If you have 100 devices, we can scale to that. The solution is scalable. It's cross platform. It doesn't care. We can support legacy devices as well as IP devices. The point is that the technology is flexible and that we can actually provide.

It's an alternative to what are considered traditional ways of providing security. Again, VLANs or putting a firewall and segregating. Okay, I've got all my IoT in one environment. I've got my Siemens PLCs. I've got my Apogee hardware software systems and all of that. And that's all VLANed out. And there's a firewall that segregates everything from my IT environment.

And then there's all of that. So we don't have to do that. We actually, I like talking to Ben, I call it the wormhole. It's how you get from the alpha quadrant to the gamma quadrant. That's really how it works. And then you just split that out and it's done. And it's transparent. It's easy to deploy.

And it actually provides, in our opinion, a stronger solution to what is a very traditional problem. And that has been resolved by methods that really are not strong enough to support where the technology needs to be. Sorry. Any other questions?

Okay. I guess it's back to you, Ben. All right. Well, thank you, Christina. I appreciate it. All right, thanks. That shows that we need to protect that IoT from the OT. We see that it's flexible, scalable, and it's efficient use of

human resources versus a traditional VPN and faster configuration and hardware agnostic. So we can put anybody on there. Okay. Thanks. Thank you. We can show this in the ICS village right over there. So if you want to see that actually in action, it's over there.