The Crucial Role of Identity in Securing Industrial IoT

Hello, and welcome to our webinar today on the crucial role of identity and securing industrial IOT. I'm John Tolbert from KuppingerCole and I'll be joined by Ashley Stevenson, the identity technology director for drop. So a little bit about us Cooper and Cole was founded in 2004. We're an independent and global Analyst organization with specializations in information security, cybersecurity, and identity management, and really anything around the digital transformation. We have three major business areas.

We do research related to those topics of cybersecurity and identity management, and we're always vendor neutral and we stay current so that we can provide independent advice. We host events such as this webinar and other conferences and invite people to come in and learn about specific technology areas. Then they'll, we also do advisory where we do decision support for end user companies and help software vendors with their product roadmaps about our conferences. We just kicked off our consumer identity world tour a couple of weeks ago.

Our next stops our Paris on November 28th and 29th in Singapore, December th 13th and 14th. Then later we have digital finance world in Frankfurt and flagship identity in Munich. So for the webinar everyone's on mute, you don't have to mute or on mute yourself. The webinar is being recorded and it will be available tomorrow. We will save about 15 minutes for Q and a at the end. And you can enter your questions anytime using the question chat feature in the go to webinar control panel that you see on the side.

So I'll start off and give kind of a general overview of IOT, the security issues and the need for identity. And then I will turn it over to Ashley.

So again, our topic is the crucial role of identity and securing industrial IOT. So broadly speaking, we'll break IOT device types into two major categories. On the one hand, we have the industrial side, which is usually made up of things that we may be familiar with from days past like SCADA nodes or various sensors or smart cities, initiatives, those kinds of things. And then the consumer side, which we're very familiar with our own mobile devices, different kinds of fitness, wearables, smart home automation, kinds of technologies.

And really the scope could almost be just about any network device at this point. You know, whether it be phones, the wearables, you know, your hay device, kinds of home assistance, home security systems and cameras. We'll talk a little bit more about web connected cameras in a bit smart appliances cars on the industrial side of power plants on the power grids, a very, very important topic. And then also factories warehouses, traffic control systems.

Most, most devices that can receive some sort of network interface. These days are receiving a network interface to be able to collect data, process that data and use that to make better decisions. So one of the reasons that we're, we're talking about the need for identity is you may be familiar with last year. That we're a number of very, very large scale distributed denial of service attacks involving OT devices. And the magnitude was just absolutely huge. If you look at the, what happened with security researcher, Brian Krebs, he was attacked. The O VH hosting provider was attacked.

And these were in the 600, 700 gigabits per second range, which was just, you know, a few years ago almost unfathomable. But the big one that happened was against the D YN DNS provider. And that was over one terrabit per second back in October. And it was attacked by the Ray, but net.

And again, to give you an idea of the scale, this botnet was a bunch of web connected cameras with hard coded username and password that were compromised by Marin malware. And it was composed over 150,000 members, and that outage affected large metropolitan areas across the us. And to some extent, other places around the world as well. And it went on for hours. So how this works is in this case with the more button at the bad guys were able to take over the devices, you know, install malware, in some cases, use the default username, admin password combination, get them in the botnet.

Then they're able to do, you know, command and control over hundreds of thousands of devices here, and then issue orders to go attack particular targets. Some of which we were just describing there.

And again, they can, they can call on vast numbers of resources and, and really hit a target very hard, a tear bit per second, just a, a huge amount of data. That's difficult for even some of the larger ISPs to, to adequately defend against. So in order to be able to do identity in IOT, which is a good precursor for cybersecurity with IOT, these devices have to be able to communicate. And there's a wide variety of implementations of IOT devices. Some are always powered on some aren't, some are always on the network, some aren't.

And in the case of industrial IOT, many of them are wired to the network. Well, probably the majority are wireless. And then looking at the transmission and transmitter types, some can communicate only across a short range, think of like Bluetooth or NFC or, or wifi while others use very, very long range transmitters. There may be agricultural sensors in the field that, you know, communicate with the home base meters and meters away. And then there's quite a disparity in the different kinds of communication protocols and methods that are used by these devices in order to do identity.

If we think about the need for credentials, again, due to the proprietary implementation, in some cases, there's really no way to get good, strong digital credentials onto devices, check certificate status. If you're doing some sort of X 5 0 9 based identity or replace them, how do you update the attributes or encrypt communication?

You know, many are sort of very specific purpose devices. So you really can install third party security to manage them, or sort of asset management software.

