Benson: When you think about what they're trying to do here, they're trying to increase awareness of cybersecurity, right? They want to start the conversation. The labeling isn't going to fix everything, but it really gets consumers to start asking, "Why aren't you doing this? Why aren't you doing that?" It gets them much more aware that cybersecurity is a good thing, and when they're looking at products, to not necessarily look for the cheapest one. So, number one, it starts the question. Number two, for the solutions providers, or vendors, it helps turn cybersecurity as a selling and marketing point. So this is another feature that we have. We have a product that's secure. Now, this program is voluntary, but at the same time, if you don't participate in it, it could be a negative, because a customer's going to ask, "Hey, how come you don't have it, and they have it?" So, it allows them to be more competitive if they participate. So, that's another good thing.

And finally, despite this cybersecurity labeling thing, it really isn't all that comprehensive. It's a minimum baseline. But the people who provide, who participate, at least have addressed the things that you should be doing, changing the passwords and things like that. So at least it has a minimum level, gets people to that point. 

That's the good. Now, the bad side of it is that it sets a false sense of security, right? So, you buy this product that has the labeling, it looks pretty good, but it's just the minimum baseline. So it sets the false expectations. It's the minimum possible, you know, and those configurations, those are kind of valid at the time of purchase. But over time, you still have to update the firmware. You still have to set it up correctly. And if you've got older products, and as products go end-of-life, that information may no longer be valid, and it may no longer be secure. 

In other words, it sets some cybersecurity awareness and some baseline, but it's the minimum possible, and it may set some false expectations. You could still get hacked if you don't do certain things. So I think people should be aware of that. There's good and there's bad. But at the end of the day, what this program does is really to increase people's awareness of cybersecurity, right. When you go and look at a product, "Hey, does this have this? Does this have this?" Well, when you buy it, it should have the minimum standard stuff. And that's all this program is. It's really driven by the outcome to increase the awareness, and have some minimum level of security. 

Sridhar: Yeah, I would add to that, also. Just as Benson mentioned, it does solve a lot of the fragmentation issues, because today, consumers are exposed to a lot of different devices that have very different interfaces and they have very different experiences with them. Some may expect them to have strong passwords. Some may have default passwords throughout. Some may expect [the manufacturer] to actively manage them, which means they have to go source software/firmware updates, and make sure it gets done, and others may be just deploy and forget. 

And so, there's a whole plethora of experiences, and I think what this would do is is try to at least give a baseline for what those can be. And I think that's a tremendous positive, coming out of this. But, again, there is a lot of education that's required for the consumer to actually understand that, as part of this, there is a kind of shared responsibility that comes with this. 

So, part of having a baseline for security means that there is also work or actions that consumers have to take to make sure that they keep their devices up to a certain security posture, that they have to look for when firmware expires. If they can actually keep it updated, and so on. So, there is a sense of shared responsibility, which is going to take a lot of education. And that is something that needs to be thought through as we go and implement this program.

Benson: Right now, the FCC is taking input. So, it hasn't been finalized yet, but conceptually, this is a voluntary program. The IoT vendors and product producers provide information, or make that information available, according to some criteria that the FCC is getting input on. And that could be asset identification, data protection information, access control, software updates, any documentation, and how long they're going to support the product, and when does a product go end-of-life. So, it's a basic set of information that needs to be supplied — that information, that base-level information that's supplied in a label on, say, the box or on the router, or on the product itself, right? So, that part hasn't been decided, where the label's going to be, but the idea is that label has some basic set of information, at a very simplistic level, and then you, as a consumer or a customer, as you want to get more information about that, you could scan the QR code, it takes you to a website where the information is in more detail. So, or you can access documentation and so forth.

That's fundamentally how it looks. And as you're looking at different products, you're comparing between the two. And ideally, you know, they'll both be the same, but there may be differences in what a product maker is doing, versus another, and the consumer can say, "Oh, I feel more comfortable with this one," and so forth. So, it's similar to an Energy Star label, when you can see how much electricity's being used, for example, for a particular appliance. 

Now, again, this is voluntary. You don't have to do it, but if you do participate, if you do participate, as a product producer, then you may be subject to enforcement of all the things that you have in there, and you need to be compliant. So, there's some enforcement of that if you do decide to participate. And you have to update that information and so forth.

