What should manufacturers and suppliers of IoT technology be doing now?

Privacy policies and terms and conditions

As described elsewhere (see Privacy), IoT devices often do not notify their users about how to find their applicable privacy policies.¹ Quite part from obligations to notify under applicable data privacy laws, such omission also raises straightforward contractual issues as many  jurisdictions typically require adequate incorporation of terms into a contract in order for them to be given contractually binding effect. 

Many businesses are using “privacy policies that meet the legal requirements created for the Internet, not the Internet of Things. Scott R Peppet, Regulating the Internet of Things: First Steps Towards Managing Discrimination, Privacy, Security, and Consent 93 Tex. L. Rev 85 2014 – 2015, page 147 – 148

These issues are not difficult to address.  IoT stakeholders should be reviewing their privacy policies and terms and conditions in relation to their participation in an IoT ecosystem as a matter of priority.

Other data privacy considerations

Generally speaking, much of what IoT stakeholders will need to consider in participating in an IoT ecosystem involving personal data is informed by data privacy considerations.  For many stakeholders these will typically include:³

• Data protection impact assessments: undertaking a data protection impact assessment due to the use of IoT as a new technology;
• Deleting raw data: deleting such data as soon as the data is no longer needed at the nearest point of data collection (for example, on the IoT device itself);
• Privacy by design: applying privacy by design and default in engineering of IoT devices and the IoT ecosystem;
• Self-determination: enabling user empowerment to permit users to exercise their rights and to be in control of their data, including functionality to allow data subjects to delete or transfer their data (on a change of device ownership, transfer of service, etc.);
• Providing accessible information: providing user-friendly information (notice) to users in relation to consent and use of data; and
• Addressing non-user data subjects: individual non-users of IoT devices may nonetheless have their data collected by an IoT device (for example, an embedded camera).

Other considerations⁴

IoT device manufacturers should consider

• Requiring the end user to set a unique username and password before an IoT device can operate (in order to avoid default factory settings);
  Operating a security vulnerability reporting and disclosure policy, reporting vulnerabilities directly to affected stakeholders (or national authorities, if this is not possible);⁵
• Monitoring and fixing security vulnerabilities as part of the product lifecycle, in timely manner, reporting vulnerabilities directly to affected stakeholders (or national authorities, if this is not possible);
• Ensuring that software components in IoT devices are securely updateable;
  Keeping embedded software updated on a “pushed” basis (automatic updates);
  Developing and publishing an end-of-life policy for software updates in relation to end user devices, so that end users will know how long a device will be supported for;
• In relation to devices that cannot be updated, ensuring that such devices are readily replaceable;
  Avoiding using hard-coded security credentials in device software.  Security credentials must be stored securely;
• Including functionality to enable security-sensitive data to be encrypted during transmission, with keys managed securely;
• Minimising attack surfaces by applying the “principle of least privilege” – for example, unused ports should be closed;
• Ensuring software integrity by, for example, alerting the user and not connecting when there is an unauthorised change;
• So that IoT devices remain operational, building in “resilience” (that is, the ability to maintain an acceptable levels of service when challenges to normal operation occur) and “redundancy” (in IT terms, redundancy is the duplication of critical components or functions of a system with the intention of increasing the reliability of the system, usually in the form of a back-up or fail-safe);
• Providing end users with information about how to set up their devices securely and how to securely dispose of the data on them;
• Validating data entered via user interfaces and transmitted through application programming interfaces or between networks in services and devices.

IoT service providers should consider

• Operating a security vulnerability reporting and disclosure policy;
• Monitoring and fixing security vulnerabilities as part of the product lifecycle, in a timely manner, reporting vulnerabilities directly to affected stakeholders (or national authorities, if this is not possible);
• Ensuring that software components are securely updateable;
• Keeping software updated;
• Developing and publishing an end-of-life policy for software updates;
• Avoiding using hard-coded security credentials in software.  Security credentials must be stored securely;
• Including functionality to enable security-sensitive data to be encrypted during transmission, with keys managed securely;\
• Applying the “principle of least privilege” – for example, services should not be available if they are not used;
• So that IoT services remain operational, building in resilience and redundancy;
• Monitoring system telemetry data (that is, data collected at remote points and transmitted to receiving equipment for monitoring by an automated communications process) for security anomalies;
• Providing end users with information about how to set up their service securely and how to securely dispose of their data;
• Validating data entered via user interfaces and transmitted through application programming interfaces or between networks in services and devices.

Third party IoT application developers (including mobile) should consider

• Operating a security vulnerability reporting and disclosure policy;
• Monitoring and fixing security vulnerabilities as part of the product lifecycle, in a timely manner, reporting vulnerabilities directly to affected stakeholders (or national authorities, if this is not possible);
• Ensuring that software components are securely updateable;
• Keeping software updated;
• Developing and publishing an end-of-life policy for software updates;
• Avoiding using hard-coded security credentials in software.  Security credentials must be stored securely;
• Including functionality to enable security-sensitive data to be encrypted during transmission, with keys managed securely;
• Providing end users with information about how to set up their service securely and how to securely dispose of their data;
• Validating data entered via user interfaces and transmitted through application programming interfaces or between networks in services and devices.

Are there relevant codes of practice and standards?

Should IoT stakeholders be looking to comply with codes of practice and standards in relation to an IoT ecosystem?  This is ultimately a commercial decision, although it may have some bearing on liability (for example, can a vendor be said to be negligent if what they have done is in compliance with then current industry codes of practice?) 

The problem for IoT stakeholders is that there are currently no industry-wide, generally accepted, security guidelines for IoT yet, although there is a wide range of ongoing initiatives in this area.⁶

For example, the U.K. Government:

• has promulgated a code of practice for consumer IoT security aimed at manufacturers, IoT service providers, mobile application developers and retailers of consumer IoT devices and associated services;⁷
• in conjunction with the code, has also published a mapping document and database that link’s the code’s guidelines with the main industry standards, recommendations and guidance; and⁸
• participated in a process of developing a global standard through the European Telecommunications Standards Institute (ETSI), based on the code.⁹ In February 2019 ETSI released such a global standard.¹⁰

IoT stakeholders may also wish to consider other initiatives, such as:

• the EU IoT European Platform Initiative, whose aim (among other things) is to promulgate open and easily accessible IoT platforms (including IT architecture)  through a range of projects;¹¹
• the Regulation of the European Parliament and of the Council on the European Union Agency for Cybersecurity and on Information and Communication Technology Cybersecurity Certification (the Cybersecurity Act),[12] which should have a powerful impact on companies operating in the IoT sphere.  Among other things, the Cybersecurity Act provides a framework for the establishment of European cybersecurity certification schemes for the purpose of ensuring an adequate level of cybersecurity for information, communications and technology (ICT) products, ICT services and ICT processes in the EU.  Such certification schemes are likely to be very relevant to IoT devices and IoT ecosystems, and manufacturers of IoT devices should be looking to follow them;
• ISO Standard for Vulnerability Disclosure: ISO/IEC 29147:2014;
• ISO Standard for Systems and Software Engineering -- System Lifecycle Processes: ISO/IEC/IEEE 15288:2015; and
• The U.S. Digital Standard (see Regulatory).