And, and in some cases the firmware or software can't even be updated. So it makes it very difficult to prevent them from becoming involved in DDoS attacks against other targets. There are three major TCP based communication protocols. We'll just look at a alphabetically MQTT message queue, Tory transport. It's a publisher subscriber it's and Oasis standard generally involves fairly small bits of data, a lot oft devices and home automation environment use MQTT.

Again, it's TCP based. It lends itself to traditional firewall types of methods. Rest is an API that management applications will generally use for moving information around about T devices, X and PP think that as the old J protocol, most instant messaging programs use it. It's it's to announce presence and then be able to communicate between nodes. This is more common for, you know, some of the industrial and medical and environmental monitoring monitoring applications within IOT on the UDP side, where transmission acknowledgement isn't guaranteed.

We have the constrained application protocol. It's, it's mostly for resource constrained devices.

Again, ones that may have small purpose built processors and limited memory. They're good for things like sensors that go in wireless sensor networks that might be involved in environmental monitoring, monitoring, air quality, water quality, those kinds of things COAP proxies can be deployed to separate that traffic from general use networks. And that's a good technology insertion point to do firewalling and, and be able to write policies based on device identity.

So device identity, we're all familiar with the concept of user identity and to some cases now, application identity need to be able to map who can do what with applications. Increasingly we're seeing a need for device identity management to be able to enumerate the devices and, and then control who does what with them.

So you could write policies based on the device identity in conjunction with user identity, to decide which traffic can be permitted through certain gateways or denied, and then do quality of service, types of policies that may throttle or limit data transfers between IOT devices and other networks as well. This also gives you the opportunity to control which users and applications can read the data coming from IOT devices. And probably most importantly, in case of these distributed denial of service attacks control, which users can administer those devices.

So in order to get device identity going, we'll say there's four major steps to handling that first, the devices have to be registered, get online, get within the identity management or asset management system. And then there's authentication. How do the devices authenticate to that system, to the network in some cases, how are these devices managed? If we're using some sort of crypto or X 5 0 9 scheme, how do the attributes get updated? How do we handle certificate checking expiration and replication replacement of certificates?

And then lastly, just like when a user moves on, it needs to be deprovisioned from the identity management system, when we're no longer using IOT devices, they need to be decommissioned, hopefully. So that, that communication can then be turned off.

And again, the device can't become part of a bot net to attack someone else. The I ETF has a specification. It's a profile of the well known all off two it's the device flow for registration. This is a good new standard way of associating OT devices with user identities, as well as groups. It's a good first step to be able to start doing identity management comes with specified device client that can then perform the standard communication with an oof two device, oof, two authorization server. And it's kind of a bear token model like oof. Two is itself on the authentication side.

This is where things can get really interesting. Again, username, password, very common, obviously not the most secure way of doing things, especially in cases where the username or password can't be changed on these devices. So we definitely like to see device manufacturers move away from this method, SMS OTP. There are some devices where you can receive a code on your phone and then enter that in the registration management screen to associate the device. This is not very common at this point.

There are also proximity authentication methods that you use Bluetooth or NFC, you know, get it close to a device and be able to associate the IOT device, say with, with a mobile phone or tablet or, or some other management device. Again, this is less common, but I think probably will become more common in in the years ahead. There's another really interesting one that called physical and clonable functions. And this is, think of it almost as a fingerprint. It's derived from the characteristics of the manufacturing process.

You know, what's in the Silicon, what's in the IC left over from the manufacturing process. So there's a little bit of debate about how truly unique they are, but there are some companies that are doing some very interesting work on leveraging these as a sort of fingerprint to be able to have some very unique identities. I think this is an interesting area, and we'll have to keep an eye on this to see how this turns out as a, an identity method, Fido UAF, you may be familiar with the phyto mobile and two factor authentication specifications.

I think there's probably room in IOT ahead to use something like Fido UAF. It has some of the benefits of PKI type of identity credentialing system without necessarily having to have a full blown CA and the keys that get generated and passed around to the devices can be unique to each application. So there's definitely some security and privacy advantages there.

I think we have to wait and see IFT device manufacturers see the value in leveraging something like Fido UAF, and when it becomes Fido 2.0 probably next year, and then crypto and certificates PKI, probably the most robust method, but it also has lots of hardware requirements that may make it more difficult for some of the less capable hardware and IOT devices. But definitely there's a, a well understood infrastructure, lots of software that can issue keys and do the revocation and replacement of certificates.

So cases where we wanna do public key crypto, obviously we've gotta have the key there's challenge response. I dash two library, there's the sticky, tricky question of what to do with the certificates.