So, that's fundamentally how the program's supposed to work in practice. It's still in flux at the moment. The FCC is still getting input from industry, and from consumers everywhere, just to understand what's practical. They're not trying to make this a real burden on product makers. They're trying to get the right information. They're trying to make it so that people want to participate. They're trying to drive the outcome, which is to increase awareness of cybersecurity, and get to some compliance on the minimum baseline stuff. 

So, fundamentally, that's how it's supposed to work, in theory. In practice, it's only as good as someone complying, someone updating information, and as things change, as the product improvements come, that that information is collected, and presented, and made available. It works both ways. It works on the producer making that information available. The other thing, I know, Sri, you can talk about that, all that information is stored in a registry, and also the registry has to keep it up-to-date.

Sridhar: Yeah. So, Somos actually operates a number of registries on behalf of the FCC. The first one is the North American numbering plan. This issues all telephone numbers, except toll-free, in the +1 country code. The +1 country code includes U.S., Canada, and 20 other Caribbean countries. So, it's a pretty broad remit. And we also administer the toll-free number registry, again, for the +1 country code. And beyond that, this is one of the recent, or newer registries that the FCC has asked us administer. It's called the Reassigned Numbers Database. This is the list of disconnected numbers, that have been disconnected by end users or subscribers. And this is a really important registry, because this is what needs to be consulted for the Telecom Consumer Protection Act compliance. It's called TCPA. And the TCPA violation is actually very, very expensive. So, TCPA compliance is actually done through consulting this database.

So, we actually run these registries, and the important thing to remember is that these registries are actually operated on behalf of the FCC, and we have to have a certain disposition when we do these, when we actually operate them. We have to service the entire ecosystem. So, we are not partial to any player within the ecosystem. We have to make sure that we provide appropriate access, and make sure we are neutral within this ecosystem. We are an ecosystem player in that respect. And we have to keep all aspects of the ecosystem happy. So, what we've also done is we are just launching a... This is now commercial. This is not something that's been sanctioned by the FCC. This is a commercial registry that actually keeps track of IoT device identities. So, some of the concepts are very similar to what the FCC put out in their Notice of Public Rulemaking. But this is also an important registry that's actually enabling all the same benefits that the FCC outlined, which is, you know, take care of the security fragmentation, provide increased visibility, and so on. And since we service the entire ecosystem, one of the key things to remember is that Somos is not just a behind-the-scenes player — invisible; we make sure that the benefits accrue to the entire ecosystem, and we have an enviable Net Promoter Score as a result of that. We have an NPS score of 72, which is unheard of, in general, within the whole telecom industry. So, we're very, very proud of that, and the fact that we've been doing such a great service to the entire ecosystem. And so, we bring decades of practice that we can actually enable, to actually help the FCC here.

Josh: From the vendor perspective, there are barriers to entry for some devices. There are a lot of concerns about research allocation and cost. When you think in terms of the security questionnaires that come in to vendors, it's not simply at the device level. There are also enterprise expectations. So you need to ensure that you have the resources allocated to not only run networks that are ISO type of certification, or SOC 2, for cloud services, but you have to think about things like this as well. And it's not like the Cyber Trust Mark is going to cover all connected devices that a vendor might sell. So it kind of increases some burden to entry for markets, but also creates a decent baseline for some of those. I also think it would be difficult, for some of these smart devices, for the regulators, over time, to make sure that what the controls they're meeting actually help the consumer, and help the device to build security into it. But sometimes that's a complicated thing, when you consider the form factor of an IoT device. In some cases, throughout the life of that product, it might have at one point had enough disk space to meet something like a Cyber Trust Mark, but it might, in some cases, require some sort of WAN management service to do some of the computational efforts.

So, I kind of push back on the regulator, and ask, if, for example, there will be a requirement talking about how you need to be able to detect and also protect. So, kind of like that IDS/IPS vibe. How would a smart device, without building something into the product or having the form factor that can support that, be able to do that? Especially when you consider what's in scope right now.

Let's say, for the sake of discussion, we have to use a remote management system. Like, for example, in the Digi ecosystem, we have cellular routers that communicate to Digi Remote Manager®. But we use computational power to do some of the detection, the alerting, and the monitoring for that. So, then, would that put a WAN management service in scope for something like the Cyber Trust Mark? And if we're not having a third-party lab audit all of this stuff, and there's not enough governance and oversight, I think there would be some gaps or false positives for a vendor believing that they meet the Cyber Trust Mark. Without that oversight, and some sort of third-party lab involvement, there could be just what I would consider a false positive registered to that national registry. I mean, how are we going to validate the data that's in the registry? I'm kind of asking questions for some of the other panelists to perhaps chime in with their feedback there.

