Bryan Skene: [00:00:08] My name is Bryan Skene, and I've been with Tempered for about five years, and I am I feel really lucky to be part of this team. It's really fun to work here. Our demo Fridays are exciting because just about every Friday our team pulls something out and shows us something that we didn't think was possible. So anyway, I'm going to speak. I'm going to give you a brief introduction of the platform. Then I'm going to do one, maybe two demos, time permitting. Since they're live demos, probably something will crash. And then after that, I'm going to turn it over to a couple of our really super smart engineers who are going to do a deeper dive into the protocol, the management of identity and trust, the data plane, how our protocol forms tunnels and then cover things like cloud, virtualization, APIs, containers, stuff like that. So I'll get started.
Bryan Skene: [00:01:13] All right. So, wow, I'm hitting you with a big eye chart right away. So this is a network. It's got all kinds of things in it. It's got stuff in the cloud. There are some remote sites. There are mobile users. There's laptops. There's phones. There's SCADA equipment. There's servers - they're in different locations. And then you see all these red things in the picture. These are like gatekeepers, firewalls, routers, switches, places where networking is implemented, where it's done, and places where security, access controls, and rules are distributed around the entire network. And it's kind of a mess. And I'm here to say that Tempered doesn't feel that it's smart enough to understand this or even to try to solve it, because if we could go in here and figure out what all this stuff is and try to connect things that are supposed to talk, then it would be that would be one thing. But then Tempered couldn't go out and get all of the changes made all over the network to make that happen in a secure and a manageable way - so we're not going to solve that. What Tempered does is we use a zero trust protocol to tunnel through the mountain.
Bryan Skene: [00:02:39] And before I jump into the platform details, I just wanted to share with you a couple of things, some of it will just seem maybe intuitive and some of it I just want to let you know, this is the emphasis if you're working in operational technology networks, machine to machine communication, stuff like that, it's very different from humans accessing Web sites and applications. So, number one, like in I.T., availability is everything, but the consequences of downtime are big. So it's not like somebody is annoyed or they have to wait a little bit and the money doesn't transfer right away or you lose a little bit of e-commerce. It's like things are in motion. You could have some kind of a pump goes out, some pressure builds up, something ruptures. You could have an explosion. People could get injured, people could get killed. So if we are going in line, we're signing up for like really high availability. And to be correct and not to delay packets. Devices can't protect themselves and they can't be patched and they're not changed out very frequently. So any of these new schemes then brilliant ideas that people come up with, how are you going to implement that on the existing infrastructure? So best defense for critical infrastructure is to not be on the Internet. So we really believe that that was the best defense. We still think that is the best defense. So we try to help them get back off the Internet or get unexposed to the IT network.
Bryan Skene: [00:04:24] The networks that we see, even though it may look orderly on paper, there's regulatory requirements, there's all kinds of things. It doesn't mean the network is still organized. These things are built 20 years ago over time by people that are no longer with the organization.
Bryan Skene: [00:04:43] The data patterns are different than humans accessing data. Very different.
Bryan Skene: [00:04:50] So networking and security policies together is not so good for anybody, but here what we're talking about, in OT, is people who really understand their domain, their things. They know what should talk to what. They know how frequently those things should communicate, but they don't really know how to create truly secure networks when their stuff is being connected to a different network.
Bryan Skene: [00:05:19] So platforms or the platform that we create has to actually go to the things - the things are on planet Earth. We can't just pick up the things and place them into the cloud and sort it all out there.
Bryan Skene: [00:05:33] They're spread around in different locations. We can't run wires everywhere. We're gonna have to have wireless. That's a reality. And cellular - if you've ever experienced cellular; it's difficult.
Bryan Skene: [00:05:49] And last thing to mention here is that, remote access is really important because things are spread around and people will do whatever it takes to get access to their stuff. They'll bring in their own access points. They'll leave them behind. They'll run a patch cable and they'll forget to unplug it. We discovered that it was very useful to build a remote access solution that is integrated into the security and communication policies of the whole system.
Bryan Skene: [00:06:26] So let's take a look at the platform, and whenever I get a presentation, I really appreciate a little bit up front, like a TLDR. So in one slide, I just wanted to give you what is an Airwall? What does it do?
Bryan Skene: [00:06:41] The Airwall restores a logical air gap by making networks invisible. You'll see a statement like that on our Web site. So what does that actually mean? Well, we have a zero trust network access solution that securely connects things at layer three. It creates an overlay network over your existing underlay network with minor, if any, modifications to the underlay. It handles communications with remote trusted devices through authenticated encrypted tunnels. And it also can segment zones of devices behind Airwall gateways in different isolated port groups. The installation of this system is very simple. You just get the Airwall edge services, you plug them into the network. Make sure that they can see each other on one UDP port for the data plane. Connect your devices either directly or through routes to the overlay side of the Airwall. And you're done. Then the next step is just to figure out what you want to allow to talk.
Bryan Skene: [00:07:51] And we start with zero trust. That means default-deny; it's the opposite of a firewall. So that in these environments that we are typically used to encountering, there's critical infrastructure - and that is the problem. They know what they have and they want to limit access to it. They want to connect to these things - and only from authorized sources. So, we create policy. Creating policy can be a little involved. But once you've got the policy and I'm going to show you this in the demo, it's really as simple as point and click to manage it. And consequently, our users spend time managing their things and not having to deal with the networking details.
Bryan Skene: [00:08:42] So another way to look at things is that we create a software defined perimeter. So on the bottom, you see an existing network that flap thing down there. So we have two devices on the network. We have a device A on the left, device B way over on the right. And they want to talk. We want these two devices to be able to communicate. What would we have to touch or change in the network to allow them to communicate with each other? All this red stuff, we have to make sure that we can get packets through there, we have to make sure that we don't accidentally allow too much through the network. With the Airwall, it deploys gateways in front of these devices to create an overlay network on top of the existing network. And that network is managed entirely by identities, unique IDs that are provisioned before anything communicates in these gateways and managed by the Airwall Conductor. And we also include an identity router on the public side of the network, if you're transiting the public side of the network to connect things that can't see each other directly.
Bryan Skene: [00:10:00] So our solution is implemented in three steps. First, you protect your things. Then you connect your things, and you manage your things.
Bryan Skene: [00:10:09] So when you protect your things, you're using edge services which come in three flavors: there's gateways; there's agents and there's software agents that go on your phone, your laptop; and then there's server software. Let's take a look at the gateway. Gateway, your devices see the Airwall as a layer three gateway, and it can be deployed in physical, virtual, or cloud environments. And it also has lots of connectivity options. On the device side, we can connect directly through Ethernet. We support serial over IP. We have a mod bus proxy built in and we support e-LAN tags and isolated port groups to create these segmented zones. And on the underlay's side of the Airwall, we have different options to connect up and we have intelligent link management software that will intelligently pick and utilize your wire, Wi-Fi, and cell connections. The Airwall Agent allows my phone or my laptop to connect directly through the overlay network, to trusted peer devices through policy. So the agent gives your device, your mobile device, a cryptographic ID so that it looks just like the gateway to the entire system. It has the full stack and has all the capabilities of managing the one device that's connected to it, which is itself.
Bryan Skene: [00:11:57] And it's resilient; IP addresses don't matter in this system. It just needs to be able to connect outbound on one UDP port to create tunnels to the rest of the entire network. The control plane is one TCP port open. You can deploy the agent with mobile device management and optionally you can lock down communications, say if you have a company issue device and you don't want somebody to surf the Internet. So the server software is like the client software in that it is more locked down and has extra firewall rules so that the server can only be seen by authorized clients through the overlay network. Which effectively reduces the attack surface to everything that you have trusted, every device that you have trusted, all the data that leaves the server is encrypted.
Bryan Skene: [00:13:00] So this is a summary of all of the places where an Airwall can be deployed. We have in summary, we have gateways that run in physical and virtual and cloud. We have agents that run on laptops and phones. We have server software that runs on Linux and Windows. Gateways run in various environments with critical infrastructure and data center environments, and the gateways have the intelligent link management for the uplink.
Bryan Skene: [00:13:38] Then after you have deployed the Airwall, you connect things. And usually if two Airwalls can see each other directly, they can form their tunnels directly between them. But if they can't, any other Airwall gateway in the system can be configured to also provide a relay service to its peers - other Airwalls.
Bryan Skene: [00:14:07] So in this picture Airwall one can't get to Airwall two directly - maybe there's a NAT, or there's a double NAT, but both of them can see Airwall three. And if they've been pre-authorized through policy, they will make tunnels through Airwall three. And the first thing you might ask me is...
Delegate: [00:14:30] Oh, just a quick question on that. What do you use for the tunneling technology? Is this something open or do you use a proprietary mechanism?
Bryan Skene: [00:14:43] The protocol is the host identity protocol. And we're doing -it's a proprietary mechanism. Yes.
Bryan Skene: [00:14:53] So the Airwall - let's go back to that picture. Airwall one and Airwall two can't see each other, but they can both see Airwall three; they know about Airwall three - not by guessing, but because the Conductor, the orchestrator, which I'll cover in about five minutes, is spreading the information around in the control plane to each of these endpoints. So Airwall one knows that it wants to form an underlay tunnel to Airwall two here. And it will try; it'll send its handshake packets for the HIP protocol to Airwall two. But if they're blocked, it will also send its packets - it'll race it's packets through Airwall three as well at the same time. And so if the packets between Airwall one and Airwall two don't make it the base exchange, the four way handshake will be completed through Airwall three.
Delegate: [00:15:57] So then just I just I want to understand that. I understand that you have this mechanism beneath. But if we do a sniff on the wire, what would we see? Let's say tunnel protocol. What do you use for the encapsulation?
Bryan Skene: [00:16:14] The only thing that you'll see is the same exact protocol. The host identity protocol encapsulated in UDP packets that would be direct between Airwall one and Airwall two. So it'll look like Airwall one and Airwall three are exchanging UDP port 10500 or some other port - you can reconfigure that. You'll see a host identity protocol headers. But the Airwall three - Ludwin is actually the next presenter. He is going to go deeper into this and I think that's a great question. And I hate to punt, but I'll punt a little. And if we don't answer it then, you can bring that back up and we'll make sure that we get that.
Bryan Skene: [00:17:05] It's really important to know that the relay, the gateway that is doing the relay on behalf of the other two, can't decrypt the information. It can't decrypt the tunnel. All it's doing is NATing the outer UDP header. That's all it has to do. And Ludwin will be able to cover that. So, probably the best way to look at this is with a little example down here.
Bryan Skene: [00:17:40] I'm not great with PowerPoint. I don't do it very often. But here's a sensor and then here's a server over here. And the server over here has the Airwall software on it directly. And the sensor over here is behind a gateway. And notice that they all have these blue addresses - they're all private addresses, sits behind double NAT. And we have an Airwall relay group in the middle here.
[00:18:11] And this Airwall gateway, and this Airwall server have been pre-authorized to use that group of Airwalls that are in the public address space as relays if they need to. So this is how it really works. The sensor wants to talk to the server. It sends its packets to its gateway. The Airwall gateway and the Airwall server will race their host identity protocol handshake packets directly to each other and through all of the relays. There's only four packets exchanged, two each way, and the first one that completes the tunnel wins. That forms the tunnel and then the devices communicate through that tunnel. So it looks like that.
Bryan Skene: [00:19:04] Ok. We've protected our things. We get our things connected. We manage our things. And we do that through the Conductor. The Conductor is the only place where policy lives; the only way to change policy in the system is through the Conductor. The policy is at layer three. The main policy that we manage is layer three policies, device to device trust. And it's a unified security and communication policy in one view; you don't have to go somewhere else and look and put it all in your head and try to figure out where - did I remember to allow something over here? Another layer, something like that. It's point and click. I'm going to demo that for you now. Another thing to keep in mind as a Conductor is the control plane and the management plane. It doesn't participate in the data plane - traffic doesn't go through the Conductor. It goes direct, point to point, secure and encrypted between the Airwall edge services. The Conductor is the single pane of glass. So we have all of these Airwall edge services. We have the devices that they're protecting. The Conductor knows about all of that and manages all of those assets. We have device discovery. The Airwalls can listen for anything trying to use it as a gateway, tell the Conductor about that; we learn; we classify; the Admin can group these things up and organize them into policies.
Delegate: [00:20:47] Bryan, in the event that the Conductor should go down, do we still maintain connectivity and tunnels and establishment between each of the Airwalls and each of the end points?
Bryan Skene: [00:20:58] Yes, that's a great question. And yes, we do. There's not many, but a few of our customers are so concerned about any changes to their network that they preset everything up with a Conductor and then they turn it off. And only when they want to make a policy change do they turn it on. And all of the Airwall end points find it and then they make a change. And then, just the part of policy that changes is spread out to just the Airwall edge services that need to know. And then they turn it back off.
Bryan Skene: [00:21:36] And I know that that actually a good Segway to the next bullet, which is we support both multi-factor authentication to gain management access to the Conductor as well as, the Conductor orchestrates multi-factor authentication for the Airwall agents say like a client machine to gain access to the overlay network to basically log into the data plane. And I'm going to show you that in a second. It also has a complete monitoring, event and action system. It's actually pretty cool. I've built those in the past and I like this one the best - you can do things like, ask a device to send you a Web page, monitor for something in the body, if it doesn't respond correctly, do some kind of arbitrary monitor of your devices or the Airwalls themselves, and then you can take any actions in our system, like creating alerts, changing policy. You can take a device and put it in a quarantine overlay network with the same IP addresses, because remember, we're all in separate overlay networks so we can handle no IP address changes. You just change to another network and quarantine that device. And we can fire HTTP post off to another system to create a ticket.
Delegate: [00:23:04] Hey, Bryan, when it comes to the monitoring event, action alerting, etc., that we can integrate with Splunk or whatever SISLOG preference we have - Is it a custom type? Is it SISLOG type? Like what's the output of it look like because I want to think about integration with some, you know, fill-in-the-blank, my favorite third party, basically.
Bryan Skene: [00:23:25] So we support remote SISLOG as a separate feature from the Airwalls. But our monitoring system will essentially; you'll be able to craft your own contents of an HTTP post to something else. And also, you can bring the metadata from the events that triggered - something happened. You can take that metadata, include it in what you're going to post outside of the system.
Delegate: [00:23:54] And just to clarify, so you live-streaming all the telemetry data to the Conductor all the time?
Bryan Skene: [00:24:02] You know, it's a little smarter than that. Good question. You know, a machine to machine networks, sometimes there are - they don't have a lot of bandwidth. They don't need a lot of bandwidth. But they might be on radio. We can't be very chatty and we can't add a lot of bandwidth for the control plane. So the monitors run on the Airwall edge services. And when they transition from an edge. So it'll monitor something locally. And when some criteria's met just at that point, the event is created and sent to the Conductor. That's for the monitoring.
Delegate: [00:24:42] So you're doing not live telemetry? It's kind of a summary. Yeah? And then a triggered summary is sent back to the Conductor. So I guess it's not absolutely Real-Time. The data that you see there.
Bryan Skene: [00:24:57] That's a you know what I'm going to in the in the demo, I'm going to flip over and show you the real time or the the streaming telemetry that we see, as opposed to this monitoring stuff, which is more of an edge trigger. Reaching a threshold, a ping fails after three tries, after whatever criteria you can figure, and the Conductor, it's pushed down to the appropriate Airwall edge service, which implements the monitor. And only when it fires, that data is pumped up to the Conductor. But there are periodic, you know, once every five minutes, I think, by default. About less than one kilobyte of information, is sent up to the Conductor monitoring a whole bunch of different dimensions of health, C.P.U resources, signal strength, RSSI, RSRP. Temperature, things like that. We're also sending traffic stats up once in a while. No packets and byte counts in and out. Underlay overlay.
Delegate: [00:26:08] Does the Conductor have to have direct access to all of the things that are deployed or is there an indirect communication method?
Bryan Skene: [00:26:15] We're working on the indirect communication method and we're actually going to do that in a really clever way. It's going to utilize the relays. But right now, you do need direct TCP one port outbound from the Airwalls to the Conductor.
Bryan Skene: [00:26:35] Ok.
Delegate: [00:26:38] Sorry. Is that a fixed port, is that configurable?
Bryan Skene: [00:26:42] It's configurable. Both the control plane port and the data plane port are both configurable and the cConductor.
Bryan Skene: [00:26:55] So Conductor can be deployed - physical, virtual, cloud - and one important piece to note is that single tenant. That means that I can give you a Conductor and you can take that and put it in your air gap network where you can reach your Airwall edge services on your private APN, for example, and Tempered never sees that again. The Internet never sees that Conductor. We don't require you to poke a hole in your network to get to the cloud to get orchestrated. Conductors usually set up in an HA pair for obvious reasons. What's really cool with Conductor is you can put your cloud credentials in. Tom Key, our final speaker, is maybe if we have time, gonna give you a demo, a little bit of this. But if you put your cloud credentials in for whatever cloud, pick your cloud, you push a few buttons and conductor will completely hydrate a new Airwall, cloud Airwall virtual gateway, or you can even push another button and have it replicate itself into the cloud and give you a hot standby.
Bryan Skene: [00:28:11] So I'm going to get to the demo.
Bryan Skene: [00:28:15] I'll pause here for two seconds and let anybody have any questions. And feel free during the demo to just break in.
Delegate: [00:28:24] Is there a restriction in which protocols I can tunnel, like only IPV4 or IPV6, or any other IP protocol?
Bryan Skene: [00:28:32] No, you can tunnel anything, layer three and above. In fact, you we carry layer two as well inside the tunnel, which is important in building automation systems and industrial control systems.
Bryan Skene: [00:28:48] So the demo setup, real briefly, you've got a network like the first picture I showed you. You've got some accounting -everybody's working from home, right? So we're all in quarantine. SCADA, Accounting, HR, and they want to talk. There's a site over in Austin that has accounting and HR stuff. There's Philly has some SCADA equipment, sensors, valves. Those things need to talk into the control center up into the historian, the HMI master, the analytics and the SCADA techs want to talk to this stuff and they want to be able to get to this stuff. And then IT has some servers here and there might even be some cloud in the network. And these little red things get rid of my drawings represent all of those gatekeepers that you might have to touch. Can you imagine how many things you would have to go touch and know about - the cell modems, the internal firewalls, switches, routers, other equipment?
Bryan Skene: [00:29:57] So when you install Airwall, you just need to make sure that outbound UDP one port from each of these locations.
Bryan Skene: [00:30:09] And you need to be able to connect to the Conductor on TCP one port. After we implement the Airwall, the SCADA techs, which are in blue will be able to talk to these things and all of these things over in Philly.
Bryan Skene: [00:30:27] So what I'm going to do. Saving.
Delegate: [00:30:34] When you say talk to this, as always, you can have access to all ports? Or is that is also a policy based. You can just allow, I don't know, the SSH port, but don't allow other ports?
Bryan Skene: [00:30:48] The policy that I'm showing you is our main policy, which is layer three. So you have access to all ports wide open, but you can further go into the Airwall, and say that I want to restrict access through this particular gateway to some particular set of layer four ports.
Bryan Skene: [00:31:07] We do lots of things that I wasn't going to dive into. We run Splunk. Sorry. Snort. We run Snort on the Airwall gateways. That's one of our monitors. You can trigger a Conductor. You get to pick from, I don't know - we've exposed like 15 different rule sets and you can activate those. And if they get a hit on info, warning or error, they'll send that to a Conductor. I mean, it does a lot more than I'm kind of handwaving on that. But layer three is the main thing I'm showing you here, but you can also put - you can do layer four. Let's just say that - it's more work.
Delegate: [00:31:53] I got a question, too. If I may, if you're talking about SCADA devices. I met a lot of people in the OT environments and what they usually don't like, if I'm coming up and telling them I'm going to install something on their devices or bringing anything into their networks, that it's anything to whatever they're doing. Usually they start fighting me instantaneously. So do you have any experience with that? What is the cost of adding that to an OT network?
Bryan Skene: [00:32:25] Yes, we have experience with people fighting us when we suggest that they install something on their laptop. So we do have small Airwall gateways. They're almost throwaway. It's like running essentially on a Raspberry Pi. And we can almost give those out. The hardware is almost free and you can plug into those. We have some customers who use our small cellular gateways. We have customers who are happy to use the small wired or Wi-Fi ones. And then, you know, let's say half of our customer base is SCADA and half of our customer base is a combination of things like building control systems and even enterprise, even like a very large global casino or a cruise ship line. A university that's well published on our Web site. Penn State, you know, we have a lot of different environments. It's not all just SCADA. So it turns out when they see how easy it is and whatever their other solution is, they don't fight us. They either choose to use the small form factor units or they install the agent.
Delegate: [00:33:44] Thank you.
Bryan Skene: [00:33:45] The policy that we build, the policy that our users need to focus on looks like this. This policy is all of this.
Delegate: [00:33:59] So in this HR and accounting example, do you see yourselves in the micro-segmentation segment of the marketplace as a way of trying to address micro-segmentation and network segmentation solutions?
Bryan Skene: [00:34:12] Absolutely. Absolutely. If I didn't say micro-segmentation 10 times, I'd probably get punched in the arm by Jeff [Hussey]. So that is, for example, a difference between us and, say, a VPN? Imagine all of your devices being both a VPN client and a VPN concentrator for themselves and their peers. We are protecting all the way through the network device to device; these policies here, these are device to device. These are expressed in terms of groups of devices are allowed to talk to other groups of devices. The Conductor knows which Airwall end points are gateways or are agents for those particular devices and communicates with them. That is what our users get to see.
Bryan Skene: [00:35:03] So I'm going to break out of here and do...
Delegate: [00:35:06] Can ask a question on the throwaway firewalls? Do the support .1X on the untrusted side? So where the UDP is going out to the other ones in the fabric - does it support .1X. So I can actually hook up sensors that do not support .1X on my network.
Bryan Skene: [00:35:26] I'm consulting my expert. Come on. Come here.
Tom Hollingsworth: [00:35:29] Yes. Please approach the microphone so that he doesn't have to repeat all of that.
Bryan Skene: [00:35:32] I will call Rick to the bench. Rick is our lead of our solution architects. And he spends a lot of time architecting solutions with customers.
Rick Suehring: [00:35:43] So Hi, everyone. Yet much like the normal tech field days where we could all go around the room and answer some questions, I'll try to slide in here and and offer a little bit of input. So on the OT side, you know, in many cases, you're right - there's a lot of resilience to installing any type of equipment. So that's where we can slide in. They don't have to re IP anything. We're just masquerading as the new default gateway. And and they don't have to re ip a bunch of backnet stuff. Similarly, in you know, in I.T. environments, we're trying to be the least disruptive and be able to plug into any underlay network so that any two devices can connect.
Delegate: [00:36:32] So in addition, in addition to that, on that underlay network, I'm running .1X with Certificate's, for example. Is that supported? Because that means I can finally get rid of NIC authentication bypass in my enterprise network with identity and security in that underlay, right?
Rick Suehring: [00:36:52] That's correct, yeah. So in an environments where and that's where we would administer trust to the things that are part of the existing network, like AD or a .1X server, to be able to authenticate that, to decide what's protected behind us can connect through.
Bryan Skene: [00:37:18] All right. Thanks, Rick. So if we. Sorry if we set this up right. You'll be able to see. A little window down here - I'm gonna start a ping in a second. And I'm going to log in to a Conductor.
Bryan Skene: [00:37:46] So you remember in our contrived demo environment, there were SCADA techs.
Bryan Skene: [00:37:51] I'm going to try to talk to the SCADA servers. I'll start a ping up. All right. So I'm pinging. The SCADA server here, one 172.16.2.22. And the policies in our system look like this. I highlight something, I'll be able to figure out that I have trust the cloud control center group, trust three things in it. And I have trust to the SCADA secure access group. So this is like various folks that are working from home or traveling, doing remote access, and I'm not in this group. So if I want to add myself to this network, I can do it a couple of ways. I can go in here and directly add myself. I have the agent on my Mac. Here I am. And so visually, I've added myself into the network, but I don't have any trust with anything, so I'm going to go give myself trust. So I trust that this group now trusts my Mac. Like that. And so the minute I did that. My pings are starting to go.
Bryan Skene: [00:39:16] I don't even know what my IP address here in the office is right now, of these, the server that I'm pinging is running and I don't even know what cloud probably AWS or SkyTap, and I don't know where it is, but I'm pinging it - this is all good. I mean, I can take policy away centrally - this like full layer three access to that device. I lost access to it.
Delegate: [00:39:50] Can that trust be set with a with a time based kind of access control, like you only get access for five hours or between a certain set of times?
Bryan Skene: [00:39:59] Ok. Let's do that. I'm going to remove myself from the network. My pings will die. I'm going to go over to - I'm going to go find myself.
Bryan Skene: [00:40:14] And I'm going to give myself a tag. Timed access or something timed? So now there's a new tag. Called Timed. And I'm going to go make that tag expire, we'll give myself, let's say, 60 seconds. And I'm going to save that. So if I put that tag on myself, it's going to last for 60 seconds. So the thing in that overlay. We make this quicker. So there's the group. I'm going to try to join this group, the SCADA Secure Access Group. And so I'm looking at the device groups.
Bryan Skene: [00:41:08] And this group is created using rules rather than manually just putting things we can you can put things manually in a group. But that doesn't scale so well. This one has a rule in it that will include anything that has the SCADA secure access tags. So I could put that on my Airwall. Right. And let's see what happens if I do that.
Bryan Skene: [00:41:39] SCADA secure access tag. And get rid of that one for a minute.
Bryan Skene: [00:41:45] Ok, because I put that tag on my Airwall, my Airwall joined the group. You can see that. My Mac is now in this group. So the diagram of trust here, the visualization looks the same as it did when we started. It's just that I'm also in this group now. And you can see that I'm in the group. Now, I'm going to add myself. I have to go modify - you gave me a little curveball, so I'm going to go and modify the definition of this group to include the new tag.
Bryan Skene: [00:42:24] And just throw this in here like this. Timed.
Bryan Skene: [00:42:31] And I'll go back to my Airwall. And get rid of this one. Which probably will kill my ping if things are working. And I'm going to add the Timed tag. Which will probably give me - and is live; never done this...
Bryan Skene: [00:42:54] I'll probably get 60 pings here. That tag will disappear from - the tag relationship - will come off my Airwall in 60 seconds. We could wait for 60 seconds.
Bryan Skene: [00:43:09] I can tap dance. Come on...
Delegate: [00:43:13] This is actually pretty neat. The I guess another corollary to this. Can you do it between say, here's a scenario. I'm thinking I have a vendor coming in on Friday between nine a.m. and five p.m. to do work on my HVAC system. Is that a capability of this also?
Bryan Skene: [00:43:30] That is precisely why we built this this way. That's exactly what we had in mind. We had requests from customers that said we have a maintenance window. It's two in the morning to six in the morning, on two Mondays a month or something. Can you grant access to these remote access users, but only in these time windows? So we built that.
Delegate: [00:43:56] Can you show us how you do that?
Bryan Skene: [00:43:58] Let's see, expires in nine seconds. Here we go. Just gonna let this tag come off.
Delegate: [00:44:05] Can I leverage APIs to hook into this tags? So my ITSM is actually generating the tags and policy that you can only access that specific device for that specific change request, which is now running.
Bryan Skene: [00:44:19] Now, you guys are giving me softballs. I love it. Yeah, the API for Conductor is full, rich, and exposes everything that you see in the UI. Yeah, and it's in JSON; it's your standard REST, JSON APIs. We've built those - some of the people in our company have worked together in the past and we built APIs before - we made the mistakes and learned from those mistakes. We built a really good API here.
Bryan Skene: [00:44:49] All right, so the tag came off of my system and I've lost Ping. So what else? Oh, I can show you one more quick thing here, and I'm going to show you how we can require that my Mac - maybe we don't trust my device. Just installing the agent on my device, is that good enough to grant me access to the SCADA server or whatever? Maybe not. So I'm going to require - my hands are here, OK. That ping is not going to work. It would have been more dramatic if I had the ping going, it would have died. So I'll give myself the other tag.
Bryan Skene: [00:45:39] Sorry, we go.
Bryan Skene: [00:45:44] I'll authenticate on my Mac.
[00:45:52] Ok. And then I'll save - I'll tag myself here, so you can see, I have a twenty four hour session going here. This - I just required username and password.
Bryan Skene: [00:46:05] We can we hook up to through open I.D. connect for multifactor auth with back ends like Okta, Auth0, OneLogin. We have customers using all of those things in production. Also very common to use AD. We have people and we have people groups and the whole system where remote access users can log in from the back using their credentials in the identity and access management system. And then Conductor learns about those and then they're orchestrated based on the group. So, for example, if you have a group in Okta of SCADA techs, we can automatically apply this SCADA secure access tag when they log in to their Airwall for that session. And it can be timed. I can also end my remote session, of course, centrally like this.
Bryan Skene: [00:47:04] Pings are dead.
Delegate: [00:47:05] So what the AD integration you mentioned - does that require that the AD server have the Airwall agent installed on it?
Bryan Skene: [00:47:12] No, the AD server is just doing its job - LDAP. Ok.
Bryan Skene: [00:47:23] So with that, I'm going to jump back over here.
Delegate: [00:47:29] So it would be the Conductor that would do the AD query, to do the authentication. Correct? And then the agents would talk to the Conductor. I guess it's a little bit backwards. So the agents would talk to the Conductor to initiate the authentication and then the Conductor would query AD to validate their credentials?
Bryan Skene: [00:47:47] Precisely. So does the query at that point. Talks to AD. Grabs group definitions, matches that with information in Conductor, decides to grant or allow or grant access to various overlay networks based on policy like this.
Bryan Skene: [00:48:11] Ok. And the last I'm going to leave you, this is a really quick demo. Tom Hollingsworth, our host. Can you turn on your phone and launch the Airwall agent that we installed last week? So Tom's going to participate in a live demo. This is probably a degree of difficulty goes up to about eight and a half here. We built a simple front end to this whole system because we wanted to give people free trials. Basically, we just wanted to give people free trials. And what you just saw with conductor is really cool. But I'm an expert, so I can fly around and I know about the features.
Bryan Skene: [00:48:53] So we built a single page GUI web app that I'm going to show you. And it's really simple, and it talks to the Conductor entirely through the public API.
Bryan Skene: [00:49:09] There's no cheating, there's no back door. There's no extra thing in the back. So you could build everything I'm going to show you. You can probably do a better job. We just kind of whipped this up. So I'm going to get out of here. Tom's over here in Oklahoma. I think you're in Oklahoma, Tom.
Tom Hollingsworth: [00:49:26] You are correct.
Bryan Skene: [00:49:28] And you are on AT&T because I asked you last week. And you turn off Wi-Fi. So we don't - we can even just get on AT&T because we know some things about AT&T and Verizon. I have my phone. I'm running the agent on Verizon.
Bryan Skene: [00:49:50] My Mac is also going to participate in this, so we're gonna have the green here is the data plane that we're gonna form.
Bryan Skene: [00:49:57] The only things that we have to worry about are these red gears. So Verizon has a one way NAT; AT&T has a one way NAT, carrier-grade NAT, double NAT problem, but we're going to be able to communicate between Tom's phone and my phone and we're on cellular, OK. This puts the pieces together.
Bryan Skene: [00:50:21] So I've got to go over here, kind of grab this.
Bryan Skene: [00:50:27] And then I'm going to switch my Mac, because one question you might have is, hey, can I see this network at the same time I can see the other network I was on at the same time I could see another network. And the fact is, as you switch contexts for your agent and then you join a network that's locked down to just what you see there. So I'm changing. I'm doing it the short way.
Bryan Skene: [00:50:55] With a command line. It's a demo.
Bryan Skene: [00:51:03] All right. And Tom, I'm going to see if Tom and I can see each other.
Tom Hollingsworth: [00:51:09] I'm into my Airwall - I'm connected to the Conductor and I can see you.
Bryan Skene: [00:51:15] Ok. Here's the single page webapp that I was talking about. And in this one, it really is just graphical. So, like, here's my phone and I could give Jeff policy just by doing that. I can give policy from my phone to one of my kids like that, and I can kill policy by doing it that way. I mean, this isn't going to scale to a really large organization, obviously, but it's it's our way of proving our concept. So I've given policy between my phone and Tom's phone. Tom, you are dot-eight. We all have overlay network IP addresses and I see you. Great.
Bryan Skene: [00:52:06] So I'm going to go over to the push to talk. We built a fun little thing into, our iOS and Android client. I'm going to highlight the dot-eight on push to talk here Tom - and Tom, you're going to highlight my phone, which is dot-two.
Bryan Skene: [00:52:24] And hey, Tom, are you there?
Bryan Skene: [00:52:31] Tom, are you there? OK. So we created an audio file on my phone and we essentially transmitted that audio file to Oklahoma.
Bryan Skene: [00:52:43] And I'm on cell, Tom's on cell. It was that easy. That's the way we want it. There's all that cool networking going on that's really awesome to talk about with you guys, but for our users, this is what they want. They want their device to be able to see their other device. Tom, you can send me something if you want.
Tom Hollingsworth: [00:53:04] OK, one second.
Bryan Skene: [00:53:08] And Tom's on mute when he's talking on that.
Tom Hollingsworth: [00:53:12] You're killing it with this demo.
Bryan Skene: [00:53:15] Hey, thanks. On behalf of this - I've got about six smart people in the room that I'm going to pass that thank you to. So then the last thing I'm going to do really quick, it's so easy. As Tom, I want you to browse in your browser, on your phone. I want you to browse to HTTP://10.17.12.2. And I'm going to bring out on my phone a little webcam app, so I'm going to serve a stream from my phone. So Tom can see my camera. I'm also going to do this on my Mac in a tab simultaneously so he can see - this is what Tom should be seeing. Can you see this Tom?
Tom Hollingsworth: [00:54:07] It is indeed. I'm showing my phone to the camera right now. But yes, I am. I am showing a slightly delayed version of your wonderful office view.
Bryan Skene: [00:54:23] Ok. So momento. And with that, I'm going to turn it over to Ludwin Fuchs. Thank you very much.