CRLs, aren't exactly efficient. This piece a little still has deployed in all cases as you should be. And then key management itself software that can accommodate the scale of IOT, particularly on the industrial side, being able to manage these kinds of devices within your factory or warehouse or smart city kinds of applications. Then in order to increase security, global platform has a couple of specifications called secure element and trusted execution environment. And think in terms of like an Android operating system, the secure element is a, a protected area.

That's really only accessible to trusted apps that are running in the trusted execution environment. So think about, you know, a U I C C or SIM card, like in your mobile phone, secure micro SD cards. And there are some specialty hardware embedded chips that do crypto that can be used, used to secure elements.

Again, the idea is to be able to lock other applications out. This happens as a result of using the trusted execution environment, which is really a secure virtual operating system within the, the devices OS itself. And it has features like limiting which applications can look at the protected area, prevent the key tampering, lock other applications out of memory.

It's, it's really, I think, a necessary architectural component, especially for going to build identity management systems that are leveraging keys and certificates. It can, in some cases be trivial to write malicious apps that can, can read other apps data so we can prevent bad guys from messing with keys and certificates. We really need to insist on using things like secure element and trusted execution environment for that from an architectural perspective, IOT and API gateways are coming into place now.

And I think these are really good ways to not only control the traffic, but you know, if you're familiar with the concept of an API gateway, it can stop authenticate the sender inspect and then authorize, you know, particular types of traffic between devices of whole networks. And this is a great place to do policy based access control for things like MQTT and X and P P that we we're just talking about. And then also COAP as well. And then COAP proxies are available. They can be, you know, surrounded by filters or firewalls.

And then now we also have dedicated OT gateways, which translates some of the non IP traffic to IP. And I didn't really have a chance to get into that, but besides the different protocols that we were talking about in TCP and UDP, there are I OT protocols that are, are not IP based at all. So that's where the IOT gateway comes into play. It can also be used to filter traffic in most cases, and also integrate with the rest of your security and identity infrastructure and on consumer identity and access management solutions.

With regard to IOT integration, some CIA platforms do allow some very simple synchronization oft device passwords. This is more on the smart home side though, rather than industrial side IOT device association.

In, in some cases they will allow you to like import information into an LD data database where you can begin to write some policies around that it has some advantages, but not nearly enough yet. There there's a lot of work that needs to be done in this area. And then again, oof, two device flow the I ETF standard, but I think the, there, there is a need for additional standardization in the IOT communication space, as well as to standardize how IOT device identity is managed. And with that, I'd like to turn it over to Ashley Stevenson from, for drive. Excellent.

Well, thank you, John. Thank you for setting the stage with all of the pieces and parts that we're dealing with in IOT security today, and especially in the arena of how digital identity impacts those things. So I wanted to pick up where you left off and basically talk about for drop a little bit and how our edge security offering is filling in many of those gaps that you discussed today and, and answering those problems related to IDs critical role int security. So I'll take just a couple of minutes here and, and I wanna tell you about for drop a little bit.

I want to give a baseline kind of foundational pieces of digital identity, as we say it, to set the stage for the different things I'm gonna talk about, and then we'll go into what our new offerings are and how they help fill these gaps for security from an identity perspective in, in IOT. So since 2010 Ford drop has been really helping our customers transform their business using digital identity.

And so we, we've got about 1.4 billion identities that we're serving today. Our business is worldwide. So about half of our business is in the Americas and the other half is around the rest of the world. You could see the rest of our stats there, but we we've definitely seen great growth in consumer identity and access management. And now in managing the identities of things and building relationships between those things and the people and organizations that use them. So this is a kind of a view of identities evolution and where things have been going.

So identity started off here in the lower left hand corner of the slide where you see legacy identity, really initially identity was compliance driven, and it was about managing the employee's identities and access and provisioning for things like synchronizing with an HR system and being able to provision email accounts and provide single sign on and be able to do re-certification to know, and be able to report on who has access to what again, to maintain regulatory compliance.

But after that, as things began moving from, you know, the moat based architecture and VPNs to a, a mobility paradigm where the people could access just about anything from anywhere. And the digital transformation really took hold, where everyone's business processes were now online and a critical differentiator for all businesses was how well you were able to give your customer in a good online, low friction experience while still maintaining security. So the ability of your customer to come and sign up for a new account and to reauthenticate again with low friction, but still high security.

That's an area where for drug is really accelerated and where we've seen great growth in our business over the last 10 years, but what's, what's happening now.

And what's been happening for some time is this third piece here called relational identity where it's really becoming important as every single business and their business processes include some sort of connected device to either help the business by the data that the devices generate for analytics and for better business decisions and insights, or whether it is being able to give customers a better experience with wearables, whatever it is just about.