William: I think there's also an issue, isn't there, with the evolution of threats. That, with IoT devices, as they evolve and as they age, and vendors try and get an IoT device to do XYZ, there's only so much capacity. And as threats evolve, this might become, over time, really quite challenging, to keep IoT devices, keeping to the Cyber Trust Mark.

Syed: Some of the concerns that I want to address, and this is both positive and negative in some sense — I know the panel is entitled the "U.S. Cyber Trust Mark" — but as you pointed out, there are very similar initiatives going on around the world. And those are perhaps even a little further along than the U.S. effort, in this case. We have customers who supply product not only within the U.S., but internationally, and that is a big deal. 

So, one of the things that I think is going to need to evolve in the future is that the registry that the U.S. is contemplating, that Sridhar talked about, is that we need to have a decent connection between what we're doing, or planning to do here in the U.S., along with the efforts that are going on in other countries, so that the burden that is being asked of the vendors, certainly in overseas countries, where it becomes less voluntary, of having to register a product around the world — and I don't want to exaggerate the point too much — but we want to make sure that they don't encounter difficulties having to conform to a different set of baseline standards, whether it is security, whether it is the registry information that is being recorded, etc. Management of that is going to take a significant amount of coordination and effort, and that is a little bit of a concern.

The second thing, from a supplier/vendor perspective, as Josh mentioned, they're in the business of providing specific product, and it is tough to understand where there might be components inside the product that have independent potential Cyber Trust Mark requirements placed on them. For example, the cellular radio module that you talked about, Josh, may have an independent mark available to that, and then maintaining the information for the sub-components is a big deal. 

I think that asking consumers to participate and look at all of the components inside a consumer product, may be tough. It's going to take some time for us to understand the purpose, method, and what requirements may evolve over time, not only the security threats, but what requirements we may have for the baseline, and for what the consumer should expect when they see a Trust Mark label on a product. That's going to take some time to make happen. And so, I think there are some challenges. It's a fairly incredibly intensive effort that's going to be required on the part of everybody, not just the vendors, but the regulators, to keep up with what is needed.

Syed: I think that this is a place where consumers are confused today, or perhaps they're not as well-educated about the cybersecurity issues that can crop up with IoT devices today. So, having a label which allows them to at least get a reassurance of some base capabilities, as Benson and Sri have also mentioned, is important. 

I think it lends credibility to the suppliers who in fact go and make the effort to make sure that those baseline security efforts have been put in place, because some of the IoT attacks that have taken place in the past have been incredibly simple to have managed up-front, and people didn't do it. That's the kind of stuff that I think consumers will set an expectation for, that the devices they are willing to purchase and acquire have met those basic minimum standards, so that things that have been an issue in the past don't happen again. 

Now, going forward, obviously, there will need to be evolution of the product, and things like expiry of product labels, etc. It's going to be a necessary part of the whole process. That's going to take some time to make it all happen.

Josh: I tend to agree. And I think it's good for the industry that we're starting to see more of these types of frameworks. It's definitely a sign that, globally speaking, we're taking security more seriously, especially from the consumer perspective. 

I think we have to also consider how are we going to educate the consumer to understand what does this branding actually mean? Because I feel like there's a lot of misunderstanding when somebody purchases something. And so we need to be more transparent, as the vendor, like, “what does this mean, a default?” And, “Are there other hardening suggestions thereafter?” 

We don't want to build this idea that, "Oh, it has the Cyber Trust Mark. I can just load it into my LAN and we're good to go." So, I think it offers an opportunity to kind of bridge that gap with the consumer, from a marketing perspective, and ensure that we're really educating the user base on what the difference is. 

But from the vendor perspective, again, it's very difficult, if you have to create multiple SKUs for different firmware. Then you have to ask yourself, "Is this just the default that we should have from vendor to consumer?" Instead of some of them, at default, might not have these security attributes.

But sometimes, that strips away innovation capabilities or other features on a product. So, I think there's a compare and contrast, and some smart devices or embedded devices require different types of frameworks, and that's why perhaps homologation would never happen across all connected devices. I could list off a litany of different certificates that speak to some of this stuff, but a lot of those attack vectors are different. 

