HKCERT IoT Security Best Practice Guidelines

IoT Security Best Practice

Guidelines

January 2020

1
HKCERT IoT Security Best Practice Guidelines

Disclaimer

The Hong Kong Computer Emergency Response Team Coordination Centre (HKCERT) and the Hong
Kong Productivity Council (HKPC) reserve the right to amend the document from time to time without
prior notice.

While we have made every attempt to ensure that the information contained in this document is
obtained from reliable sources, HKCERT is not responsible for any errors or omissions, or for the results
obtained from the use of this information. All information in this document is provided "as is", with
no guarantee of completeness, accuracy, timeliness or of the results obtained from the use of this
information, and without warranty of any kind, express or implied, including, but not limited to
warranties of performance, merchantability and fitness for a particular purpose.

The information contained in this document is intended to provide general information and for
reference only. Reliance or use of this information shall be at the reader’s own risk. Nothing herein
shall to any extent substitute for the independent investigations and the sound technical and business
judgment of the reader. In no event will HKCERT, HKPC or its partners, employees or agents, be liable
to you or anyone else for any decision made or action taken in reliance on the information in this
document, or for any consequential, special or similar damages, even if advised of the possibility of
such damages.

Licence

The content of this document is provided under Creative Commons Attribution 4.0 International
Licence. You may share and adopt the content for any purpose, provided that you attribute the work
to HKCERT. http://creativecommons.org/licenses/by/4.0

2
HKCERT IoT Security Best Practice Guidelines

Table of Contents

1. Executive Summary ......................................................................................................................... 4

2. Introduction .................................................................................................................................... 4
2.1 Overview ....................................................................................................................................... 4
2.2 Objectives...................................................................................................................................... 5
2.3. Scope ............................................................................................................................................ 5
2.4. Target audience ........................................................................................................................... 5
3. Methodology................................................................................................................................... 6
4. IoT Security Best Practice Guidelines .............................................................................................. 6
4.1 IoT Architectural Model ................................................................................................................ 6
4.2 Best Practices and Verification Checklists..................................................................................... 9
4.2.1 Personal Data Privacy............................................................................................................. 9
4.2.2 Application Layer ................................................................................................................. 11
4.2.3 Management Layer .............................................................................................................. 16
4.2.4 Network Layer ...................................................................................................................... 18
4.2.5 Perception layer ................................................................................................................... 21
5. Appendix: List of Reference Publications...................................................................................... 25

3
HKCERT IoT Security Best Practice Guidelines

1. Executive Summary

The adoption of Internet of Things (IoT) technology is a growing trend in various sectors.
Startups, small and medium-sized enterprises (SMEs), and other enterprises have started
adopting IoT technology to create business values for their products and bring about new
customer experience. As focus remains on the functions and features that IoT technology
brings, not many people fully understand the accompanying potential security risks.

This document aims to facilitate developers to incorporate IoT security best practices early at
the design stage. And, it provides verification checklists for developers to perform self-
verification on their IoT solutions in order to raise the security awareness of IoT technology.

An IoT architecture model is proposed to illustrate the composition of IoT solutions. It consists
of four layers, namely the perception layer, network layer, management layer, and application
layer. IoT-related security issues, best practices and verification items are discussed pertinent
to each layer and presented in tables for ease of reference.

This document enables developers to first be aware of various security issues raised at each
layer; second, to understand the associated best practices while developing IoT solutions; and,
finally, to conduct self-verification to verify their IoT solutions according to the verification
checklists. In the long run, it is hoped that developers would incorporate IoT security into their
development cycles.

2. Introduction

2.1 Overview

Put simply, the Internet of Things (IoT) technology uses network connectivity (e.g. Internet) to
interconnect various physical devices to collect, exchange, process, and react to the data
around the physical world. It ushers a new era of innovation and business opportunities that
yields benefits in terms of efficiency, business growth, and quality of life.

However, new cyber security threats also arise from IoT technology as attackers from time to
time have been seeking to exploit vulnerabilities in IoT devices. One famous DDoS attack from
infected IoT devices was the Mirai Botnet which brought down the domain registration
services provider, Dyn, in October 2016.

To better preserve IoT security, developers are encouraged to get involved and adopt the best
practices at the early stage of product design. Besides, developers should go through the self-
verification checklists to verify the security level at the testing stage.

4
HKCERT IoT Security Best Practice Guidelines

2.2 Objectives