Every in fact, every now major business line or major industry has some sort of devices that they're connecting up to serve their business processes ultimately in their bottom line. And what that comes down to is you need to be able to manage those relationships between the people and the things as well, because if you are registering and, and, and managing identities of your connected devices over in a silo somewhere else, it's not gonna lead to the business value that you actually need to be able to get, get what you need out of those devices in your business processes.

So this is where for drop has been, has been building for some time is around being able to manage all of these different devices together with our authentication and authorization and so forth in a single platform. Now, I don't wanna assume that everyone here in the audience has focuses on digital identity every day. So I just wanna take three slides and talk quickly about the foundational elements of digital identity from our perspective. And then we'll build on top of that. So when we say digital identity, we're talking about taking information about something that is true.

This could be a person, well, a customer, a car, a device, and a factory, whatever it is, and turning, and then storing that as an identity record in some so and managing the life cycle and change ice attributes over its over the time that it's managed until, as John mentioned, it goes through decommissioning. So there's a constant there's changing and updating to the attributes, ownership, location, all those different types of things. So getting that information in to it, turning it into a digital identity record and managing its life cycle is the baseline of digital identity.

So that's step one out of four in steps, two and three it's about credentials in authentication. These two sort of go together and a user writing in password, or whether it's a PKI certificate, a credential is essentially something, a token, something that binds your identity attributes to something that is trusted by someone else in the context of a given organization or a use case. And we'll talk more about different types of credentials and how they apply the humans versus devices coming up.

But suffice it to say this credential is what bridges the identity record of a person or a thing to some type of runtime system to say, yes, this, this person on the other end of this transaction or this device is who they claim to be to a high enough level of assurance. So that, that third piece in, in the, in the foundation of identity takes place, which is authentication saying this user or this device is authentic up to some level of trust. That is enough for us to allow this, this subject to do whatever it's requesting to do. So now we've got an authenticated user or person or device.

The last piece is authorization. We know who you are up to a certain level of trust. What are you allowed to do? Are you allowed to delete someone else's files? Are you allowed to see all of the data? Where are you allowed to go? And so making authorization decisions is that, is that fourth piece.

Now, of course there's many other pieces that wrap around this, like decommissioning, like the ability to, to do reporting and, and so many others. And one of the ones that, that I hinted at earlier is the ability to build relationships between different types of identities.

So within, for drop, we say the term often identity relationship management and the ability to have an identity for everyone and everything and tying them all together. So here's an example of relationships between all different types of identity classes. So you see here, we've got people identities that could be employees, customers in an automotive scenario. It could be drivers, maintainers, renters, and so forth. We've got the identities of the cars themselves as an, as a complete unit that could be based on, let's say the vehicle identification number.

We've got different cloud services, not just the cloud, but many different cloud services that would connect to a device or that a device would connect to, to send and receive and share information. Each car has sensors that are, and, and different sub computing systems inside of each vehicle that have their own identities, including software that runs on many of these systems, including the head unit for, for the infotainment system. And then finally infrastructure, what are all the different things in a smart city or in a, in a connected world that that vehicle is gonna connect with.

So not only do we need all these different types of identities, but they have to be interconnected with each other, and we have to understand those relationships. So this is a quick view of the for drop identity platform, all of the boxes to the left of the two that say new represent our, our current backend platform, if you will, that runs in the cloud and your cloud and your data center installed software that runs wherever you want it.

But what we're adding and changing now, where you see for drop edge security is that we're adding software that runs out on the edge that actually can run on a connected T device. And that can help us establish trust in that device's identity. So the Ford drop identity, edge controller and message broker are the things we're gonna talk about today.

Now, I think most of us are familiar with the, the, the trouble with today's IOT security that we see on these slides. But of course, with many IOT devices, especially leading up to the past 12 months, security is definitely not built in by design. That's a pretty typical pattern with things that are new is getting things out to market first and fixing security later. Then there has been an initial focus on transport security for IOT devices, but that's not enough in itself.

We know, as we heard earlier from John that hard coded usernames and passwords, you know, our, our problematic, we hear about the webcam compromise PPI certificates can also be problematic in terms of managing, especially certifi certificate validation or verification from devices that may have limited connectivity. And the final thing here. And if you take one main message away from what I'm talking about here today is that an untrusted device equals untrusted data.