Some of the industrial sector already have their own type of frameworks. I look at this type of branding as something that could expand into other markets. I see even the cellular routers as something that should have a baseline like this for consumers that buy them too. But overall, I think it's a good thing. I just think the scope isn't broad enough for what's connected there out on the Internet, and I just feel like we're not looking at it to have enough governance, and without regulation, we might get people that don't think that they need to volunteer, and then it just becomes more about, "My competitors are marketing this thing. Now we have to do that." Then it will actually put the burden on a vendor, and it might not actually serve the purpose that the consumer thinks it's getting, because they're just going to do the bare minimum.

But one of the things, I mentioned — I thought the fact that they also wanted the companies to have a risk management framework as part of this. Because, ultimately, the ecosystem is going to win by having that in place. So I'm wondering, and maybe Benson you can speak to this; is this going to be, like, a NIST-grade risk management framework? Like, some of the different FIPS publication, kind of tied to that, or could you elaborate on where you think that part of it would expand?

Benson: So, great question, Josh. So, the criteria is based on NIST criteria for cybersecurity labeling. So, I think that's some work that's been done by NIST a few years back. And so, they're applying some of those. So, now, today, the criteria starts, or at least this program starts for consumer products. Now, we had a speaker that spoke to the IoT Advisory Board a few months back. He was on top of this particular program. And they're going to extend this to industrial products, to healthcare products, but they have a different set of criteria.

Josh: Oh, that's great. So, we've already done some pilots for some of these types of smart devices? Or is this just, we're conceptualizing what it could be? Because I always question the efficacy. Like, a smart TV, is it going to be able to minimally do these things that are in this list?

Benson: I think it's a minimum standard at this point, because when you talk about consumer, or you talk about industrial, it covers a wide span of products. And so, they're just looking for the minimum set that is applicable to all. Otherwise, it gets segmented and segmented, and it becomes harder and harder to manage. You know, Sri, I think as you know that, as the registries go into great details of it, then the specific information that's being stored is very different, very unique. But at the minimum, they're trying to have this minimum baseline that’s somewhat easy to comply with, for now. 

Josh: Yeah, it does seem like a very minimal baseline. Like, it can make the audience understand that what's in this Trust Mark isn't something that we shouldn't already be doing as a vendor. It should already be assumed, and that's why things like, "It's a voluntary program," kind of exacerbates the issue a little bit. We need to kind of force the issue that our consumers aren't looking at this stuff. If they're, by default, exposed to the Internet, like a lot of IoT techs in the past, I would tell them that, "Like, okay, have we moved on from using protocols that don't have encryption or authentication? Because I have."

Syed: I think that we need to take into account that different kinds of IoT applications are going to have a different set of requirements, and if the baseline accommodates all of that, great, but your comment, Josh, about a smart TV is a good point. The risk associated with a breach of a smart TV, as opposed to a Fitbit — you know, a health monitoring device that a user is wearing, or a home automation system that is controlling the HVAC — the requirements for these are going to be somewhat different, and the baseline needs to be carefully managed so that what is secure for one device may not necessarily be an issue for another. But as long as the baseline tries to accommodate all of the consumer IoT devices that are out there, so that consumers can make the effort to say, "Aha. This device has a label, and this device does not," so that the active comparing becomes meaningful, I think is going to be a big deal.

Sridhar: I do want to add a point to that. So, I know this particular FCC NPRM is focused on consumer. But in our minds, the consumer security requirements bleed into the enterprise and industrial requirements. I'll just talk about one particular thing. This is post-pandemic, right? The biggest concern among CIOs in 2023 is something called shadow IT. So, with shadow IT — with a good chunk of the workforce being remote — what happens is your home consumer IoT devices essentially are part of the attack surface for enterprises. 

So, what happens to security within the enterprise? We have to extend it beyond not just your laptop, but now everything else around us, right? So that is becoming a big concern, and the way this is translating into dollars and cents is, the cyber insurance market, that is what enterprises pay in case they ever have a cyber breach, that market is going up, growing at a rate of 25%, compound annual growth rate. That is incredible, right? So, which means there's increased threats, whether it's shadow IT or not, but the thing is, shadow IT is definitely expanding the overall attack surface, and so we gotta think of not just consumer as siloed, but consumer bleeding into enterprise, and actually look at it a much more holistic way.

