So I will be focusing a bit on the standards for IOT. And I will start with saying, I think one giving one definition of IOT, if it's not communicating, it's not IOT. So the definition from on the internet of things says that it has to have a communication component inside it. And what it may not have is that it may not interact with a human. So IOT involves machine to machine communication between, you know, embedded computing objects, but also between objects and online services. What are the standards in that space? There are a lot.
So we have standards from three GPP for mobile communications and also for the communication mode known as narrow band IOT, which is optimized for IOT products. We have standards from one M Tom, which is focusing on the service layer that you can use then to build applications for IOT in a technology agnostic way. We have standards from I ETF basically also security standards there, GSMA, which is basically giving us industry best practices for IOT, especially narrowband IOT, since GSMA is focusing in the domain of mobile operators.
It's an industry association and of course, standards from Oasis OS for web application security I and international standards.
Now, if we look at IOT, I want to give you at first a view of what are the risk components. IOT is basically about a value chain. There's an embedded computing product, which is communicating through some infrastructure, either to other embedded computing products or also to some online services.
So all these stakeholders are part of the things, the, the kind of entities that get involved in IOT, you will have service customers, which are the users of the online of the online services involved in IOT. These are not necessarily human users. They can be applications, right? You have the service provider, which is basically what the on IOT service is running.
You have your platform provider, and then you have connectivity providers, device, provider, and that's basically at the device provider where we see the aggregation of the different components that you get from the supply chain perspective.
So you have component providers, someone may be manufacturing the, your IOT product, the device, and somebody else may also giving you the framework for, for it, because it may be a firmware based on an open source component. And therefore it's not entirely within one player to own that. So this is like the risk ecosystem of IOT.
And I want to give you just a brief overview, just a brief enumeration of the different kinds of, of standards that we have here. So in IOT, it's not the problem that we don't have standards for things. We have a lot of standards for different aspects of it. What we are challenged with is basically the fragmentation that we have in IOT, because we are covering many domains, consumer industrial automotive cellular, and those standards typically having evolved from a different tracks are not entirely aligned sometimes. So it's a bit of challenge to actually work with them.
So if we look for instance, at the supply chain, we have the ISO 28,000 series of standards for how to build security management systems for the supply chain, best practices, requirements for different kinds of bodies who will audit those kind of systems and who will certify those kind of systems. And why are this relevant?
Well, if we're going to be embedding computing into products and we are going to be making those products part of the physical world around us, we need to have some kind of, you know, supply chain assurances, because those things are going to have, for instance, actions on, on physical level, like the brakes on an automotive vehicle, for instance, controlled by some closed loop sensor or some other standards in that area.
Some of them may be known also in the it domain because they have, they come from another older standard, the O TTPs, which is about the open trusted technology provider standard, which is basically to provide you protection against the counter five products and tainted products. But these are also relevant. We shouldn't actually exclude them from this discussion
Standards also from N on again, on the supply chain risk management. And you can see now that I'm only touching three stakeholders in the value chain, but I'm starting to enumerate probably around eight standards so far.
And I haven't even mentioned the whole 27 K series on, on cyber security, other standards, which are relevant. There are standards from the manufacturing domain, so actually not manufacturing the fabrication domain. So the stakeholders who are fabricating circuits have done significant work in AC in developing standards to ensure that there's no TA painting and no countered of digital secrets boards and manufactured PCBs, and so on. And I'm not saying that these are directly, for instance, applicable in the context of it, I'm saying they're relevant.
And I'm saying they're probably good lessons there for anybody who is involved in an IOT product manufacturing position, finally again on the ISR level, also other standards from the supply chain. And I know I'm focusing a bit more here on the supply chain, but I will move out of it and give you also later on, hopefully an update from how the standards are developing and how the standards are responding actually to the fragmentation that I mentioned,
Again, just a brief listing of the ISO standards, 27, 0 36 information security for supply relationships.
This is a multipart standard from part one from the overview concepts part two requirements, part three, you are the guidelines for supply chain security. And part four is basically the security of cloud services. And I'm not saying these are the only standards again for first and part for their additional standards for cloud security, which are relevant, but there's not enough time to actually go through them.
Now,
There are some framework standards, which are relevant when I say framework standards or standards, which can help the organization in establishing what we, we refer to as the control framework and the governance framework around cybersecurity, which is these aspects covered. For instance, capability, maturity models, common terminologies, all the things that we need to get people speaking the same language, because that's one of the first impediments that we find in IOT. Exactly because we have a very diversified value chain.
You have product manufacturers, developers, service providers, integrators, application developers. So you all these people do not necessarily use the same parlance and do not necessarily attach the same meaning to the same words.
Now we'd like to take a post and speak a little bit about the security situation in IOT. And why is it important looking first of all, at the, at the, the market situation, I think it's a common knowledge that right now there's an economic, as we say a market failure, because they're not economic incentives for cybersecurity.
And that's, for instance, we have seen some regulations like GDPR, which refers to privacy, but provides economic incentives for instance, to actually put privacy measures in place. The similar situation we have in cybersecurity, because simply put customers and people attach more value to utility and lesser value to cybersecurity and that's their priority right now.
The other problem is that even when we, when we have a secure product, because which is based on software, the security level of that product does not remain the same after it's released, because it's impossible to make perfectly perfect software it's or actually extremely costly. And therefore the discovery of new vulnerability means that the security level of a software depreciates with time, because there's always a probability that a new vulnerability will be discovered and discovered does not mean disclosure, necessarily somebody may discover a vulnerability and simply leverage it.
So that depreciates over time. And the other problem we have, which is more, more intense in IOT is that poor security practices result in a cost, which is external. So for instance, if somebody is making, if a product manufacturer in a specific version of their, for instance, IOT hub component has poor software. And that hub component is that compromised and assembled into a botnet. The manufacturer doesn't actually have any direct costs of that per security. It's somebody else who is paying the cost from the Dedos attack that that botnet will be used to launch, right?
That's the cost externalization factor.
And finally, I think it was also mentioned by the first picker, this session, the human factor, the consumers who are using IOT products and services, do not necessarily have an awareness of, of security. Okay. And this is a problem in general because the more we use products, which rely on software, the more, and the more we that software reaches different aspects of life, the more, the more amount of the wider public we reach. And those people do not necessarily come from a computer science background, let alone a cybersecurity background.
So this is inevitable as a society becomes more digitized.
So if I wanted to summarize this, what I've said so far, what would be the main points? First of all, scale IOT devices are easily expected to be low cost so that they can be, be produced in large number. And that's why it's important that we have some sufficient level of security for those devices, because otherwise the impact of low cybersecurity and those devices has, is multiplied by the scale at which they are distributed and deployed.
We don't have good incentives for engineering robot security at the device level economic incentives that I mentioned. And we have a low security awareness from the perspective of the human user, who will be using, for instance, a consumer ID device.
There are also the fund underlying issues of economic incentives in the value chain, which I mentioned before. We have a market failure for security people pay for features first security later, that's the generally accepted reality. And finally, there's an aspect of practice.
If you look at all the reports of about security breaches and incidents, they all agree on one thing. Misconfiguration is the number one cause of security root cause of security incidents or breaches or anything. And misconfiguration is usually attributed to a human factor because there was a human in the loop and something was not configured properly.
So this is the kind of, these are two main parameters of the problem we are facing.
One, one, we have scale on other one, we have poor incentives, not a good economic model. What can we do? One other thing we can do in which I will briefly explain how relevant standards take action in this space is for instance, to start leveraging and deploying some light white route of trust for IOT. And they are at least two or three different things that are being done in the space, the work of the trusted computing group on first of all, trusted platform modules, which are for more capable systems, but also for the thin profiles that they started working, for instance, for automotive TPM.
And for instance, the trust computing group is working on TPM for automotive. There's a, a thin profile, which is targeted to the more resource constrained components in a car.
And there's a more capable profile, which is targeted to the more central components in the car. Like for instance, the T are called telematics box in the car and so on. And these approaches are, are, are directly aligned to the environment of I IOT, where we have products and that are constrained in resources.
And that's why we need thin profiles, another relevant approach in this direction, which is not TPM capable, but has as upset of the TPM features that enable you to build hardware, supported identities is the dice device identifier composition engine, which is also from TCG trusted computing group and allows you to build a hardware baked hardware, supported identity for constrained IOT devices with minimum hardware footprint.
The other aspect where we can take action is that we should to develop standards that allows us to build infrastructure that can cope with different levels of details.
If you look for instance, at the I ETF dots, working group, what that working group is doing and where we participate, of course, as Hui, we are building standards that enable you to build a market for DDoS so that you can have market stakeholders, which go and request DDoS mitigation services. And then you can have DDoS mitigation providers, which actually offer those services when needed. And that allows you to build an efficient mechanism around the whole DDoS mitigation required.
Another aspect, which in my mind is one of the most important ones is standardization are the standards for firmware and for software updates, because at the end of the day, we, we don't, we can't build perfect software. It's going to be deployed with imperfect software. And unless we have a mechanisms to actually update things on the field, update their software, we are fighting a losing battle. And if you look here, there's a significant work, which is being done.
The automotive industry has worked and basically refined a version of the software update framework, which was used for Android into the so-called obtain framework, which has been now considered for the automotive industry as a, as a de factor standard for software updates. And also the ATF software update for internet of things, which is a new working group, is working on, on ratifying basically and defining what are the minimum information that I need for software update in IOT, which is very important in to be able to have updates of any software IOT device.
And finally, the other aspect will be into balancing stakeholders, initiatives. And that's where basically we can look into also other aspects of the developments that are coming into, for instance, law and regulation.
Recently, I mentioned those things before, but now I'm just putting in putting them on the slides for you. So if you're interested, you can go and see what DCG dies has done. And the TPM also in the economics area. I don't know if you have heard of units working party 29. This is a working party of an international organization, which is the focusing on the regulations of vehicles.
And one of the regulations which is coming for vehicles is that first of all, whoever's manufacturing them will have to have a cyber security will have to have a security management system, which is certified and pass some criteria. And the other thing with scamming is that the vehicles will be type approved for cybersecurity.
So it doesn't get on the road. If it's not in some way, cyber security certified Anisa has done a lot of work. I'm a member of their working group on IOT security. We have published, we're close to publishing three reports because the last one has isn't out yet.
And they're all focusing on IOT security. So if you want to, you can go there and see also what recommendations and best practices are GSMA needs, CSA. Like they all have good materials on that one. And I will spend now a couple of minutes to talk to you about, to give you an overview of the latest developments that we have seen in the standards. So
We're out of time,
We're out of time. So you wanna stop or I can finish in one minute for this.
Yeah. Just wrap it up
Real quick.
No, no problem. So roughly a year ago in the UK, the, the CMS published 13 principles of good practice for cybersecurity. And later on, they were BA they were adopted in TSI in a technical specification, Ts 1 0 3, 6 45 cybersecurity for consumer IOT that now is being in the, in a new work item for TSI to, towards a new harmonized standard in Europe for consumer security, but that's work in progress. So it's not out yet.
And at the same time, we have some developments and publications from nest on securing small business and small it IOT devices, considerations for managing cybersecurity and privacy risks. And also from the GSMA, a series of I IOT security guidelines and all these are the latest updates from the standards. And I thank you for your patience and your time.
Great. Thank you.
