Secure Your Enterprise: Why Over-the-Air Security Access is Crucial for Industrial IoT

Nate: This is mainly speaking to a lot of the values that we talked about in the presentation here. Because if you try to take it from a traditional perspective, and say, "We need a robust security environment," there's going to be a lot of networking changes you have to make to make that happen, both in the immediate, just to make sure your network is initially secure for your operations team, but also ongoing.

As IPv6, say, comes in more into play, or you need to have different site-to-site connectivity options with different protocols, all that requires constant updates to your network, and might require even different networking solutions over time. You might start with one VPN option, but then you decide you need to add some OSPF or BGP routing, to kind of share the different IP stacks and networks from each site together, to help with providing that seamless operations efficiency for your team.

With Atsign, that becomes a bit of a point you don't have to think about anymore with IP networking and site-to-site, you know, kind of network sharing because, each device that you're trying to access for that operations team becomes an atSign. It just becomes an ID that you can then say, "I need to connect to this particular device.” I don't need to know how to get to it, because the device is building an outbound connection between itself and me directly, as a secure, end-to-end encrypted tunnel. So, there's no overhead with having to know how to route back to each site, or how to route back to each equipment, piece of infrastructure. And that's the main benefit that we're highlighting here.

Colin: Building on that, Nate, I would say traditionally, we've overlaid networks. And we've put more IP networks over top of IP networks, like VPNs and tunnels and all the rest of it. And that has worked very effectively, but if you're having to manage those, and worry about them, it's another network to worry about, so you're putting even more workload on your security, so now you have an overlay network, and you've got to manage that as well as the existing IP network that you're using. The Atsign approach is not that. We're not creating overlays. You're at the bottom of the stack, with individual sockets and ports. Now, you can do whatever you want over that, but you're not creating a whole new network. You're just getting connectivity for the smallest thing that you need to do, which is, you know, generally a good security stance. So, that's how you balance it. You have connectivity, but without any attack surface, and you make sure that everything's end-to-end encrypted, but you don't put more burdens on your network staff. You know, it's enough to tackle one network, let alone having overlay networks.

Colin: So, we work very hard at Atsign to make sure that if you have an IP network, then you'll be able to run it. So, the basic constraints are, are you running IP? And have you got access on the device that you want to run it on with user privileges? So there are no complex things to install, which means it can be installed as a container, as a binary, whatever you want to do, without having to change the underlying OS.

So, that's why we can pick up and create your container, and hopefully not have too much pain, because we don't have to play with kernels. Essentially, you just need to have user rights on the device you're running on, and have an IP connection. That's it. And then you can apply it to pretty much anything. We can run essentially anything that's got a processor, from an MCU, to a router, to a light bulb, to anything you like. And then it really, it's down to the hardware you choose to run it on, and in the industrial IoT space, it really is about connectivity to remote devices, and using public networks in a secure fashion. What I mean by that is, you know, 5G-connected, but without an attack surface.

Nate: So, the short answer is yes, it is outside the Atsign connection. But it is reduced vulnerability because it is similar, as far as it's an outbound-only connection that the device establishes via a secure EDP TLS tunnel, to Remote Manager, and it's strictly just for the device-to-cloud communication, for monitoring and managing of the device.

So, there's a secure connection that's established, and again, it's outbound. There's no inbound port or IP address that Remote Manager has to know about for the device in order for it to remotely manage the device and do any sort of communication there. Which is, if you're familiar with other remote monitoring tools, even things like SNMP or Nagios, as far as generic options out there, that is also IP-based, where they have to have that known IP address of the device, and be able to route to it, in order to do that polling, monitoring, and management of the device. Whereas with the Digi device, and its connectivity to Digi Remote Manager, that's all an outbound connection, so there's no knowledge or exposed ports on the device in order to manage it.

Nate: Yeah. That's a very good question, and one that comes up quite a bit in the security ecosystem these days, and the main answer there is to kind of protect your weakest link, because you're only as strong as the person that doesn't take the security training against any sort of social engineering. So, there's a lot of resources and tools out there for doing training for your employees, so they can be aware of what common vectors social engineering hackers will attempt to try to convince them to give access to your network. And that's really your first line of defense, to get that in there.