And the thing that we're really work working to solve and show with our edge security is about trust in devices, it's trust in the source of your device and trust in that data that comes out of the device. So while it is important, and it is also part of the whole IOT security spectrum, if you will, to have threatened vulnerability management, it is important with identity systems, which for drop can do to control who can see devices and who can access devices and what devices can talk to others.

But all of that goes back to this root of trust of, do you trust that this thing on the other end of the network is what it's really claiming to be? And how do you know that? How do you know that it is what you think it is? It's that spoof, and it's not something else that's sending bad data or is, is being used to gain access to the rest of your devices on your network. So how do we establish a sufficient level of trust in those devices so that we can build all the rest of the functionality that we've talked about, which digital identity provides on top of that trust.

And that's what we'll talk about here in the next few minutes. And I think the best way to do that is with this little grid here, you know, the title is trust in people and trust in devices. And I wanna compare some credentials going back to when we talked about credentials and authentication that people use and how they could be compared to different levels of assurance of how a device can onboard itself. So let's actually start off at the bottom. If I am someone at a conference or, and I have a conference badge on my lanyard, or I have a business card, I could give that to you.

And that would instill a certain level of confidence that I am who I say I am, but on the other hand, it wouldn't be too hard for me to print my own business card or to borrow someone else's conference badge to say, hi, this is who this is, this is my name. And it may or may not be true in the device context. This would be a lower assurance device attestation, or the initial part of an onboarding where a device could, you know, derive something from what was on the device or something, creating something unique.

And then using that to register that device's identity from which all the other pieces would, would flow the credential, you know, the different flows, the authentication and so forth. So this may be a very viable solution for devices that have low level of assurance requirements. It may be very valid, but what we've seen is there are many other other use cases out there where we need a much higher level of assurance of how the device is initially onboarded, which is a technology problem. And also a process problem. We need better ways to have higher level of assurance.

And that's where we're gonna get to what John talked about earlier is the global platform's trusted execution environment and chip level security. So let's work our way up. There we go to the second level here, we have a driver's license.

So in, in the human world, this is a medium assurance credential. I'd say it's trusted by a smaller group than the passport, which we'll get to, but it's trusted basically within, let's say in the United States, it's trusted within the country across state lines and so forth. And this would be on a device level, a medium device attestation.

So let's say that this includes a PKI certificate or includes some sort of crypto credential, but that credential is stored in the operating system of the device, meaning that if someone can access the OS, they could compromise or get access to the key material for that device. And so it has a stronger credential, but the credential is not as well protected. It doesn't have, let's say as many anti anti fraud devices tied into it, but it is definitely better and more trusted than a conference badge or a business card.

Now, if we move up to the top and we talk about passport level security, and let's start on the human side, if we think about what it takes to get a passport first, you need your secure documents. You usually need to go in person to maybe a post office and sign something, but you need to have your birth certificate and another form of identification. That was sort of like your, your, your initial identity documents. If you will, to get this passport in the first place, once you get this passport, it has many different anti fraud capabilities.

It has part of your identity stored in a chip in the front pocket of the sleeve in some cases. But the point is it's a high assurance credential, and it's based on strong identity proofing. So if we think of this now, in terms of a device that is using a trusted execution environment where the private key is generated inside of that, inside of that secure element and never leaves, and it is actually trusted at the chip level. Now we're talking about this strong device at a station with chip level credential security.

Now that's the technical side of it, but the other piece is somewhere in the line of, of this device being manufactured or deployed a trusted human.

Since all these devices are ultimately agents of humans, a trusted human has to initiate a process so that when that device does ultimately come online in its production environment, it can attest itself securely through cryptographic means to say, hi, I am this device that you initially set up, and then it can go through a process of getting a strong credential that can be, that can be used to build a chain of trust so that the device can, can operate in trusted environments from device to device, device, to cloud and so forth in the most trusted way possible.

And so that's, that's what we have built with our four drop identity edge controller is the ability to facilitate that process integrated with chip level security in order to securely onboard. These devices have the strongest root of trust, if you will, and then be able to generate web-based standardized tokens like oof tokens, open ID connect, token tokens, and jaw tokens that are based on that secure chain of trust. That was started from the very beginning in the secure element or the trusted execution environment of that device. So what is the edge controller?

It is four drop software that will run on edge hardware that can actually, you know, run software packages. So these would be smart devices, intelligent devices that would bet gateways that would then connect, let's say to other smaller, more constrained devices that, that, that could onboard. So there's no passwords involved in here. We don't use full P PX 5 0 9 certificates. Although we do use the asymmetric key pairs and our own key management, but this does allow us to have that hardware route of trust.