The objectives of this document are as follows:

 To raise the security awareness of IoT technology;

 To give developers a basic understanding on common security issues with IoT
solutions;
 To facilitate developers to incorporate IoT security best practices at the design stage;
and
 To provide verification checklists for developers to perform self-verification on their
IoT solutions.

2.3. Scope

The scope of this document mainly focuses on common security issues that HKCERT has
observed with regard to IoT solutions, as well as proposes feasible and essential best practices
for improving the IoT security. As the scope is not aimed at providing a holistic security
framework on IoT security, this document cannot be served as a bulletproof security baseline.
Yet, it serves the purpose of attaining a certain level of security controls that would reduce
common security risks.

2.4. Target audience

The target audience of this document is developers, who take part in the following areas:

 IoT hardware design

 IoT software / firmware development
 Use of wireless technologies
 IT related infrastructure supporting IoT solutions
 IT application development supporting IoT solutions
 Mobile app development supporting IoT solutions
 IoT architecture and solution development

Besides, this document may also benefit other audiences including:

 Business drivers who are sourcing for different IoT solutions

 Business owners who adopt IoT technology in businesses
 Academics who teach topics related to IoT technology (e.g. STEM education)
 General public who are users of IoT related solutions

5
HKCERT IoT Security Best Practice Guidelines

3. Methodology

This study was carried out in five stages.

1. Scope definition
The scope definition involves defining the scope, objectives, target audience, key
elements of the document and the study.

2. Desktop research
The desktop research involves identifying existing publications and information on the
topics related to the objectives of the study, which will serve as supporting materials
for analysis and formulation of the best practice guidelines. The list of reference
publications can be referred in the Appendix.

3. IoT security testing

The IoT security testing involves identifying the common IoT security issues from the
security tests on various technologies used in IoT solutions.

4. Analysis and development

Analysis and development stage involves analysing the results collected from the
desktop research and IoT security tests. Common security issues were then identified
and categorised into a proposed IoT architecture model for formulating the best
practice guidelines.

5. Report write-up and validation

The report write-up and validation stage involves synthesising related information to
form the report structure. The report was validated according to the publication policy.

4. IoT Security Best Practice Guidelines

4.1 IoT Architectural Model

Layered Structure of IoT solution

In general, several layers composite a complete IoT solution. It can be depicted in the below
model with a basic four-layer architecture which shows cross-cutting security across all layers
(see figure 1).

6
HKCERT IoT Security Best Practice Guidelines

Figure 1: IoT Layered Architecture Model

Application Layer

Application layer is responsible for delivering application services. In general, this layer
consists of web application, API service, data analytics, business process and mobile
application. Users mainly interact with this layer through the web application and mobile
application. This layer also handles all application data processing, analytics, and storage.
Some IoT solutions may also integrate with their corporate IT infrastructure for other business
workflow processes, big data and AI modelling.

Management Layer

Management layer is used for managing the IoT services. In general, this layer consists of
management platform, monitoring system and software update platform. IoT solution
providers interact with this layer through the management interface to manage the lifecycle

7
HKCERT IoT Security Best Practice Guidelines

of the IoT devices. For example, this layer manages the provision, deployment, monitoring,
software update, and disposal of IoT devices.

Network Layer

Network layer is responsible for network connectivity for IoT devices, network devices, and
servers. This layer handles data transmission between IoT devices, mobile phones that runs
over the mobile application and backend servers. This layer involves different network
technologies including short range device to device wireless connectivity (e.g. RFID, NFC,
zigbee, Bluetooth, etc.), long range device to carrier gateway wireless connectivity (e.g. Sigfox,
NB-IoT, LoRa, etc.), wireless Internet connectivity (e.g. WiFi) and cellular network connectivity
(e.g. 4G and 5G).

Perception Layer

Perception layer is the physical layer where IoT devices reside. IoT devices interact with the
physical world through different sensors to collect different physical measurements (e.g.
temperature, air quality, speed, humidity, pressure, flow, movement, electricity, etc.). IoT
devices would also have some sort of kinetic interaction with the physical world through
actuator, motors, robotics, etc. Depending on the capability of IoT devices, some IoT devices
may not be capable of supporting Internet Protocol (IP) to connect the Internet directly. In
this case, IoT gateways are used to act as the network bridge between the IoT devices and the
Internet.

Personal Data Privacy

The personal data privacy cuts across all the above four layers. It covers various security issues
arising from each layer and the necessary solutions to mitigate the risks.