And then beyond that is where what we've talked about in the webinar today can really help secure that next level. So, say that event does happen, you are compromised, where someone uses social engineering to get into your network. Once they're there, with Atsign, there's no exposure to then have to say, "Well, I need access to this device," or I need to port scan and try to find what equipment's out there, because they're not going to find an open port on the device. Yes, they might find an IP address on your local network, but then there's no way to actually talk to that device unless you have that secure atSign ID to get there.

So, it's really that next level of the secure connection that we talked about in this webinar, that's going to help mitigate the event that social engineering does succeed, but with helping with how to combat social engineering and attacks, and hacking, that's really where the training for each employee at your company comes into play.

Colin: An atSign is a unique identifier for a person, entity, or thing. And you can use it simultaneous for an application, for remote access, for anything, because you're cryptographically authenticated every time. So, you could use your atSign for SSHing, as Nate did, for logging into a Digi router, and also use the same atSign for maybe an application on your cell phone and do it all simultaneously.

So, an atSign's really designed for people, entities, and things. And not only have we got sort of solutions like Nate showed for sort of No Ports and access, but there's a full SDK, that you can actually build your own applications. So, if developers are seeing this and saying, "Yeah, I'd like to be able to do that, and I'd like to do something else," then everything's open source, and everything's really designed for scale. So, you can look at our SDK, build your own tools, or buy off-the-shelf, via Digi, and just install it. There are many options open, and as I say, the, both of the original co-founders, myself and Kevin, came from large-scale infrastructure, so, you know, it was built to scale. So, simultaneous use is sort of, like, a given, I guess, at this point.

Colin: So, with atSigns, you can, as you saw in the control plane, you can actually specify which atSigns are allowed to log in remotely. We're extending that to another atSign for policy. So, each atSign on a Digi device can speak to another atSign, to say, "Is this atSign allowed to log in or log out?" We call that a policy plane, and which is really, comes out of the work that NIST have done. They talk about a policy engine. We actually think that's a whole plane of itself, that, in particular, chief information security officers are going to be interested in, like: What device can speak to what device? Which person could log into what device at which time? Is it break glass? There's lots of options there.

And removing the complexity of IP addresses, and just having a digital identity at that level, just makes things a whole bunch easier. So maybe you need to get some technical support on a device, and give them access. You can do that at the policy plane, so, you know, "What's your atSign? I'll give you access." And then, once they've fixed whatever they have, then you can remove that access. That can be done programmatically as well. So, you can group atSigns, and say, "All these people can get in. Those people can't." There are many, many use cases of having a policy plane, probably many that we haven't thought of yet, but I'm sure, you know, people out there listening have got their own challenges, I think, can be addressed by having this new idea of a policy plane.

Colin: So, atSigns, as I said, the first thing you do when you get an atSign is cut your own cryptographic keys. Those cryptographic keys tend to be stored in secure elements, or on devices that have secure elements. So, those atSign keys really shouldn't get lost. You need to guard them very carefully. But you can actually cut new keys for each device you use. So, if somebody, I don't know, steals your device, you can kill that particular atSign and key combination. You can have multiple keys for an individual atSign, essentially. So, if you use, like, an Amazon Kindle, you have a bunch of Kindles, and you sell one, you can sort of unassociate with your account.

That's the same sort of approach we've taken. And that means that those keys never actually have to leave the device. So, the keys you cut for the Digi device never have to leave the Digi device. And that means the cryptography's really neat like that. It's not like a padlock, right? You can have multiple keys for the same lock, so... Which is how you approach that. Please don't lose your keys, but if you do, then you'll be able to kill those keys remotely.

I wish there were better ways, and if mathematicians come up with better ways, we'd love to include them. But for the moment, that's the best we've got.

Colin: So, as I said, we come from telco backgrounds, and we're really big on that. So, much of our diagrams look like there's a single device, but everything's backed up and redundant. So, we run a combination of Docker Swarms and Kubernetes. And if an individual component fails, then essentially something else jumps in and replaces it. We also have, as Nate talked about, this relay, or rendezvous point in the middle. It doesn't have the keys, but obviously, that needs to be up and running. And we have regional deployments of those. And, as I say, it's open source, so you can deploy to your own relay server if you want to as well. So, yeah, we've thought about as much as we can, now that, obviously, you know, sometimes the large-scale things go down, like a whole data center might go down, so we have redundancies in the data centers, so we're spread across multiple data centers. I think we thought of everything, but you never know. But as soon as more options come available, we tend to use them straight away.