The following are the outputs of the captioning taken during an IGF virtual intervention. Although it is largely accurate, in some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid, but should not be treated as an authoritative record.
***
>> Defining what will be our scope, what will be the information we need to collect from these documents, what are the questions that the researchers need to respond from these documents, for example, what are the challenges that the researchers see, if there are any gaps. There are the stakeholders involved, right? For example, some of the documents mention obligations for manufacturers when they are designing and constructing Internet of Things. There are other stakeholders, for example, for the companies, themselves, that are selling these products to have vulnerability discussions. So, we have this research. I need to say it was very difficult to find, for example, documents from the African region or Latin American region. There is a lack of documents in those regions compared to the other regions.
Then we had a training and briefing of the research team that was a practical exercise with one or two documents, when we did (?) that was reviewing the document, responding to the questions, and we did these exercises with the researchers so they were encouraged to learn about this methodology. And then, Phase 4 was the stronger one that was from May to October this year. It was about the profound analysis of these policy documents. Then, last phases were Phase 5, where we compiled all of these documents in a brief document, categorizing these best practices, identifying the kind of types of categories because the different documents have different terms, different acronyms, different natures for the best practices. But because we need to collect all them and do like a brief, we needed to create categories and to create things with the researchers themselves needed to create or to compile in different sets or grouping. That was Phase 5. Then we are here on the presentation of the draft in the Internet Governance Forum, and this will continue because we will open a global consultation, as was mentioned, maybe at the IGF platform for you to make comments and put additional documents that you want to be addressed in the future. We want to know.
Also, this session, we will have some parts for you to make comments and questions about the research and about the conclusions. And then, this global consultation will also field the global initiative compact because we are going to submit a submission to the compact by the end of February. And as I told the publication of the final report and the printable version will be available in February. I am hoping next year the IGF will have some printable to bring to the people to know more about this research. Well, this is a world map where you can see the geographical spread of these policy documents. As I said, we tried to consider documents from each of the regions. We have a lot of documents from the Asia‑Pacific and the UDEP and also from North America, but we have lack of documents from the African region and Latin American region. There were also some documents that were from the European Union, so we consider that these documents are more important because they are more regional. And yes, we found documents from Singapore. We found documents from Kenya.
Here are the documents per region as you can see. It is very notable that North America has a lot of documents and a lot of work done in respect to the Internet of Things best practices. But also, you consider the Western Europe and other groups are also in that list. So, these other countries from the Western Europe part and Australia parts are also a considerable quantity as well as the Asia‑Pacific. But as you can see, only two documents from Africa and three from GRULAC we found.
But something to mention is that we are seeing an increase in consideration of these kinds of policies around IoT. For example, in 2022 this year, there were a lot of processes happening in terms of laws and regulations among Internet of Things that we are not considering here because it is the current work that is happening. But certainly, we will include those in future research or on an extension of this research.
So, here I will start to explain a little bit on the categorization of best practices. As I explained before, it was a very complicated process because we found that the different documents have different meanings for the different things and the different documents have different categories, different ‑‑ for example, some of them talk about privacy, some of them talk about VMware updates, right, but some of them called operation or continuity. So, we were trying to identify, what were the correct words, and this was a very profound work, because there were some concerns between the researchers about the technical terms. For example, when you are talking about the devices, maybe you are talking about the interface of the devices, because there is a back end there that you can login and connect with the device from an external part, but some of the documents mention the device, as the device extended to this interface, but other documents mentioned the device as the device itself. So, as an isolated thing. So we needed to deal with these kinds of differences.
And also, as I told about the best practices. So, going to the next slide. These are the main four categories we found. The first one is privacy and exposure. That takes into account all focus on encryption, right, all focus on these algorithms used in the Internet of Things, also for authorization purposes. Then also, the word is exposure, because we also included these exposed surfaces when it's not maybe the device is protected, by the interface or the manufacturer has a back door or something that, because they need to update the devices, they need to maintain it and have continuity. But these attack surfaces sometimes are not covered, like they are not sufficiently secure. So, we put all in this category, privacy and exposure.
Also, about having a secure management of the keys, or for example, how to deal with the personal data, right. When you are storing personal data in these devices, you will need to extra protect those because personal data, as you know, is very a global issue. Well, it's not the same to show, for example, a sensor that is measuring temperature in the air, is not the same kind of privacy you will need to have when talking about personal data, right? So, all this stuff, all these issues are in this category, the privacy and exposure. If you want, you can make comments or questions on this.
About the update. You know, software and VMware update is a very important issue because you need to have the software updated. Every day is a CVE there, a vulnerability that happens because the interfaces use libraries, right, where some of the devices use open libraries, some of them use private libraries. So, these libraries need to be updated because as I told every day there is a CV there and there are devices that are Internet of thing devices out there that has no possibility at all to be updated. So, that is something very important.
For example, blocking unauthorized software installation also is very important. Some of the best practices around there includes, for example, when you are booting your Internet of Things device, if the image of the software installed is not like integration checks, right, you need to have the integrity checks in order to ensure that the software in this device was not manipulated. So, this category we think is very importanted.
Also, about the policies around the security updates, about authorized entities, because we have seen in the past, for example, staff members of the manufacturers or staff members of these companies, maybe they don't have a good policy of privacy or security requirements in their companies, so the staff will be installing malware on these devices. So, this needs to be addressed. They need to have an automatically update feature. They need to explain very clear to the customer what is the end of cycle of these devices, so to what intent they will be updating these devices. Maybe an end of life and they will not update anymore, so you need to ‑‑ the users, right, they need to know about that. So, we included these other categories that are non‑technical.
For example, identifying what the device is transmitting, what data has been transmitted, what level of security this device has. So, this labelling that we found, for example, in our economic at home, we know that the whole thing there, it has A‑plus mark to say that it is energy efficient. So, in the Internet of Things, it happens the same. All this non‑technical information for the user, for the manufacturers is very important. Also, the education programs. There are a lot of education programs that their aim is for the users to understand how these devices work, what is encryption. So, people need to know and protect their password. They need to protect their data. So, these are more non‑technical requirements. You must have also support channels. The manufacturer needs to have support channels. For example, when vulnerabilities are disclosed, they need to know and they need to update, but these need to be informed also to the users. So, all this non‑technical best practices were fitting in, in this category.
And the last one is about the operation and continuity of the device, for example, what are the things the user can configure on the device? They can change the password on the device, except using the default password or not. These are the kinds of things that the best practices are mentioning in this sense. Also about to feel safely and securely, what happens if the Internet connection fails and the device is trying to transmit, maybe the device fails.
What will happen, they will replace the device when end of cycle ends. They need to state all these kinds of things. For example, the login of the security events is very important. What will happen if a thief is attacking the device or there is a denial of service attacks and the device gets interrupted to transmit information, you need to log this, because the manufacturer needs to know that, needs to know that something has happened, and the device on the user needs to know that there is an attack under way.
Then, about the secure good practices, as I mentioned, the device when it is put in, if they don't have the integrity of the image, they cannot work because the various requirements. If not, they will work in an anomaly way. So there are some best practices about this, about security procedures.
About the security state, also, if you have devices that are vulnerable, in a moment, the user needs to know, and there needs to be an alert in the device, at least to notify the user that they are still compromising in some way. So, all these things, there are in terms of best practices. Some of them we haven't really seen. We see when we buy some devices, they already are asked to change the password before starting, but some of these best practices I mentioned, I am sure that you never seen these in any of the devices. So, there are things that are things to have in place, but they are not right now happening. So, going to the next slide.
What we found on these documents, we analyzed a lot of documents and we are more than 250 best practices from the different documents, and we found that there are different types of best practices, because some of the documents, some of the authorities that create these documents, the policy document, regulatory documents, some of them are put as a requirement, but some of them are put as a recommendation. There is a difference, because we have an organization that says, okay, we'll recommend that these devices have high security standards, but the reality is that if it is a recommendation, they are not really encouraging that. And at the end, the devices are not following these recommendations. But if it's a requirement, it's more like a hard thing, right?
For example, we have found documents that focus on the Internet of Things, specifically to A259a and b are talking about requirements, right? Nowadays in the USA, for example, you cannot sell an IoT product if it's not following all the requirements. That is something good because we need to have these kinds of more requirements than recommendations because it's a thing and we have found that the states or regulators say that, yes, we have these recommendations, but at the end, they are not following if the recommendations aren't met. So, it is very important that the type, and our findings is just saying that, right?
You have seen the red graph there, the red bar and the blue one. For all the categories we found, there is a lot of requirement policies. It's more like a recommendation things. So, this is something very important to note.
So, before going to some of the researchers' point of view, they will talk a little about their findings and their personal conclusions on the documents. But first, I will ask our online moderator if we have questions or comments, and also for the general audience, if you want comments or questions at this point. Very good. So, Mark?
>> MARK CARVELL: Yes, thank you, Nicolas. Good morning, everybody. I'm the online moderator. I don't see any comments yet in the chat, but we've got a possibility for anybody to provide feedback, questions, and points for clarification. So, please, use the chat if you wish to raise anything. Nicolas, back to you.
>> NICOLAS FIUMARELLI: Yes, we'll ask again. Maybe someone here in the room will have some comments or questions. Now is the time. We will have two more times to do this, but it will be nice to have some feedback at this point.
>> WOUT DE NATRIS: If you have a question, please raise your hand and we'll try to answer it. Please introduce yourself first.
>> AUDIENCE: Thank you, Wout. Thank you for the presentation. Good overview. And makes a lot of sense. Right now you haven't considered the good practice document that DC‑IoT put in, but basically, it's a step further. So, I really appreciate the work done there. One of the specific things that I think may require some attention is the identity schemes. You make some reference to it, but identity and how it's handles is also a worldwide thing that will influence authorization and that kind of thing. So, it may make sense to put more attention to that.
>> WOUT DE NATRIS: Yes, I want to say we included ‑‑ there are some of the best practices around identity management. Some of the things that they mentioned, for example, that these devices need to be unique at each of the manufacturers, but some of the consensus we have with researchers is maybe not by manufacturer, we need to have unique globally, right? That could be something very important. And about the authorization, as you said, it is maybe because ‑‑ well, I am from another perspective, but maybe each of the IoT devices need to have an IPV6 that is unique. That could be something that could be in the future. But yes, there are ‑‑ we found a lot of best practices that mention about the identity. Some of those, I think the Singapore one also mentioned some of the things. Also in the labelling, you need to identify the unique ID of this device. Very good comment.
>> AUDIENCE: Identification of the object, of the thing. The other thing is the identification of the one tampering with it, installing new software or whatever. And a part of this could be you want to prevent the back doors rightly, I think, but if you build in back doors, then they're general back doors that would apply to all the devices IS vendors send out across the world. We don't want that anymore, right?
>> NICOLAS FIUMARELLI: Yes, there are some best practices specific to, for example, of the part of the update. The thing with the update and the software update, on the continuity also, we have found several best practices talking about that only restricted authorities only can do this remote management of the devices. So, yes, we think that, definitely, they interface with the external authorities updating the device, getting the load from the device, establishing good mechanisms and new enmeshes for the device. All of these need to be restrictive to only the authorities that have the control about it. So, there are some of the best practices we also found.
>> WOUT DE NATRIS: Thank you. And just to identify Martin, he used to be the chair of the IoT of the IGF ‑‑
>> Martin: I used to be. I stepped down, but I am still well informed.
>> WOUT DE NATRIS: Thank you for the question. Anyone else with a question? Please raise your hand. Yes, please introduce yourself.
>> AUDIENCE: Yes. (?) from El Salvador. My question, Nicolas, is looking at the lack of documents in regions such as Africa and Latin America, is there research going to provide some recommendations for all multistakeholders in those regions to start doing this or to look at the topic? Because I believe IoT will spread like in those regions, like in the other ones, soon enough. So, we need to take a look at this. Thank you.
>> NICOLAS FIUMARELLI: Thank you. That is a very good question. I think our conclusions of this research are more in that sense. Like, there is a lot, there is after identifiable gap, so that could be the first basis for the authorities to start moving themselves to go. If there is no policy regulations or policy documents or code of practices about IoT specifically, now could be the moment they start to create those. Because as you say, it's a necessity. The quantity of devices is very equally by region, so we will have the same amount of devices in Latin America and Africa, so there will be a necessity to do the same thing that in the other regions, totally.
>> MARK CARVELL: Comments?
>> NICOLAS FIUMARELLI: If there are no more comments ‑‑ yes, please.
>> WOUT DE NATRIS: Introduce yourself.
>> AUDIENCE: Thank you. (?) from Bolivia. I wanted to ask about the plans for capacity‑building, not only in LAC region, but in the world, because it's important to raise awareness about IoT and security, please. Thank you.
>> WOUT DE NATRIS: Thank you for that question. We are in the second phase of the Dynamic Coalition. There is a clear goal to go into a third phase, which is about creating capacity‑building programs, and most developed for that are the education and skills at this point in time, but for others, it will be the same. As soon as we have the procurements ready so we can literally teach governments how to procure safe, that will be the ideal outcome. But for that, we also need to be recognized for the work that we are doing, and that is ‑‑ what they say, the uphill struggle that we're facing at this moment with the IGF, how to get this work recognized as an official IGF outcome. So, that's something we will discuss next week. That is not for this session, but your question is totally right. We need to translate this work into some sort of a template that the world can start working with, using. And from that moment onward, perhaps we will change things faster. Thank you for your question.
>> AUDIENCE: Thank you. This is (?) from Ethiopia. My question would be, I don't know whether this is within your scope or not, but what would be the legal measures if devices are found vulnerable and somebody is, you know, using something, you know, to do some bad things? So, what would be the legal consequences? And how are they tackling this? So, can we include this within this framework? Thank you.
>> WOUT DE NATRIS: The problem there is, basically, it becomes a legal question. And what we're discussing here is a mix of voluntary measures and some requirements, as Nicolas has identified. This is about the manufacturing side of the discussion. As soon as things are tampered with or abused or misused or attacks take place through these devices, it is not the owner of the device usually who is responsible for the attack; it's the person abusing it. So, that becomes a criminal investigation and sometimes a regulatory investigation. That is something that each country will have to put in their own law, but that is not what we are studying at this moment. But you're right, it's the other side of the coin that we are discussing here: What do you do with the person perpetrating rules, basically, around the world? And that is something which has to do with cross‑border investigations, which are incredibly hard to do, but something that the world will have to find an answer to in order to be able to prosecute people who live in other countries and perpetrate their trespasses in other countries as well where the mishaps takes place and where people are losing the money or their identity. So, this is a very valid question. Thank you.
>> If I can complement on that, I think the UK and Netherlands have frameworks in place where they look at the value chain of delivery and recognizing there are different responsibilities, as Wout says, in different parts of the chain. This is not one person responsible for everything. That's the problem.
>> AUDIENCE: Hello, everybody. My name is Ron. I am one of the researchers. I will try to tell a little bit more about a document that I worked on that is the document from Korea. And it tries to tackle this issue of the appearance of new vulnerabilities into two ways. The first one is that the manufacturer is obligated to provide security patches to the document. And the other way to tackle it is that during the period of checking the standard in the releasing of the device, the device cannot be released until there is a vulnerability disclosed and exploitable in the device. But this creates, like, a new issue to us because, well, okay, so you're obligated to patch the device, but how much time the manufacturer must patch it? It is related to the amount of the devices; it's related to the complexity of the vulnerability. So, we have a lot of factors that can alter and can really make everything a little bit more blurred. So, it's a very difficult point that we face of how to address it, how much time did we need to take to fix it, and also, how much time do you need to do a security warranty to the device. That's it. Thank you.
>> WOUT DE NATRIS: Looking at the time, we will come back to the second round of questions, but first, let's go into the presentations of the researchers so that we have time to do the public consultation and ask you about your opinion of the recommendations. And that we don't run out of time. So, who do I give the word first?
>> NICOLAS FIUMARELLI: Yes, Savyo will start. Go ahead, Savyo.
>> SAVYO VINICIUS DE MORAIES: Thank you. My name is Savyo. I'm one of the researchers of this research. And, well, I'm basically going to talk about, should documents that I have analyzed. One of the documents is a report of previous consultation carried out by the Uruguayan government with the support of the Internet Society and the other document is in regard to the security recommendations for the supply chain of IoT devices that was published by and developed by the ‑‑ sorry, I forgot the name ‑‑ European Union, under the ‑‑ let me check the name ‑‑ the European Union Agency for Cybersecurity.
So, these are basically the two documents. Both are kind of recommendations, not regulatory documents. I think that the presentation has the title of the ‑‑ okay. I can put this in later, the links of these documents. But basically, starting from the document from Uruguay. What I could see by analyzing this document is that this public consultation reached more the end users, the person as users ‑‑ not companies, not government ‑‑ the end users as Civil Society, and it brings some concerns and some security recommendations in regard to IoT. And considering the scope, it is mostly focused on personal data privacy and also security for home IoT device, wearable devices and this category of devices, of IoT devices.
And I have highlighted some of the recommendations and also some concerns presented in the document. Maybe I should start from the risks and challenges cited by the document. And one of the (?) is the one that says that competitive pressure to introduce market release times for system and/or devices and to lower the cost of these devices, the manufacturing of these devices, has resulted in fewer resources being assigned to security, which means that the market competition may become a threat to the IoT security, basically, if we don't care about that, if we don't regulate these kinds of things. This is a personal comment. This kind of releasing and the marketing of these devices, this could lead us to bad cybersecurity configuration in the devices.
And going ahead, should the best practices mentioned in the document. One of the best practices that I saw many times during the analysis was in regard to the use of the passwords of the devices. Like, all the devices may be in the same company, not exactly from the same category of the device, but using the same password can lead us to really bad security damage. Basically, you have a back door or a front door ‑‑ open front door, if you want to understand as this. So, if someone discovered this password, can get access to every device. And in some cases, we could find in the devices hard‑coded credentials, so you cannot change a different password, and this is worse than just a password that can be changed.
Another point that is mentioned by this document from Uruguay is the point of low‑blocking parts and unused parts of user services, for example, one of the main IoT botnets exploits the access of the Internet protocol for remote access and control of devices. That part, that basically no one end user will use this service. And in some cases, we can't ‑‑ or is not an easy process to block this part, to stop the service, and this can lead us to one vulnerability.
And in the same meaning, limiting the connection of IoT systems or devices to the Internet, to the minimum necessary to proper functioning of the devices. We have basically local communication in my home network, for example, or in my company network, and then the Internet connection to that device. So, the idea is to limit the Internet connection of that device, the services and so on, and take more care in the security of this Internet wide‑open connections.
One important thing here is to allow consumers to easily identify the degree of security of the IoT systems and/or device. This basically means the need for labelling system or any other system that makes easier to the user understand if one device is secure or not.
And, well, one of the things that it mentions is also the need for security by design and security by default, in the meaning of the full configuration of the device must be as secure as possible, basically, by default. And if the user needs to make unsecure configurations for specific use ‑‑ needs local network, for example ‑‑ it can do it, but by default this is disabled. So, this is basically the main points of this document. We have many other recommendations that will be in the final document, but this is the highlights. How much time do I still have? Okay.
And, well, the other document from the (?) this is an important document that I highlighted. It brings concerns basically to the manufacturers of IoT device, and maybe this can be used also for regulatory actions in regard to the certification of device, for example; that is security recommendations for the whole supply chain of the devices that goes, basically, from the manufacturing of the integrated goods through the end of the life of the devices, so the planning, the development, the manufacturing, the building the device itself, the software, updates and so on. So, this is basically the scope. This is a really, really complete document. It has good recommendations and basically can be used for big companies to adapt their security maturity to the IoT devices, to the development of IoT devices, with more specific questions for this context, and also for small companies that still are not that much mature on developing secure IoT systems to understand their first step, what should they care about and how should they prevent some problems in each phase of the manufacturing of the device.
So, some of the risks mentioned, risks and challenges are mentioned in the document. The first one that I can mention, it can refer to our research, is that one of the recommendations ‑‑ sorry, I'm... So, going more specific in the manufacturer, the risks, for example, the risk of the bug interfaces user to the development of the devices to understand the bugs and so on, should be disabled when the device goes to the market. So, this is one problem that, it's deeply technical, but it happens often with some devices, so it's important to talk about that, and it's simple to handle this kind of problem.
So, another problem, for example, is ‑‑ that counterfeit products are sold by unauthorized suppliers who are not part of the manufacturer's official sales channels. So, for example, if we have the manufacturing of one device ‑‑ one thing that I don't trust, that I cannot trust, the team can maybe make more devices and then sell these devices by other means, and this is important to talk about, basically having original devices in the market.
Another important thing that is related to it, as Joao just said, that users should be properly informed and trained to raise awareness about the vulnerability and the security risks of the devices and also the companies should have one vulnerability disclosure policy in this kind to make the user aware of the new threats to its devices are susceptible.
And, well, going to the recommendations. Some examples. That the capability of one device being updated when some new vulnerability is discovered in a short time, but there is no specific term to update this kind of thing. This is important, because during the life cycle of one device, the vulnerabilities can appear at any time, in the time frame of ten years, for example.
Another important recommendation is to build a comprehensive set of documentation resources to combat human errors that include clear guidelines or action points to implement at each deliverable. Basically, teach the users how to make the devices secure and to avoid unsecure, accidentally enable some unsecure configurations.
And also, the last one, one very important, both for end users and for the whole supply chain, is that stakeholders, especially suppliers, should the transparent offering clear information about the operation and the normal behavior of the supply product. Since the integrated to the IoT device and system, all of the parts in the supply chain should be aware of the risks and potential problems and also should know behavior of that part of the software, of that set, basically. So, that's it for now, and I hand over to Mark. Thank you.
>> MARK CARVELL: Thank you, Savyo.
>> NICOLAS FIUMARELLI: One comment. I think what's important to understand is that Savyo said about the initial document that is very complete and maybe the best that he's seen, but it's a recommendation. (Wout speaking) So it means it's easily ignored by everybody who has to deploy these sort of measures. The second thing I was reminded about, one of the first things he said is that when I interviewed people on the work before we started this Dynamic Coalition on Internet Standards, the person said to me, "But these chips, they cost less than $1 apiece, so you can't demand of these manufacturers that they put security in there, because they wouldn't make any money." So I said to them, so we let these $1 chips basically ruin the world? So, I think that is something you need to think about when you talk about the manufacturing of these sort of devices, because it's all about chips. And if these chips are inherently insecure, then it also means that the rest of the device is insecure, and that ‑‑ then it becomes $1.05, right? Then we have security inside. So, what are we talking about? I think that that is the sort of recommendation that you could take home and share to everybody you speak to, because that is probably a mind‑changing idea that, perhaps for 5 cents apiece, you have security. Just a theory. Let's go on to the next presenter.
>> NICOLAS FIUMARELLI: Yes. Before going to the next presenter, I have a comment regarding that, because as I said in the beginning, these IoT devices are constrained devices. What's that mean? The constraint is about the memory, about the ability to do encryption, right? So, here we are in a thing because they are going to sell ‑‑ trying to manufacture these in a much cheaper way, as you are saying. But at the same time, they need to have security. But there is a balance between the constrained device and the level of security they will have, because the more secure you want to be, the most energy you need to spend or the most, how to say, memory you need to have, to have all these keys stored. So, in the end there is a balance that needs to be achieved. There are very good standards at several standardizing entities to achieve this balance in the different kinds of devices because there exists these types of devices with several differences of these constraints. And yes, I think that maybe an explanation of why these constrained devices are not secure is because they are not capable of doing security. So, we need to address this. We need to address the issue of having constrained devices balanced with the security they have. Just one comment about that, because it's not only about making cheaper because of no security at all, but also because of these constraints doesn't allow for the security to be. So, there is a balance, and very good cybersecurity or encryption mechanisms also for this balance, devices.
Just to give you an example, you can sign the data that is transmitted in the device, maybe some of the microcontrollers already in the market have the capability of doing encryption at that level or at least to do some sign‑in, but then the other part of the sign‑in is done in the interface, or in the gateway, the place where they have more resources to do this encryption. So, with a combination of a level of encryption that is minor at the device and with the combination with security mechanisms in the capable device, in the gateway or the computer or your mobile phone, they have ‑‑ the mobile phone and the computers have capability to do strong encryption, right? So, with this combination, I think that will be the way that the devices have more security. Some comments there? Starting with Joao.
>> JOAO MORENO FALCAO: Hello again. One of my reference points are cryptography. So, I think it would be very important for us to point out that there is ‑‑ there are actually cryptography algorithms that are focused on protocols with an execution disparity. Like the power execution disparity. If one of the devices are not capable of doing so much heavy computations with another that are capable. So, maybe we could, like, light on this kind of protocol, the kind of protocol that we would have, smaller and weaker devices being able to do like full setup of encryption algorithms but with the help of the main device. Like a cell phone or a computer.
>> SAVYO VINICIUS DE MORAIES: One more comment. With all these things and problems, we already have great integrations on system architectures and protocols that deals with this problem. So, we can ‑‑ these are challenges, but we already have some answers to ‑‑ some responses to those challenges. So, this is what we saw, for example, in the documents that we analyzed. And we can see every day in the new document releases by the IGF and other standardizing spaces and organisms. So, this is what we could see in the research, too.
>> MAARTEN Botterman: I think it is important that you look to the function of the device. We all know there are different devices. There is the active ones. There is the passive ones. The active are more likely to be able to deal with encryption than the passive ones. But also, the purpose, how they're used.
Now, the thing is, any IoT device could be part of a bigger system. And that will make it more important to have it certified from a certain quality or not. So, I think we should be wary of giving the impression that everything should be top‑notch secured. That doesn't take away Wout's argument that security by design also means taking into account that you need different levels for different things.
But the problem is, when you think this device is secure enough as it is, if it's put in a plane, it is different than when it's put in a child's toy.
>> WOUT DE NATRIS: So, now, we would like to hear from one of the researchers who is online. He will be speaking in Spanish, so, please, if you can use the translators, it will be well for you. Oscar, the floor is yours.
(Non‑English language).
>> Oscar Giudice:
(Non‑English language)
>> WOUT DE NATRIS: Oscar? Sorry, we don't have translation to Spanish. It is very bad to say that. But yes, we will try to put your comments in. We will share the comments in the output of the session so everybody can read. So, I'm very sorry about that, because we don't have translation from Spanish to English.
>> Oscar Giudice: Okay.
>> WOUT DE NATRIS: Sorry. Thank you for being with us.
>> Oscar Giudice: No problem.
>> WOUT DE NATRIS: That will cover the Korean and the Singapore documents.
>> JOAO MORENO FALCAO: Hello, everybody. My name is Joao. And I want to first thank you all for being here and start with my background. I work as a penetration tester, so I am a hacker. And as I am in this point of view, I try to think of, like, an attacker, and also with someone that is going to test this kind of document.
So, the first document I have here is the Korean one. And actually, this is my favorite, because, well, this document was released as a regulation about an Information and Communication Network Act from 2021, and it was focused on certifying devices and systems to work with IoT. And this document, to me, is the main thing that captured my attention here is that it has plenty of examples. So, we have like a dozen of best practices, of obligatory, things that you need to comply to be able to release your device. And for each one of them, you have, like, a document, code exempt of how not to do and how to do the implementation and testing of this device.
And in one of the best standard capabilities, they ask for penetration testing. So, it's very important that we have, like, an active person to understand, to learn, and to try to attack the system, to be able to guarantee that it's safe.
One thing that Nicolas said before that I think it would be interesting to point out is about the capability of the microcontrollers. When we say about that, the IoT devices here are divided into three main categories. And for each one of them, we have two kinds of certification. So, for the light one, it's focused on ‑‑ it's like I am reading the document. It's focused on its bare metal devices such as sensors. So, we are talking of these kinds of devices that are in the end of the network. So, it's like a doorbell; it's a movement sensor; this kind of device. And we know that it's very, very simple. Normally, it wouldn't have even an operational system.
So, the thing they try to tackle here is like, okay, does this device have sensitive data? Does this device, like, handle personal? And if not, it's like easier to tackle, easier to protect, because the stakes aren't really high. So, when we talk about the basic devices, we are speaking of small and medium‑sized device with flows‑back operational systems. So, there are simpler systems with several of their functionalities disabled to run faster and lighter. And to this kind of device, we need an additional security bare minimum because it has an operational system; it has several threats running there. And when we talk about the standard, they think of small ‑‑ sorry, medium and large smart home appliances. So, we are talking, like smart assistants, a home controller. And to these devices, they run fairly reasonable equipment. You can even compare some of these devices with old computers, like 10‑20 years ago computers. So, they are able to run most of the protocols that we have.
The thing to me ‑‑ another thing that captured me is that they show an intelligence shift. Like, the standard types aren't like, oh, the basic one and simpler, just to everything, and there are an advanced that we are not going to use it. They say like, oh, we recommend the advanced, but knowing the devices that are on the market, we need ‑‑ we divide it.
And another thing that is interesting is that this document adds the application and service and the API systems that interact with the IoT devices, so you must comply with certain obligations, even if you are running the system that the device connects. And this is actual novelty to me when compared with other documents, and it makes total sense, because if you have, like, safe system, but you can hack the server or intercept the connection to the server, you really break the security chain of the system.
And there's a recommendation that it's actually not obligatory to any kind of the standards, but I want to point out, that is the necessity of keeping private data in rest safe. So, if someone steals a device and tries to break it, tries to access the data, they shouldn't, even though they can, like, connect and read directly from the memory. But this kind of recommendation is actually more difficult to apply because you need proper microcontrollers, proper systems to guarantee the safety of the key, because the key is isolated and it is kept off the system. So, this is actually difficult.
And when I, as a programmer, too, tried to buy this kind of device to construct and interact myself with IoT devices, I had issues, because there aren't plenty of these kinds of hardware available right now. (Off microphone)
So, the second document that I worked out is the Singapore document. It was produced by Cybersecurity Agency of Singapore, and it's heavily based on the European Telecommunications Standard Institute. This is interesting to us because, well, we have like few countries which produce these devices, and the whole majority only receives and applies these patches. So ‑‑ oh ‑‑ (off microphone) can you pass it? Oh, okay.
The Singapore agency says, like, okay, we understand that these devices will normally not be produced here. So, how can we enforce our laws, since we are, like, a small country with small market? And the way that they decided to tackle this issue is using the umbrella of the decisions of (?). So, they elaborated on top of it, but the whole idea is to create a common ground, something ‑‑ recommendations that are shared between multiple countries and can be used by them. This document is a labelling system document, so it will have like four tiers that will be given during the release of the product. So, here is the first issue.
If a device is released with security patches, everything is okay. But if in, like, the next month, some major vulnerability is released, how can you degrade or even lower the security level of the system? And the problem is that you can't. You bought the device. You installed it in your home. We will not keep an eye checking if the device is still compliant with the labelling system you chose. And, well, speaking firstly about the security levels of the system, we have four levels. The first one is actually a declaration of conformance, so the manufacturer will say, like, "I comply with these requirements" and provide documents that agree with their claim. The second one, you will do like a check if the device was created using a security‑by‑design approach. The third one will do a binary analysis. And actually, the third is quite advanced. And even though we don't have, until now, an active search for vulnerabilities and I as a pen tester know that it's very limited, these kinds of tools, yet.
So, the fourth level, with pen testing, will be definitely the most ‑‑ the most useful and could guarantee the capability of that device. But we have huge limitation. Like, interim, these documents will say that the certification process cannot last longer than 15 days. And 15 days? It's not reasonable. Like, they argue, if you are going to Level 4 of security, you have four days to test the system, so how can you really, like, turn the device upside down and disassemble it, check the circuits? This kind of analysis takes a reasonable amount of time, and it's not feasible to do.
So, in conclusion, I think here we have, like, huge advance because we are already checking at least a point of development life cycle to check if this device is safe, but after the release, there is not much thing that we can do.
And another interesting path that the Singapore document showed is that they are already partnered with German and Finland to be cross‑compatible. So, the Level 1, 2, and 3 is compatible with Finland's system, and the German system complies with the 1 and 2. So, yeah, that's it. Thank you for your time.
>> WOUT DE NATRIS: Thank you, Joao. I think it's very important that you note that the labelling, and specifically this kind of information for the final user is something that is very important. (Nicolas speaking) And also the compliance with the label is something that is the future of the Internet of Things. All devices need to be compliant with these rules, and this is the way to be compliant with the label, right?
Now we are going very rapidly for Savyo. He will mention the document that Oscar was to mention about the Brazilian one. So, yes, if you can have, like in less than five minutes? Yes, very good.
>> SAVYO VINICIUS DE MORAIES: Well, I have ‑‑ Brazil was one of the documents that was analyzed by this research. Oscar was the responsible for analyzing this document. But we have also in the Brazilian IGF, the one session with one of the members of the certification team for general telecommunication devices, that act for the certification of general telecommunication devices, that also includes IoT systems and has some specifications that fits to the IoT systems.
So, basically, what we have are not exactly requirements, but can be understood as some recommendations. In the case of similar to the labelling systems of Singapore, Germany, and Finland. Thank you. But what we have is that, basically, the vendor of one IoT device must go to the Anotel, which is the organization that regulates telecommunication in Brazil, and says that "I comply with this point, this point, this point, this point," and then the device can go to the shelf, to the market.
But in the case of, in general terms, basically, this problem that Joao just mentioned of a new vulnerability or something else happening, the Brazilian document provides means to Anotel remove devices, when we discover a new vulnerability, Anotel can go to the market and remove the device from the shelf, and then they only can get back to the place, to the market, when that vulnerability, that some patch, some update or something like that. So, these are the general points of this document.
But I think it is kind of weak in this document that it does not mention minimal requirements. It's just, this is not exactly legal analysis, but basically, the manufacturer of the devices choose which requirements it will take care about and then satisfy for that. This is not a minimal requirement. Thank you.
>> NICOLAS FIUMARELLI: Thank you, Savyo. And I will ask Mark if we have online questions. So, please, Mark, the floor is yours.
>> MARK CARVELL: Thank you, Nicolas. First of all, just to say, in the chat, if you're entering the Zoom, we have put links to ‑‑ well, Savyo put links to the Uruguay documents and the ENISA one, the European one, and Nicolas has put the other in the chat, a link to that.
A couple of comments and one question have come through in the chat, in the online communications. Firstly, a general comment that this is very useful work, to look at how regulations and guidelines are evolving. And I think that's a characteristic of the project, that this is a continuously evolving area of important work.
Secondly, there was a comment about engaging more directly with equipment manufacturers, as well as the majors who set requirements for equipment RFQs ‑‑ requests for quotes ‑‑ in governments, and instrumentalities, et cetera. So, that's perhaps something you want to comment on, request for quotes. It's a way ‑‑ the comment says, it's a way of better developing decent manufacturers' requirements, in the absence of usual market or demand forces with industry.
And then, we had a question: Is there any research on IoT devices and IPB6? If you care to comment on that and respond to that, Nicolas. Thank you.
>> NICOLAS FIUMARELLI: Thank you, Mark. Very interesting comments. And yes, about the inclusion of IPV6 in the IoT theme, I have not seen in the documents like mentioning about this. But as we have one comment at the beginning from the person from ICANN, I think that it is very important to handle this, right, to what will be the way to identify these IoT devices globally. So, that could be something.
So, returning to the presentation, and we will go to ‑‑ okay, we have questions here in the audience. Please, first here and then there.
>> AUDIENCE: Thank you. Thank you for a good presentation, for the researchers, I think. This is Matasava, private consultant here in Ethiopia. Actually, I'm working also on the cybersecurity policy research. I'm really wondering ‑‑ this is just my view ‑‑ Internet of Things, IoT, is new for us at this moment, but it is an integration of existing technology. Internet is here with us for a century or most half a century, and devices, the smart devices, before they are smart, they are here with us for centuries and for longer. They are matured.
So, the point that what the current research is doing is how we can bring those devices to the Internet. So, it's just a bridge that we are doing, how we can make this electric or mechanical devices, or whatever devices that there is in the existing, bringing to the Internet so that adding some features of smartness. So, the security's coming here. Security is Internet with the different layers of Internet protocols for long, it's matured. Standards are here, protocols are here, policies are here. And even for device production, there is a standard. There is different industrial standards. So, what we have to do is how we can hybrid these things and bringing to the Internet of Things and then create these standards, policies, or whatever recommendation that we can give to it, to the point.
So, I think all of the presentations that you are seeing is, what software then, in different countries, under policy regards ‑‑ but can we see these things and we can create a better documentation over here? Really appreciate for you.
>> NICOLAS FIUMARELLI: Yes. I have a small comment on that, then I will go to Joao to answer. I think that there is a difference between what we know or where wha we understand as the Internet ‑‑ computers and browsers and applications in the Internet ‑‑ and the Internet of Things. Actually, they are different protocols that are being used in the Internet of Things. And it is, in some way, if you look at the architecture there, you have routing system that is different in the IoT system, so, but I understand your point, that at some point, this information from the device comes into the Internet, what we know as today. But yes, we need to address this as an isolated thing or a different thing, because the standards, the function, the capacity, and, well, I talk about the constraints things, are different. In the device, there is something ‑‑ an attacker could access the device by tampering the device, by trying to go to a connection that is not Internet but is another thing, for example, loader or different protocols there, that you can access the device, but it's not Internet. So, we need to address this as, in my point of view, as a different thing, because there are different capabilities, different protocols there. But I agree that it will be very interesting if we can have a hybrid thing, like considering this as a cybersecurity challenge for Internet in general because Internet of Things sometimes is not the Internet itself, but we can see these as a set of things.
And I think Joao has a similar comment. Go ahead.
>> JOAO MORENO FALCAO: Hello. Thank you for your question. Well, nowadays, I work as a security tester for industrial systems, and we also have this kind of question. Like, okay, factories are here for like a century. So, what changed? Why do we need to double, triple, quadruple the amount of money to secure it just because we plugged it in a socket in a switch? And the thing is that when the factories were designed, and most of the regulations were cached, the security was focusing on, like onsite security. So, how can we protect this cable that connects this machine to that? And when we connect it to the Internet, the possibilities, the attack vectors are multiplied. So, now, if an attacker, like, compromises the network of the company and migrates to the industrial network, it's done. If they have the correct tools, it can, like, do reasonable damage and critical damage to this site.
So, what changed is that we have a clash here of a fast‑evolving system that is the IoT devices and the computer science part of the challenge and a crazily fast evolving system that is the Internet. So, how can we integrate that, considering that we usually, like, update our cell phone once a week, our computer once a month, with devices that are meant and that we think must last for years, in an unattended way? So, to me, this is the big challenge here. It's like, the person that buys this device, installed in their home, the company that installed in the office, or even the industrial facility that installed machines doesn't want to, like, interact with each one of the systems to guarantee that it is functioning correctly. It must be unattended. And our computer isn't unattended. We use it every day. We use it, our cell phone, every day. So, this is the main change to me. Thank you.
>> WOUT DE NATRIS: Thank you. And Savyo also has some answer, then we go to the other person.
>> SAVYO VINICIUS DE MORAIES: Just one short comment. This is the main question probably of everyone here in this room and everywhere, basically. And, well, it can be one of the places that can fill this gap. There are many options, but here in the IS3C, we have a specific working group for IoT cybersecurity by design, which is discussing this. This is one of the works that we are carrying on. So, we have more researches, more actions to make, to take, to fill this gap. And if you are interested on it, please join us.
>> NICOLAS FIUMARELLI: Yes, go ahead.
>> AUDIENCE: Okay. This is Said from Ethiopia, the (?) university. I have three questions. The first one is: When you review documents from different countries or from different regions, did you find any of them which dictates the type of encryption algorithms or encryption tabs they have to use or review declarations?
The second one: What about ‑‑ the first one is to preserve the data vulnerability ‑‑ what about the hardware vulnerability? For example, manufacturers may add some, another additional additives on our hardwares. Therefore, if ‑‑ do you find any regulation to detect that type of things? Maybe the manufacturer leaks information from the users. Therefore, do you find any regulation to dictate this?
Another one. I'm from, as I told you, I'm from university. What mechanisms do you have to integrate such up‑to‑date regulations which are available in the world of education system, such that we can deliver to students the up‑to‑date and the excellent regulation systems? Thank you. Thank you very much.
>> NICOLAS FIUMARELLI: Yes. Do you want to cover, Joao?
>> JOAO MORENO FALCAO: Sure. Thank you. Well, the first question about the hardware vulnerabilities is a very trickier question, because actually, if we think of cybersecurity, we are seeing that it left military point of view, like 20 years ago, when it migrated to common sense and started to be discussed inside companies. But, like hardware security? I don't know. It's like on diapers. So, yeah, I really enjoy this field. I started, but we are starting, and it's a big challenge. Most of the hardware vulnerabilities aren't covered because we ‑‑ when we think about these devices that are really key, we need that the chips aren't integrated with the systems that we are going to use. So, like, oh, you are going to use AES, you need a core processor to encrypt your data. And doing that, you cannot patch this core processor. So, the capability ‑‑ the flexibility to cope with this problem is very limited.
And about the education. Actually, in the cybersecurity field, it's a huge problem that we are facing, and we don't have enough people to tackle the demand. And we also have another working group focused on that, focusing on how to improve ‑‑ how to really improve the education on cybersecurity.
>> WOUT DE NATRIS: And that working group, as I said at the beginning, presents its first report on Thursday, 16:15, I think in the large briefing room, but it's in the schedule. Dynamic Coalition Internet Security and Safety, and that's the session where we present the report.
>> NICOLAS FIUMARELLI: Yes, thank you so much. I also think the question was very interesting, because the encryption changed everything, right? We are facing, for example, quantum computers right now, and the algorithms, the algorithms need to be quantum‑resistant also, right? How to update the algorithm that the IoT uses, that is a full question, and yes, it's a very good issue that needs to be faced, right. What will happen with our data collector right now and in the future with the quantum computer, they can decrypt some in seconds. So, we are at risk right now. Our personal data that is right now will be fully readable in some of the years, but this is another conversation and maybe for another working group on the quantum communications.
>> WOUT DE NATRIS: Yes. Will be announced as well.
>> NICOLAS FIUMARELLI: Yes. We are also trying to create a working group on quantum.
So, returning to the ‑‑ if there are no more questions? One more? Okay. Go ahead. Final one, please.
>> AUDIENCE: Okay. Thank you. My name is (?) from GTE. Please allow me to ask my question. My question is, there is some device which is unknown, you know, because the factories produced some and it might be software or hardware. So, this device is compatible with any devices. And if you just install or make it somewhere, so unknown, how can we just make it this? And how can we detect it? Because the purpose of this software or hardware to steal personal information or company information in hiding way? Thank you for answering my question.
>> NICOLAS FIUMARELLI: Yes. To you, Joao?
>> JOAO MORENO FALCAO: Thank you for the question. So, cybersecurity nightmare is having like a dozen of protocols speaking with, like, 100 different systems. So, we already see works trying to integrate and use common protocols and common management systems to manage all these kinds of devices. So, in the Internet engineering task force, we see initiatives trying to, like, standardize the update system of these devices, because we know that if the user needs to connect to each device each time they are going to update, it is not going to happen. So, we are really looking into this, how to integrate and how to ease management of this kind of system, because one of the main problems in cybersecurity is the visibility; is to know what is happening into your system.
>> WOUT DE NATRIS: Thank you. We are going to close the questions again because we are coming to the recommendations, which is finally the outcome of all this work, and to hear your views on that. So, Nicolas, please proceed.
>> NICOLAS FIUMARELLI: Yes. Following with the presentation there. Okay. So, for the report is trying to identify these 20 best practices from all these documents. So, what I will mention some of the criteria we find or the challenges we find to have a commonalities or how to get these top 20 best practices. Well, there are different types of documents, as I explained. Some are more with requirements. Some others are with recommendations. (Off microphone) Yes. And that is something very important to mention, that it is a challenge to identify what are the best practices.
If we are talking about recommendations and requirements. So, those are different things.
So, we need to ‑‑ we try to include in our criteria different types of documents. Also, other things that we identified were that some of the best practices were repeated in different types of documents, so we try to prioritize this kind of repetitive best practices as the best practices also. Also, we try to figure out, what are the most consulted sources, right? If there are several best practices that came from the same source, from the same best practices standardizing company, et cetera, we also give higher priority in selecting these best practices.
Then also, the good practices that the researchers found more critical or essential at this moment of time were also highlighted or prioritized. Also, we think that we need to have different balance in terms of the categories of the four categories I mentioned, so we could have best practices from the labelling to the privacy to the operation and continuity and the update of these devices, and a special attention also on the ones that included other stakeholders' responsibilities, right? Because we know that's something that is lacking right now is enforcing these other stakeholders, not only the user, but the manufacturer, the states, the market, to follow and be compliant with the rules that have been ‑‑ or the recommended practices, right?
And then at the end, we also see the ‑‑ because we found some of the open consultation documents there, out there, that they were lacking of sectors or stakeholders. For example, in the Argentina open consultation, they were only private sector and other of the stakeholders, so not all stakeholders or sectors were there providing recommendations, so could be some kind of bias in these recommendations.
Also, I think the Argentinean one, in some of the part, it says that no cybersecurity requirements are needed, or something like that. So, we are trying to focus more on the policies coming directly from the regulator on policy‑making instead of over the open consultations.
Examples of the best practices were a lot that were mentioned in this session. We are in the process of finalizing the top 20. We will be in the report for the open consultations for you to review. And we also want you to maybe, if you know of other documents or other regulations and policy documents happening, it would be nice for us to know, to include in our research, for an extension of this research. I will not deal in the other best practices because we are lacking of time, but it will be all in this report, and you can ‑‑ as I mentioned, it will be an open consultation, so we will be open for comments and to put some suggestions, et cetera.
And some of the conclusions of this work is that, yes, these need to be evolutionary thing, right? We are seeing in 2022 there are a lot of ‑‑ or right now, there are a lot of policies being implemented and created. So, we also see, for example, in Latin America, in Africa, there are a lot of policy documents being addressed right now, for example, in the Caribbean region there are two or three countries that are already working right now in this policy document specifically for IoT. So, we would like to include this. But a conclusion would be that this is an evolutionary work, right? We cannot say we will stop here, but we need to continue including more documents and continue this analysis.
Then, we have seen that the adoption of these best practices as some of the researchers' comments and really the concerns we have, so we see that this is increasingly urgent, right? The following year will be more urgent and the following one will be super urgent. So, we need to address these right now. That is some of the conclusions. Because as I told, not all the documents mention all of the best practices, so at the end, why this is not happening, why there are some of the best practices, for example, on the labelling, that not all the countries are addressing right now. But we see that we are very concerned about this. We think that this needs to be something mandatory to do in all states.
Well, there are also other topics of relevance that were not included in this list, in these 20 top best practices list, because for example, as we mentioned about the quantum computing and other things ‑‑ no document mentions about this, so we need to be very aware of, for example, quantum‑resistant algorithms. The researchers identified other best practices that are not in any of the policy documents, so, that we think are important, and all of this will be in the report also.
But there are some, like the quantum computing and other things like the identity management that is not fully covered. So, just in closing, because we are not ‑‑ maybe we could have another final round of comments and giving the floor to Wout. But I think that we will have this open consultation starting from next week, probably, in the IGF Review Platform. So, you all can see this. And we will have a final report in February, as Wout said, with all the comments and the suggestions being collected from you, from your side, so this will be a thing that will evolve.
And then, to mention the relevance to the Global Digital Compact. There are several organizations ‑‑ IGF ‑‑ providing a contribution to this. The Global Digital Compact has a roadmap with different key points or focus key things to address. And two of them are listed ‑‑ the promoting digital trust and security; that is something that we found link with this research because promoting digital trust and security is about having rules, having requirements for the things. So, in order for the E. User and for the companies to be more trustable about their devices, there are some of the descriptions on this key point of the roadmap there are very, very interrelated with the work of this research.
And also, the other point is the ensuring the protection of human rights in the digital era, because we are talking about personal data, sensitive data. There are a lot of countries that have personal data or data protection rules, right? But how these data protection rules are being implemented? Because if we don't have these requirements for the Internet of Things or different computing systems, we will not be following the criteria of the rules that these laws ‑‑ because there are laws, right, on the data protection. So, we need to have these, and this is fully interrelated with this point of the Global Digital Compact, about ensuring the protection of human rights.
Well, here I will stop and let Wout do some conclusion points and following next steps.
>> WOUT DE NATRIS: Yes. We have a few minutes left, so let me look at the online comments section, if there's anything there, Mark, that you would like to present on?
>> MARK CARVELL: Yes, thanks, Wout. No new points coming through online, but just to say that I've included links to the Korean and Singapore CSA documents that Joao described. They're in the chat. So, if you want to access those documents, go to the chat for the links, okay? Thanks. Back to you, Wout.
>> WOUT DE NATRIS: Thank you. Then we have time for one final question. So, who would like to ask it? Yes, sir. Please introduce yourself.
>> AUDIENCE: Hello. My name's Gabriel from the USA. I am wondering if your researchers give any time to discussing the consequences of inaction? We talk about how these devices, if they're not secure, they can remain online potentially forever, and that the market, if I understand you correctly, does not currently incentivize the adoption of non‑obligatory standards. So, is there a Doomsday, is there a discussion of what those consequences could be if we don't come up with good international obligatory standards?
>> WOUT DE NATRIS: Let me start, is there a doomsday? Not in the sense that the Earth will explode, but if you look around you, there are so many incidents each and every day that, of course, there's a need that the world needs to come together and solve this problem. Because in whatever country you live, when it really comes down to security, we do have the same ‑‑ I can't think of the word in English ‑‑ but the same common ground, basically, because we want to keep our data secure. We want to keep our, whatever we have, secure. So, we do have common ground there. And should we ‑‑ can we be able to find each other on the common ground? And that seems to be becoming incredibly hard, but that is different from the attacking point of view, because everybody has an attacking point of view. And you use the vulnerabilities that we find when we attack somebody. Not me personally, but we as a country, basically. So, yes, it is ‑‑ what is the most important point, being more secure or being able to attack another more successful than another? I think that is the heart of your question. So, let me stop there and, I think Joao.
>> JOAO MORENO FALCAO: Yeah, hello. Thank you for your question. And I want to bring another document here, just to tackle this issue; that is, the Senate Bill number 327 from California. Well, this bill addresses a little bit about the liability of the security, how to impose the security standards, and it's actually interesting to see. Because when we compared with the Korean document, they ask, like, oh, the user cannot have full control of the device because he will do things that will make it unsafe, and the Senate bill says, like, no, the producer must not ‑‑ are not obligated to block the total control from the user.
And about the liability. They also say that the store selling this device are not liability for the security damage caused by the device that they are selling. And also, the producers are not liable for a third‑party systems that are installed. And this is trickier, because if you think, like, about one TV, and you install an app, so that it's crucial to the usage of this TV, the producer will be like not liable anymore. So, how can we create this ‑‑ how can we settle the division about what software are actually essential and weren't installed by default, by the factory, and what is not; what is totally optional, and, well, the producer will not be liable about any kind of breach.
>> WOUT DE NATRIS: Thank you, Joao. I think that leads us to our concluding remarks, because everybody will have to go to another session and people will want to come into this room. Let me start with saying how amazed I was by how many people came to this session. So, it proves how important this topic is. And as IS3C, we have managed to, hopefully, contribute successfully to this discussion and through our reports, hopefully, like Roberto mentioned at some point, to turn this into actions and capacity‑building programs. But that's the next step.
As Nicolas mentioned, we are going to start a public consultation, hopefully, the week after the IGF, and we invite you to come to that public consultation and leave in your comments so that we can produce the best report this world is able of producing at this point in time. That is the aim, basically. But we will have compared about 22 jurisdictions that we have found on their best practices, and from there, come up with the recommendations and best practices and find the spots that have been left out, because that is, as has been mentioned by the researchers, there are some points that are simply not mentioned. And the question from the gentleman from the U.S. saying, should we convene in some way in the world to tackle this problem? Then the answer, of course, is yes. And recommendations are all nice, but they can be easily ignored. And coming back to the comments on quantum computing, which will be upon us probably within the next decade, we have the chance to do it right and not to make the same mistakes that we've made with the introduction of the Internet and then with the Internet of Things. Because I remember discussions of previous IGFs in Brazil, in Mexico, some years ago, saying, "We have to act now!" And look at where we are, in a quagmire of threats, basically. And that is that if there is no regulation in place, when it comes down to voluntary action and when your competitor is not adhering and you are, you probably will be out of business because you're not competing anymore. So, I think that that is where some sort of a guiding hand is necessary. But we are going to provide the recommendations to do so.
The report, hopefully, will be there in February. And from there, we'll start discussing the next phase. And anyone who's interested to join IS3C, please go to our web page on the IGF website. It's on the Dynamic Coalition's Internet Standards Security and Safety. You will find a link to an email system. And once registered there, you're in on our communications, and that means that you can join the working groups that you're interested in and contribute to them. So, as I said, we have about three up and running at this point in time. We have the IoT one we're discussing here. We have education and skills and data governance and security. We will be announcing the start of the Procurement of Supply Chain Management working group, what we call the list. But we will also announce the intention to start working groups on three main standards, which one is DNSEC, the other is IPKI and the other is RP version 6, and to drive the discussion towards an even faster deployment than we are at this point.
And finally, there are two proposals on quantum computing, which I haven't had the time yet, because the day before I left here before Addis Ababa on quantum computing and post‑quantum encryption, so we'll have to see whether they're really different or that we can merge them, but that is a discussion we'll have. The fact is that we have two proposals on the topic, the series and the furthest away is on consumer advocacy. So, how can consumer organizations, when they test devices with IoT component in them also test the IoT in the right way, because that would be a tremendous driver for companies to make it more secure. And we hope to discuss this with Brazilian representatives pretty soon and start that working group somewhere next year, hopefully with the help of Brazilian Government, but we'll see whether it gets that far. But then you can see how broad this coalition is growing to be. And the furthest one out is on the vulnerability disclosure that Joao mentioned. We should organize ourselves globally also where vulnerability disclosures are concerned, because the dark side is testing these devices/software 24/7 a day and using every vulnerability they find. So, why doesn't the right side organize itself in the same way that testing takes place, reporting takes place in the right way, so that is done in a legal way and that manufacturers are reported in time that they have a vulnerability and not something which is disclosed after we've had multiple attacks on these vulnerabilities. So, that is the one that we still need to discuss even, but it's in the back of our minds to do.
So, this I think is the end of our session. I think I want to have a round of applause for our researchers, because I think they did excellent work, as you were able to see. So, first, for the researchers, an applause, please.
(Applause)
Thank you very much. And thank you for being online. Thank you for being in this room. And as I said, join our cause, because the more we have, the better we'll do. So, have a very good IGF and I hope to meet you in person later this week. Bye‑bye.