8
 HKCERT IoT Security Best Practice Guidelines

4.2 Best Practices and Verification Checklists

4.2.1 Personal Data Privacy

The following best practices are applicable to all layers.

Security Aspects Security Issues Best Practices Verification Checklists

4.2.1.1 Personal  For handling of personal data, security  The solution should observe the  Personal data is collected, retained,
Data Privacy protections are critical. Failure to Personal Data (Privacy) Ordinance1 in used and protected in compliance
Security comply with related regulations on collection, retention, use and security with the Personal Data (Privacy)
personal data privacy could result in of personal data. Ordinance.
legal liability.
 The solution should provide clear  Clear privacy policy is communicated
explanation to end users on its policy to end-users.
and practice in handling all personal
data throughout the data processing  All reasonably practicable security
lifecycle (i.e. privacy policy), such as measures have been implemented to
what kinds of personal data will be protect personal data, including
collected, the purposes of collection, encryption of personal data at rest
the potential transferees of the and in transit.
personal data and the security
measures adopted to protect the  Collection and retention of personal
personal data. data is minimised. Only de-identified
or anonymised data is stored if
 The solution should protect the applicable.
personal data collected by taking all
reasonably practicable security  End users’ consent is obtained for
measures, such as using encryption at data collected beyond what is

1
Personal Data (Privacy) Ordinance (https://www.pcpd.org.hk/english/data_privacy_law/ordinance_at_a_Glance/ordinance.html)

9
HKCERT IoT Security Best Practice Guidelines

rest and in transit, and other IoT needed for proper operations of the
security best practices recommended device.
in this Guideline.
 End users’ consent is obtained before
using personal data for purposes
 The solution should minimise the unrelated to the original core
collection and retention of personal functions of the device, or for
data, and should only store and purposes not specified in its privacy
process de-identified or anonymised policy communicated to end-users.
data if applicable.
 Personal data that is no longer
 The solution should seek end users’ necessary is destroyed or
consent for data collected beyond anonymised.
what is needed for proper operations
of the device.

 The solution should seek end users’

consent if personal data is to be used
for purposes unrelated to the original
core functions of the device, or for
purposes not specified in its privacy
policy communicated to end users.

 The solution should destroy or

anonymise personal data when the
data is no longer necessary for
achieving the purposes communicated
to or consented by end users.

Note: The developer or business user of

the device may make reference to ISO/IEC

10
 HKCERT IoT Security Best Practice Guidelines

27701:2019 for security techniques for

privacy information management2.

4.2.2 Application Layer

The following best practices are applicable to application layer.

Security Aspects Security Issues Best Practices Verification Checklists

4.2.2.1  Authentication plays an important role  The solution should adopt strong  The solution only accepts strong
Authentication in application security. Without password where authentication is password (e.g. at least 8 characters
Security authentication, your application will not needed. containing uppercase letters,
be able to determine on the provision of lowercase letters, numbers and
application functionality and the  The solution should include role-based characters) where authentication is
authorisation of data access. As such, access control for multi-user needed.
role-based access control is necessary environments.
to provide granular control on data  Role-based access control is
access for each user.  The solution should implement two- supported for multi-user
factor authentication where possible. environments.
 Other security measures, such as strong
passwords, account lockout, two-factor  The solution should provide secured  Two-factor authentication is
authentication, etc., are essential to password recovery mechanisms. supported (e.g. use of mobile
prevent account hijacking and identity authenticator, SMS verification).
theft.  The solution should support password
expiration enforcement and periodic  Password recovery mechanism is
 Default usernames and passwords can password change policy. available and requires verification
be obtained easily on the Internet. through registered email and/or
Changing them after setup can reduce mobile SMS verification code.
the risk of unauthorised access.

2
ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management — Requirements and guidelines
(https://www.iso.org/standard/71670.html)

11
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

 The solution should enforce mandatory  User is mandated to perform
default password change at initial setup password change in case of password
stage. expiration.

 The solution should provide an option  User is mandated to change default

for changing privileged account password at initial setup stage.
username.  Users have the option to change
privileged account username to
 The solution should support account reduce security risks.
lockout mechanism to prevent against
brute force attack.  Account is locked out when multiple
incorrect password attempts were
 The solution should have proper logged.
measures (e.g. CAPTCHA) to prevent
account lockout DoS attack.  Login requires CAPTCHA verification
to prevent automated attacks.

4.2.2.2 Web  Web application is considered a major  The web application should be checked  The web application is checked not
Application attack surface that requires the against well-established web security vulnerable to common web
Security implementation of effective security standards. application vulnerabilities (e.g.
measures. Many web application OWASP 3 Top 10 including cross-site
standards have already been well-  The web application should require user scripting (XSS), SQL injection and
established. As such, it is advised to authentication (refer to the row Cross-site request forgery (CSRF),
reference and check against those well- “Authentication Security” for details). etc.).
established web application security
standards to ensure web application  The web application should enable  The web application requires user
security. session timeout. login for user authentication.

3
OWASP Top 10 (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)

12
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

 Other security measures, such as  All data input of web application should  The web application automatically
session timeout, input validation, be validated before processing. logs out the user after the session has
encryption, digital certificate been idled for a period of time.
authenticity, etc., are essential to web  The web application should use
application security. encryption to protect transmitted  The web application denies the input
information. that contains invalid or malformed
 As web attack tactics are ever-changing,  The web application should be data (e.g. data generated by fuzzing
using web application firewall is an protected by web application firewall. tool).
effective way to protect the web
application with up-to-date ruleset  The web application uses encrypted
addressing web application HTTPS protocol only.
vulnerabilities.
 The web application is protected by
web application firewall (WAF)
software component or network-
based WAF.

4.2.2.3  API service is supported by a backend  The API service should be checked  The web application is checked not
Application web server that is subject to the same against well-established web security vulnerable to common web
Programming security risk as web application does. standards. application vulnerabilities (e.g.
Interface (API) Web application standards also apply to OWASP4 Top 10 API Security including
Security API services.  The API service should require broken authentication, injection and
authentication prior to processing other rate limiting, etc.).
 Many web application standards have service requests.
already been well-established. As such,  All unauthenticated requests are
it is advised to make reference to and  The API service should respond to denied by the API service.
check against those well-established authenticated request only (refer to the
web application security standards to row “Authentication Security” for
ensure web application security. details).

4
OWASP Top 10 API Security (https://www.owasp.org/index.php/OWASP_API_Security_Project)

13
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

 Authentication is required by the API
 Other security measures, such as  The API service should enable session service prior to accepting other
session timeout, input validation, timeout. service requests.
encryption, digital certificate
authenticity, etc., are essential to web  The API service should perform input  The API service asks for re-
application security. data validation for all input data. authentication after the session has
been idled for a period of time.
 As web attack tactics are ever-changing,  The API service should use encrypted
using web application firewall is an connection protocols.  The API service denies requests that
effective way to protect the API service contain invalid or malformed data
with up-to-date ruleset addressing web  The API service should deploy valid TLS (e.g. data generated by fuzzing tool).
application vulnerabilities. server certificate signed by trusted
certificate authority such that API  The API service accepts encrypted
clients can verify the authenticity of the connection protocols (e.g. HTTPS)
API service. only.

 The API service should use rate limiting  The web server which hosts the API
to slow down volumetric attack service uses valid TLS server
attempts. certificate signed by trusted
certificate authority.
 The API service should be protected by
web application firewall.  The API service has defined the
maximum number of requests to be
accepted per second and per source
IP address and blocked access
exceeding this limit.

 The API service is protected by web

application firewall (WAF) software
component or network-based WAF.

14
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

4.2.2.4 Mobile  Mobile application often involves user  The mobile application should store  No sensitive data is stored outside
Application data collection, processing and sensitive data (e.g. personal data, user application containers or system
Security visualisation. But there is a risk of credentials, cryptographic keys, etc.) to credential storage facilities.
mobile phone being lost or stolen that system credential storage facilities.
poses security risk of information  Two-factor authentication is required
disclosure.  The mobile application should for accessing sensitive data in the
implement mobile supported two- mobile application.
 Security measures, such as encryption, factor authentication (e.g Face
secure storage, two-factor recognition, Fingerprint, etc.) to further  The communications from mobile
authentication, etc., are essential to protect sensitive data collected and applications to backend cloud
protect the sensitive data stored by stored by mobile applications. applications or IoT devices are
mobile applications. encrypted.
 The mobile application should use
encrypted communications with
backend cloud applications or IoT
devices.

4.2.2.5 Cloud  It is common to build IoT solution with  The solution should protect the data on  Data is encrypted at rest and in
Data Security cloud database or cloud storage cloud using encryption at rest and in transit.
platform. Since the cloud database transit.
and cloud data store is directly  In using data encryption on cloud, the
accessible through the Internet, it may  In using data encryption on cloud, the solution adopts key management in
pose higher risk of data breach due to solution should adopt encryption key whole lifecycle of encryption key
cyber attack. management to manage the whole operations (e.g. key generation, key
lifecycle of encryption key operations storage, key usage, key rotation, key
 Although many cloud service providers (e.g. key generation, key storage, key revocation and key destruction).
provide various data protection usage, key rotation, key revocation and
features to address the data security key destruction).  For IoT solution that processes highly
on cloud, the adoption of the features sensitive or requires higher security
are often neglected, which may pose  For IoT solution that processes highly assurance of data encryption on
sensitive or requires higher security cloud, Hardware Security Module

15
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

higher risk of sensitive information assurance of data encryption on cloud, (HSM) is used to protect all encryption
disclosure. FIPS 140-2 certified 5 cryptographic key operations.
module (e.g. Hardware Security
Module) should be used to protect
encryption keys throughout the
lifecycle of encryption key operations.

4.2.3 Management Layer

The following best practices are applicable to management layer.

Security Aspects Security Issues Best Practices Verification Checklists

4.2.3.1  Every software may contain security  Manufacturers or developers should  Manufacturers or developers provide
Vulnerability vulnerabilities that need to be fixed and devise vulnerability management and an official channel (e.g. product
Management patched from time to time. The same disclosure policies for the IoT products. website) for the disclosure of device
issue applies to software and firmware vulnerabilities and related
running on IoT devices. Vulnerability  Manufacturers or developers should information.
management is essential to manage the provide security patches to fix the
entire process of vulnerabilities device vulnerabilities within a  Manufacturers or developers provide
discovery, risk assessment, fixing and reasonable timeframe. an official channel (e.g. product
patch deployment during the lifecycle website) for the security patch
of IoT products.  The device management platform software.
should provide the automatic software
 Since attackers may compromise / firmware / patch deployment  Users can validate the authenticity of
software source or delivery mechanism capabilities. the software / firmware / patch files
to inject malware into delivered by verifying digital signature or file
software / firmware / patch files, checksum.

5
FIPS 140-2 Security Requirements for Cryptographic Modules (https://csrc.nist.gov/publications/detail/fips/140/2/final)

16
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

proper validation of integrity of  All software / firmware / patch files
delivered items is required. should be signed or provided with file  Software / firmware / patch can be
checksum such that users can validate deployed to connected device
the authenticity of the files. through the device management
platform.

4.2.3.2 Device  Managing IoT devices with unique  The device management platform  Individual device can be identified
Management identifiers can prevent invalid or should have the capabilities of with unique identifier.
illegitimate IoT devices from affecting managing and tracking connected
the security of IoT solutions. devices through unique identifiers.  Individual device can be tracked on
the device management platform.
 Since IoT devices may not be kept  The device management platform
updated in a timely manner and the old should provide device asset information  Device model and firmware version
version may be still in use, device asset including device models and firmware can be checked on the device
information is essential to assess the versions. management platform.
scope of impact on vulnerability
management.  The device management platform  When anomaly with IoT device
should validate the integrity of device integrity is detected, individual device
 IoT solution usually involves data root of trust boot process status, can be quarantined from the device
collection from IoT devices, analysis of monitor abnormal behaviour of IoT management platform.
data and producing insights into devices and quarantine devices if there
business decision making. It is essential is any anomaly with IoT device integrity.
to ensure the integrity of IoT devices
and avoid tampering the source of data
collection.
4.2.3.3 Data and  Unlike IT system, IoT devices often lack  Audit logs and security event logs  Audit logs and security event logs are
Event data and event monitoring. should be monitored. being monitored.
Monitoring
 On-going security monitoring helps  The solution should define all security  Security relevant events, such as
maintain the security status of IoT relevant events. elevation of privilege attempts;

17
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

solutions and provides timely alerts for successful / unsuccessful firmware
quicker response to security incidents.  The solution should monitor anomaly of update events; configuration changes
relevant security events across the to IoT devices and service software;
 Detection on event anomaly and entire IoT solutions, including any account modifications; and tamper
threshold is conducive to providing devices; cloud services; mobile services; events, are well-defined.
early warning of potential security network or telemetry services; and
incidents such that necessary security storage systems.  Anomaly with security events are
measures can be taken in a timely being monitored and can be
manner.  The solution should define thresholds identified.
for each type of security event and
 Proper access controls are required to trigger alerts for investigation when the  Alerts can be triggered when the
ensure the integrity of audit logs and thresholds are exceeded. defined thresholds are exceeded.
security event logs.
 The solution should restrict read access  User with auditor role has read access
of security audit logs to user group with to security audit logs.
auditor role.
 No write access of security audit logs
 The solution should not provide write is granted to any user.
privileges to any security audit logs.

4.2.4 Network Layer

The following best practices are applicable to network layer.

Security Aspects Security Issues Best Practices Verification Checklists

4.2.4.1 Wireless  Since attacks can sniff wireless network  The solution should enable encryption  Encryption is enabled in all wireless
Security traffic with radio sniffing tools, adopting in all wireless communications. communications.
encryption in wireless communications

18
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

is important to ensure data  If the wireless protocols are not capable  Data is encrypted in application layer
confidentiality. of supporting encryption features by before transmission through wireless
default, the solution should adopt protocols without encryption
 Due to the lack of encryption support application layer encryption. features.
for some IoT devices, alternative
methods should be considered to  If the device computation power is not  Due to limited device computation
prevent information disclosure from capable of supporting encryption, power, content in wireless data
eavesdropping. alternative methods such as light- stream is still secured from trivial
weight encryption or tokenisation eavesdropping with alternative
 Since devices may incur acceptance of should be adopted to secure the encryption methods.
any connection during the initial pairing content of wireless data stream.
stage, proper measures (e.g. physical  User interaction is required in initial
interaction) can prevent interception  When wireless communications require pairing process to avoid unintended
from unauthorised remote party. initial pairing process, the solution pairing to unauthorised remote party.
should request physical interaction with
the device or manually key in a random  Default wireless passphrase is only
shared secret. used once during initial pairing
process and enforced to be changed
 During initial pairing process, the for proceeding to normal service.
default wireless passphrase should be
changed from the factory default or
reset password prior to providing
normal service.

4.2.4.2 Network  Since attackers scan for any vulnerable  The solution should ensure all  No unnecessary network services are
Services network services over the network, unnecessary network services are detected.
Security reducing attack surface on the network disabled.
and securing the network services  Access is denied to network services
minimise the security risk of network  The solution should require without authentication.
attacks. authentication in accessing the network
services.

19
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

4.2.4.3  Since Internet communications routes  The solution should use Transport Layer  The end-to-end communications
Transport through public network hop may Security (TLS) encryption for the between source devices and
Security expose to eavesdropping attacks, communications between devices and destination Internet servers are
Transport Layer Security (TLS) the Internet. encrypted with TLS.
encryption ensures the end-to-end data
confidentiality, data integrity and  If the device does not natively support  If the device does not natively support
authentication in the course of Internet Protocols, the solution should Internet Protocols, the end-to-end
communications over the Internet. provide IoT gateway for TLS encryption communications between IoT
communications over the Internet. gateways and destination Internet
 Some IoT devices may not natively servers are encrypted with TLS.
support Internet Protocols, IoT gateway  The IoT gateway should act as a firewall
can act as a firewall to enhance the to isolate IoT wireless network from the  The IoT gateway can block network
network isolation and support TLS Internet. traffic from the Internet to IoT
encryption for the communications wireless network and vice versa.
over the Internet.  The application service endpoints
should use valid TLS digital certificate  The application service endpoints use
 Attackers may intercept the network signed by trusted certificate authority. valid TLS server certificate signed by
transport by man-in-the-middle attack IoT device endpoint and IoT gateway trusted certificate authority for
between the communications should validate the authenticity of authenticity validation.
endpoints. Transport security can connection endpoints with TLS digital
ensure the authenticity of certificate.  Each IoT device endpoint uses unique
communications endpoints. API token or unique TLS digital
 For IoT solution that requires higher certificate for authenticity validation.
security assurance of the authenticity of
each IoT device endpoint, the IoT
solution should validate the
authenticity of each IoT device
endpoint with unique API token or
unique TLS digital certificate signed by
trusted certificate authority.

20
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

4.2.5 Perception layer

The following best practices are applicable to perception layer.

Security Aspects Security Issues Best Practices Verification Checklists

4.2.5.1 Software  Since vulnerabilities may be exploited  All software / firmware / patch files  Users can validate the authenticity of
/ Firmware during the device lifecycle, firmware should be signed or provided with file the software / firmware / patch files
Security update is essential to address software checksum such that users can validate by verifying digital signature or file
issues and vulnerabilities. the authenticity of the files. checksum.

 Since attackers may inject malware into  The device should include software /  Users can update the device software
software / firmware / patch files, firmware update capability. / firmware with official software tools.
proper validation of legitimate software
/ firmware / patch files update would  The device should include security  Users can apply security patches
prevent against malware infection patch update capability. update to fix device vulnerabilities.
through tampered update files.
 The device should establish the root of  The device has hardware-validated
 Since attackers may reverse engineer trust of device integrity by hardware- boot process to allow booting from
the firmware to extract hardcoded validated boot process with signed or signed or encrypted software /
account credentials or passwords, it encrypted software / firmware / patch firmware / patch files only.
would pose serious security risk on IoT files.
devices if the hardcoded password is  Users are restricted from updating
disclosed publicly.  The device should only allow the unofficial or modified software /
installation of signed software / firmware to the device.
 Since users may often fail to change firmware / patch files.
default password during initial  The device manufacturer / developer
installation and setup, default password confirms that the factory default or

21
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

is likely to be used by attackers to gain  The factory default or factory reset factory reset admin password is
unauthorised access and control the admin password should be different for different for each device, with the
device. each device, with the default password default password for the device being
for the device being printed on the printed on the serial number label.
serial number label.
 User is mandated to change default
 The solution should enforce mandatory password at initial setup stage.
default password change at initial setup
stage.  The device manufacturer / developer
confirms no hardcoded manufacturer
 The device should not contain support password and account
hardcoded account credentials for any credentials.
manufacturer support purpose.

4.2.5.2 Physical  Since attackers may exploit  The device should disable unnecessary  No unnecessary physical external
Security vulnerabilities through external physical external interfaces or ports on interfaces or ports exist or being
interfaces or ports, disabling or limiting the device. enabled on the device.
the capabilities of physical external
interfaces or ports reduces the security  The device should restrict direct access  Users cannot gain administrative
risk of gaining device control locally. to administrative capabilities through capabilities through physical
physical interfaces or ports. interfaces or ports.
 Since anyone can easily gain system
control of the devices, debug interface  The device should disable unnecessary  Debug interfaces or ports are disabled
disabling or applying security restriction debug interfaces or ports. if they are not required.
on debug interfaces or ports reduces
the security risk of system compromise  If debug interfaces or ports are  If debug interfaces or ports are
due to physical intrusion. required, authentication or access required, authentication or access
control should be required to restrict control is required before granting

22
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

the access only for manufacturer access to system administrative
support purpose. capabilities.

 Users cannot gain administrative

capabilities through debug interfaces
or ports.

4.2.5.3 Data  Since IoT devices are more likely prone  Personal data, sensitive data and user  Personal data stored in the device
Security to physical tampering, proper credential data should be protected storage is protected with encryption
consideration and handling of data with encryption in device storage. (e.g. AES-256).
security of the device storage are
important.  Where the device hardware is capable  Neither personal data, sensitive data
of supporting asymmetric nor user credential data is stored in
 Since device storage can be physically cryptography, each device should have plain text in both internal and external
extracted with the provision of proper a unique asymmetric key-pair securely storage memory.
hardware tools, sensitive data has to be generated at manufacture, with the
encrypted at rest to ensure data private key secured within a Secure  The device manufacturer / developer
confidentiality. Element (if supported by the hardware), confirms a unique encryption key is
and a PKI digital certificate from the generated and stored within a Secure
 In addition to encryption of sensitive manufacturer’s PKI. Element (if supported by the
data, proper usage and protection of hardware) for each device.
encryption key are also often neglected,  For device hardware that does not
which may pose higher risk of sensitive support asymmetric cryptography, a  Users can perform data erasure on the
information disclosure. secret symmetric key unique per device device such that all personal data,
should be securely generated at sensitive data and user credential data
 Since devices may be recycled or re- manufacture, with the private key are erased.
used by other users, users should have secured within a Secure Element (if
control of performing data erasure supported by the hardware). The  User can perform factory reset such
when the device is no longer used or manufacturer should securely that all data and user configurations
being disposed. distribute the device symmetric key to are cleaned up.

23
 HKCERT IoT Security Best Practice Guidelines

Security Aspects Security Issues Best Practices Verification Checklists

its customer as for each device supplied
to that customer.

 The device should provide the

capability of erasing all personal data,
sensitive data and user credential data
when the device is no longer used by
users or being disposed.

 The device should clean up all data and

user configurations upon factory reset.

4.2.5.4 Device  IoT devices may counter different  The device should remain operating and  The device can function locally as
Availability operating conditions such as network locally functioning in case of loss of normal in case of loss of network
outage, power outage, etc. that may network connectivity. connectivity or absence of network
affect the device availability. connectivity.
 If the device requires network
 IoT devices should be able to recover connectivity to function, the device  If the device requires network
automatically and resume the normal should resume to an expected, connectivity to function, the device
operation state in the event of different operational and stable state after can resume to function normally after
operating conditions to avoid exposure resumption of network connectivity resumption of network connectivity
of security loopholes. automatically. automatically.

 The device should recover to the  The device can recover to normal
operating state in case of power operating state after power outage.
outage.

24
HKCERT IoT Security Best Practice Guidelines

5. Appendix: List of Reference Publications

Publisher Publication Name Release

Date
BSI and Navigating and Informing the IoT Standards Landscape - A Guide for 2019
PETRAS SMEs and Start-ups
https://www.bsigroup.com/en-GB/navigating-and-informing-the-iot-standards-landscape/
CSA IoT Security Controls Framework May 2019
https://cloudsecurityalliance.org/artifacts/iot-security-controls-framework/
CTIA CTIA Cybersecurity Certification Test Plan for IoT Devices version Oct 2018
1.0.1
https://api.ctia.org/wp-content/uploads/2018/10/CTIA-IoT-Cybersecurity-Certification-Test-Plan-
V1_0_1.pdf
DCMS Code of Practice for Consumer IoT Security Oct 2018
https://www.gov.uk/government/publications/code-of-practice-for-consumer-iot-security
DCMS Mapping of IoT Security Recommendations, Guidance and Oct 2018
Standards to the UK’s Code of Practice for Consumer IoT Security
https://www.gov.uk/government/publications/mapping-of-iot-security-recommendations-guidance-
and-standards
ENISA Baseline Security Recommendations for IoT in the context of Nov 2017
Critical Information Infrastructures
https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot
ENISA Good Practices for Security of Internet of Things in the context of Nov 2018
Smart Manufacturing
https://www.enisa.europa.eu/publications/good-practices-for-security-of-iot
ETSI Cyber Security for Consumer Internet of Things Feb 2019
https://www.etsi.org/deliver/etsi_ts/103600_103699/103645/01.01.01_60/ts_103645v010101p.pdf
GSMA GSMA IoT Security Assessment CLP.17 v3.0 Sep 2018
https://www.gsma.com/iot/iot-security-assessment/
IMDA Internet of Things (IoT) Cyber Security Guide Version 1 Jan 2019
https://www.imda.gov.sg/-/media/imda/files/regulation-licensing-and-
consultations/consultations/open-for-public-comments/consultation-for-iot-cyber-security-guide/imda-
iot-cyber-security-guide.pdf
IoTAA Internet of Things Security Guideline V1.2 Nov 2017
https://www.iot.org.au/wp/wp-content/uploads/2016/12/IoTAA-Security-Guideline-V1.2.pdf
IoTSF Secure Design – Best Practice Guides Release 1.2.1 Dec 2018
https://www.iotsecurityfoundation.org/wp-content/uploads/2019/03/Best-Practice-Guides-Release-
1.2.1.pdf
IoTSF Compliance Questionnaire Release-2.0 Dec 2018
https://www.iotsecurityfoundation.org/wp-content/uploads/2018/12/IoTSF-Compliance-
Questionnaire-Release-2.0-December-2018.xlsx
JPCERT IoT Security Check List Jun 2019
https://www.jpcert.or.jp/research/IoT-SecurityCheckList.html
NIST Consideration for Managing IoT Cybersecurity and Privacy Risks Jun 2019
https://doi.org/10.6028/NIST.IR.8228
NIST Interagency Report on the Status of International Cybersecurity Nov 2018
Standardization for the Internet of Things (IoT)
https://doi.org/10.6028/NIST.IR.8200
OWASP IoT Top 10 2018 2018
https://www.owasp.org/index.php/IoT_Security_Guidance
OWASP Mobile App Security Verification Standard 1.1.3 Jan 2019
https://mobile-security.gitbook.io/masvs/

25