William: Very good point. 

Josh: Yes, those are great points. I mean, shadow IT in an organization could be your deathbed. If you don't have the right monitoring... And in some cases, some of these IoT devices don't have the interoperability with some of these tools to actually do monitoring. So, I think that's a gap in the IoT industry. And even in your own house, you might not realize all of these TCP or UDP streams going on. Because it's shadow IT in your own house that you forgot you set up. But the enterprise perspective, and Sri, a lot of these vendor questionnaires that I field, it's asking for all of that. There's more transparency that consumers are expecting, that are purchasing large swaths of products. They don't want to just see at the device level, are we secure? Is there risk in the supply chain by adding you as a preferred vendor? All of that stuff is important, and that's why it's extremely hard to really grab this market and say, "You know what? From end to end, we can do everything security." So, companies are having a hard time... "How do we fund that?" And “How do we also build features on top of that?” And then, you know, expensing out enough teams, or having third-party security to be able to monitor that? 

Group: Yes, exactly.

Benson: Sure. There are other programs out there. I know you mentioned Singapore, EU, and so forth. Right now, they're stand-alone. So, what applies in the U.S. may not necessarily apply in Singapore. You know, there are some considerations of how do we harmonize the different standards, or the different sets of programs, so that you develop one for one country, it's valid for the other? But at this point, they're considered separate. At the same time, some of these things are the minimum basics of security. You need to change the password upon logging in, and so forth. It's very basic things like that. The FCC is putting out a request for comments, as it tries to launch the first version of this program, but the harmonization across programs in other countries, that's being considered. But at this point, it's just under review.

Sridhar: I think the NIST criteria, or the NIST guidelines, have been fairly clear. It actually provides a lot of guidance. The first thing it says is, you need to be able to establish the identity of the device. So, that is a big, huge aspect of what this registry needs to hold, which is the identity information of those devices. And typically, identities for devices are actually already fragmented. There is a serial number put in by the manufacturer. There is an IMEI or MAC address put in by the company that actually puts in the actual connectivity module, either a cellular module or a Wi-Fi or Ethernet adapter. Then there is the IMSI, which is the one that's provided by the connectivity provider, which is the SIM card ID. And then, there is the enterprise meta identity that they actually put on the device. So, there's already a fragmentation of identities. So, we actually have to normalize and capture that. That's the first part of it.

Then the second part is what the NIST guideline says is the security configuration, and this is a very important part of that, which is, how do you know what the baseline security configuration for that device is? And this is where you actually keep track of all the dynamic changes that need to happen to the device so you can actually make sure that when there are new zero-day threats that come out, here are ways to actually keep ahead of all of those things. 

And of course, there are the software/firmware updates that need to be kept track of, as well as any certifications and credentials that are put in for that. So, certifications are, again, important. Which is, if it's certified to work in the U.S. in certain frequencies — or let's say it's certified to work in Europe under certain frequencies — if it comes to the U.S., it needs to be certified to work in the U.S. frequencies. If it doesn't have that, it's a violation, and so it needs to be turned off. So, those are all things that need to be considered and put into the registry so there's a clear way to look at it.

And the interesting thing that, when we look at the parallels to our nutrition, food labeling, you know — back when it came out, when people looked at added sugar, it was just another, okay, something 8 grams, 10 grams. It didn't really matter. Now, just, that's the first thing people look at. When you buy a food product, you look at the added sugar. 

So, similar to that, having the bill of materials (BOM) added to this is so important, because, today, it may not seem that relevant, but over time, when we see that there are so many different new vulnerabilities in the software that are being put together, actually aggregated by all these national vulnerability databases, here's a quick way to say, "Oh — this has this particular component, and this, we know had all these software vulnerabilities before." And that becomes second nature to consumers and IT managers within enterprise. It becomes a really important part of that. So, I think these are all the key things that the registry needs to hold: identity, bill of materials, device metadata, certifications, and key credentials.

Syed: Yes, I think the registry content is going to evolve as we discover more need in the future. There's no doubt about that in my mind. My concern about the registry has more to do with keeping it up-to-date. I think it's going to be important to recognize that there will be security events that will lead a vendor to perhaps say, "Oh, I need to recertify," or, "I need to go re-check the certification status of the components inside my product," and then have to update the registry to keep that useful. 

