 So there's a lot of places that IoT, Internet of Things could be. And then there's the Internet, or the Industrial Internet of Things, right, IIoT. So those kinds of things are more industrial looking. So they could be smart valves. So normally you'd buy a valve in the old days, it just opened and closed some pipes, and it would talk electrically to the PLC, but not smart. 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 know, 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 with, from the late, early past, or long ago past in our world, 2010 with Stuxnet or Ukraine or lately with, you know, with the Russians hacking into the electrical system. So have we been improving since all those times? Have we been improved since 2010? I think in OT, in a traditional OT sense, yes. But you know, there's a legend that before, 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 there's, 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, you know, the great unwashed masses of those devices can really affect the rest of OT. So it is a good, it's a mixed bag of how we're doing. And where are we going with this? Like, what's helping us to move forward? Well, there's a lot of standards out there. There's a standard for everybody. Some OT, OT installation, some plants use IT standards, like ISO 27001. That might be all they use. Some people, there's 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 and 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 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, okay. All right, so it's just a model of OT. It's a model of industrial control systems. And on the right side is that, 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 would be, 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, right. 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, okay, 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. You know, there's insecure ways of accessing it. There's lots of vulnerabilities in IoT and IOT devices. There's instability with regards to communication so you could break something with sending certain packets to these devices. There's back doors to these devices. There's buffer overflows. There's lots of different, you know, 10 years ago vulnerabilities are now creeping back in because people are using IOT and IOT. So what 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 IOT 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, you know, 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 it goes in a deeper sense. Okay. So what we're looking at here is on the left is a typical IT OT mix on a network. We're doing a high level discovering topology of all devices under under one scan. In the center 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 IP Sec. 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're not, they don't have the background to understand that these are important or worry about those attack surfaces or could just be there being pushed to get this out. And when 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. 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. It was a mouthful. But that was a an exploit in the way XML was parsed, which allow a 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 common vulnerabilities and some of the reasons why VPNs aren't the best solution, even though they can technically be secure. So with domain six 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 and 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 boil down explanation of how this is configured to give an idea. And we have essentially two cameras in 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 the gateway zero and gateway one that you see above them. And then to whatever local network they're on, whatever router 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 the key piece is these are very simple. The it's we're not trying to manage a 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 their 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 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 the MAC address of that camera, which you can see the IP right there. And the the goal is then to to capture that MAC address and to capture the flag area. We also have a a laptop set up, which is monitoring the 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? Yep. Okay. So that's a 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 want 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 something else than that. But any questions? No, this would be you're creating a I'm sorry. You're creating. So the question was supposed to repeat that is, is there any inherent security built in for wireless devices, correct? So it's no there's not. So these are for for Ethernet hardwired devices. It's 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 side 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 that is just connecting those two together. And any wireless or any other connectivity would be on top of your your uncle. So if you were, if you had a wireless access point, say, so you have your your wireless devices on this this land in 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 on Clay 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 IP Sec over VPN? So it actually is not IP Sec over VPN. That is an explanation just a similar concept. So the it. Oh, I'm sorry. Oh, okay. Yes. So these are there. They create an encrypted tunnel through the 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 two. Oh, I'm sorry. Okay. I may have to ask Christina Phillips here, who has 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 an ICs hardware that's been around for 20 years. It's never been hacked. So the thing is the key exchange is done by the secure bridge environment that's 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 dash two compliant. The original spec developed 20 years ago was actually FIPS 140 dash two certified. But it has not been re certified 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 and one door controls and 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, I, 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. That the solution is scalable. It's cross platform. It doesn't care. We can support legacy devices as well as IP devices. So that's the point isn't the tech, the point is that the technology is flexible and that we can actually provide and we, it's an alternative to what are considered traditional ways of providing security. Again, VLAN 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 Apigee hard software systems and all of that. And that's all VLAN 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 how 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, Christine. I appreciate it. All right. Thanks. That, 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. Yes. 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.