It allows for simple and easy onboarding into our backend access management piece of our platform. And then it allows us to manage those secure credentials, doing data, signing, encryption data tagging, and so much more. Now it's important to understand that IOT is, is everywhere. It's not just in, you know, one or two industries. I talked about this a little bit earlier, but this solution really is edge security for all different industries. So if we see on the left here, starting with edge services, we've got any kind of different IOT device.

The edge controller is connecting to that and allowing for device discovery at the station authenticity. The other piece of our, for drug edge security is actually our message broker earlier. John talked about protocols like MQTT.

So the message broker works in con in concert with the edge controller and allows us to authenticate and authorize MQTT messages that when, when a device or a service wants to either subscribe to an MQTT topic or publish data to that topic, we can with our backend platform over MQTT authenticate and authorize those devices to protect what messages are subscribed to, or, or are published through through that channel, if you will. So you see our, our unified platform, which you saw a few slides ago, our access management identity management device at station and device registration.

And we're also building cloud microservices that will allow us to scale up even further with different services related to IOT. And if you do wanna learn more about what for drop is doing with microservices, we actually have another KC webinar coming up on December 5th. So check that out and be sure to tune in. If you're interested there, I'll go into one other industry example in transportation before I wrap up, and we go to questions here, think about the automotive industry, right? So think about a car.

We talked about a little earlier as a rolling IOT ecosystem, each car, and the ability of all the different subsystems of the car to communicate through the car, through that car, single cellular connection, think of autonomous driving lane departure, you know, skid control, your infotainment system, all of those capabilities. You want to be able to onboard each of those devices through the vehicle itself as a trusted identity. So that that vehicle can be trusted when it's talking to traffic lights. When it's talking to smart parking, when it's talking to toll tags and so on and so forth.

So Ford rock is a member and supporting member of automotive grade Linux. And we are basically the security layer or the identity layer, if you will, within AGL, which is essentially an, an operating system for the vehicle that would've at first run in the infotainment system and allow users to interact in a with vehicle. What are we doing? Automotive, we're working on authenticating drivers and passengers to the vehicle. So that's person to device authentication, profile management in the cloud for in vehicle personalization.

And then also with the of that vehicle and all the sensors and software and in pieces and parts that are a part of that car's IOT ecosystem to, to manage their identities in a trusted way, and build those relationships with the Ford drug platform for vehicle to vehicle, vehicle, to smart city and vehicle to what have you. So X vehicle to any other connection. So that concludes my presentation here today. I think that leaves us some time to take questions. So I will turn it back over to the moderator for questions. So let's check here.

First question we see is exactly what types of devices can the edge controller run on. And can you secure small IOT devices that don't speak standard web protocols, Right? So the edge controller itself is a piece of software that can run on small smart devices, but it does need to run on some sort of device that has enough network and capability to speak, you know, web protocols, HTTP. Hopefully if you are gonna go high level security, it would have a chip that could support the trust execution environment and so forth.

So you're not gonna find the edge controller running on a tiny little sensor in a car, but the architecture of the edge controller is such that you run it on what would be considered the IOT gateway depending on the system. So if you're in a factory, you've got many different sensors that would connect to a gateway over there.

Native IOT protocols that gateway itself would running the edge controller would then be able to act as the proxy to, in a trusted manner, since it onboarded itself, initially to onboard those smaller devices, create identities for them and create relationships between the, the organization that owns them, the location, the edge controller gateway, and all the different devices and where their locations are. So if we go back to the connected vehicle example, the infotainment system would definitely be powerful enough to run the edge controller. And that would onboard itself.

Initially when the car is rolling off of the assembly line, establish a trusted identity, and then be able to, to subsequently onboard the automated advanced driver assistance system or the a, a, the systems that run the, the connected dashboard and whatever other subsystems are in the vehicle, sensors and software could be onboarded as their own unique identities, and then could be related to that car as a unique identity itself, probably be via the, the vehicle identification number. So that's, that's one PR real world industry example. Okay.

Next is how does the edge controller integrate with the existing for drug platform? Sure. So we have two new pieces that will be released with, with the edge controller later this year within our access management platform. And those are new authentication modules, and that's what the edge controller software talks to from the edge in order to initially attest and register and update and request credentials from our back end. So we have a new attestation authentication module and a new registration authentication module, and the edge controller uses those to connect back.

And that's how it will cryptographically allow the device to attest itself and do signature verification and so forth, and then maintain the identity attributes and the ongoing registration and credential management for that device and the other devices that it may manage on its behalf. Okay. Can for drug secure edge security sign and encrypt data at the edge before sending to the cloud. So the short answer is yes.