It is important to keep in mind, and I think Sri mentioned this, just perfectly, which is that consumers will eventually come to rely on this. And if that happens, when that happens, it won't just be a tool that the vendors have to sort of make sure is up-to-date and kept up-to-date, but the consumers are going to place a judgment on the kinds of comparisons that they're going to make between product one and product two from two different suppliers, and they have to rely on that. 

So, one of the other things that I think is very important, that I mentioned earlier, is that you need to have an expiry, because devices do evolve. The security threats do evolve. And if you have a firmware change in a device, then it is up to the vendor in general to be able to update the information inside the registry, and keep it updated. And that, I think, is going be something that we will discover, in time, what exactly it takes to make sure the content is accurate, correct, and kept useful?

Josh: I wanted to talk about SBOM (software bill of materials) a little bit. So, that artifact in itself. I think Benson was mentioning something earlier about how we're envisioning a QR code with this branding. And then, would that go to the national registry, and the consumer would be able to pull down things like the SBOM? Is that kind of the idea?

Benson: Or it goes to the manufacturer website, or something like that.

Josh: The reason why I'm a little concerned is SBOM is this evolving thing. Every time a new version is kicked out, or even if it's a non-release candidate, an attacker would be able to be at a store, potentially, and I'm not sure of this (the accessibility of this data) and they could pull down the SBOM and could use a firmware analysis tool. All of a sudden now, you kind of understand the attack vectors of this. So, SBOM is good if it's in the right hands, and if it's a mutual relationship between consumer and vendor, not this third entity, who's now understands what's on the bill of materials here.

Sridhar: Actually, there are many bill of materials analysis tools available. So, essentially, this is going to be the vendor, as part of this larger certification program — being able to provide their firmware to be certified, or to actually have the analysis done — so it becomes part of that. And this is amazing, because we've been trained, as consumers, about food nutrition labels. The other thing I do is, when I go to a wine store, I take a picture, and I can immediately find out the exact region, and not only the region, but comparisons, reviews and all of that. So, that's the same, I think that behavior is going to bleed over into this area of technology, and I think that's going to be really important. So, knowing the "ingredients," which is the bill of materials, is going to be really important as we move forward.

Josh: No, I completely agree that what SBOM is a great thing to the consumer and also the vendor to understand what's under the hood. Are there licensing issues? Are there dependencies that we're not seeing? Are there vulnerabilities? But will this national registry data be available to anyone?

Syed: You know, that's a tricky question, right there. I think that if we're going to make this open to consumers, who don't have to create a login account, etc. on the registry, all of those control factors allow anybody to have access to this data, and you're concerned about the attackers, the TAs, the threat attackers also having the similar kind of access to go look and see what device may be vulnerable, is a concern.

Josh: Yes. And it's no different than if your firmware image is out on the Internet, and it's non-encrypted, and someone could do a binary analysis on it, and now have an understanding of how to exploit that device wherever it's employed.

Sridhar: Yeah. So, I'm not sure how this is going to be implemented. This would...kind of speculating here, but there is the public domain information, and then there is the public access information. So, public access may still require some level of registration and so on, and may require registration through the vendors they've actually purchased the equipment from. So that way, it may be a more coordinated way to get to this information than just being public domain, out in the public domain, that anybody can access. But I'm speculating, because this is, again, just a concept at this point.

Syed: It's an open area, and my concern about what you just said, Sri, is not that it isn't a good thing, but that it sort of diminishes the effort of a consumer to be able to do comparisons, if they haven't even bought the product yet.

Josh: I think some schemes make sense. Like, if it's carrier certificates. Currently, I could say that Digi goes through certification for things like FirstNet via AT&T or Verizon Networks. And I think that makes sense to have a broad carrier certificate, that had inheritance down, versus having to do it for all the different carriers; it gets kind of annoying. But this one, it really seems like if it were to broaden what it branded, it still would have to have different scope, based on that type of embedded device.

Syed: I think the question relates to the fact that the definition of a consumer IoT device is a little fuzzy, to be honest with you. Some are clearly something that a consumer would buy at a retail store, but there are maybe other devices which may have been purchased elsewhere. I mean, to use a somewhat strained analogy, is a connected car a consumer IoT device? That's something that has been shown, and demonstrated, that security attacks against connected cars is something that the OEM auto manufacturers are very concerned about. Are they going to be part of a Cyber Trust Mark label? And that's a tough thing to try and identify. 

