Etsi Consumer Sec
| # | Cat Etsi | Etsi Req Nr | Cat Descr | Description | Remarks | Include | |
|---|---|---|---|---|---|---|---|
| 1 | 4.9 | 4.9-3 | Make systems resilient to outages | Devices should be able to return to a network in an expected, operational and stable state and in an orderly fashion, rather than in a massive-scale reconnect. | The aim of the above provisions is to ensure that IoT services are kept up and running as the adoption of IoT devices across all aspects of a consumer's life increases, including in functions that are relevant to personal safety. The impact on people's lives could be prevalent if, for example, an internet connection is lost to a connected door and someone is locked outside. Another example is a home heating system that turns off because of a DDoS attack against a cloud service. It is important to note that other safety-related regulations can apply, but the key is to avoid making outages the cause of these problems and to design products and services ready for these challenges.
|
Yes | View |
| 2 | 4.9 | 4.9-2 | Make systems resilient to outages | As far as reasonably possible, IoT services should remain operating and locally functional in the case of a loss of network and should recover cleanly in the case of restoration of a loss of power. | Yes | View | |
| 3 | 4.9 | 4.9-1 | Make systems resilient to outages | Resilience should be built in to IoT devices and services where required by their usage or by other relying systems, taking into account the possibility of outages of data networks and power. | IoT systems and devices are relied upon by consumers for increasingly important use cases that can be safety-relevant or life-impacting. Keeping services running locally if there is a loss of network is one of the measures that can be taken to increase resilience. Other measures can include building redundancy into associated services as well as mitigations against, for example, Distributed Denial of Service (DDoS) attacks or signalling storms which can be caused by massreconnections of devices following an outage. It is expected that the level of resilience necessary is proportionate and determined by usage, with consideration given to others that rely on the system, service or device given that an outage can have a wider impact than expected. |
Yes | View |
| 4 | 4.8 | 4.8-3 | Consumers who gave consent for the processing of their personal data shall be given the opportunity to withdraw it at any time. | It is expected that the appropriate entity, such as the service provider or device manufacturer, ensures that personal data is processed in accordance with applicable data protection law, for example the GDPR [i.7], and also in accordance with applicable legislation regarding security and regulatory matters. Obtaining consent "in a valid way" normally involves giving consumers a free, obvious and explicit opt-in choice of whether their personal data can be used for a specified purpose. Consumers expect to be provided with means to preserve their privacy by means of configuring IoT device and service functionality appropriately.
|
No | View | |
| 5 | 4.8 | 4.8-21 | Where personal data is processed on the basis of consumers' consent, this consent shall be obtained in a valid way. | No | View | ||
| 6 | 4.8 | 4.8-1 | Device manufacturers and service providers shall provide consumers with clear and transparent information about how their personal data is being used, by whom, and for what purposes, for each device and service. This also applies to third parties that ca | No | View | ||
| 7 | 4.7 | 4.7-21 | Ensure software integrity | If an unauthorized change is detected to the software, the device should alert the consumer and/or administrator to an issue and should not connect to wider networks than those necessary to perform the alerting function. | The ability to remotely recover from these situations can rely on a known good state, such as locally storing a known good version to enable safe recovery and updating of the device. This will avoid denial of service and costly recalls or maintenance visits, whilst managing the risk of potential takeover of the device by an attacker subverting update or other network communications mechanisms. If an IoT device detects something unusual has happened with its software, it will be able to inform the right person. In some cases, devices can have the ability to be in administration mode - for example, there can be a user mode for a thermostat in a room that prevents other settings being changed. In these cases, an alert to the administrator is appropriate as that person has the ability to act on the alert.
|
Yes | View |
| 8 | 4.7 | 4.7-1 | Ensure software integrity | Software on IoT devices should be verified using secure boot mechanisms, which require a hardware root of trust. | Yes | View | |
| 9 | 4.6 | 4.6-5 | Minimize exposed attack surfaces | Software should run with least necessary privileges, taking account of both security and functionality. | Yes | View | |
| 10 | 4.6 | 4.6-4 | Minimize exposed attack surfaces | Code should be minimized to the functionality necessary for the service/device to operate. | Yes | View | |
| 11 | 4.6 | 4.6-3 | Minimize exposed attack surfaces | Software services should not be available if they are not used. | Yes | View | |
| 12 | 4.6 | 4.6-2 | Minimize exposed attack surfaces | Hardware should not unnecessarily expose access to attack (e.g. open serial access, ports or test points). | Yes | View | |
| 13 | 4.6 | 4.6-1 | Minimize exposed attack surfaces | Unused software and network ports should be closed. | Yes | View | |
| 14 | 4.5 | 4.5-2 | Communicate securely | All keys should be managed securely. | It is expected that products meet the needs of users whilst remaining resilient to attacks on encryption. However,
appropriateness of security controls and the use of encryption is dependent on many factors including the usage context.
As security is ever-evolving it is difficult to give prescriptive advice about encryption measures without the risk of such
advice quickly becoming obsolete.
|
Yes | View |
| 15 | 4.5 | 4.5-1 | Communicate securely | Security-sensitive data, including any remote management and control, should be encrypted in transit, with such encryption appropriate to the properties of the technology and usage. | Yes | View | |
| 16 | 4.4-1 | Securely store credentials and security-sensitive data | Credentials and security-sensitive data shall be stored securely within services and on devices. Hard-coded credentials in device software shall not be used. | Reverse engineering of devices and applications can easily discover credentials such as hard-coded usernames and passwords in software. Simple obfuscation methods also used to obscure or encrypt this hard-coded information can be trivially broken. Secure, trusted storage mechanisms can be used to secure security-sensitive data, such as those provided by a Trusted Execution Environment (TEE) and associated trusted, secure storage, or the secure storage and processing capabilities of software running on a Universal Integrated Circuit Card UICC/embedded Universal Integrated Circuit Card (eUICC).
|
Yes | View | |
| 17 | 4.3 | 4.3-9 | Keep software updated | For constrained devices that cannot have their software updated, the rationale for the absence of software updates, the period of hardware replacement support and an end-of-life policy should be published in an accessible way that is clear and transparent to the consumer | There are some situations where devices cannot be patched. For constrained devices a replacement plan needs to be in place and be clearly communicated to the consumer. This plan would typically detail a schedule for when technologies will need to be replaced and, where applicable, when support for hardware and software ends.
|
No | View |
| 18 | 4.3 | 4.3-8 | Keep software updated | For constrained devices that cannot have their software updated, the product should be isolable and the hardware replaceable. | Yes | View | |
| 19 | 4.3 | 4.3-7 | Keep software updated | When software components are updateable, the provenance of software updates should be assured and security patches should be delivered over a secure channel. | NOTE 2: Software update mechanisms can present an attack vector.
|
Yes | View |
| 20 | 4.3 | 4.3-6 | Keep software updated | When software components are updateable, updates should, where possible, maintain the basic functioning of the device, which can be critical to remain available during an update. | It can be critical for consumers that a device continues to operate during an update. This is why the provision above recommends to "maintain the basic functioning of the device" where possible. EXAMPLE: During an update, a watch is expected to continue to tell the time, a home thermostat is expected to continue to be operable and heating settings changeable by users and a smart lock usable for unlocking and locking a door. This can become a critical safety issue for some types of devices and systems if not considered or managed correctly.Particularly, devices that fulfil a safetyrelevant function are expected not to turn completely off in the case of an update; some minimal system functional capability is expected. |
Yes | View |
| 21 | 4.3 | 4.3-5 | Keep software updated | When software components are updateable, the need for each update should be made clear to consumers and an update should be easy to implement. | Developing and deploying software security updates in a timely manner is one of the most important actions a company can take to protect its customers and the wider technical ecosystem. Vulnerabilities often stem from software components that are not considered to be security related. It is good practice that all software is kept updated and well maintained. "Timely" in the context of software updates can vary, depending on the particular issue and fix, as well as other factors, such as the ability to reach a device or constrained device considerations. For a non-critical bug, it can be acceptable to deliver a software update within a regular patch cycle; for a severe, remote code execution flaw, a more immediate update can be expected. Software security updates can be provided for devices in a preventative manner, often as part of automatic updates, which can remove security vulnerabilities before they are exploited. Managing this can be complex, especially if there are parallel cloud service updates, device updates and other service updates to deal with. Therefore, a clear management and deployment plan is essential, as is transparency to consumers about the current state of update support. In many cases, publishing software updates involves multiple dependencies on other organizations such as manufacturers of sub-components, however, this is not a reason to withhold updates. It is essential that the entire software supply chain is considered in the development and deployment of security updates. Software updates are expected to be provided after the sale of a device and pushed to devices for a period appropriate to the device. When purchasing the product, the consumer expects this period of software update support to be made clear. Software in consumer IoT devices can be one or more categories (this is a non-exhaustive list): firmware, platform software such as an operating system, services and applications. The update process can be different for the different categories of software. |
No | View |
| 22 | 4.3 | 4.3-4 | Keep software updated | When software components are updateable, an end-of-life policy shall be published for devices that explicitly states the minimum length of time for which a device will receive software updates and the reasons for the length of the support period. this | This policy shall be published in an accessible way that is clear and transparent to the
consumer. |
No | View |
| 23 | 4.3 | 4.3-3 | Keep software updated | When software components are updateable, updates shall be timely. | Yes | View | |
| 24 | 4.3 | 4.3-2 | Keep software updated | The consumer should be informed by the appropriate entity, such as the manufacturer or service provider, that an update is required. | NOTE 1: The appropriate entity is decided by the relevant jurisdiction. |
No | View |
| 25 | 4.3 | 4.3-1 | Keep software updated | All software components in consumer IoT devices should be securely updateable. | Yes | View | |
| 26 | 4.2 | 4.2-3 | Implement a means to manage reports of vulnerabilities | Companies should continually monitor for, identify and rectify security vulnerabilities within products and services they sell, produce, have produced and services they operate as part of the product security lifecycle. | Knowing about a security vulnerability allows companies to respond. Vulnerabilities are expected to be reported directly to the affected stakeholders in the first instance. If that is not possible vulnerabilities can be reported to national authorities. Companies are also encouraged to share information with competent industry bodies. NOTE 1: Competent industry bodies include the GSMA and the IoT Security Foundation. Guidance on Coordinated Vulnerability Disclosure is available from the IoT Security Foundation which references the ISO/IEC 29147 standard on vulnerability disclosure [i.4]. The GSMA's industry level Coordinated Vulnerability Disclosure programme is located at: https://www.gsma.com/cvd. Coordinated Vulnerability Disclosure (CVD) is standardized by the International Organization for Standardization (ISO), is simple to implement and has been proven to be successful in some large software companies around the world [i.4]. CVD is, however, still not established in the IoT industry and some companies are reticent about dealing with security researchers. CVD provides a way for security researchers to contact companies to inform them of security issues putting the company ahead of the threat of malicious exploitation and giving them an opportunity to resolve vulnerabilities in advance of a public disclosure. Companies that provide internet-connected devices and services have a duty of care to consumers and third parties who can be harmed by their failure to have a CVD programme in place. Additionally, companies that share this information through industry bodies can assist others who can be suffering from the same problem. Disclosures can comprise different approaches depending on the circumstances:
NOTE 2: The Common Vulnerability Reporting Framework (CVRF) [i.5] can also be useful to exchange information on security vulnerabilities. Cyber security threat information sharing can support organizations in developing and producing secure products [i.6]. |
Yes | View |
| 27 | 4.2 | 4.2-2 | Implement a means to manage reports of vulnerabilities | Disclosed vulnerabilities should be acted on in a timely manner. | A "timely manner" for acting on vulnerabilities varies considerably and is incident specific, however, the de facto
standard for the vulnerability process to be completed is within 90 days. A hardware fix can take considerably longer to
address than a software fix. Additionally, a fix that has to be deployed to devices can take time to roll out compared
with a server software fix.
|
Yes | View |
| 28 | 4.2 | 4.2-1 | Implement a means to manage reports of vulnerabilities | Companies that provide internet-connected devices and services shall provide a public point of contact as part of a vulnerability disclosure policy in order that security researchers and others are able to report issues. | no remarks
|
No | View |
| 29 | 4.13 | 4.13-1 | Validate input data | Data input via user interfaces and transferred via application programming interfaces (APIs) or between networks in services and devices shall be validated. | Systems can be subverted by incorrectly formatted data or code transferred across different types of interface. Automated tools are often employed by attackers in order to exploit potential gaps and weaknesses that emerge as a result of not validating data. Examples include, but are not limited to, data that is: i) Not of the expected type, for example executable code rather than user inputted text. ii) Out of range, for example a temperature value which is beyond the limits of a sensor.
|
Yes | View |
| 30 | 4.12 | 4.12-1 | Make installation and maintenance of devices easy | Installation and maintenance of IoT devices should employ minimal steps and should follow security best practice on usability. Consumers should also be provided with guidance on how to securely set up their device. | Security issues caused by consumer confusion or misconfiguration can be reduced and sometimes eliminated by properly addressing complexity and poor design in user interfaces. Clear guidance to users on how to configure devices securely can also reduce their exposure to threats.
|
No | View |
| 31 | 4.11 | 4.11-3 | Make it easy for consumers to delete personal data | Consumers should be provided with clear confirmation that personal data has been deleted from services, devices and applications. | IoT devices often change ownership and will eventually be recycled or disposed of. Mechanisms can be provided that allow the consumer to remain in control and remove personal data from services, devices and applications. When a consumer wishes to completely remove their personal data, they also expect this to include backup copies that the service provider may hold. Deleting personal data from a device or service is not simply achieved by resetting a device back to its factory settings. There are many use cases where the consumer is not the owner of a device, but wishes to delete their own personal data from the device and all associated services such as cloud services or mobile applications. EXAMPLE: A user can have temporary usage of consumer IoT products within a rented apartment. Carrying out a factory reset of the product can remove configuration settings or disable the device to the detriment of the apartment owner and a future user. It would be an inappropriate technical mechanism to delete all personal data in this context.
|
No | View |
| 32 | 4.11 | 4.11-2 | Make it easy for consumers to delete personal data | Consumers should be given clear instructions on how to delete their personal data. | No | View | |
| 33 | 4.11 | 4.11-1 | Make it easy for consumers to delete personal data | Devices and services should be configured such that personal data can easily be removed from them when there is a transfer of ownership, if the consumer wishes to delete it, if the consumer wishes to remove a service from the device and/or at disposal of the device | No | View | |
| 34 | 4.10 | 4.10-3 | Examine system telemetry data | If telemetry data is collected from IoT devices and services, consumers shall be provided with information on what telemetry data is collected and the reasons for this. | Examining telemetry, including log data, is useful for security evaluation and allows for unusual circumstances to be identified early and dealt with, minimizing security risk and allowing quick mitigation of problems.
|
Yes | View |
| 35 | 4.10 | 4.10-2 | Examine system telemetry data | If telemetry data is collected from IoT devices and services, the processing of personal data should be kept to a minimum and such data should be anonymized. | Yes | View | |
| 36 | 4.10 | 4.10-1 | Examine system telemetry data | If telemetry data is collected from IoT devices and services, such as usage and measurement data, it should be examined for security anomalies. | No | View | |
| 37 | 4.1 | 4.1-1 | No universal default passwords | All IoT device passwords shall be unique and shall not be resettable to any universal factory default value. | Many IoT devices are being sold with universal default usernames and passwords (such as "admin, admin") for user
interfaces through to network protocols. This has been the source of many security issues in IoT and the practice needs
to be discontinued. Following best practice on passwords and other authentication methods is encouraged. Device
security can further be strengthened by having unique and immutable identities.
For guidance see, for example, the NIST Special Publication on Digital Identity Guidelines,
Authentication and Lifecycle Management [i.3].
|
Yes | View |
Loading...
Saving...
Loading...