Iot Security Policies and Standards - A Global Perspective

I will be trying to spend the next 15, 17 minutes to give you an introduction of I security and policies on a global level. So let me start, of course, with a view of the global map, just to show what kind of activities are taking place globally in I IOT security policies and standards there, activities looking from left to right on the, in the us, in the UK activities from the UK have been endorsed and expanded in the U their activities in Finland.

And I, then I will be focusing more a bit on the right side of the map in Australia, Singapore, and Japan. So let's start by saying, first of all, that these activities are not exactly independent or without any coordination. There is some effort for global alignment. For example, in July, 2019, Australia, Canada, New Zealand, the United States, and the United Kingdom set out in a commitment to align their approaches, to enhancing the security of fire devices.

And as I present the, these different approaches, you can see the point of alignment there starting a bit from the U in the European union. The main vehicle Fort security standard has been the work that has been done by ETSI in E 3, 3, 6 45. This standard defines baseline requirements for cybersecurity. For consumer I IOT its out of the need to respond to widely known cybersecurity incidents.

Some of those include the botnet with one KPS Dedo attack against team, but also what followed the MII several, the botnet spinoffs, which actually numbered quite significant number of devices close to a million. The purpose of em, 3, 6, 4, 5 is to improve on basically a non-existent a non-existent provision for cybersecurity and data protection in IOT. And it does that by establishing a compound baseline across the European and wider global market.

So the, this standard has the, has incorporated the feedback and has the approval of the member states as well. The standard is outcome focused. There are 33 mandatory requirements and 35 recommendations. And just to give you a view of the different kinds of categories of pro from provisions that we find in E 3, 3, 6, 4, 5, there's most importantly a so-called reporting implementation. So if our recommendation is not implemented, the manufacturer has the obligation to report why to give a justification a rationale for that.

But then there are also a number of other provisions, for instance, for no universal default passwords for making it easy, to delete data, to delete user data, to make the systems resilient to outages, as was mentioned before resilience, to ensure software integrity, to communicate securely, to keep the software updated and so on. I don't need to go through them in detail because you can always find the references at the bottom of the slide. And remember that this is an outcome focused standard.

So it is accompanied by a guide and it's accompanied by another standard, which is the assessment specification, the assessment specification clarifies how somebody can assess a device, an I T product for compliance to E 3, 3 6, 5 from the implement standpoint, how does one process the standard the E three or 3 6, 4 5? Well, the first step would be of course, to review the definitions. These are provided in the annex and they clarify the device architecture, the device states and the network architecture and to review the terms and then they would proceed to implementation.

There are 3 33 mandatory requirements to implement and 35 recommendations if recommendations are not implemented then for each one of those, a rationale has to be documented. And the 1 0 3 6 1 provides the guidance on how to actually proceed in this step. And the final two steps would be that the, of conformance where the manufacturer has to complete the implementation, conformance, performing my NXP and to proceed in the assessment on the basis of Ts 1 0 3 7 1, the assessment can be inhouse or external. So this is the overview of the five in Europe.

And let's jump a bit to the left on the map or look at what's going on in the us, in the us needs has mistaken a series of activities under the umbrella of I a 2 59 to improve the cybersecurity of IOT. The main guidance document. There is IRA 2 59, which defines the foundational cybersecurity activities for IOT device manufacturer. The kind of activities that IOT device manufacturers should have take in order to ensure that the products they make, the IOT products are sufficiently capable when it comes to security measures that they implement.

Now, there are specific parts there under a 2 59. So the part a and part B, which referred to manufacturers a 2 59 a provides a device security capability, core baseline. This defines a set of features that should be implemented by manufacturers and IOT device, but they features are defined without restricting the implementation. So the manufacturing is allowed to innovate there, and there is space for performance improvements and tradeoffs.

The T a 2, 5 9 B is a nontechnical support and capability called baseline being non-technical. It refers to processes and procedures that are relevant from the manufacturer stand point of view, like for instance, the ation awareness and other process related aspects, because it's not just about the product security, there's also the procedure and activity aspect of, of it. The other parts of a to five nine are the a to five nine C, which is about how to create profile using the core baseline and the non-technical baseline.

So the two previous parts, and finally a to five 90, which is using the T core baseline and nontechnical baseline for the federal government, it's basically providing a profile for the federal government. Let's see a bit how that looks together. So the foundation guidance of this work in N is 802 3, which is the IOT device security guidance for the federal governments.

This provides domain specific guidance for the application of I IOT security on the basis of that, we have 8 2, 5, 9, as I mentioned, which is the process for manufacturers and the two core parts of that 8 2 5 9 a the technical code baseline, a 2 5 9 B the non-technical core baseline. These are being applied in the case of the federal profile example. I mentioned before to produce a 2, 5 90. And in that context, this process is also informed by the special publication 853, which are security and privacy controls by nest. So well known.

One of course, additional profiles can be defined for other domains or other verticals. And those could be informed by the process defined in a 2, 5, 9 C, which is the profile development process. So this picture shows how the different parts that are under the 8 2, 5, 9 umbrella work together in the new specification. And while we are at the us, let's look a bit into what are the legislative initiatives at the federal level. So in the us, there was the internet of things, cybersecurity improvement act in of 2020.

This mandates needs to develop standards and guidelines for the federal government and on how to use and manage internet of things, devices by federal agencies. That means that there are two basically groups of standards and guidelines. The first one is for federal agencies and it has to do with topics like vulnerability management, secure development, identity management, partnering, and so on. But there's also another part which has to do with standards and guidelines for device manufacturers.