These are issues that I think are important to understand, and there's going to need to be some evolution of definition, scope, what baseline security standards are applied, what the registry has to hold, etc., etc. There's a lot of work to be done. It's an immense amount of work, frankly.

Josh: Yeah. I think about, like, a router. Sure, you could have it for an enterprise perspective, but a consumer could just buy a router and have it in their home. Is it not a consumer good that could still have this labeling? I think it could.

William: Are we proposing making Benson's task absolutely impossible? I mean, one area for example, is healthcare wearables. I mean healthcare wearables, I think, at present, gets sort of bundled in with clinical information systems in ICUs, which, again, it is a question of definitions and scopes. Is a wearable that you actually use for running, should that be covered in the same area as a clinical information system, and something that is used in a critical ward, or does that belong more in this area?

Benson: I think we have to be careful. I think, Z, you said it. What is the definition of an IoT device? And within the IoT Advisory Board, we had a discussion on what is considered IoT, and that's a long discussion. And even within the government, they can't decide what is considered IoT and what is isn't. So, that discussion kind of gets out of hand very quickly. 

But that said, I think if you were to look at the IoT for the different sectors, they have very different requirements. So, let's just say a consumer is not as savvy, when it comes to how the device works. They just want something that's cheap, it works, plugs it in and it works. Minimum setup. And that's why companies like Apple have been relatively successful. Like, it's very easy to set up.

Now, as you start to go up the food chain, and you get into healthcare, you get into industrial, the buyers are much more savvy, right? They should be asking the right questions, the industries, in particular — healthcare or industrial or utilities — to regulate it. So, they mandate certain requirements. In that case, a Cybersecurity Trust Mark doesn't necessarily buy them anything, because they're a little bit more savvy that they have requirements imposed. 

For example, with the FDA, they just turned on the requirement for the cybersecurity requirements to be met on new products, literally a month ago. So, all of a sudden, it's a whole different set of standards. Now, with that said, they were practitioners. They weren't necessarily cybersecurity professionals. So, they may not always know. 

But the buyers, in these cases, are much more savvy. They're looking for a different set of information, whatever that is, but the requirement for security is built in. Now, as you get into small business, you're kind of straddling that line. You could use a consumer router for business. And so, you know, so you're starting to...at least at the small business. But as you go higher and higher up in the business food chain, you're running into the Ciscos of the world, which is very sophisticated. Or more sophisticated. 

So, I would say if you're trying to expand this to other areas, you're just asking for trouble. Number one, you're going to be inaccurate. Number two, the information set is going to be so huge that you can't possibly keep up with all of it. And, Sri, as you own a registry, it becomes an administration nightmare at that level, at that point.

Sridhar: It's never a nightmare for us.

Josh: Would it be possible to have different levels? Like, there's other certifications, like the platform security architecture, and they have Level 1 to Level 3. What if Cyber Trust Mark, the baseline just covers these smart TVs and these other devices that don't have a lot of sensitive data, so we could have data classification for different levels of the Trust Mark that tapped into different sectors?

Syed: Josh, that's a great comment, except I'm a bit concerned that we're complicating a problem that is already going to be difficult for most consumers to understand the implications of having a label versus not having a label, let alone the levels of it. 

I think that makes a lot of sense, because every application's going to have a different degree of security requirements, if you will. So, that could be an evolution in the future, but we need to get consumers using this system to begin with. The express purpose is, if you look at the NPRM from the FCC, it's consumer-driven. The objective is to get them to get information that is relevant to protect them from security information, and I'm a bit concerned that if we overcomplicate it too early, it may take...it may get rejected too quickly, and that's not a good thing.

I mean, I like the idea of having a label, so we just need to understand exactly what expectations we want from the consumer, clearly identified, so that they understand also what a label means. Which leads to a concern that I think we have not yet touched on, which is that the act of having a label doesn't guarantee anything, and therefore, if a device fails, and does indeed have a security breach, now what? What are the expectations that we need to have about liability? Is there a safe harbor requirement that needs to be incorporated, so we don't end up in a situation where the expectations end up in court in a heartbeat?