And that's one of the, one of the advantages of using the cryptographic key pairs that we do that are in a trusted manner, is that once we have those now, the data that is flowing from that device can actually be signed and, or encrypted before it leaves. So that not only do you have transport security, but you have data level security for that data, that's flowing out to the cloud. And also the ability to tag that data.

So, you know, a very big piece of the value proposition in many industries for connecting devices is all of the different data that flows out of those devices and the ability to not only ensure that it's secure as it flows, either to other devices or to the cloud is very important, but also the ability to separate it so that you can a comply with privacy and, and consent requirements, especially with upcoming GDPR regulations in Europe, and, you know, other emerging privacy requirements, and also to be able to monetize that data.

So if you think of a data stream, that's coming off of a connected vehicle or off of name, your use case, you may have connected information about the actual person who's in the vehicle and how they're driving and where they're driving along with how the car's performing and where it's going. And other things that third party auto parts suppliers or manufacturers may be interested in. So the ability to not only secure that data, but tag it in a way that you can separate out this data is user private data. So that goes over here, this data is intellectual property data of the OEM.

So they're not gonna share that. And then this is what will monetize the other third parties, pretty sensitive pieces monetize this data across many other different industries. So that that's a big business value proposition for these connected devices.

As I said, and this, this edge controller really enables businesses to have high assurance in the data that they're actually receiving on its provenance. And, and to be able to be sure that they're not sending data somewhere, that they shouldn't. So what other device manufacturers and other organizations do you partner with? Right. So partnership is important in this arena because when you want to integrate all the way down to the chip level, you have to, you have to be able to work directly with how those chips, how, how those chips handle this type of security.

So I'll mention three representative, but we're working with many other vendors in the industry first arm. So Ford drunk is partnered with arm, and we are directly integrated with arm trust zone, IE trust execution environment, which allows us to our current software to create and have created that private key in the secure element, in the trust execution environment, without it ever having to leave. We are also partnered with Dell and EdgeX Foundry.

So running on the, on the Dell IOT gateways and being a, a contribute a founding member and contribute to ejects Foundry for that security paradigm. And also finally, as I mentioned in the automotive space, being a member and a contributing, basically the, the identity layer, if you will, of automotive grade Linux in vehicle, which automotive grade Linux is an organization under the Linux foundation. So that's three examples of, of industry partnership that we have related to this. Can you say a bit more about the chip to cloud security?

Yeah, absolutely. So I guess starting off with, I, I just said quite a bit about the, the, the chip piece, right? But the way that that gets kicked off is that before a device is deployed, and this could be on the factory floor, this could be when a device is purchased by an organization, but before it's deployed the first step here, and I mentioned, it's not just a technology issue, it's a, it's a process issue.

There, there is a, there's a process by which a, a secure, a trusted person who would be authenticated at the highest level initially, would be responsible for getting the software onto the device and doing the initial process where the key is generated. Hopefully it's generated in the, in the secure element and then public keys are exchanged between the device and the four drop back end. So what this essentially does is this creates the device's initial identity record in the backend before it ever comes online in production.

And it creates sort of that seed, that cryptographic seed, so that when the device comes online, it can call home and say, hi, I, I'm sending you this signature to prove that I am the device that you, you know, seated with an identity back before you deployed me or back on the factory room floor. And, and that is the attestation piece that is the attestation authentication module. So following that piece, the, the edge controller after that attestation is done, then goes into registration where additional attributes about the device are sent over HTTPS to our backend.

The identity record is updated, and that device is then authenticated into the, into the, for drop backend, meaning it can then make requests to, to have an O off token and open ID connect token, a jot token that it could use in a secure chain of trust to go present to another device or to a cloud service so that it could be authenticated because let's face it as much as PKI and X 5 0 9 security is, is a part of I T I don't think we're gonna reach a point where every single device is using X 5 0 9 client off to be able to authenticate to cloud API, to get some information or to send some, send some data.

So we need to be able to have that secure chain of trust, where you can say yes, that this token goes all the way back to a high assurance at the station authentication, but I'll accept this token as authentication because that's the standard way that we do it in web and cloud API. So it supports that. And then again, that used for signing and encryption of the data that flows out, You know, know the X 5 0 9 definitely has its merits, but it's even with, with PCs and bigger devices that we, you know, have possession of every day, it can be difficult to do the management there.

So things that are often found in the field sometimes literally, you know, X 5 0 9, maybe a very difficult to work kind of solution. So that's a very interesting approach, Right? And I think the final point to that is that it's important to stress that.