And they have to do with coordinated vulnerability, disclosure, resolution of vulnerabilities, information sharing about vulnerabilities. And these practices are aligned to international standards in the ISO.

Finally, let's look quickly at legislative initiatives at the state level, we have the cybersecurity of connected devices act in the state of California, which provides specific applications on manufacturers of a connected device. For instance, to provide a reasonable security feature appropriate to the nature of fraction of the device, appropriate to the information may collect container transmit.

But this act also set specific requirements as alternatives, which are set by the legislation for, for instance, that the pre-program password is unique to each device manufacturer or that the device contains a security feature to that requires the user to generate a new means of authentication before access is granted to the device for the first time a so-called trust and first use approach. Finally, still in the us let's look at the CT I IOT cybersecurity certification program.

This is about certifying I UT devices defines three levels of increasing complexity, sophistication, and manageability level one with a minor fee is about terms of service, privacy, policy, password management, access control. And so on level two is extends to the audit log confidentiality of data in transit, secure boots and multifactor authentication and threat monitoring. And level three goes even further to data address digital signature generation validation, temporary evidence design, and other design features.

Since we're talking about certification labels, labels, we cannot omit the work that has be done by the Singapore cybersecurity agency. They have a, this so-called CLS scheme for consumer smart devices, which defines four tiers of increasing testing and assessment. It's a voluntary scheme and the label is valid for as long as security updates are available, which is up to a maximum of three years. So the tier one covers baseline requirements, tier two on top lifecycle requirements. And those can be covered by developers, declaration of conformance.

However, tier threes refers to software binary analysis and tier four penetration testing, and those involve a third part independent laboratory laboratory testing. So it's a uhno, this is another scheme, which has been at least in terms of feedback from the industry we've received positive and good feedback in Japan. We have the IOT security safety framework, which refers to a combination of risk perspectives taking into account the degree of economic impact of incidents and the degree of difficulty of recovery from the incident.

And this has to do with the resilience that was mentioned in my, by the panel and highlighted, it refers to devices as well as systems, and it tries to generate security safety requirements from those perspectives. So there are a set of requirements that have to do with before operation, typically manufacturer process requirements for, from the manufacturer and so on their requirements, which are in the operational scope and their requirements for the operator, which are more of our major like licensing, statutory regimes and so on.

And they're also other requirements designed to, with mechanisms relevant, to social support. It's interesting to see how this framework is rather more comprehensive in the sense that it tries to combine several perspectives, the economic perspective, the resilience perspective, but also the security and safety perspective.

Finally, since we are in that part of the, of the map, let's look at what Australia has done. I mentioned at the beginning that Australia was part of global corporation agreement. And of course, it's no surprise here that we see that the Australia has a code of practice, which is about securing the internet of things for consumer it's about voluntary application and it's based on 13 principles.

And if we, if you were to look into the em, three or 3, 6, 4, 5, which actually originated by an activity in the UK, by the CMS, you would recognize exactly those 13 principles. These are the basic principles that have been identified as relevant for the improvement of the non-existent baseline of I IOT security. And actually the top three principles have been found that they are relevant to more than 85% of the incidents. So by implementing the top three principles alone, somebody could address the 80, 85% of the security incidents that have been observed IOT security.

So after Australia back to the origination of this, the UK department of DCMS, digital culture, media, and sport, they had done a consultation to secure consumer IOT. This led to Ts 1 0 3, 6 45 and 3, 6 45, because it has been adopted by the European standard organizations in ETSI. And as I mentioned, these are the top three guidelines. So for passwords IOT device passwords must be unique butt to any universal factory setting. Vulnerability disclosure policy manufacturers must provide a public point of contact as part of vulnerability, disclosure, policy and security updates.

Manufacturers must explicitly state the minimum length of time for which the device will receive security updates. And these are the top three.

Finally, in, in Finland, we have the finished transport communication agency, Finland being aneu member state has picked up on the work that has been done on ETSI. So on the work on E N three, six for five, it has created a cyber security label with the requirements from that the standard they are, there are a fee structure per product and service, and it provides a description of the product and what measures are there to protect against common threats in IOT. So that's the scope of the labeling.

It includes specifically addresses passwords, and whether it's weak, guessable hard coded, or whether there are insecure or out of date components in use, it addresses also privacy protection, data and transit and data addressed network services and ecosystem interfaces, and last but not least secure defaults. So to summarize, what can we say that we have learned today?

Well, there are a number of policy initiatives that have been undertake by different nations to improve the cybersecurity of I IOT to improve the baseline. There are some differences among the schemes, particularly if we look at the labeling that has been chosen, different parts of the world, for instance, there are differences in terms of the levels, the tiers or the fee structures, but what's important to observe is that there is convergence, which is emerging already among initiatives and schemes.

There's clear convergence on secured by design principles that an IOT manufacturers should apply in IOT device development. There's clear alignment in baseline cybersecurity capabilities that an IOT device should avail. And there's clear guidance on what are the most important ones. For instance, the top three I mentioned, and there's also clear alignment on the responsibilities that the IOT manufacturers should own, or with regard to the treatment of vulnerabilities.

So this I hope has provided you with a sufficient enough summary of the state of IOT security standards and policies, and some legislations on a global scale. And with that, I would like to stop here and open the floor for any questions.