Benson: Yeah, I think as we talk about this, it's kind of important to understand what the goal is. It's to increase the consumer's awareness of cybersecurity, so that they can buy products that are at least secure, or at least that met the minimum baseline. So, that's, you can say, the outcome of that. And today, that's not necessarily the case. As, you know, for a lot of the people, they can't tell the difference between router A and router B. As long as it meets my needs, and it's the cheapest, that's what I'll do. Many years ago, I worked in the high-end smart home industry, in networking. These are the people that have million-dollar home theaters. And it was shocking what the installers were putting in their homes. Absolutely shocking.

Josh: Yeah, I think harmonization is really required when we live in a global market. If you're going to buy something with a Cyber Trust Mark out of the U.S. from the EU, well, okay, it needs to meet stuff like GDPR. So, we have to have this global discussion on how does this branding impact or affect its ability to be bought in another country? 

Digi International sells to 200 countries. I live in this world all the time. It's very complex to figure out, and there needs to be more by committee globally to accomplish what is reciprocity for something over here. What would it have to meet? Are there certain laws that come into play that we're not aware of? It's a very complex monster. But it's very clear, for example, that the EU and the U.S. have different ideas, even by state and country… what is cybersecurity? In California, it seems like they're more progressive. Currently, with machine learning and AI, legislation coming in between EU and U.S., it's completely different. The EU is like, "You know what? We care about the machine learning algorithms that the AI uses, and that's tremendously important." Whereas the U.S. is like, "Well, we should care about how the AI is used," but if you don't know how it was trained, does it actually matter? So, we need to bridge this gap, and I'll let it slide over to someone else on this panel.

Syed: I totally agree. I think Josh's comments are absolutely spot-on. I may have mentioned this already. His 200 countries where he sells his devices is where we offer IoT services. And our customers in general are going to want guidance on how they can provide product in all of those countries as these initiatives, IoT protection initiatives, evolve — beyond the EU, beyond Singapore, and beyond the U.S. effort, once it gets in place. 

Having the label, having the capability of informing consumers is important. The question is, can we get to the point where we can effectively allow the vendor to successfully deploy products everywhere where the consumers need to have this information, and be able to get to that information? It's going to be a tough road. It's a lot of work, and, as you pointed out, the NIST is not the only organization that's gonna need to be able to solve this, and so harmonization, to me, and certainly, eventually in time, getting everybody on the same page, is going to be incredibly important.

Benson: I think, when we talk about harmonization, it’s good. But each country and each region has its own standards or regulations, and those are driven by their social system, their own political viewpoints and certain things like that. So, in the U.S., for example — and I'm just speaking on behalf of myself — the U.S.'s approach is more laissez-faire, a little bit more industry-led, industry-driven. If you go into the EU, they're about protecting the customer a lot more. So, I look at the upcoming AI bill of rights. They're more about doing no harm. In the U.S., we don't necessarily have that. It's a little bit like, let's not constrain industry, right? What can we do to thrive, and if industry thrives, then the people underneath it will thrive as well. So, those are really two very different systems.

And so, when we look at the standards or the programs like this, that are set, they're coming from two very different philosophical and political viewpoints. So, harmonizing that is hard, number one. There's going to be some things that are common. But, realistically, they each reflect their own values. It's not to say one is right or wrong. 

So, GDPR did some tremendous good, right? But it started on the EU, and now California's adopted their own version of it. Now there's talk about the national privacy legislation. You know, but they come from different perspectives, and they may meet in the middle in some areas. But as more and more IoT devices get put into the registry, into this program, it gets harder and harder. So, harmonization is a good idea. I just don't know if we're going to actually get there, or maybe whether we should or not. That literally depends on the political and social values of the country that's selling it.

Syed: Again, if I might make one final comment, which is that security may become as important as, for example, spectrum, where we have entities like the World Radio Congress and the ITU having to manage that. There may need to be a security equivalent, if you will. And that's an extreme position, and I recognize that I am being a little bit controversial, but it may be necessary.

Josh: I completely agree. I don't think security is a feature. I think it's a way of life.

Sridhar: If I may add one final thing, the thing is, security is so common, or the lack of security is so common across the world. So, if you look at IoT, IoT is global. And if you look at the most deployed, most commonly-deployed use case, which is a connected camera, there's over a billion, or maybe billions of connected cameras deployed. And a breach, in any country, it's the same thing. It is a security breach. So, there needs to be some way to harmonize the fact that there is a security breach that is possible through IoT, and it doesn't matter which country, regulation, and so on. We gotta make sure that those things get fixed.