So once we have a trusted device, we've gone through this process, a lot of the value lies in being able to dynamically understand where it fits with other devices, with the people in the organization that owns the devices with the federated partners that may wanna consume pieces of the data, being able to build those relationships in a single platform like the, for drug platform, so that your data about your devices is not siloed. Often some asset management system, or, you know, a lot of times we talk about, okay, we need PPI credentials for a device and that's identity.

Well, that's not identity, that's just a credential. And it has some, some pieces of an identity record, but being able to have a full identity record and identity management and manage different credentials for the devices, and then build those relationships and manage the authorization of who gets to see what, and even if it's a service to service or a device to device and insight on what data can go, where all of those different things are opened up.

Once you are able to put these identities and their attributes and their policies into a single platform, that's where you really open up the value. Yeah, I would agree. We've mostly been focused on the industrial side. What do you foresee, you know, using a product like this on the smart home side as well? Is that something that may be in the future? I do. I definitely see smart home smart city and especially transportation, right? Different devices in different transportation.

And this is where you combine not just the device management and the relationships on a single platform, but now we're gonna combine sort of a, a new paradigm if you will, with an IOT, which is user to device authentication. And in some cases, maybe without a mobile device, but even if it's with a mobile device, the idea that a user can be authenticated to a car or a piece of construction equipment, or, you know, a jackhammer, a slot machine, a house, right.

You take all the paradigms that we've had in traditional identity management, like single sign on, for example, and you apply it, let's say to a smart home where you're going to an Airbnb and you're able to authenticate to, you know, the main device that supports the gateway of all the other devices in the house. And suddenly all of the connected devices in the house, sort of, you know, take on your profile or report to you and allow you to manage that house for the time that you're in it.

And then your time comes and log out or your, your, your staying session expires and everything goes back. So the ability to have a devices, be identity aware, and have a context of who is using them and what they're authorized to do will, there's definitely a, a need for that. I know the automotive industry is, is definitely looking for how do I have, first of all, the automotive industry needs to monetize services through vehicles and not just sell vehicles anymore. Right. So how do I know the person who is in the seat? How do I authenticate to this device?

That's the car so that I can then help sell and broker user based insurance, so I can sell services to that user through the vehicle. And then I can also combine knowing who's in the vehicle with what the vehicle's allowed to do.

If you imagine a fleet scenario where you've got a police officer emergency responder, and the police officer authenticates to the vehicle and has an attribute of sworn law enforcement officer now, because the vehicle knows that there's a, a valid police officer in it, the vehicle itself is authorized to send signals to automatically change traffic lights or open gates and emergency situation. Whereas if I steal the car and I'm driving it around, it wouldn't do any of those things for me, because I was not authenticated as it trusted police officer.

So I think that we'll see many upcoming scenarios about a user to device authentication and the relationship between the user and the device and what they're allowed to do together. But of course the device has to be a trusted identity in that, in that value chain, in order for it to work In those cases, similars proximity, authentication methods will probably become more important as well.

When you get sort of a preponderance of devices, whether it be, you know, a car and a phone together, you know, lending credibility that you've got a certain user present, or, you know, same thing in the home as well, where you've got, you know, multiple devices, including maybe a primary, you know, the mobile phone. Do you foresee that being the case then as well, the greater use of proximity, Bluetooth, NFC, and some of those cases or, or wifi. Absolutely. And let's not forget voice as one of those.

So if you imagine you wanna authenticate to your smart home or to your vehicle without ever touching a keyboard, you may get within a certain proximity and say, hi, it's me, John. And then your phone buzzes, and you put your fingerprint down and now you're authenticated without ever having really touched a keyboard. And by the way, you just did a Fido UAF or a Fido 2.0 authentication flow with a trusted pH authenticator. And you never had to type a thing and you just did two factor authentication.

So whether that's, you know, Bluetooth proximity and then a second factor, or just proximity, the key is IOT devices. Don't have input devices like keyboards very often at all. And so now we need to really go passwordless authentication when, especially when you're talking about a user to device authentication. Yeah. Yeah. That's a great point too. Upon IOT device management is you don't have a keyboard most of the time.

So, you know, accessibility, usability, how do we do a lot of the things that we used to doing, you know, with, with the macro PC and even mobile device world on tiny sensors or other kinds of devices that really just don't have user interface. That's right. And those are all things that we're building solutions for right now within the, for team.

Well, that's great. We're up the thanks, Ashley. Great presentation. Thank you. Thanks to everyone who's dialed in here. We are recording and this should be the recording should be available sometime tomorrow. So thank you very much and have a good day.